This is a continuation of the discussion of 10 factors in evaluating enterprise architecture processes. This post will concentrate on Factor 2: Does the EA group have both functional and technical responsibilities and generate actionable outputs to both?
Looking back, I should probably have re-phrased the ending of this factor to read "generate actionable output to both IT and the business," and that's what I'll concentrate on in the discussion.
There are many definitions of enterprise architecture, and the majority of them give equal due to both the business and technical sides of the discipline. However, in practice, it is often skewed more toward the technical side. Todd Biskie's excellent posts and resulting comments on horizontal and vertical thinking provides a lot of depth on functional and technical issues in business and IT contexts.
I'm assuming here that there is an enterprise architecture group involved within organizations as opposed to a single person. Single-person architects are better than no architects, but in the majority of cases, that individual has more responsibilities than one can be reasonably expected to handle, and problems often develop when certain aspects of the job fall by the wayside because there is insufficient time or expertise to handle them.
The other major part of this factor is the generation of actionable outputs by the EA group. By 'actionable outputs,' I'm saying that all artifacts that an EA group generates must have value to others within IT and the business and be useful to these folks in carrying out their job responsibilities and/or decision-making.
Here are possible answers to this question and what they usually mean:
"Our EA group has primarily technical responsibilities and generates output to the IT organization, which may use the artifacts or not at their individual discretion." There are a number of problems in this response. First, it's clear that this group is doing more "solutions" or "software" architecture than enterprise architecture, because there is no indication that the group is working with the business. Next is that the work products the group delivers can be (and probably are) ignored if the work doesn't coincide with the worldview and perspective of the rest of the IT organization. Finally, there may be a major disconnect between the group and the rest of the IT organization where the architects specify and develop X, but the implementation and operation downstream implements and maintains Y. It is unclear in such instances what precise role the EA group has, but it's usually very clear that the current roles they do have don't produce much value.
"Our EA group supports the business and IT at a level of abstraction necessary to translate corporate strategy and initiatives into the current and future-state architecture. However, the business is having some issues with the artifacts that the group produces in terms of understanding and coverage of business issues and requirements." This is another fairly typical scenario, and usually can be remedied with adjustments to work products that make them more comprehensible to non-technical people. In Todd's horizontal-vertical scenarios, the coverage of business and IT issues here is fine, but the EA group may wish to concentrate their work products using the distinction Todd makes between architectural boundaries versus project boundaries.
Producing EA work products that are comprehensible to a wide range of business people can be a black art. The cliche' "know thy audience" is a key differentiator between artifacts and presentations that confuse and bore business stakeholders and ones that engage them fully. Another factor in the production of EA artifacts for the business is the altitude of the work product - higher-to-highest levels of abstraction for the business and non-IT stakeholders; and lower-level, "down in the weeds" levels with technical detail for IT, particularly development teams and project managers. I have found that in business contexts, a good approach is to cast EA in terms not only of business requirements, but also of the current (and if present, future-state) operating models of the business. Executives are interested how IT will support operational business models, but start checking Blackberrys or yawning if EA starts and continues a box-and-arrow session fresh from the architect's whiteboard.
The converse dilemma can happen with work products produced for IT, and the situations usually revolve around not enough detail, or too much. The former case usually invites derision from development teams calling EA an 'ivory tower;' or similar chafing from the feeling that development teams are being micro-managed by EA if the artifacts are too detailed and leave little room for day-to-day professional judgment by development staff.
I have found what works best with development organizations is that EA acts with authority on IT infrastructure, and as more of an advisor and coordinator at other technical levels - insuring that developed applications and other systems comply with architecural direction and standards, but not down to the level of dictating how & what code must be written and when. This involves communications to development teams that they can act on and account for. Depending on the organization, this can range from the formalism of UML models, use of architectural and design patterns, all the way down to informal whiteboard sessions if that's what works best. As long as the outputs are actionable, the form shouldn't matter much to those involved.
Coming soon is Factor 3: How is EA Specifically Funded?
Comments