19 March 2009- 11:05 AM

Death By Architecture

by Mike Rosen, Director, Cutter Consortium Business & Enterprise Architecture Practice

I told the story, recently, about a large architecture document I received to review. It’s a story that I think is worth retelling …

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.

Comments [10] Trackback Permalink Category: Enterprise Architecture, Featured Tags: architecture, Enterprise Architecture

Comments and Trackbacks

1. [...] The Cutter Blog » Blog Archive » Death By Architecture 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. (tags: Architecture agile_development enterprise_architecture) [...]

   Structured Methods › links for 2009-04-08 On April 8th, 2009 at 2:03 pm

2. Hi Mike, Great article! I had put together a post that builds on your ideas here. Would love your thoughts.

   http://www.mikethearchitect.com/2009/04/death-by-architecture.html

   Regards,
   Mike Walker
   http://www.MikeTheArchitect.com
   http://msdn.microsoft.com/architecture/EA

   Mike Walker On April 8th, 2009 at 2:50 pm

3. Mike,

   Thanks for the comments and great write-up.

   And, the very good suggestion about keeping track of architectural decisions as part of the process of building and keeping architecture current.

   Mike Rosen

   Mike Rosen On April 8th, 2009 at 4:07 pm

4. Hi Mike,

   Great article! I have a few comments about some of your points.

   “Don’t confuse good architecture with ivory tower architecture projects”

   Completely agree. I have seen first hand the effect of having an Architecture division too far removed from the day-to-day business of software implementation. The result is too often that the edicts received are overthought in the wrong areas and unworkable in others. Architecture becomes something you work around to get your job done, not something which facilitates better solutions.

   “The world’s most successful applications are based on solid architectures and so should yours.”

   I’d tend to agree with that, but not what I believe to be the implied corollary: “solid architectures are the result of careful planning”

   Take wikipedia for example. I’d argue that this is one of the world’s most successful applications, and that it has a solid architecture. However, the story of how the MediaWiki architecture came to be is one of collaborative open-source innovation and a constant reappraisal of what works.

   Now, of course I’m not trying to say that the steps laid out in this article are not effective ways to build successful software architectures, just that they are not the /only/ ways to get things done and done right.

   “Good enough delivered on time beats late but great every time.”

   100% agree – couldn’t have said it better myself.

   Jim R. Wilson On April 13th, 2009 at 11:02 am

5. Excellent post, Mike. I actually am jealous that I didn’t use “Death by Architecture” as the tagline for two case studies in my book. I went with “Spaghetti Architecture” but like yours more.

   In any event, I’d only add that there are certainly absolutes with respect to architecture. However, I’d argue that even a moderately complex setup is bound to fail if the organization does not have sufficient human bandwidth to support it. I know of one organization that has customized its ERP so much that it actually calls the vendor to tell them which line of code to change for future patches. Of course, that organization has ten FT employees supporting the application. Obviously, this is fundamentally different than a small IT staff supporting a ‘vanilla’ installation of an enterprise system.

   Phil Simon On April 16th, 2009 at 8:02 am

6. [...] Enterprise Systems, Systems Implementation, Why New Systems Fail by Phil Simon on April 16, 2009 Mike Rosen’s recent post got me [...]

   Death by Architecture « Phil Simon’s Systems Blog On April 16th, 2009 at 8:14 am

7. In response to Jim…thanks for the comments. I didn’t mean to imply that solid architectures are only the result of good planning. Wikipedia is a great example, and I’m sure we can both think of examples of crappy, but carefully planned architectures as well.

   Solid architectures are the result of adherence to solid architectural principles. It helps to have a vision in mind, too. How you get there is probably some combination of luck, plan, agility, and opportunity.

   Mike Rosen On April 17th, 2009 at 11:44 am

8. Hi Mike,Well said and I completely agree but i can;t stop myself asking to review my design …I would like to share my ppt designed for a contest which is closed now and there is no way to get feedback for my submission.I greatly appreciate if you could have a glance and put your valuable comments for my ppt.
   Pls find it here – http://cid-410e76c6390c7090.skydrive.live.com/embedrowdetail.aspx/Public/India%20Election%20Pedia%201.0%20-%20Mahesh.pptx
   Thanks,
   MAhesh,IN

   “Implement, collect, and report metrics to prove the value in terms of Cost, Time, and Quality.” – Really these 3 facts decides the project success & profit.

   Mahesh On April 27th, 2009 at 1:35 pm

9. [...] on 16. Apr, 2009 Categories: Consulting, IT infrastructure Mike Rosen’s recent Cutter.com post on poorly conceived projects got me [...]

   Death by Architecture | philsimonsystems.com On October 28th, 2009 at 8:11 pm

10. [...] his part, Mike Rosen of Cutter has written extensively about how many organizations’ efforts to implement new technologies [...]

    Information Development » Blog Archive » 8 Rules for Managing Complexity On June 13th, 2010 at 6:04 pm

Post a Comment (or leave a trackback)