WebServices dot org

Who’s Going to Pay for this New SOA? (Don’t All Jump Up at Once…)

The other week, I had the chance to chat with Michael Liebow, vice president of SOA and Web Services, IBM Business Consulting Services, about what he saw as the biggest challenges to SOA. Michael pointed out that organizations have only begun to get a grasp of governance as the vehicle for building and maintaining support for the effort.

Michael agreed with my observation that there hasn’t been a whole lot mentioned about the financial side of governance of SOA projects, namely that the costs of SOA projects should be shared by various parts of the enterprise. “In the CIO conversations that I have, today IT projects are funded on a project level with strict ROI,” he pointed out. This is, essentially a non-starter for conversations about SOA, he added. “You can't go to that business owner, and say, 'hey listen, we're going to create a set of services that can be reused across the enterprise, and it's going to cost you more than if I did it the normal way.'”

“You can imagine that conversation. No one wants to foot the bill, and be that magnanimous. They've got businesses to run; let somebody else pay for it.”

SOA is a cross-enterprise initiative that can benefit all business units that come into contact with it. The question is, who’s going to foot the initial bill to help out the rest of the organization? IT? Logical, but IT departments are famously strapped with tight budgets and ongoing maintenance expenses. Line of business? Sure, which ones will open their wallets first? If the marketing department absorbs the costs of developing and maintaining that customer name and address lookup service, how will they feel if finance and customer service gets to use it for free?

According to Gartner, this year, “a lack of working governance mechanisms in midsize-to-large (fewer than 50 services) post-pilot SOA projects will be the most common reason for project failure.” Talk about “governance” in the SOA sense of the word, and images of repositories and registries come to mind. That’s part of the picture, of course, but governance also has a very high-level place in moving projects forward as well. Namely, who gets how much, to do what, for whom. Where the support for the effort is going to come from.

If you’ve been to enough conferences and read enough articles, you’ve heard the stock phrases of ‘business and IT alignment,’ and ‘IT understanding the business processes.’ But the bottom line of all this utopian thinking is the bottom line: who’s going to ante up the funds to get this project rolling? In the old days, it was relatively straightforward. The call center was billed for the call center application, human resources was billed for time and materials related to HR management systems, and so forth. But when you’re talking about building an inventory of components that will be made available to any business unit that needs it, how will that business unit be made to pay for the service? Who will pay for its creation in the first place?

Plus, SOA isn’t built with a single project, but rather, through an ongoing series of projects. It’s a never-ending process of adding new functionality, users, and tools. An effective good governance structure may help answer the question of who pays the first bill, and how the organization should prioritize, validate, and manage this ongoing series of projects we call SOA.

“The trick is that organizations that already have good IT governance in place should be able to leverage this very easily,” said Liebow. “But the bulk of the market doesn't have the IT governance in place.” That brings to mind a paradox – some organizations are run so well that they could survive without a SOA, but are more likely the ones to be building SOAs. Those companies that really could benefit from SOA don’t have the wherewithal to know where to start.

The folks at ZapThink have also pondered this question, and conclude that SOA tends to be a ‘feature-less’ architecture, versus a specific solution for a specific problem. Strike one. That’s why many SOA ventures are likely to start out as “smaller, more tightly scoped projects,” funded by mid-level managers’ discretionary budgets. “The larger the project, the more levels of management must participate, stretching out the sales cycle and raising the stakes for everyone involved. For enterprise-wide SOA projects like those that corporate governance or regulatory compliance motivations drive, obtaining funding is a matter of getting buy-in at the very highest levels in the organization, often the CIO or CFO.”

“Even at the departmental level, it is not entirely clear who should be paying for SOA,” ZapThink adds. ZapThink proposes a solution that I actually first heard from Richard Phillimore, senior VP at Sanchez Computer Associates, a few years back. The SOA library of components could be regarded as a separate line of business in its own right, administered through the CIO’s office. The effort can be started gradually, rolling out a few services at a time, versus a more big-bangish approach.

ZapThink concurs, but also cautions that treating “enterprise architecture as a separate LOB is a new and potentially risky concept.” However, the consultancy “has already seen some companies take the bold step of creating such a separately funded architecture group that has control over SOA projects across the enterprise.”