Let's focus on the demand organization for a minute. When business units each have their own demand organizations, who should control them, IT or the business?

RAU: Let me make an analogy: The finance function often has controllers embedded within the business units. If the controllers have a solid line into the CFO, they can discharge their fiduciary responsibilities to the corporation overall while also helping their business units. In general, if you follow this same approach with IT, you can have these demand organizations report solid-line into the CIO and dotted-line to the business units and help make sure that no one is overspending on projects. In this way, the demand organization has some real power to control the budget.

MARK: You'd need a fair degree of maturity to have the dotted line be to the IT organization rather than to the business unit. Theoretically, once the demand and supply organizations are up and running, and the governance processes are mature and stable, you can imagine that eventually flipping around to consisting of a heavier tie to the business and a dotted line to the IT organization. But I don't think we've seen that anywhere yet. And there's a risk in that scenario, in which the relationship managers in the demand group may not necessarily have the kind of backbone they need. For example, they may not feel comfortable telling their business unit: "Hey, we should use this system that already exists in another business unit and extend it." They may become more like order takers for their own business.

How about this scenario? Given that CIOs constantly complain about their huge project backloads, wouldn't the demand units eventually get frustrated and say: "Forget it. I'm going to go outside and get someone else to do this." Then the credibility of your supply organization — and by extension, IT in general — will suffer, won't it?

MARK: If anything, splitting supply from demand helps with the overall planning because you gain more transparency and better clarity into what's being demanded, what's being supplied, and how well the supply side is functioning and interacting with the demand side.

But, of course, if the performance isn't there, it will become more transparent under the split that we're talking about, and it will highlight the issue.

RAU: If you can build this collection of demand organizations that have a strong value system and really work closely together, they should be able to make decisions that are in the best interest of the organization as a whole.

You say something revolutionary when you argue that IT should unequivocally own business process. What self-respecting businessperson is going to agree to that?

RAU: We do really see this trend that ownership of business process has been moving from something traditionally inside the COO organization, or other parts of the organization, into IT. Businesspeople are tired of their processes being broken and their IT not working right.

I often hear businesspeople say: "I'm the one who bought the SAP system, and I'm the one who'll determine how it's configured." I sense a lot of reluctance on the part of the business — at least those that really care about IT — to give up the specification, or requirements, phase of IT.

RAU: We get a sense that there are certain parts of the workflow that the business may want to retain, but there are plenty of parts that they want to get rid of. And they don't necessarily feel like they need to own the entire process end to end. I think this has been a huge problem for many IT organizations. Business process is a little bit of a red-headed stepchild. I mean, nobody knows exactly where or how to fit it into the governance model, or the development model, and it has tended to shift around a little bit in terms of ownership. And I think it's a root cause of a lot of pain between business and IT.

MARK: System specification and implementation planning in business process are getting so welded together that you need a capability that is at a fairly detailed level to specify the business process, and then sync it into the technology plans that are being developed. So I think if you're the head of sales and marketing, you're clearly going to be involved in speccing out what your business imperatives are, what your high-level process looks like and how that marries to your objectives.

But then there's the translation of that into the specific technical architecture, the components and the requirements that the business is willing to part with. I think putting it in the demand organization is actually a pretty attractive idea. It gives you sort of a natural home to weld those pieces together.