Summary
Is it valuable for an enterprise to adopt a <i>Reference Architecture</i>? If so, how should that RA be used?

Recently I was consulting for a firm that stressed their adoption of a Reference Architecture. The RA was not an uncommon one. It was based on Webshphere and EJB, and made use of a number of proxies and shunts to connect their web servers to a DB2 back-end.

In my talks with them I pointed out that I prefer to allow new applications to grow into the reference architecture rather than just assume that it will be used. I told them that I wouldn't start out using a database, or EJB. I'd start out doing the simplest thing I could and, over time, let the growing application force me into adopting architecture elements. If I got the application finished before I had to adopt the entire architecture, then that would be a good thing.

Some of the architechts were, shall we say, aghast. They made some good points. One of the best was that if you have a reference architecture that everyone follows, then all programmers will be able to understand every application. At least there would be common structures that they could follow.

While I accept this as valuable, I reject the notion that a reference architecture should be followed by default. I think a reference architecture must be tested and proven for each new use that it is put to. And I think the best way to accomplish that testing and proving is for each new application to be allowed to evolve from very simple beginnings. If those new applications start requiring architecture elements, then the developers have the choice of using the existing RA, or of using something different.

Clearly using a different architecture is risky. No development team would undertake it unless they were strongly motivated. Yet if such motivation exists, and if the developers find a better solution, then the enterprise will benefit from the new knowledge. However, if all application must adopt the RA from the outset, then the opportunity for this benefit is squelched.

My experience is that RAs are big and cumbersome impediments to simple development. Instead of writing one or two classes to get a job done, one must write one or two dozen, spanning different groups, different disciplines, and different languages. One must adopt tools and infrastructures that have long learning curves, and that make automated unit and acceptance testing difficult if not downright impractical.

My advice to the industry is to allow reference architectures to constantly evolve, and allow them to be challenged and tested with every new application and every new change.

Talk Back!

Have an opinion? Readers have already posted 20 comments about this weblog entry. Why not add yours?

RSS Feed

If you'd like to be notified whenever Robert C. Martin adds a new entry to his weblog, subscribe to his RSS feed.

Digg | del.icio.us | Reddit

About the Blogger

Robert C. Martin (Uncle Bob) has been a software professional since 1970 and an international software consultant since 1990. He is founder and president of Object Mentor Inc., a team of experienced consultants who mentor their clients worldwide in the fields of C++, Java, OO, Patterns, UML, Agile Methodologies, and Extreme Programming. In 1995 Robert authored the best-selling book: Designing Object Oriented C++ Applications using the Booch Method, published by Prentice Hall. From 1996 to 1999 he was the editor-in-chief of the C++ Report. In 1997 he was chief editor of the book: Pattern Languages of Program Design 3, published by Addison Wesley. In 1999 he was the editor of "More C++ Gems" published by Cambridge Press. He is co-author, with James Newkirk, of "XP in Practice", Addision Wesley, 2001. In 2002 he wrote the long awaited "Agile Software Development: Principles, Patterns, and Practices", Prentice Hall, 2002. He has published many dozens of articles in various trade journals, and is a regular speaker at international conferences and trade shows.