Mike Rosen from Cutter wrote a great post called "Death by Architecture" on the Cutter Blogs the other day that discusses pitfalls of architecture. His article mostly refers to how bloated architecture documentation has gotten over the years. Rosen asserts that this is a big problem.
Frankly, I couldn't agree more. I discuss these types of issues here on my blog and on the Microsoft Enterprise Architecture Center. Specifically I wrote an article that I think aligns very well with Rosen's thinking on a Pragmatic Approach to Describing Solution Architectures. In the article I discuss these problems in length and provide some technical solutions to the problem. This solves only one part of the problem, the rest is social engineering.
Coming back to the Death by Architecture post, I think overall the post is great especially the topics around how architecture has become bloated but there is a lot of aspects of the post that I believe have been talked a great deal about. Notions of "Ivory Tower Architects" and "Big Bang Approaches" are well accepted pitfalls of EA.
In an effort to fully qualify these statements, I am taking a generalized approach here. Documentation is sometimes a necessary evil. I say this because, coming out of an industry like financial services there are regulatory pressures to produce more documentation. This is sometimes a good thing to mitigate risk and provide the ability to have rapid response to complex mission critical solutions. In all of these cases I don't think the information is necessarily bad it's making the information useful in the future and doesn't start to decay in the information grave yard. There are definitely process, skills, and technical improvements that need to be done here. I talk about this in the Pragmatic Approach to Describing Solution Architectures as well.
To comment on a few items in his post:
Rosen: 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.I agree with this but be careful. This really depends on the scope of what you are architecting. I believe the duration aspects applies to how substantial the architecture works are. As an example, you wouldn't want to tell your business unit that it will take 2 months to come back with a design for a small LOB application with 10 users. However this would be perfectly acceptable for a mission critical system such as the corporate CRM system.
Rosen: 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.This is a great one! I couldn't stress any more on getting the quick incremental wins. Deliver quality rapid bite size nuggets of good solution architectures and they will be hungry for more. They may even install the architecture buffet line.
Rosen: 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.I agree with the practice of collecting lessons learned is critical for almost every thing you do but I think there is something significant missing here. I will talk about this in a future post but I will give a high level overview here because I think it makes sense. One of the greatest challenges with architecture models and documents is they only tell you the "what" and sometimes the "how". Often times they do not describe they "Why" question. I would assert that this is the most important of them all. So, through the architecture description process you want to itierativly capture the architecturally significant decisions as you work through your descriptions. This should capture the trade-off analysis that you as the architect went through to deicide whether this solution should as an example go to a 3 tier DMZ or just a single limited protected tier. It will also help with traceability to business architecture and as a result of the process provide something that has missing for awhile in architecture, accountability on all sides of the process. We can get accountability because we can enforce approvals of these architecture decisions by not only the architect but all others involved in aiding in the decision such as the VP's, Directors of development areas, Business Analysts, Business Solution Owners, etc.
Rosen: Implement, collect, and report metrics to prove the value in terms of cost, time, and quality.Ideally, you should define metrics that are generic across all architecture initiatives to ensure you can baseline the metrics and correlate them to show measurable results. This maybe what Rosen is referring to here. But if not, you have my thoughts.
Rosen: Know the difference between great and good enough. It will never be perfect. Good enough delivered on time beats late but great every time.This is another gem. Knowing when to quit is definitely a skill. It is easy to loose focus. I call this "over architecting". No solution is perfect and architects should keep that in mind when building solutions. But, you do need to keep all the critical quality attributes of the architecture in mind when you are building and make sure you fulfill those. Also, your work isn't done by saying that this architecture is "good enough". You still need to define the road map for the architecture, create a risk mitigation plan (if needed) and lessons learned. Like I said earlier, Rosen brought up some great points and provided valuable insights for architects. Check out his full article here: http://blog.cutter.com/2009/03/19/death-by-architecture/
Technorati Tags: Enterprise Architecture, Architecture, Documentation, Process
