Joe, While I am bullish on the concepts that constitute SOA (modularity, distributability, discoverability, sharability, loose coupling), I am less bullish on the name "SOA" given how it has wound up meaning just about anything anyone wants it to mean.

As for the "18 month" comment, I was using "SOA" somewhat tongue-in-cheek. What I was referring to was the SEC announcement in 2008 that between now and 2011 it will be phasing in mandatory use of XBRL for financial reporting into the SEC.

Since the audience was primarily composed of IT employees of public companies regulated by the SEC, I thought I would highlight that "everyone" will have to use the automated SEC reporting service to deliver their 10Qs etc. in the form of XBRL. This is what I meant by "you’ll all be doing SOA in 18 months or so".

But of course, one isn’t really "doing SOA" unless the system one creates using services is modular, distributable, discoverable, sharable, and loosely coupled — something I pointed out later in the talk.

Feel free to add your 2 cents either here or on Joe’s post.

While I agree with many of the sentiments behind Anne’s declarations that “SOA is dead”, I disagree with her way forward: “long live services”.

It is services thinking, as conventionally understood, that led to the mess in which we find ourselves: fragmentation caused by entity-specific (service) interfaces. I’d say instead, “long live the web.” I’m shocked that Anne’s blog post does not even mention the web!

I agree when Anne says, “it requires redesign of the application portfolio. And it requires a massive shift in the way IT operates.” But the disruptive redesign required is to make IT more Web-like — both in the architecture of software and in the way the ITO operates.

The most “spectacular gains” we have are those of Google, Amazon, and even Salesforce. What they have in common is an embrace of the Web, including web architecture, web community, and web business models. To paraphrase Anne’s blog post:

“Web-orientation is a prerequisite for rapid integration of data and business processes; it enables situational development models, such as mashups; and it’s the foundational architecture for SaaS and cloud computing.”

Because of such consensus, the note can put forward Gartner positions such as:

• Interfaces based on WS-* specifications should be constrained by WOA, especially the generic interface constraints.
• More often than not, the WS-* protocol toolkit is unconsciously misused to create needlessly specialized interfaces.
• Application neutrality should be the principal goal of an interface, and implementation neutrality should be a secondary goal.

While I can’t share the entire note with the blogosphere, I can share a couple of highlights — first and foremost the official Gartner definition of Web-Oriented Architecture:

WOA is an architectural substyle of SOA that integrates systems and users via a web of globally linked hypermedia based on the architecture of the Web. This architecture emphasizes generality of interfaces (UIs and APIs) to achieve global network effects through five fundamental generic interface constraints:

1. Identification of resources
2. Manipulation of resources through representations
3. Self-descriptive messages
4. Hypermedia as the engine of application state
5. Application neutrality

Those of you familiar with Roy T. Fielding’s REST Thesis will no doubt recognize that WOA’s five generic interface constraints are an extension of Roy’s four uniform interface constraints. The one additional constraint, application neutrality, is implicit in the thesis, but we think it is so fundamentally important that we made it a "first class" constraint.

What is application neutrality? Here is a brief excerpt from the 13-page report:

The primary problem with the specifications known as WS-* (such as SOAP, WSDL and UDDI) is that their principal emphasis is on implementation neutrality. All the specifications focus on generalizing away the details of specialized middleware technologies, so that services can be accessed using any one of those technologies. Although this is not an unworthy goal (especially for vendors of specialized middleware technologies), it shifts the focus from the generic interface constraint of application neutrality.

Application neutrality should be the principal goal of an interface, because it is precisely this characteristic that enables shareability (a fundamental SOA principle). In other words, interface designers’ primary goal should be generic, application-neutral interfaces, which generalize away application-specific details.

The key to shared use (reuse) is a generic, application-neutral protocol, such as the Atom Publishing Protocol (APP) or Google’s GData Protocol. Conversely, the more application-specific a protocol is, the less shareable it is. With sufficient generality, the most powerful kind of reuse becomes possible: serendipitous reuse. So important is this kind of reuse that Tim Berners-Lee and Roy T. Fielding have highlighted it an essential characteristic of the Web:

• "Unexpected reuse is the value of the Web" (Tim Berners-Lee)
• "Engineer for serendipity" (Roy T. Fielding)

In terms of Gartner’s hourglass model for identifiers, formats and protocol operations (IFaPs), application neutrality makes the top of the hourglass wider; implementation neutrality makes the bottom wider. A wide top is more important than a wide bottom. In other words, generic application protocols (application neutrality) at the top of the hourglass are more important in creating powerful network effects than portable implementation protocols (implementation neutrality) at the bottom of the hourglass.

…

The key to generic interface design, WOA-style, is nested generality: gradually specializing generic interfaces in small increments. Whatever level of generalization one begins at — whether it is at the APP-envelope level or the SOAP-envelope level — it is a mistake to embed application-specific schemas and identifiers in either envelope.

Don’t just build on generic interfaces; build up generic interfaces that are only slightly less generic than those built on.

One last point highlighted in the note: let’s not get into a battle over names. If you don’t like the name WOA, call it REST, or ROA, or Web Architecture, or Fred. "The goal is to focus on the key generic interface constraints that unite these concepts, not debate the nuanced differences among them."

We’d love to hear your feedback on this key set of concepts –especially application neutrality — whatever name you choose to call it!

I’m calling [Bull****] on Business-SOA, which I interpret as business-only SOA, ie believing that technology is basically irrelevant to the success of SOA because "good" business-only SOA can work with ANY technology, including smoke signals. That’s pure fantasy concocted on PPT slides. Hence B-SOA (business-only SOA) is BS-SOA [bull**** SOA].

T-SOA (Technology-SOA) is just as bad. It believes that business-issues don’t matter because SOA technology is so powerful and wonderful and magical that the mere purchase, deployment, and technical training in WS-*, ESBs, Registry/Repositories will improve the business automagically. T-SOA (technology-only SOA) is also BS-SOA [bull**** SOA].

Marc: “Your application? It’s all metadata.”

Marc: “We run your metadata.”

I find it refreshing that Marc calls this concept “metadata driven” instead of the more hifalutin “model driven”.  The term “model driven” has LOTS of baggage.

One other comment that made me smile was his observation that people have only recently made this connection between metadata-driven and SOA. I smiled because I’ve been talking about it since 2001. I even blogged about software as infrastructure and metadata as application and SOA back in 2005.