One of the big questions about SOA is how to fund it. Creating services just doesn't lend itself to project-by-project funding in the same way traditional integration projects do. In fact, SOA is somewhat unusual in that its cost actually goes down the more you connect to the services.
So, who should foot the bill for services that help the whole organization?
I've seen theoretical discussions of how you can fund the creation of services, but I've never seen a piece so exhausting in its calculations as the lengthy analysis published today at SOA World.
It's written by Marc Rix, an SOA solutions architect at SAIC. Rix points out that, so far, there hasn't been a good model for comparing SOA development costs to traditional point-to-point integration projects. As a result, companies often start out with good intentions, but are turned off by the immediate, higher costs of SOA development. In turn, they decide "SOA is just too expensive" and revert to what they know best -- point-to-point integration.
What Rix does is take the long view of paying for SOA versus point-to-point integration. While P-2-P may keep costs down on a per-project basis, it actually costs the business more in the long run.
Ultimately, he doesn't provide an easy answer for "who pays for SOA," though he does raise a few good points for why it's in IT's best interest as a strategic partner to commit to SOA over point-to-point integration.
Put on your accountant hat and check it out.