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

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

Share this post

Michael Rosen

Michael Rosen

Michael is Director of Cutter Consortium’s Enterprise Architecture Practice and Senior Consultant with its Business-IT Strategies Practice. He has more than 20 years of technical leadership experience architecting, designing, and developing software products and applications. Throughout his career, Michael has been a frequent technical speaker and author. He has presented keynotes, tutorials and seminars at conferences in the US, Europe and Asia and has articles in publications including Web Services Journal, EAI Journal, Software Magazine and Enterprise Development. He is coauthor of the book Developing E-Business Systems and Architectures: A Manager's Guide and Integrating CORBA and COM Applications, which grew out of his contributions to the OMG COM/CORBA interworking specification. He can be reached at

scroll to top
We use technologies such as cookies to understand how you use our site and to provide a better user experience. This includes personalizing content, using analytics and improving site operations. We may share your information about your use of our site with third parties in accordance with our Privacy Policy. You can change your cookie settings as described here at any time, but parts of our site may not function correctly without them. By continuing to use our site, you agree that we can save cookies on your device, unless you have disabled cookies.
I Accept