Despite the widespread hype and reams of articles in technical and business journals alike, one question that still causes consternation amongst customers and practitioners alike is, “What is Service Oriented Architecture (SOA)”? If compiled, the answers to this question would fill copious volumes, but a consensus on an answer would be elusive. The reason the answer to this question doesn’t fit into the mold of a precise technical definition is due to the fact that SOA is mostly a business concept, hence it has to be defined in a business context. Yes there is a set of technologies and industry standards, whose widespread acceptance has enabled IT to support SOA; nonetheless the way to define SOA is in terms of business value to the customer. The architecture, approaches and patterns of Service Orientation help an enterprise to:
- Achieve agility
- Increase interoperability
- Increase business and technology alignment
- Increase Return on Investment (ROI)
- Avoid vendor lock-in
The SOA Manifesto is a great guiding beacon for SOA initiatives as it helps provide clarity and focus around the actual objectives. In our current project, issues with the software cost for the Enterprise Service Bus (ESB) component in our SOA architecture necessitated a rethink of strategy. As a consequence of the loosely couple architecture that we had created, we were able to replace the middleware layer with another component in under two weeks, without impacting the Presentation Layer or the Persistence Layer. This drove home the Agility and Vendor Diversification benefits of SOA to the customer. Despite this, a query was raised, is it SOA if there is no ESB? Yes it is SOA, the intent is to use the solution architecture to help the customer achieve business value rather than obsess over the rigid adherence to a technical strategy.
With the same customer, “Integration Spaghetti” prevailed in the IT enterprise, where custom ungoverned point-to-point integration existed between stove-piped systems. As we created a proposed SOA Roadmap, one of the first tasks was to use a Service Oriented approach to Integration (SOI) to help reduce the integration “clutter” by using standards based Data Services. As I pointed out in my recent article at SOAInstitute.org[2], SOA purists might split hairs on how SOI is not SOA, but evolutionary refinement is better than insisting on initial perfection. Hence for a customer, SOA should be defined in terms of the benefits that will accrue to them, not just in terms of the how many layers of a SOA Reference Model are implemented.
Barely had the effects of SOA started percolating within Enterprises, than the buzzword wagon moved on to the “cloud”. Cloud is now becoming the new SOA, with same level of ambiguity surrounding its definition. Besides this common vagueness, SOA and cloud are interconnected, with SOA acting as an enabler for cloud. Cloud is a target platform for deploying SOA where reusable services are provisioned. In my opinion SOA and cloud are joined at the hip and there are many connection points between them. If enterprises jump to the cloud without having a Service Oriented enterprise, they risk creating more silos in the cloud.
According to the OASIS SOA Reference Model, interaction with Services produces real world effects i.e. changes to the world’s state. Extending this thought, as an enterprise rolls out SOA, it should produce positive real world changes to the enterprise.
