May 24, 2007
I’ve been running across a number of articles lately (e.g. here and here) that attempt to reconcile the concepts of SOA and Web2.0; or at least define them adequately to describe how they fit. They obviously share a number of concepts and a lot of terminology, but also differ in some fundamental ways.
It is probably an over simplification to describe SOA as an IT-department driven mechanism for planful standards-based line-of-business application integration and Web2.0 as more of an emergent phenomona, but it is a starting point.
In the commercial world that demarcation between “web” and “enterprise” is much more clearly drawn, and there is more shared language and understanding around what they mean. If it is integrating my line of business applications, connecting my trading partners, and it uses “middleware” to implement “SOA” it is “enterprise.” If it is consumer oriented, customer facing, or based on REST/LAMP it is “web.”
The DoD unfortunately lumps everything together under the SOA and NetCentricity aegis. I think this creates lots of confusion since most people still equate SOA with web services. For example, when we talk about discovery are we talking about web-like real time content discovery, or are we talking about SOA-like design-time service discovery (for example)?
The interesting thing is that the DoD is so big, more of a super enterprise really, that there is room inside of it for both concepts. Inside an enclave, the typical enterprise concerns related to application integration and “trading partner integration” with other enclaves are key. This is IT-driven SOA stuff.
But there is also lots of room in the seams for web and web2.0 constructs. Search, mashups, widgets (www.programmableweb.mil anyone?), rapid composability, dynamic provisioning and the like.
Consider something like NECC to illustrate the point. NECC at the back end is really a collection of capabilities brought about by integrating existing systems (either as SOA integration of existing runtimes, or by actually creating a new runtime from existing pieces – the strategy right now isn’t clear). It needs traditional IT-managed integration to bring together situational awareness feeds, targeting databases, geo-spatial and imagry data, and etc. There will also need to be “traditional” thin and thick client access to all this stuff.
However, the real interesting part starts when NECC exposes a set of REST-based API’s of the type that Yahoo or Amazon would build if they were creating NECC and maybe also implements a widget library. Imagine users being able to add these widgets, subscribe to a variety of RSS feeds from NECC and other systems, use things like Yahoo Pipes to combine them, and etc. All without having to go through another C+A process because no new code has been written.