.comment-link {margin-left:.6em;}

Saturday, March 04, 2006

 

The Keys to Good Enterprise Architecture

I'm often asked what makes a good architect (enterprise, system, application, etc.) over other business and IT roles in an organization such as business analyst or developers. The key attribute an enterprise architect has is what I'll call balanced abstractionism.

As I mentioned previously
, an enterprise architect's primary function is to look at both the business and IT (development in particular) in the abstract, a level or two or three away from the 'action' to ensure the following:

  1. The organization gets its process needs objectively met through information technology
  2. The resulting technical solutions are efficient, reliable, secure, cost-effective, and agile
  3. Specific segments of the business-technology interface in a given organization, while using commonly available technologies, represent a core competency or value-add unique to the organization that provides competitive and profitable differentiation from rivals.

The hue and cry of certain parts of the business (and other IT pundits at times) is that all enterprise architecture produces is nifty-looking diagrams in geek-speak that don't deliver much value to the business. On the other hand, development teams resent EA being an 'ivory-tower' operation dictating standards and guidelines from on-high with no appreciation of development issues and goals.

Each camp wants EA to focus on their issues, usually exclusively. Both camps miss the point because EA is properly practiced with a balance of abstraction of and between both sides.

Why are we the middleman in all this, and why can't we (as an organization) remove an expensive cost-center from the mix and use the money not spent on EA for something else?

The answer is the same for both sides of the two camps: it's too easy to get bogged down in details on either side and partially or completely miss various opportunities to improve business processes or systems under development (or the aggregation of them) because our noses are at the grindstones of business/systems analysis, development, or project management exclusively. It skews perspectives so much that on one hand, business processes cannot be optimized, nor can systems or infrastructure because we're too close to the root issues of the matter to see what can and will go awry.

That's partially what thinking in abstract terms is about. Take SOA as an example - are we thinking about what types of loosely-coupled services we are going to offer the business, or are we thinking about how precisely they will be implemented down to the actual code? Actually, we are thinking about both, but at a level or two above what the groups responsible for more-specific definition and execution are thinking. This is a check-and-balance activity that yields great benefits to the business in terms of agility and response to business, cost/time-to-market, and technical issues.

Finally (for now) there is the issue of producing artifacts for these abstractions. As with the balance of abstration necessary between technology and business, enterprise architects must communicate the architecture(s), rationale, and benefits to a broad audience in terms that the specific audience understands. Too many architects rely on a single artifact (or tightly-coupled set of them) to address multiple constituencies. The usual result is that the works are too dry and technical for the business; and not detailed or nuanced enough for IT.

Before I get to a guideline list of artifacts useful for various constituancies that architects routinely encounter, allow me to point out that documentation should be, as Aglists put it 'good enough' to communicate what needs to be said, and nothing further. Striving for perfection in documents costs too much time for the little additional value added, and if you produce an artifact that nobody reads (or will read) except you, I would revisit the decision to produce that work.

Here's a sample of artifacts from various abstractions that could be produced:

  1. The Business: Non-technical overview of the architecture with partcular emphasis on business initiative/process support, agility to meet changing demands, and efficiency both in time-to-market and costs.
  2. Developers and Other Technical IT Folks: Technically oriented functional overview of the architecture with the understanding that you are describing "working softwares" with emphasis on the plural rather than singular. Individual project architectures and designs are part of the development team activities with EA support and input. Take great care to describe how all of this - applications and infrastructure - work together. Discussion of any singular project or system generally produces 'silo' thinking and discussion, which should be avoided.
  3. Senior IT Management and Project Management/PMO: A combination of (1) and (2) above as necessary plus preliminary estimates of cost, time-to-market (design, develop, test, deploy) and resources necessary to execute.
Note that I don't specifically mention design technologies here like UML, MDA, RUP, and others. Use what you know and feel comfortable with. The tools aren't as important as the intent, communication, and results.


Comments:
The main problem with your suggestion is in producing artifacts for the business. Some may refer to this as "Business Architecture" yet most folks don't know what it would contain or even look like.

If in a future blog entry you could point to publicly available examples you feel are of high quality then this may be a start...
 
Post a Comment



<< Home
Technology Blog Top Sites |

This page is powered by Blogger. Isn't yours?

Weblog Commenting and Trackback by HaloScan.com