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.

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.

Some suppliers and their supporters within an organisation may say that packages capture and implement “industry best practice”. But this is not true for all packages, in my opinion it is not true most packages.

Leading packages from leading suppliers will typically implement industry standard practice or best established practice. Many organizations may not live up to these levels and achieving them may be a big step forward and may be good enough. But they will not be among the best, there will only be differentiation in an industry where there has been widespread historical underinvestment in IT.

We often spend too much time selecting the package when it really doesn't matter that much because we are only trying to get to first base and any mainstream package will do the job.

A package can only enable creative differentiation if it differs from other packages on the market. To do this it will contain emergent best practice and have a low market share. But how can you tell the difference between emergent best practice and a collection of unproven and destined to fail techniques? How can you know whether the package supplier will fail and leave you with an unsupported application that is going nowhere? Basing business differentiation on a package is a business risk.