Accounting for Use

A common cause of the failure of reuse has little or nothing to do with technology, Pulier says. Rather, reuse often fails because organizations are made up of multiple fiefdoms filled with people seemingly more interested in competing than cooperating with other divisions. So the business unit leader who invests $1 million from his own budget on building a system may be determined that no other area will get credit for the work unless they are prepared to stump up some serious cash.

To address this unhelpful culture, organizations should develop an internal reconciliation model to deal with such attitudes and to track who is using what and how. But since most applications are not built with reuse in mind, someone also has to figure out how to present service level agreements across the organization so that different aspects of the organization feel comfortable that they can use these services.

Unless those dramatic problems are addressed, Pulier says, an SOA can be inefficient and inadvisable. Take security. In the past most application developers did not have to deal much with internal security because they were only building applications for their own area. Often enough, too, those applications were built in such a way that their intended users could hardly access them, let alone third parties in other parts of the company. Now, thanks to open standards, those developers are creating applications that can be readily accessed by anybody, internal and external to the company, since the integration costs and complexity have fallen dramatically. That means you now have to think about security in a completely different way.

Organizations that fail to appreciate that new reality will likely have to learn the hard way, Pulier says.

"The way that organizations tend to look at these things is that they fail to appreciate the need early on. Then they start to appreciate it and they start to build their own tools and proprietary systems to overcome these problems. They end up with essentially just another proprietary system because they've patched up all these issues of security and management and quality of service and governance in their own way, rather than trying to understand the standardized manner that these problems have been solved by the industry," he says.

Further, Pulier says, the efficiencies an SOA should offer are only achievable with a move towards a more standards-compliant operation. Unless the organization is prepared to adopt those standards it is likely to end up in a worse situation than it faces today, because it will add latency to the interactions between systems, he says.