Todd Biske: Outside the Box

James McGovern called out that he hasn’t seen much discussion on the topic of reference architectures, and called me out for my thoughts. I’m never one to pass up a good blog topic, especially when I don’t have to come up with on my own.

First, some background on my experience. My current job responsibilities include the development of reference architectures, my engagements with clients while I was a consultant all included the development of either a deliverable that included “reference architecture” in the title, or was clearly some form of reference material, and my job prior to consulting, included the development of reference architectures within the last 12 months of my time there. So, I’m no stranger to this space.

Reference architectures, and reference materials (since the need doesn’t stop at architecture) in general are an interesting beast. Personally, I view them as part of the overall governance process, mainly because they’re created to document a desirable pattern or approach that the authors would like (or will ensure that) others follow. At the same time, a document alone does not create governance, just as buying an SOA Registry/Repository doesn’t create SOA governance. Reference materials are a tool in the arsenal and the degree to which they are used is dependent on how you architects work with the end consumer of the reference material. Organizations are all over the spectrum on this. Some architects live in an ivory tower with virtually no interaction with teams on active projects, some architects are the exact opposite, with their time completely consumed by day-to-day project activities. Most organizations fall somewhere in between.

My opinion is that reference material is absolutely necessary, if nothing else but to prevent the organization from tribal operations. If none of the standards and guidelines ever get written down, and decisions are solely based on tribal knowlege, the organization can quickly break down into the haves and the have-nots. If you’re part of the tribe, you have the knowledge. If you’re not, all you can do is make your best guess until you have to show up to tribal council and get lambasted. Trying to gain the knowledge from the outside is a very difficult process.

The next question, however, is what information belongs in the reference material? Does it do any good to document something in the reference architecture that everyone should already know, or should you assume that no one knows anything, and document it all? The problem is that EA has limited resources, just like everyone else, so you have to give consideration to the bang for the buck in the reference material. Once again, what’s “right” is very dependent on the end consumer of the material (which is why having a consumer focus is important). If you have an organization of seasoned Java programmers, how much reference material is needed on developing good web applications? If you have an organization with lots of VB6 and COBOL developers, they may need lots of reference material on web applications. So, know your audience, and make sure that the reference material is relevant and valuable for them.