Its amazing how travelling on a plane can help the thinking process (assuming you can have peace and quiet).

I had a reflection back on what I have observed on companies that have embarked the SOA bandwagon over the last several years.  There were a lot of disillusionment on the promise of SOA.  I think the key reason is that SOA idea is very logical and seems easy to implement at the conceptual level.  But as they say, the killer is in the details.

A few observations where large companies have made good in roads on this journey:

1. Usually a small project team started with a specific problem to be addressed.  However, the architect had enough vision and know how to ensure the application is contain some flexibility in the design to allow for some of its common components to be exposed as a service.  The full focus of the project is still on delivering the biggets value to the project stakeholder.
2. The vision is quite specific and practical.  So the benefit can be realised.  Most of the time, the technologist in these teams have a very practical approach to problem solving.  They understood the difference between having a vision that can be delivered vs a vision that will remain in the realm of theory.
3. They understood that as Technologist they should and need to play a part in helping the business owners in specifying the requirements.  They don't hold onto the idea that "If the business folks don't know what they want then they ain't getting it".  They understand that as the business asked for new systems to help them, they are also venturing into a new teritory (new business processes or idea that has not really been tested).  The theme of design a little, develop a little and show a little is very effective, especially if its coupled with a good and solid Architecture guiding principles.

Companies that have had issues:

1. The technologist usually paints a grand picture of nirvana where once developed the next time the business changes its process and direction the technology can be easily configured.  This is not so.  Having a solid understanding of the key business processes and more importantly being able to refactor the key common processes that can be re-used is very important.  This will determine the Services that can and should be reused across business units.
2. Another common failure is getting too caught up in designing the "Perfect" architecture.  Architects generally falls into this trap.  We all want to have the best and perfect design that will last for eternity.  The reality is that as technology change, the architecture theme or design will also change.  Continous evolution and improving on the desing is a better approach than design once and they will flourish approach.  This is similar to building architectures, go back 500 years ago when concrete was not readily available available, the way they design building is very different than today because the materials they can use is different.
3. "us vs them" approach between group of technologists that sits in a centralised "think tank" and the people who actually worked with the users and developed practical systems.  The best approach is to pick a particular project to start with and desing it with expansion in mind.  This will ensure we start small and design for the bigger whole.