Initially implmenting an Asset and Enterprise Architecture Process and an AEAR

As discussed in a previous post, one key problem with using Enterprise Architecture is initially implementing the process and the AEAR.  Most US Federal government departments, bureaus, and agencies have enterprise architects and a Chief Architect because of the Clinger Cohn Act, mandating that they have them.  Most of the agency and department Chief Architects understand the role of an Enterprise Architect, as I've described in this blog, and yet they are singularly ineffective for two reasons.  First, as I've discussed in several previous posts (see those labeled Enterprise Architecture), operating with an enterprise architecture process and repository is a organizational cultural paradigm shift.  It requires a champion at the highest level leadership Dr. Michael Hammer repeatedly made this point in his writing on Business Process Reengineering--BPR.  However, even with a champion and adequate resources, an Enterprise Architect's role as the key advisor on process, tooling, and IT investment--as least the equal of the CFO (a radical idea in itself)--will fail, unless three other challenges are understood and met.  The results of the first iteration will always be poor--unless the Enterprise Architect lucks out, Big Time.  Critics of the enterprise architecture process will attempt to denigrate it, using the first results of the first iteration.  There are at least three reasons for poor results that have nothing to do with the design of the process; the learning, minimum data available, and poorly defined metrics.

The Learning Curve

Simple unfamiliarity of the process complexity of the process and organization cultural/political resistance to any change, let alone one that changes the balance of influence within the organization all mitigate against good results in the first iteration. 

The causes and affects of the learning curve are well known and documented.  In one study Robert L. Corman and I showed that it took 6 months after new technology and process insertion for the routine tasks of a work processing center to really improve--but boy, once they did, they really did (see http://portal.acm.org/citation.cfm?id=800079.802565 for the complete PDF.)  Since word processing is a relatively simple process (or set of processes) rather than a completely new process and since the word process center had been established well before the technology insertion we documented, and since we encountered a significant learning curve with that, I suspect and have evidence that indicates that there will be a very significant learning curve for the Enterprise Architecture process.

The understanding that change creates resistence is also well known.  For example, many mid-level managers and not a few well placed Subject Matter Experts (SMEs) use the tactic of passive agression, that is, "I'll do it when I get around-to-it"; then never can a "round-to-it" anywhere in the office.  So they just "Yes it to death."

Minimum Data in the AEAR

The second reason for poor results in the first cycle through an enterprise architecture process is, that if it's executed at the proper time.  Frequently, inexperienced (and even experienced) Enterprise Architects attempt to collect all of the data required for an enterprise architecture before starting the process.  For any medium or large organization, say over 1000 employees, this is an exercise in futiliy because by the time "all of the data" has been collected, its out of date.  So if an Enterprise attempts to collect complete and correct data for the organization, he or she will never finish.

If the initial Enterprise Architecture process cycle is properly timed and executed the data in the Asset and Enterprise Architecture Repository (AEAR) will contain less than 10% of the data that a complete AEAR would need.  However, the Enterprise Architect will define the data required to create the Enterprise Architecture for a small sub-organization of the organization and start from there, then there is a good opportunity to "pilot" the process and repository for that small portion.  Then the Enterprise Architect can grow the data store in the AEAR through time. 

Or the Enterprise Architect can start with inserting "as-built" data from all current programs and projects of the organization, without reference to the current "as-is" architecture.  This is not as silly as it may sound, since, most large organization refresh, update, or upgrade most of their IT systems every 3 to 5 years; in the past creating an AEAR for a large organization may take that much time by itself.  Consequently, gathering data from current proejcts to build the AEAR takes the same time as simply attempting to construction a "complete" set of data for an AEAR.  However, the data that in the AEAR from programs and projects can be much more useful than data gathered simply to create an AEAR because its from the areas the organization's management and leadership is focused on transforming and will provide up to date data in those areas.  This enables the complete Enterprise Processes of Mission Alignment and Governance and policy management to be piloted early on projects management feels are "the right" areas of focus.  The Enterprise Architect can then adjust and refine the processes as he or she creates the AEAR and the organizational culture in which Enterprise Architecture has a key support role in investment decision-making.

Poorly Defined Metrics for the Functions and Linkages

Frequently, the metrics for the process, for the functions, and for the linkages employed by an organization, don't measure what the management intended them to measure or are simply missing.  This includes financial metrics that are either missing or don't measure what management intends them to measure.  Finally, there are metrics that measure what they are intended to measure, but either are measuring the wrong things (things that are counter to the vision, mission, and strategies of the organization) or don't measure all of the consequences of leadership and management decisions.

As organizations grow in complexity, the consequences of poorly defined metrics can beinsidiously devastating--much like putting frogs in a pot of cold water, then turning up the heat until the water boils, these organizations never knew what is hitting them.  This is one key reason to implement an AEAR. 

It is in the interest of the organization for the Enterprise Architect to start the AEAR by basing the functional and linkage metrics on the current metrics of the organization for three reasons.  First, it lends a feeling of continuity.  The leadership and management see the data they are expecting; though the Enterprise Architect should expect to suppliment the current metrics with additions for those functions and, in particular, links, without current metrics.  Second, using the current metrics provides an immediate baseline of data for those metrics that do not need immediate revision--yes, there will always be some good metrics.  Third, inserting the current metrics into an architectural structure, especially if linked to good visualization tools, will allow the leadership and management to "see" at least some of the poor metrics--poor from the standpoint that they do not measure what they are supposed to measure.

Summary

Never expect or promise much for the first iteration.  Remember the Law of Superiority: "The first example of a superior principle is always inferior to the developed example of a inferior principle."  Always expect the start working with a very partial repository; it's the only way to get the Enterprise Architecture process and AEAR operating.  Start with a reasonable scope paying particular attention to sizing and use as many of the organization'a current metrics as possible.  Remember that for all but the simplest systems, the initial set of metrics will never measure what they are expected to measure.  Finally, be sure to educate the organization's leadership on these before you start.