Continuing my discussion of 10 factors to consider when evaluating how effective enterprise architecture is within organizations. This post focuses on how enterprise architecture work products (also called artifacts or outputs) are received and utilized within the business and IT.
Enterprise architects serve multiple constituencies in both the business and technical sides of the organization. This makes the tasks of communicating architecture, strategy, plans, ideas, etc. with various groups a complex task. As with any other function in the organization, what is produced and communicated by EAs must be actionable by those receiving work products - whether it be models, presentations, specifications, etc.
There are certain assumptions made when evaluating how well EA's and their work products convey actionable information:
- What is being said, specified, designed, etc. is far more important than how the work is accomplished. Thus, noted objects of angst such as Powerpoint, modeling toolsets, and other EA "appliances" don't matter as much as content and abstraction.
- The enterprise architect activities are performed by a group, and not a single individual.
- The EA's are actually performing EA, not straightforward business analysis, or software development, or IT operations.
Another issue of interest when evaluating EA work products is the knowledge base across the EA group. Very few, if any of us, practiced EA our entire careers. We grew into the role from the business and/or technical ends, and became proficient in areas we hadn't had much exposure to in the past. It isn't realistic that individual enterprise architects are experts in every possible topic (including technical) that concerns IT and business. A lot of us specialize in certain technologies, and in specific industries. My point here is that a good-to-excellent EA group contains people originally from both sides of the house, and the locus of their interactions as a group produces quality EA work products.
Now comes the difficult part: how to evaluate EA work products. The key issues here are: a) proper level of abstraction such that the work drives, in whole or in part, action by recipients; and b) comprehension and acceptance by the recipients of the work product.
Let's take work product abstraction first. This represents a thorny problem for many EAs' because of the diverse nature of the constituancies being served. If a work product is overly technical and detailed, the business-types will be checking watches and Blackberry's in short order. The opposite is true when dealing with IT and developers. Finding the proper level of abstraction is key, and admittedly hard to do, at least at first.
The best explanation I've run across describing abstractions, albeit in the realm of business intelligence and data warehousing, is Malcolm Chisholm's article "The Twin Towers of BI Babel" in the December, 2007 issue of DMReview (registration required). Malcolm describes architectural abstraction issues in terms of the "Abstraction-Translation paradigm" as follows:
"[the Abstraction-Translation Paradigm] visualizes the processes by which applications are created as passing through successive layers of abstraction and translation that ultimately enables business information to be stored as binary representation of facts in implemented databases. This data can then be moved into data marts for use in BI applications. However, it is still a binary representation of facts. To be used, it has to be transformed and translated through the same layers required in the creation of the operational application that produced it. Finally, it emerges back at the business level as information again."
In a great graphic accompanying the article, Malcolm divides abstractions into the following categories (from business side down to technical):
While the middle layers (logical and physical) primarily apply to data-related and database systems, the point here is that EA groups should have similar levels of abstraction for work products. Some are targeted to business, others to IT management, and others to developers, their team leads, and IT operations folks. This type of delineation assists EAs' in producing work product that is absorbed and acted on, in the proper context. The business gets information they need to make decisions and approve and fund work. The IT side gets the specs and other direction necessary to built architecturally-compliant systems. The architects get their points across and contribute to the organization as originally intended. So, a key indicator in this factor is recognition and use of proper levels of abstraction.
A further indicator regarding proper abstraction is the diversity of work products across the spectrum given above. This is situational in most instances. However, if there is a large quantity of work products addressing some of the categories above, and very little in others, it would indicate that something is amiss in the relationship between EA and the constituencies that could utilize such work.
Another key indicator is comprehension and acceptance of EA work products by constituents. We've all seen or heard about "ivory tower" EA and box-and-arrow presentations that have the room full of business folks snoozing or checking watches and Blackberrys within 5 minutes. These scenarios represent the default "get help and refactor EA now, or shut it down" condition.
Determining comprehension and acceptance of EA work products is straightforward: always solicit candid feedback from recipients and constituents about the quality of the work. Did they understand what they were examining? Did they agree with the results of the work? Did it enable them to make better-informed decisions and designs? What, if anything, could be improved? The relationship between EA and constituents is a two-way street, and EA groups should not be afraid to solicit feedback in order to improve work products, including their delivery and use by others. Use of surveys or comment forms are handy in this regard to do the measuring of this indicator, and they aren't difficult to produce or have produced for the group.
Gauging this factor reveals a lot about how an EA group functions and how their work is viewed. If I could only pick 1 or 2 factors to evaluate out of the 10 that I proposed, this would be one of them.
The next post in this series is Factor 5: How skewed are EA efforts toward specific vendors and/or integrators?