When do Web Services Become a SOA?

There has been a long discussion on the Federal CIO Council's SOA Community of Practice around SOA and Knowledge Management and how to actually put together a meaningful SOA demonstration. One of the (many) valuable pieces that is emerging from this discussion is:
How to differentiate between Web Services as yet another point to point integration tool/pattern and Web Services as a realization of SOA.

First, we're recognizing that SOA must ultimately address the challenges of information sharing. Ultimately, the technical dimensions of the problem are the easy ones. The harder ones (even) to understand are not technological at all. Rather, they are the very same challenges that must be faced every day, in every line of business. IT, in general, and SOA technologies, specific to this context, are no exception.

The challenges are:
COMMUNITY
*Dedication throughout a community to overcome challenges to information sharing.

GOVERNANCE
*Agreements upheld by all stakeholders to identify information and capabilities to share (exchange).

PRIVACY
*Sharing and dissemination protocols consistent with privacy laws and regulations impacting all participating agencies.

CULTURE
*Overcoming community and personnel concerns that prevent effective sharing.

TECHNOLOGY
*Leveraging existing technology to integrate knowledge, consistent with the established rules of governance.

LEGAL
*Navigate the various laws and regulations impacting dissemination of sensitive and/or case-specific information.

I would suggest that any services (thus Web Services also) expressed as part of SOA must exhibit several dimensions as part of a litmus test for determining when a collection of web services evolves from a collection to SOA.

The proposal currently on the table from Paul Prueitt (see the mailing list):

Web-services (expressed with a SOA) must have the following dimensions
1) re-use that is measured against community transparent utility functions
2) agility measured as the ability to respond in novel circumstances, and to novel requests
3) governance that is open to inspection from stakeholders
4) commonality within a community or community of communities
5) competency that is measured at several levels including competency

Too often we see existing systems or information being “service enabled” simply by generating WSDL from the existing code used to gain access to the information. One of the key challenges is to get folks to understand why that type of step != SOA. As a first step, perhaps a demonstration that web services which are in fact a realization of the technical aspects of SOA must exhibit these dimensions BECAUSE they address the challenges set out above:
COMMUNITY
*Dimension 4

GOVERNANCE
*Dimension 3

PRIVACY
*Dimension 5

CULTURE
*Dimension 4,5

TECHNOLOGY
*Dimension 1,2

LEGAL
*Dimension 3,5

Globalization?

Here’s what’s fascinating to me – within relatively short order, the discussion of SOA and a particular demonstration of the applicability of SOA concepts to this context is not primarily focused on the technology aspects of the challenge. The same “lessons learned” will eventually be recognized in technology evolution, much as they are in cultural and societal evolution. While listening to an NPR newscast on globalization, I started thinking about how the characteristics of economic globalization may in fact also emerge in a truly service oriented technology system. Where do incentives come into play? What about middlemen, traders, brokers?

I posit that many, if not all, of the evolutionary patterns of the trading and economic system can be abstrated into the context of SOA.

Commentary on SOA Standards

David Sprott (CBDi Forum) recently published commentary "On SOA Standards". I believe you need to be a member to access the full text of the editorial.

However,a couple of very relevant excerpts:
“...SOA is very different to most of the IT trends that come sweeping through our industry from time to time. First as an architectural concept SOA is not primarily technology driven, rather it is technology enabled. Second SOA adoption is inevitably situation specific because the needs of each enterprise are driven by the existing and future business and technology situation. Third the real impact of SOA will only be realized by most enterprises when a critical mass of content as reusable services is available either from internal sources or from enterprise application vendors such as SAP and Oracle.”

“The core principle of SOA is about standardization and reuse of common functionality in many different contexts, in a structure that is architected and engineered to be evolutionary and to have a managed level of adaptability.”

“In a very short time, probably less than one year...vendors will find a new focus for their marketing dollars. But in the real world enterprises, systems integrators and developers will be embracing SOA practices and techniques and building them into their kit bag because it makes sense.
• Architects and developers will use concepts of contractual separation and reuse because it makes sense.
• Enterprises and their suppliers will embrace SOA, progressively solving critical business problems in a better way than they might have done previously:
• Introducing core business services to enable consistent data and business policy,
• Using process services to separate the process and application layers, and
• Creating utility services to deliver very high levels of reuse across the enterprise.”

We're a long way from the days of the Captain Picard in the Starship Enterprise simply telling the computer "Access data banks" to get a perfectly relevant response. However, there is growing recognition that standardization, re-use, and business needs should drive technology rather than hype driving technology. As we continue to head in that direction, long after the the latest and greatest of SOA products are phased out of technology petting zoos and into technology archives, we'll get closer and closer to the ultimate objectives of SOA.