Blogger: Richard Watson
A business case for SOA investment is so littered with paradoxes it’s astonishing any of them get funded at all. Joe McKendrick, in his ZDNet SOA blog, has written about the paradox of including SOA in a business case:
In presenting a business case, the three letters “SOA” probably shouldn’t even be mentioned. However, SOA inevitably results in a bump in costs (at least for the short-term) that needs to be explained and sold to the business.
Let’s look at 2 more paradoxes inherent in funding for SOA investments.
The paradox of too much project funding
In many organizations the IT funding model works like this.
Here’s the money, just build it. Now.
Demand for IT projects comes from lines of business and the supply of funding for all projects also comes from those same business lines. Shadow IT moves in and out of vogue in cycles responding to this paradox. At the peak of the cycle CIOs and CTOs can add some value implementing portfolio management and enterprise architecture. At the trough, CIOs look like mere demand aggregators with little influence to mediate the demand and supply of IT funding.
The real resolution to this tension comes down to transformation along a number of axes including incentives, accounting, control and culture. Right now business units are not comfortable being asked to do any of the following things:
- act like a service provider for the organization
- rely on services provided by other business units
- fund infrastructure, architecture or education improvements
- • or accept that designing reusable services takes more time and needs deeper collaboration than bespoke applications.
In fact it’s unrealistic to expect business units to act in any other way, given the metrics and related incentives that feed and nourish this behaviour. One of the clients we interviewed for the SOA contextual research project pithily summarised this point:
Altruism is not an effective corporate strategy
An organization’s incentives need to be shaped to promote service provision, service reuse and support for shared infrastructure. Other changes are required to follow through with this strategy including the accounting and financial flexibility to fund and charge-back shared infrastructure and service development and new control and operations strategies to govern cross-business system dependencies.
Often achieving this means fundamentally restructuring a business into horizontal capabilities. Aren’t you sorry now you started pulling on that thread? You just wanted to get funding for a SOA initiative and now you’re restructuring the business.
This is the reason executive level sponsorship is a common theme in all our clients’ SOA success stories.
The annual budget cycle paradox
SOA is not a quick fix to the problems in IT; it’s a long-term strategic investment that will take decades to pay-back. However, projects are typically scoped and funded on an annual basis. The issue here is finding return on investment (ROI) measurements that are required as a minimum to get that SOA business case over the line.
Oracle CEO Larry Ellison acknowledged 6 months ago in a CIO magazine article that slow SOA adoption has been widely documented:
While I've read [about slow adoption], people have to understand when you have a fundamentally new computer software architecture, SOA, it takes a long time for adoption.
Moving to SOA is not as easy as flipping a switch.
It takes about 10 to 20 years before [you can] rewrite all of your applications.
We think it's a long-term growth story, it's a very rapid growth story.
It takes a long time for our customers to have a majority of their applications modernised and we think this is a growth story for a decade for us.
Larry’s sales force, like the rest of us, is finely attuned to the need to show quarterly value. They know that just because the full ROI of SOA infrastructure they sell won’t be realized for a decade, they have to have a good enough story to sell it this quarter. So it is within IT organizations and annual budgets.
Changing architecture and culture is a multi-year, perhaps decade-long project. Looking for the quick fix is counterproductive to this effort, and likely to create more complexity in your environment, not less. But don’t confuse the quick fix with projects that deliver value early and often, and recognise the need to architect for the long-term.
The resolution to the tension in this paradox comes in two flavours. Firstly, if your organization has a mature IT portfolio management effort, with a central project management office (PMO) that offers multi-year funding for strategic projects, take that route.
Secondly, suck it up like Larry’s sales animals. Restructure the business case to deliver value annually if not quarterly. This is the only route to building up that trust relationship with the sponsors. Look for projects that deliver value as clear business outcomes: increased revenue per client, increased client retention, more visibility into customers’ purchasing patterns, more flexibility to outsource non-core business capabilities.
One success story amongst our clients in resolving the tension in these 2 paradoxes together is a financial services company that favours the centralized funding approach. There is a mature IT governance process in place which means that while much of the funding demands are still for business unit driven projects they are funded from a central budget controlled by the CTO. The CTO architecture group has a unique vantage point from which to plan the evolution of IT, and identify the contribution each discrete project can make. The remaining demand comes from the CTO-governed group itself for strategic projects, including those that cannot show ROI over one, two or even five years, but are crucial to transforming IT.
If you’re trapped in what looks like a paradox, change your viewpoint. If your paradox is working out the question of how to get funding for your SOA initiative, change the question to this one: how to get funding to add business value while transforming IT in the long-run.