Death by Architecture

Please note: This articles is being published in cooperation with the Enterprise Architecture Conference Europe hosted by IRM UK on June 8-10 in London UK.  For
more information please visit this site or
click through their banner on the left side of the main page. 

I recently received a large architecture document to review. After poring through a few hundred pages of text and drawings, I was impressed by how much work and thought had gone into it yet how
utterly useless it was. Now, don’t get me wrong: it’s not that architecture is unimportant; quite the opposite. The classic, big architecture document is just the wrong way to deliver it. I had
hoped that the industry had gotten past these kinds of deliverables; apparently I was wrong.

Perhaps nothing is more drawn out and aggravating for an IT organization than what I call “death by architecture.” The story goes like this: the high priests and architects depart for the ivory
tower and return some months or years later with “The Revealed Truth,” in the form of 1,000 pages of architecture documents. In the meantime, new applications have been developed, requirements
have changed, and the architecture is out of date on delivery. Other reasons may also contribute to its being DOA: It may be irrelevant to the development organization or might not have enough
buy-in to be accepted. It may be hard to understand its value or how it achieves business goals, or dozens of other reasons.

Obviously, I believe in the value and importance of architecture, but don’t confuse good architecture with ivory tower architecture projects. There are right ways and wrong ways to do everything,
and IT architecture has more than its share of wrong ways. Architecture is hard to do well. Even good architectures sometimes fail because IT does not have the will to implement the associated
organizational changes required to make it work. Other common reasons are poor project management, changes in leadership or sponsorship, or a shift in priorities. Sometimes, the architecture group
itself is to blame. And there is no doubt that it is a primary responsibility of the chief architect to avoid death by architecture. Here are some suggestions:

• Quickly create an architectural vision and strategy. It should take about two months to develop this high-level architecture. Use this to prioritize and
  guide the implementation of the architecture.

• Pick an appropriate project to start implementing the first pieces of architecture. Choose one that is important enough to get noticed but not so critical
  that outside pressures will make it impossible to do the right things.

• Implement a small portion of the technical and application architecture as part of a project that is delivering real business value to the organization. Use
  your architectural vision to help pick areas that demonstrate architectural values such as consistency and flexibility. Services and frameworks are often good candidates. Continue to
  incrementally implement more of the architecture as part of subsequent projects.

• Use the project to build out the business and information architecture. Make sure that they are used to guide the project design and implementation.

• After every project, integrate the lessons learned into the next iteration of the architecture. Keep it current. Constantly solicit feedback from
  development. Get buy-in by demonstrating that architecture makes the job easier.

• Implement, collect, and report metrics to prove the value in terms of cost, time, and quality.

• Know the difference between great and good enough. It will never be perfect. Good enough delivered on time beats late but great every time.

• Don’t try a big-bang approach. It never works.

Don’t give up on the idea of architecture, even if your experience with architecture in the past has been painful. There are many very successful architecture projects and they are a joy to
behold – from a technology perspective, from how they enable and transform the business, and from how they have changed the organization’s behavior and perception of architecture. The world’s
most successful applications are based on solid architectures and so should yours. But please, don’t send any big, fat, documents to review.

I welcome your comments and encourage you to send your insights on enterprise architecture to me at mrosen@cutter.com.

This article originally appeared in the Enterprise Architecture E-Mail Advisor series. Copyright 2009 by Cutter Consortium. All rights reserved.