SOA: Conference Summary and Random Thoughts

I recently attended a SOA and Application integration conference. The conference itself was technology agnostic, but Microsoft did have a presence, along with several other vendors. I have decided to publish some of the notes that I took over the course of the conference. I figure that they may be worth looking back on as SOA continues to evolve. Hopefully they may help out some other readers as well.

Disclaimer: The thoughts described are not necessarily my original thoughts. Where possible, I will try to give credit to the original 'author' however in some cases I may not necessarily have all of this info. I have also done my best to take these notes in the context that they were presented in.

Themes/Ad hoc notes:

• Desire to react to change is greater than the need for the application to last several years. No longer are companies expecting their applications to last "for ever". Gone are the days were people will build systems to last 10 - 15 years. Now systems need to be flexible so that when business needs change, IT can react in a timely manner. - Massimo Pezzini


• If a definition/summary of a Service cannot be understood by both a Business person and someone from IT, then it is not a SOA service. - Massimo Pezzini


• Business Activity Monitoring (generic, not specific to Microsoft BAM) is the single biggest near-team opportunity for IT to shine. - Massimo Pezzini


• Now that Web Services are fairly mainstream, do we still need integration? Yes, Web Services only solve the communication problem. They still do not address other characteristics of SOA: Business Activity Monitoring, Extreme Transaction Processing, Complex Event Processing, Centralized Business Rules, Modeling. - Massimo Pezzini


• An organization needs to establish a SOA Centre of Excellence (COE) in order to be successful in delivering a SOA. Someone, or group, needs to own the process. Without this direct accountability, the project is bound to fail. - Hans C. Arents


• SOA is more than an architecture, it is an approach to developing software. - Hans C. Arents


• Introduce SOA in a stepwise manner. - Hans C. Arents


• When 'pitching' SOA, you need to provide actual numeric(empirical) measurements. You cannot look for project sponsorship without providing empirical data on the benefits of SOA. You cannot say it will improve reliability or improve efficiency. You need to associate real values to your claim(s). The drivers do not necessarily directly relate to dollars, but need to be measurable. - Frank Kenney


• Integration is inevitable in today's market. However, the decision needs to be made as to whether it will be piecemeal or systematic. Piecemeal refers to point - to - point integration like file based FTP integration. Systematic refers to a level of abstraction and loosely coupled interfaces like an ESB or Broker. - Frank Kenney


• Using Web Services, in a point to point manner, is not SOA. It is essentially the same as using FILE based point to point integration. The difference is only how you communicate. You still need middleware to ensure you have loosely coupled systems. - Mark Driver


• Some companies may decide to go the piecemeal route as it may be "easy" or it is "the way it always has been done". A decision maker also needs to think about what are the costs, or lost opportunities, of not doing integration. - Frank Kenney


• Systems that are "built to change" are more valuable than systems that are built to last. - Frank Kenney


• The best integration systems are built to change, adapt and control change. - Frank Kenney


• SOA is not solely for IT. In fact if SOA is an IT initiative, then you are bound to under deliver to your business units - several authors


• You need "buy in" from both IT and the Business to be successful.


• Some topics that I need to spend more time researching, but were continually being discussed within an SOA context are: Event Driven Architectures and Extreme Transaction Processing

Random Thoughts

• During many of the sessions, "selling" SOA to the business was a popular topic. I think nearly every presenter brought up the value of reusable code as a key driver to adopting SOA. On the surface, I think this point is valid. But, I don't think that it is a statement that can be applied universally. Thinking back to some of the organizations that I have worked for/with, I can see opportunities where this is true. One organization, use to store customer information in 7 different places. Having an address being consistent across these systems was practically a miracle. This case is obviously a good candidate for a common service. Then there are other organizations that have used 3rd party COTS(Commercial Off the Shelf) applications. Presumably, selling the reusable code argument is not as convincing in this type of scenario if the COTS product has not duplicated functionality through out the application.


• There are a lot of politics in rolling out SOA. People tend to work in silos and tend to be protective of their domains. Programmers also tend to not trust the work of others. When writing code, ego can play a role in programmers being objective; "I can write that [functionmoduleservice] better than that guy". Getting buy in from all of the various groups (silo owners) may be difficult.


• Whether people like it or not, SOA is coming to an organization near you in the next 2-5 years. Vendors like SAP, Oracle and Microsoft are continuing to release products that leverage SOA. With this said, it is better to understand SOA and plan for it than to try and fight or resist.


• Having visited some of the other vendor booths that compete in the SOA/ESB/BPM space, I was impressed by some of the vendors offerings. Comparing their capabilities to Microsoft's did validate some of the features that BizTalk enthusiasts have been asking for. More specifically, Modelling and Low Latency messaging were areas that some of the other vendors did impress me with. The good news is that both of these areas are being addressed in OSLO.


• All in all, I do think that SOA is a step in the right direction. However, every organization is unique and you need to produce a business plan that justifies the implementation of SOA. SOA is invasive and can lead to massive failure if it is done for the wrong reasons. SOA is definitely more than just an IT initiative. If you treat like it is just an IT project, then you are bound to fail, or at a minimum, under deliver.