As service orientated architecture (SOA) hits mainstream, anecdotes about SOA deployments gone awry become increasingly commonplace. Like the report of Mark Twain’s “death,” in which his illness was distorted by word of mouth into the ultimate departure, reports of the demise of SOA have been greatly exaggerated.
No doubt about it SOA is difficult. However, application development and deployment are notoriously difficult activities to carry out successfully. Our industry is very much one of evolution rather than revolution, and SOA carries the genes of its predecessors.
If the success of a software project is defined as one that falls within 10% of planned cost and completion date, and one that is delivered with all requirements intact, they are successful about 30% of the time. Does this have to be the case? No, it doesn’t. But the unavoidable fact is SOA adds risk to an activity that is already “success challenged”—to coin a politically correct term for dismal, abject failure.
To the CIO faced with business requirements for innovation and agility, it can be a matter of choosing between the rock and the hard place. On the one hand, the business is screaming for new capabilities. On the other, history indicates that change and innovation, in the IT space at least, are high risk activities. The problem becomes one of delivering value to the business while minimizing the risks of doing so.
SOA & ITIL
Challenged to optimize the processes involved in delivering IT services, companies worldwide have turned to the IT Infrastructure Library (ITIL). ITIL was developed in the
ITIL initiatives are clearly driven from the top down. That is, it is unlikely that a network engineer is going to work to convince his management that adoption of ITIL Configuration Management is going to improve the quality of his group’s change management process. Even if he believed this to be true, most IT engineers already have a full plate and a project backlog.
ITIL tends instead to be driven by executives at higher levels of the business whose role it is to assess, strategize, and plan ways for the organization to align in a way that best fulfills the needs of the business at a reasonable cost.
SOA is similar to ITIL in that, to be successful, it has to have executive support. It also has to focus on cross-business goals, objectives and resources rather than on the department level service deployment strategies of the past. Not coincidentally, best practices tend to promote this cross functional perspective as well. For this reason, the CIO is as vital to SOA deployments as he or she is to ITIL adoption. Further, investments in best practices can improve an organization’s likelihood of successfully transitioning to a service-oriented approach.
Without the cross silo focus that ITIL and other best practices bring to an organization, evolving towards delivering business services, rather than simply delivering applications, may not be possible. IT sees the services they deliver as a combination of technologies. The business sees them as a form on a screen. Bridging the gap between these two views requires that a link be made somewhere. And since the role of engineers is to be engineers, the task of evolving IT to a broad focus on business service delivery lies with the executive.
SOA as Strategy
SOA isn’t simply a way of deploying technology—it is a shift in the way IT and the business relate to one another. SOA profoundly changes an organization’s thinking about funding and support and demands better communication across all departments within the business.
Almost without exception, successful early adopters stress that the biggest challenges they faced were business and governance related, not technology related. For example, much of SOA’s purported value comes from service reuse. In a banking example, a service that checks credit ratings can be leveraged by applications used by multiple departments within the bank. However, software acquisition and development are traditionally funded at the department level.