SOA : The Vision & The Hard Part Of Adoption

Accenture's Donald Rippert believes that with SOA, the building blocks of a simpler future are in place . He imagines a future where SOA will make it possible for business managers to create instantly the IT functionality they need to support business initiatives, instead of submitting a technology request that disappears into the IT department’s backlog. At the same time, SOA will force IT to begin speaking the language of business rather than technology – driving corporate productivity by putting technology in lockstep with the business. As he sees it with an SOA, business applications are constructed of independent, reusable, interoperable services that can be reconfigured without vast amounts of technical labour. Soon it will be common – at least in high-performing organizations – for business managers to assemble technology services, drawing upon reusable components developed by their counterparts in IT. The maturing standards set SOA apart from previous generations of integration technrologies, which were largely proprietary to each vendor. He believes that SOA adoption would increase with standardization just as standardized browsers fuelled the adoption of the worldwide web. As SOA delivers the promise of solutions that transcend lines of business – and the organizations themselves – IT managers, newly decoupled from applications they manage, will have a broader view of the potential they can deliver. Once IT speaks the same language as business, it will be primed to design services that help companies bring distinctive capabilities, products and services to market quickly and companies and government entities that adopt SOA have the chance to drive substantial productivity gains and higher levels of performance.
Brenda Michelson brings in a reality check in adopting SOA. Amongst the key concerns:
- Many enterprises find it difficult to determine the correct bounds (job and tasks) and granularity (collaborations) of business services. Enterprises have erred equally on creating services at too fine a grain, and too large a grain. Industry specifications for true service interactions, rather than information hand-offs, are the exception rather than the norm.
- In most cases, architects and business analysts are relying on service definition practices from SOA technology and/or solution providers, or adopting best practices from experience, gut feel, and a wide range of published methods.
- A publicly available, cohesive, services definition methodology is missing. Its a challenge to deploy SOA program while balancing the natural tension of executing business projects (today, on-time, on-budget) with the need for architectural integrity.
As I see it in terms of SOA adoption amongst other things issues like several critical problems like communication mismatch between business and technical architects, ever evolving standards and a lack of a visible wave in embracing this technology all come in the way. Further, as I see it, the lasting value through SOA deployment is not just in empowering the business manager, but in fostering and creating a new global business framework where disruptive technologies /methods like outsourcing, offshoring, SaaS & Open source shall meaningfully intersect creating new value chains.