A lot of what I see with CTOs and architects is that they are very strong in understanding how systems work and how to build technical solutions and architectures, but what they often don't have a good handle on is how the funding works within their own company. Every company has a pre-arranged set of rules and processes by which projects are funded whether they are business line projects or IT projects. So the first piece of advice I typically give is to really understand how that works within your company. If you don't understand how the game is played, it's pretty hard to be a star athlete. Are there commonalities across most companies in how they fund projects?
Most commercial organizations fall into a few different models for how projects get funded that leverage IT. Depending on which model and organization's culture is leaning towards, that sets some of the ground rules in terms of a strategy. In general, its good to looks at past projects that were similar to SOA and how they got funded in your organization. Can you tell us a little more about the different models you see in different organizations?
In most organization there are four basic models used to get SOA going. The first one is project-based funding. It's by far the most common. It's also what I call the anti-enterprise strategy. This is a model that says the way money gets spent in a line of business for a large company is to launch a project. So you launch a project. Then anything IT has to get done from a funding standpoint rolls up into that project and it kind of lives or dies by the business case for that project. So if the project is that the business line wants to make improvements to warehouse X, and you come along and say it will need three servers plus software, then the business line decides if the cost is worth the benefit. Of course, if they say no, the whole thing is shelved. So what happens is you end up in a scenario where at the portfolio management level, you have a collection of projects, each one linked back to a business unit. And each one having to justify its ROI on its own merits. Does that work?
The challenge with that model – and it's by far the most common model – for doing SOA is that SOA at its core is a shared IT investment, sort of like the network. The problem is when you try to justify all the software and the training that goes along with it within the bounds of one project, it doesn't take into account that other projects are going to benefit. The project then asks one department to be a good corporate citizen and fund this project for everybody. It's kind of like you're going to buy a car, we're going to put a $5,000 tax on it that will benefit everyone else who drives the car in the future, but you have to pay it now. Obviously, if you're the one buying the car, you do one of two things. You say, "I don't think I need a car." Or you say, "I think I'll buy a car a month from now and let someone else pay the $5,000." So that doesn't sound like a good model?
It makes it very hard to fund SOA. That's why I call it the anti-enterprise model. A CIO I used to work for used the analogy: "He who comes to the river first, builds the bridge." That was his model for how things should be funded. But when you have architects stuck in this model, it's very frustrating for them to get multiple stakeholders to agree that SOA is the right thing to do. What other models are there?
The second model is enterprise funding, which is the opposite of project-based funding. A small percentage of companies realize that there are things, and SOA might be one, that impact the whole enterprise versus any individual project or business line. So these companies have an allocated funds for enterprise projects. It's almost like these companies have put a savings account off to the side that you can tap into if you can justify that what you are going to do is strategic. Companies will frequently set up enterprise funding when they are doing an ERP rollout or upgrading a huge swath of IT infrastructure. These are projects so large, they don't fit into existing funding models. That kind of model is much more conducive to SOA because it's shared across the entire company, so the funding is shared. Unfortunately that model is not all that common. So what is the third funding model?
The IT funding model is one where some CIOs have a budget and within their budget they carve off money to be used internally by IT to fund an improvement initiative. Typically these are things like updating old servers, upgrading the network, things that are more infrastructure-related for keeping the data center current, but it's not attached to any particular project. In this scenario the strategy for funding SOA is to argue that SOA will improve how IT is going to deliver solutions. The upside of this model is you don't have to link your whole SOA initiative to one particular business project. The downside is the business side isn't sitting at the table in this model. That can be bad because without business input you may not build out a very good service-oriented architecture.
The fourth one is kind of a shell game. It's not a very nice model. This is where within a very large IT organization, in addition to what things really cost, there's this concept of allocation. Let's say, in a very hypothetical example, I have an enterprise network and I have a thousand employees in the company. If the enterprise network costs $1,000 per year to run, I'll charge each employee a dollar a year. This last model plays with that concept. I say I really need to do SOA. I can't get the business to agree to fund it. So I raise the cost of the network per employee to $1.03. If I can push that through the business saying the price of the network has gone up, what I do with that three-cents per employees is I fund SOA. This is a backroom, not recommended way, but it is something I see happen in the real world. So what is your favorite among these models?
The best model for funding SOA is the enterprise model. I typically recommend that. But most customers are sitting either in the project-based model or they are trying to use the IT funding model. In those two cases, I recommend getting an enterprise funding model established for the SOA initiative. That's important because it gets the business involved in the SOA program rather than have it being done off to the side. And if that fails?
Then you try to work with the project model if that's all they have. You play the game on the field you're given.
Tuesday: Making the business case for SOA funding.