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.

Joe McKendrick asked why Europe seems to be ahead of North America in EA. John Michelsen asks is Europe ahead in SOA. Ronald Schmelzer thinks that the USA is not behind but its not ahead either.

From my European perspective, this is an odd debate. I have the impression that a lot more money has gone in to enterprise architecture over the last 10 years in the USA particularly from government. Obviously, this has not been the case across the board but the struggling American architecture manager has not had a very high profile.

If you have millions of dollars and years to deliver then what pressure is there to be pragmatic? This has meant that the dominant approaches to Enterprise Architecture are Big Architecture Up Front approaches. Where architecture has had less acceptance and less money, we have had to evolve alternative ways of achieving our goals. We have had to develop creative approaches to making our money go further.

If I am right then, what we may be seeing in action is natural selection. Perhaps the reason that we can move ahead more quickly with SOA is that we are more focused on delivering benefits, we have had to be more pragmatic, and we have had to work out how to move incrementally down a strategic path. Because we have been under greater environmental stress, we have evolved enhanced capabilities to manage architecture effectively, to demonstrate its direct business benefits and now our SOA initiatives are reaping the benefits.

We are told SOA is worth it, we are also told that it is difficult, and then we are told that there have been many failures.  What do we need to do to deliver?

I was in the forefront of component based development in the mid 90s.  We framed and solved most of the issues that seem to be troubling SOA then.  We worked out business oriented methods of identifying components that were worth building and would be reused, and that the business would buy into investing in.  We reorganised the IT department from top to bottom to meet the needs of the new style of development.  We changed the development process.  We changed are release process. We made the effort at all levels to change, the methods that we put in place then have evolved and now successfully deliver SOA.

Some of the technical issues that we had then have been addressed through infrustructural product development.  But the conceptual and managerial issues are deep and require major surgery to the traditional IT department.  We hear a lot about SOA governance being the answer.  It is much more than that!  It is business change governance, it is business change organization, it is business change processes, it is aligning IT attitudes, processes and organization.  You cannot deliver SOA successfully unless you have a collaborative approach to business change.

There are those organizations that are willing to invest time and effort in changing the way they deliver IT so that they can deliver SOA successfully.  But for the others, maybe SOA is just too difficult?