Why SOA?

There a couple of things every speaker giving a presentation on SOA feels obliged to do. One is to define SOA and the other is justify it. When I presented last week at an ArkGroup Conference I also did both. The definition I discussed was in my earlier posting. The justification is the subject of this posting.

We do SOA for the following reasons
• Agility
• Reuse
• Assist Transition from Legacy
• Federation
• Extensibility
• Manage Incremental Change
• Better Alignment Between IT and Business Processes.
• Intrinsic Interoperability
• Vendor Diversity
• Support New Technologies
• Reduced the IT Burden

Some of this list comes from a book by Thomas Erl, “Service-Oriented Architecture: Concepts, Technology, and Design,“. 'Manage Incremental Change' and 'Better Alignment…' come from the forward by Scott Dietzen (CTO BEA) of “J2ee Web Services on BEA Weblogic”, a book by Anjali Anagol-Subbarao. The order of the list is from most important to least important and is my own opinion.

Agility and reuse are generally the two main motivations for SOA and they are certainly important to my organisation. The cost of changing a monolithic legacy application is embarrassing. We need to make change at lower cost.

We have a strong need to access its legacy functionality in order to add application functionality delivered in newer technology. This theme was discussed later in the presentation and is covered in a posting on legacy transition.

My organisation is part of a network of agencies that shares one monolithic mainframe database system. This needs to be broken up and moved to a federated model so that we are not bound up in each other’s business decisions. Each agency needs more control over their services. Similarly Australia is a Federation. Each state in Australia has an agency like ours and we all want to share our information. We however also want to retain sovereignty over 'our' data. This is the essence of federation where we share but retain some independence.

Our applications need to be extensible without going back and building from the ground up. This is part of reuse but goes further than that. You reuse what already have and you add to it without compromising the quality of what you already have.

Change has to be incremental. The days of the two year project without showing any output are dying. We need to be able to progress in small, low risk increments. This is also important in my agency because we are unlike to get funds for large changes. We do not only focus on building more code but on changing what we have already built. We should be able to make changes to one part of an application without affect the rest and SOA enables this.

Our applications need to reflect the way our business processes work. SOA promises to deliver better alignment between IT and Business through providing a closer match between the tasks in a business process and software services. I do not believe we will get to the point of business users mapping their business processes and orchestrating their own applications. But if the structure of our systems is aligned to business process then changes should be easier and more compatible with the business.

This slide emphasises that interoperability is not the only game. What is more, it is not point to point interoperability we are concerned with. It is building applications that are intrinsically interoperable (and integrated). The concept of intrinsic operability is explained on a web page by Thomas Erl. SOA provides the promise of systems that provide the ability to interoperate without having to add integration mechanisms. I have an earlier posting that elaborates on interoperablity and integration.

Lastly vendor diversity is important so we can use products and middleware without being tied to a particular vendor. This should therefore help keep costs down and avoid being locked into proprietary systems. SOA also limits the risks of a proprietary product not being supported in the future.

The ability to support new technologies is due to the standards involved in SOA and the loose coupling that means the organisation avoids a huge commitment to presentation and data storage technologes. Thus an SOA will not require a large rewrite to add new presentation mediums (such as mobile computing) to its applications. The SOA can be adapted if the data storage approach changes for some of its services.

Thomas Erl explains that SOA can reduce the IT burden of the organisation. This basically means that in the long the run there is less IT to implement if the organisation is properly reusing services. There is less code, less maintenance required, less support of different applications and in general less IT.

Each organisation will have different motivations for adopting SOA and the priorities will be different. As we go on the journey it is important to keep the reasons in mind and assess occasionally whether you are achieving what you set out to achieve.