A single concept but different ‘definitions’
For several years now, SOA, or “Services-Oriented Architecture”, has promised to deliver unprecedented flexibility and cost savings to IT, by defining a methodology for the use and re-use of software components and business processes.
SOA is, first, a business operations strategy for leveraging information to meet the organization’s objectives, such as increasing overall revenue, boosting customer satisfaction, improving product quality, and enhancing operational agility.
In practice, SOA means different things to different people:
-
To an IT Architect, it means the overall enterprise architecture definition and the process that enables IT to develop and deploy business capability rapidly. Architects seeking information usually go to vendor sites for product details, case studies, and best practices which they then compare to other publication and standards sites such as The Server Side, W3C, java.net, and OASIS.
-
To the LOB-IT liaisons it means the governance, organization, and process for project/program management–and the various business building blocks that could potentially be reused in order to reduce cost. The LOB-IT and CIOs typically attend CIO Forums or subscribe to journals that provide information.
-
For the legal team, SOA is a potential liability: they want to know whether the service is delivering information to partners, customers, and others outside the company firewall, and what regulatory issues and exposure might arise.
-
And finally, for the CIO, SOA is the IT strategy for delivering business capability. What business functions will be automated: which services, and what maturity, cost, and SLA to expect?
However, SOA is still new, and organizations are still in the process of learning how to implement it so that it fulfils its potential for intra and inter-enterprise services reuse and process interoperability.
Meanwhile, companies like SOA People, encounter the challenges typical of a software methodology that is not yet supported by a fully mature industry.
For example:
-
Every major vendor claims to have adopted SOA and has published its own view and reference architecture for SOA. SOA start-ups are being acquired by larger vendors, creating further volatility
-
IT typically does not communicate effectively to the business how money spent on SOA will automate business functions and deliver solutions cheaper, better, and faster
-
Every major standards body has multiple groups attempting to define SOA, adding to the confusion and slowing adoption of SOA.
-
Development and management tools are not sufficient
-
A lack of common vocabulary across the industry has made it difficult to share best practices from vendors or analysts.
