This topic came up on day two of The Open Group's Enterprise Architecture Practitioners Conference in San Diego. The term "Web 2.0" refers to a second generation of Internet-based services - such as social networking sites, wikis, communication tools, and folksonomies - that emphasize online collaboration and sharing among users. It features the combination of services provided by external enterprises to create so-called mashups of information drawn from different sources, and the exposure of core capabilities as services that external enterprises can use.

So each enterprise will do what it is good at, and mix and match the best information from outside sources to deliver a complete package. This sounds like a recipe for real progress. Where is the problem?

What concerns many people is the lack of discipline and control. With the latest tools, it is easy to create mashups, but will their creators take the trouble to maintain them in the long term? Where services are combined without proper transactional control, how can data integrity be preserved? How can distributed development work without central governance?

These are serious questions. The short answer to them is that companies such as eBay do expose core capabilities as web services, and other enterprises do use them. This may be a new phenomenon, but there are working examples today, and we can expect the art of using and combining external services to become better understood as it is more widely used.

This art lies in creating an environment in which collaborative operation can take place and evolve, rather than in trying to impose central control on all services used by the enterprise. Architects who insist on controlling everything should indeed be frightened. For the others, the convergence of SOA with Web 2.0 is an exciting prospect.

There were presentations from John Whitridge, VP, Enterprise Architecture at Marriott International; Maja Tibbling, Lead Enterprise Architect at Con-way; Robert Roth, Director, Shared Development and Services at Intuit; Toshiro Kawamura, Executive Advisor at NEC; and Takashi Kawakami, General Manager, Enterprise Architecture at the Global IS Division, Nissan - architecture decision-makers in corporations that are household names. They told a consistent story. SOA delivers real benefits, but you can't just say "Let there be SOA" and switch it on like the electric light. It needs a smooth transition - no "rip and replace", as John Whitridge put it. And it can take three years, from the decision to go SOA, to roll-out of mainstream services.

So what are the blockers? Eric Knorr, Executive Director at InfoWorld and a man with his finger on the pulse of SOA, moderated a vendor panel session on breaking SOA bottlenecks. On the panel were Sam Ceccola, Deputy CTO in the Office of the CTO at BEA Systems; Oleg Figlin, Senior Solution Architect in the SSM Solution Office at SAP UK; Alex Heublein, HP Distinguished Technologist; and Rob High, IBM Distinguished Engineer and Chief Architect for WebSphere Application Server Family. Their analysis identified some significant problems.

First, there is the need to sell the SOA dream. This is hard because the business value is not purely - or even mostly - financial. There are other benefits, such as improving customer satisfaction. An indirect approach may succeed where a direct attempt to calculate ROI would fail.

Secondly, it can be hard to derive the SOA implementation from the business process model. There is an ingrained disposition of IT staff to look at business people as though they came from Mars. SOA can help to break down this barrier. But it is really down to the enterprise architect to bridge the gap.

Then, there is the "G word" - governance. The very effectiveness of SOA in enabling large-scale solutions leads to problems, as the difficulties can spiral out of control. When you add mashups and Web 2.0 to SOA, you are in the Wild West. Dictatorship doesn't work, and neither does anarchy. A balance between these extremes must be set, to meet the needs of the organization, but without killing creativity.

Incorporation of commercial off-the-shelf products can be difficult. The value of SOA is to take customization out of each of the purchased applications, and to put it on top of all of the purchased applications. But it isn't always easy to see how to do this.

Finally, there is security. There are two major problems. A big selling point for SOA is that it gives control to the business people - but these people are often not security-aware. And it is easier to integrate the functionality of stovepipe applications in an SOA environment, than it is to integrate their security mechanisms.

Despite these problems, SOA is delivering real benefits. Maja Tibbling reported that the time for a truck to cross the US/Canadian border had been reduced from 2-3 hours to less than a minute, because of collaboration with customs authorities in an SOA environment.

This is an example of another interesting development. SOA between enterprises is becoming a reality. SOA generally starts within a single enterprise. We are now seeing serious cross-enterprise SOA.

The gestation period of SOA seems to be about three years. The early adopters now have production-quality SOA. Their evidence is that SOA delivers on its promise. There are difficulties, but they have been overcome.

There are many companies following the early adopters. They should be encouraged by the early adopters' success, and learn from their experience. There are problems with SOA, but we know how to deal with them. SOA is the architectural style of choice of today. SOA has come of age.