A recently released report on SOA from ZapThink contained a tidbit that has huge implications: IT departments aren't creating specific budgets for SOA initiatives. Instead, they're using the SOA approach on projects funded to solve specific business problems.
The obvious implication is that IT departments are finally aligning more closely with business goals. But there's another, larger issue: In general, who's going to fund SOA projects?
Think about it. Department A creates a service like "currency converter" (the cliche example), but it ends up being used 90 percent of the time by Department B. Should Department A still have to pay for its maintenance? Should the cost be split 10/90 between the two departments? And oh, by the way, who's tracking usage, and who's paying for that?
These kinds of problems, which have nothing to do with technology, are going to increase. And there's another non-IT constituency besides the accountants who may start to make trouble for SOA.
After all, the services that comprise an SOA are intellectual property. And when services get exposed outside the firewall -- a likely event given the integrated nature of modern supply chains -- who knows what will happen next. Our guess is, whatever happens, legal won't like it.
The net here -- no pun intended -- is that as SOA emerges from the lab and makes its way into the real world, IT managers are going to have to deal with a lot more than XML, SOAP, UDDI and WSDL.