Thursday, December 16, 2010

Thoughts on Solving the Federal Debt Issue

There is a straightforward, though culturally and politically difficult, way to reduce the US Federal debt.  It is through the proper application of process Enterprise Architecture as applied to the Federal Enterprise Architecture Framework (and embodied in DoDAF 2.0).  This is what the Clinger Cohn Act envisioned; but what hasn't panned out, so far.

Using Enterprise Architecture would spotlight where organization's have gone beyond their charter; sometimes well beyond, bureaucrat's that are spending on private agenda's, and many types of waste making the departments costly, ineffective or both.

There are two keys to effective use of Enterprise Architecture in this setting.  The first is in integrating Enterprise Architecture into the business processes of the organizations such that they have the power to more optimize the organizations processes and systems to meet their mission and/or charter.  Technically, this is relatively straightforward, and should be simple, except for the second key.  That key is to change the department, agency, or bureau's culture and the power of management to enable them to spend on private agendas, while having it seem to be part of the charter.  This is the hard part because of the threat to the power of the mid-level managers.

A second problem is getting the Enterprise Architecture with its associated Asset and Enterprise Architecture Repository set up and running.  More on this in a future post, "Using Enterprise Architecture to Reduce the Federal Debt".

2 comments:

  1. We have similar ideas here. I've labeled mine as "terminology management" due to the conceptual overload on the term "enterprise architecture".

    Terminology is a building-block of communication. From a terminology perspective, EA is a subset of architecture, which is another name for a knowledge base. An architecture is built from an architecture metamodel, just as a knowledge-base is built from an ontology.

    An ontology is an advanced form of concept model. A concept model consists of one or more assertions (i.e., triple, noun-verb-noun combination) in a set.

    Other concept models, simpler than ontologies, are flow models, process models, activity models, product models, activity-based-cost (i.e., budget) models, data models, object-role models, knowledge models and their knowledge-bases, and architecture metamodels and their architectures.

    Another type of concept model, more complex than an ontology, is an axiology (value-chain metamodel) and its value-chains (which can be decomposed into interal LEAN value-streams and then deeper into Six Sigma activity models).

    From the above concept models, common in management and technology work, but called by different names, using different standards, and different tools, with different underlying data structures, you would build controlled vocabularies - taxonomy and thesaurus - for a give subject. The subject I'm focusing on is "endeavor management", to enable effective, efficient, rapid, and accurate communication based on clear meaning (via the taxonomy) and consistent terms (via the thesaurus).

    ReplyDelete
  2. An additional point.

    If you consider that "enterprise" is a verb, and is the activity of an organization and all of its value-chains (which I call a value-lattice), then an enterprise is a value-chain built from an axiology. An Enterprise Architecture is thus the representation of all of the parts of the value-chain (including the organization at its center, as in IDEF), their relationships to each other, and the attributes of those parts and relationships. The parts are arrayed in a taxonomy, the relationships in concept models, and the attributes in details of the concept models. The EA metamodel is the axiology.

    So how does one turn this into a "mechanism" or tool that the average worker, supervisor, manager, leader/executive, board member/legislator, owner/citizen can use without advanced knowledge?

    ReplyDelete