Chief Architect

I have posted a link to Serge Thorn's excellent enterprise architecture discussion group in the Enterprise Architecture Resources.  The following toics are a snapshot of the type of content typically discussed:

• EA and MBA
• Training opportunities in India
• Building an EA Practice from scratch
• Where should the Enterprise Architect's focus?
• Government Interoperability Framework (GIF) and National Enterprise Architecture (NEA)
• Location of the architect in the organization
• The Big Eleplant of Enterprise Architecture 

There is also a good list of enterprise architecture blogs on the site which are well worth browsing.

An important tool in developing business architecture is a business domain reference model.  They typically provide a standard business language and are used to provide context and standards for systems integration within that domain.  These solutions may be between organizations or within organizations.  This systems integration bias can be a blessing in that it ensures rigor.  They may provide a kick start in identifying business services that must be the foundation of a successful SOA strategy.  It also mean that the model may be skewed towards the particular integration issues that have historically occured and may not be complete in some required areas.  This said they are important tool in accelerating business architecture development so I have listed a number of models.

This list is not complete, so please feel free to let me know of any more models and to provide feedback based on experience of using the models...

Peter Evans-Greenwood  has published a slideshow which describes the shift in enterprise architecture thinking that many organizations need to go through to deliver ongoing business value. 

| View | Upload your own

Peter has several other slideshows  that are well worth a look.

A pet hate of mine is complex diagrams that I cannot read on my laptop without zooming in and out and scrolling around. They may be fine for posters that are put on a wall but they are not generally useful architectural artefacts.

I am going to state the obvious – most people look at documents and diagrams on screens or on printouts that they carry around. The size of these is pretty consistent at around A4 size. If you cannot read and understand a diagram that is that size then the diagram is a waste of effort. So, please have some consideration for your audience when creating diagrams – it is a simple and common courtesy.

But I said it is “bad architecture”, surely this is bad presentation. First, since communication is critical for architects, then poor communication is bad architecture. However, the point is deeper than this…

Good architecture is well modularised. It is separable logically. A large complex domain can be decomposed into multiple simpler domains with clean simple interfaces between them. This implies that a set of hierarchical diagrams can be created to represent the architecture each of which can be understood on their own and with sufficient contextual information. So, going back to the communication point. If the architecture is good then it can be presented simply. Is there any benefit in making simplicity appear complex?

What about the as-is? If the current architecture is a mess of spaghetti then how can this be represented simply. Well, this is a core part of the architecture skillset! Logical partitioning is a critical step towards resolving the mess. In short, you must partition it logically as you would a good to-be architecture and what you will be showing is that interfaces are not clean and the components are not well formed. This gives you a start point for refactoring. Showing a mess by producing complex diagrams highlights the problem but does not help solve it.

Please don’t produce complex diagrams, there is no need, ever! I do not want to waste my time trying to understand another diagram with 200 blobs and 500 lines on my laptop again. The person who produced this diagram had the knowledge and has singularly failed to transfer it effectively. That is bad architecture and failure for an architect!

Recently, I was working with Steve Ross-Talbot for a new client. We received a large number of documents describing the architecture that was to be implemented.

I noticed that, in order to assimilate this information, he took the same approach that I did which was to abstract the information upwards into a single simple diagram that captured the entire architecture in about seven blobs. He then took each blob and exploded this into further diagrams each with about seven blobs until he had an understanding of the problem area.  The result was a concise and easily comprehensible story at increasing levels of detail that was easier to follow and understand than the original.

We had a discussion about this and noted that in our experience we rarely see architects develop simple sequences of structured diagrams that tell a comprehensible and compelling story.  Instead we see diagrams with confusing inconsistencies in style and far too much information.  A set of diagrams should tell a story - there should be an obvious start, middle and end.  They should stand alone without the need for a narrator - a picture should not require a thousand words to explain it.

Rather than put my own tips for diagramming, I have deferred to an expert and added a link on the site to "Whiteboards that Work” by Bill Branson which contains a range of communication best practices.