We Might Clear the Fog Around SOA, but its Future is Still Cloudy

Rate this:
Total votes: 0

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[1] 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.

References:

[1] SOA Manifesto [http://www.soa-manifesto.org][2] Being Intelligent with SOA [http://www.bpminstitute.org/articles/article/article/being-intelligent-with-soa-using-soa-to-lay-the-foundation-of-your-business-intelligence-bi-initi.html]

Sumeet is a Senior SOA Architect at SAIC USA, a FORTUNE 500 company, where he leads the SOA Adoption Roadmap, Strategy and Implementation for a large DoD client. Sumeet has been on the forefront of SOA and its related technologies. At webMethods (now Software AG), he was involved from the very early stage with the implementation of XML-RPC (US Patent: 7028312, circa 1999), the precursor to current day SOAP. During his tenure at webMethods he has acted as the lead engineer and architect for numerous SOA infrastructure products, starting from webMethods Integration Server, B2B to Enterprise Application Integration, SOAP stack and WS-* standard implementations, high performance Policy Enforcement Points and SOA Governance products. These Enterprise level SOA software products are currently deployed at thousands of customer sites.

Comments

Join the Discussion

Remind me later

If you wish to make a purchase today and experience an error with the shopping cart, you can place your order over the phone. Please contact us at (508) 475 0475 x15 or toll-free within the U.S. at (855) 300-2686 x15.