It's the hot technology for most large companies, but business, technical and cultural issues must be addressed for a successful SOA implementation

The vast majority of companies and government organizations around the world today have set a service-oriented architecture (SOA) as their target. From a technical point of view, the decision is a no-brainer, because in truth, most organizations would seem to have little choice: in the past three years virtually every major technology company in the world has agreed to adopt Web services. After a generation of failed attempts this revolutionary accord is paving the way for organizations to connect - relatively simply and easily - computers running incompatible operating systems, programming languages and communications protocols under the SOA.

SOA is a potential boon to business because it simplifies IT, lowers costs and provides great agility in managing business processes. But while technical teams work with enthusiasm on projects designed to lead the organization to what they hope will be an SOA Nirvana, very few organizations have begun to address the implications of a service-oriented architecture for the organization and the new governance models it will force them to establish if they are to achieve their goals.

As a result, Eric Pulier, author with Hugh Taylor of Understanding Enterprise SOA, and presenter of a paper called "SOA Play Nicely" to last year's CMG conference in Orlando, Florida, warns that some organizations are unwittingly laying major traps for themselves by rushing to take up SOA prematurely. Worse, he says, some organizations have been conned by vendor hype into thinking a service-oriented architecture can be the answer to all of their prayers, without stopping to consider what they would need to do to make it so.

"They're not recognizing the issues," he says. "[Yet] because all the major platform vendors have adopted this as the normal course of business, every IDE, every development environment, naturally pushes you towards spitting out more and more services before you're ready. You need caution and you need to lay a real foundation first before you start rolling out services."

The fact is, Pulier says, SOAs blur traditional boundaries in large organizations. Until now, most IT initiatives demanded coordination between such distinct groups as software development, network operations, security, architects and line-of- business managers. Not so any more.

"Obviously the entire world has decided that these standards for interoperability are to be adopted as a means of achieving more efficiency in the enterprise," Pulier says. "But that means that the traditional boundaries of an organization will necessarily have to be rethought. That comes back to a fundamental proposition of an SOA, or one of the reasons for your trying to move towards that, which is reuse."

With the SOA potentially creating reusable software code that must be accessed dynamically by composite applications, both inside and outside the firewall, the traditional roles and responsibilities of IT have been forever changed, or even erased, he says.