SOA, ITIL and the Strategic CIO

By Julie Craig

(Back to article)

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. Enterprise resource planning (ERP) implementations and the massive software projects of the past were notorious for failure, even before vendors such as SAP and Oracle began to move towards more modular, service-oriented designs.

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.


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 UK, and adoption has traditionally been largely driven by growth outside the U.S. However, EMA research shows that ITIL adoption in the U.S. has tripled in the last two years.

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.

When a service developed using funding from Installment Loans becomes available to the Commercial Loans group, for example, how does Commercial Loans reimburse the other department for its "portion" of the service? When five or six departments are using the service to the point where performance degrades, who pays for the additional server horsepower? Who keeps track of who is using the service, and who controls security access? And when the service needs to be changed, who funds the change, and even more importantly, who else will the change affect?

Once an organization realizes that SOA is more than the sum of its technology parts, investments in ITIL and other best practices become no-brainers. ITIL adoption can well be considered to be a foundation for successful SOA adoption. Without disciplined processes in place across IT, the added challenges of cross business coordination becomes a weighty load that, over time, adds resource requirements to an already over burdened IT organization. And without disciplined channels and processes in place, the cross business strategy changes that are necessary for "successful SOA" cannot be effectively carried out.

Decreased Risk

For companies successful in deploying applications using SOA, one of the big benefits can be a reduction in risk. If most software projects fail—and research shows that most do fall short in some way—the risk is greater as the size of the project grows. Watts S. Humphrey from The Software Engineering Institute found, in a study of software project success, that while half of the smallest software projects succeeded, none of the largest projects did. Other research agrees with his assessment, and this is one way in which SOA can contribute to an organization's long term business success.

SOA, by its nature, is a modular architecture. When an "application" is developed in a modular fashion, the product is a series of small modules rather than one huge one. The rise of agile development methodologies over the last few years support this modular approach, and, combined with a service-based architecture, can materially improve the quality and success rate of application deployments going forward.

The Strategic CIO

There are multiple ways that IT executives can significantly improve an organization's chances for successful SOA initiatives.

A few are summarized below:

Evangelize - Many of the most successful SOA adopters started their SOA projects at the executive level. They did their research to find out specifics about reuse, loose coupling, and modularity: three of the major ways that SOA adds business value.

They then socialized SOA and its possibilities with executives across the business. These "SOA evangelists" set expectations with the business that reflected SOA's realities, and prepared the business for potential challenges and payoffs. They found that these activities helped to build links between IT and the business and brought non-IT executives into the loop regarding the ways in which SOA could potentially impact their departments and provide value to the business.

Be Clear - A major benefit of SOA is business agility. There is a reason why the financial services industry is one of the big SOA adopters and that is because regulatory and compliance requirements change on a dime. Such initiatives take the need for business agility to a new level, and it is unlikely that these companies could remain in compliance without the agility that SOA has made possible for them.

Executives within these companies, in close touch with the requirements of the business, guided IT to find ways to address constant change. Companies requiring less agility may be well advised to avoid SOA altogether—SOA is definitely not for everyone. However, if the goals of the business reflect requirements to adapt more flexibly to change, to develop IT-based services that differentiate them from competitors, and/or to decrease the cost and risk of software deployment, SOA can be a good option.

Set Expectations - We consistently hear that, in its initial stages, SOA is a money pit. It costs money to change a software architecture, to adapt existing applications to a more modular deployment methodology, to train developers to write to SOA and IT organizations to support it. Reinventing cross departmental funding and governance processes requires additional time from IT as well as non-IT executives.

This is reality, but one way to deal with it is to let the business know ahead of time that it shouldn't expect instant cost savings. As reuse starts to kick in, as software development becomes more predictable, and as governance brings order to the chaos, the business can expect to see all the benefits that have been touted. However, it will take time for those benefits to materialize.

Be Realistic - If your organization has a history of software project failures and nothing has changed, it's likely that your SOA project will fail as well. SOA requires strong technical capabilities, well orchestrated project management, executive support, and strong cross business processes. Lack of one or more of these capabilities will dramatically limit chances of success.

SOA is best tackled by mature IT organizations, as defined by organizational maturity models such as the one described in the Control Objectives for IT (COBIT) best practice library. If you are unsure about the maturity level of your organization, check it out at www.isaca.org. Maturity requires well-developed, repeatable processes, cross organizational communication, and above average ability to leverage automation to manage technology. From the SOA perspective, it also requires business need.

As the place where the buck stops, the CIO is, in the end, responsible for judging whether SOA's benefits outweigh the risks for a specific organization. SOA is certainly not for the faint of heart. If approached strategically and realistically, however, it strengthens ties between IT and the business and strengthens IT's ability to deliver services cost effectively and with high levels of discipline and consistency.

Julie Craig is a senior analyst with Boulder, Colo.-based Enterprise Management Associates (www.emausa.com), an industry research firm focused on IT management. Julie can reached at jcraig@enterprisemanagement.com.