That is because in the real world CIOs face multiple hurdles during deployment of SOA, starting from when they first "get their toes wet" and continuing through to total SOA immersion. The hurdles begin with the need to define a security model, as Boubez relates.

"As a CIO, let's say I have over the last five, 10 or 15 years been implementing and provisioning identity access control mechanisms into my organization. I also may in a lot of cases have implemented PKI. In some instances I have regular directory services such as LDAP or Active Directory. Maybe I have portals also that I have integrated somehow into those secure infrastructures. Now Web services comes along and everything gets routed through Port 80, right? So how do I deal with that new model, and much, much more importantly, how do I deal with that new model without having to rip anything out and start fresh? How do I leverage my existing security infrastructure into the service-oriented architecture that my architects — and I believe them, I have to trust my architects — are telling me is the way to go?

"The question is: can we do that using Web services technology today?"

Probably not. Consider the way Web services are supposed to work in the area of owned and managed inventory. In theory, Boubez says, when an organization wants to enable suppliers to manage their own inventory it gives them an entry into its inventory system so they can check product availability. Under Web services that means creating an inventory Web service and then creating and publishing the service description of that service to a registry like UDDI under the Publish, Find and Bind mechanism. The vendor of the procurement application queries that UDDI registry using the Find mechanism, gets the API and then uses that API to produce a request (the Bind mechanism) to send to an inventory where it gets the information it needs.

That is an approach that works brilliantly in the lab, but stumbles at the first hurdle as it hits the real world and the issues that organizations face in that real world, Boubez reiterates. "For instance, why would I expose my back-end systems on the Web? What about security, privacy, reliability?"

It is these issues, Boubez says, which make the potential of Web services a governance nightmare and make that policy abstraction layer so essential. "Typically, if you don't use that policy abstraction, that policy layer, you end up having your developers write the access controls into the code of the services. So you start with a particular project, a lot of times you have pilot projects, and you say: 'All right, I am going to make my inventory control or my inventory management system available to other applications through Web services'.

"So somebody builds that Web service and then they say: 'Well, wait a second, this can't just be open — we need to secure it, right?' So they go into the code of that service and they build some kind of access control. And if that access control mechanism changes again they will have to go back into the code of the service again.

"So now you have developers whose main task really is to resolve functionality or business logic, to actually start to build security and access controls into their applications. But much, much worse I believe is the fact that you are forcing developers on the other side of the requesting application — let's say one of your partners — to write code."

For example, Boubez says, an organization implementing vendor-managed inventory may want to give vendors access to its inventory controls. Suddenly, their developers are writing their security model into their own code, and if the organization wants to change its access control, those vendors will also have to make changes.