It’s nearly the middle of 2007 already and I’ve had occasion to sit
down and look at where Web 2.0 and SOA software models have evolved
lately. Partly it’s because we’re now seeing some of the bigger
software companies seriously embrace lightweight SOA recently, and it’s
also because we’re continuing to see more clearly that Web 2.0 and SOA
really are largely (but not 100%) the same concepts that merely lay on
different — if fairly different — parts of the software continuum.
Here’s the latest on this story.

For those not up-to-date on this trend, the fact that these two big
conceptual foundations in the software business overlap extensively —
and somewhat unexpectedly — appears to be a pretty important subject
for a number of reasons. One is that SOA is the dominant design
paradigm in business software today, with most software development
projects using some subset of it as their primary organizing principle.
The core principle of SOA is the decomposition of software into sets of
services which can be used and composed into new applications that have
a very high level of integration and reuse.

The second reason this convergence is important is that potent ideas
in Web 2.0 have been mapped back from what seems to be working best on
the often unruly, much less-organized, but considerably larger Web. Web
2.0 is more of a pragmatic extraction of what actually works best in
online product design than a rigorous a priori engineering
exercise. That both have arrived at largely the same endpoints on their
own, but with very different priorities and focus in some areas, should
not be understated.

SOA and Web 2.0 have also crossed over considerably around Rich Internet Applications and Ajax. Read ZDNet’s Joe McKendrick recent post for the latest on this story.

I’ve written in the past about the considerable overlap and convergence of these two popular software models. From my contrived or converging article exploring the early possibilities to my first Venn diagram
showing the similarities and differences, it’s been clear that Web 2.0
and SOA are closely related. Understanding the exact demarcations and
differences between the two, however, is driven by a couple of
realizations. One is that from a product design perspective,
understanding the advantages and disadvantages of each method
prescribed for creating your software can dramatically effect what an
online product can do in the market or for your business internally. Go
with traditional SOA and you’ll be able to leverage the advantages that
its design center confers. Go with Web 2.0 ideas,
and you’ll be able to take on a different set of challenges and be
successful in a very different environment and for different reasons.
But make no mistake, it’s fairly clear that choosing one of the other
can really matter to a project’s or product’s ultimate success.

Both conceptions do make one very important assumption, that all
software is part of a larger ecosystem bigger than itself. This idea
has been with us for a while, ever since distributed computing. But the
focus of software ecosystems has continued to move around over the
years, from computing, to services, to data itself. What’s the real
core? What’s the most important aspect of our applications? The
O’Reilly concept of Web 2.0 tells us that data is one of the
most important parts of our software applications these days, and this
is backed up by citing one world leading product after another that
took this idea seriously. SOA tells us that services are the
center of composition. That services in a SOA also transport data is
also important, but the focus in traditional SOA tends to be much more
on the seams of our IT systems than what makes them the most valuable
overall. These may be seemingly academic distinctions but the ongoing
struggle of SOA implementation in many organizations and the runaway
success of many a Web 2.0 application hints that this may indeed be
some very important hair splitting.

To show how SOA and Web 2.0 line up when compared to each other,
I’ve included in the diagram above my most recent update depicting the
overlap and convergence of the ideas in Web 2.0 and SOA. It paints a
clear picture of what the two have in common and how they are different
as well. Note: No depiction like this could be complete and this is
very much a work in progress. For this version, I’ve recently added security and monetization as
two core aspects that SOA and Web 2.0 share, but with varying degrees
of importance (SOA cares more about security, Web 2.0 cares more about
monetization of products and services.)

Another important item: The bottom of the overlapping circle contains a cryptic acronym near the edge of the circle: WOA. This stands for Web-Oriented Architecture, a concept that I’ve written about several times here and here
in this blog. It’s an idea that basically states that software that
goes naturally with the “grain” of the Web, extending the core
infrastructure of the Web in natural ways, works the best. Fighting the
Web and its standards is a losing battle and the products that embrace
it and play to its strengths seem to do the best, time after time.

Traditional SOA is based on a protocol known as SOAP, whose
strengths and weaknesses have been well-understood for a while now.
SOAP is not Web-oriented for reasons too detailed and technical to go
into here, but competing protocols such as REST, and now ATOM, are very
clearly Web-oriented. SOAP, though the foundation for many an IT system
that is increasingly being exposed to the Web, is generally not a great
protocol for Web-facing systems. This is one reason that Google got rid of its SOAP search API
late last year and it’s why Amazon offered it’s very commercially
successful APIs in both flavors (SOAP and REST) and the market place
chose REST.

My point is not to rekindle the seemingly endless REST vs. SOAP
debates, but to point out that the industry itself seems to be
confirming that this is an important lesson to learn. For example, my
fellow ZDNet blogger, Phil Wainewright, and myself recently had the
opportunity to look at Microsoft’s innovative Project Astoria just before release at MIX 07. Project Astoria, downloadable today in CTP form here, makes it possible to expose almost any ADO-compliant database as a set of granular, queryable URLs in simple REST form.

The reason that the ability to expose our data in WOA form is
important is this: One of the biggest arguments against traditional SOA
is that there are literally thousands of software platforms and
enviroments that presently exist in the world. And if they don’t speak
your unique flavor of SOA (SOAP and WS-*), interopability with them
won’t (and doesn’t) happen.

With WOA, anyone that can speak HTTP — the fundamental protocol of the Web — and anyone that
can process XML, which is to say just about every tool and platform
that exists today, can interoperate and work together simply, safely,
and easily and build applications on top of one another services.
Importantly, mashups are a key outcome of the trend towards WOA and
most mashups are based on REST or REST-like services.

So Project Astoria is literally an API server that Web-enables the
vast repositories of data that we are awash in within our IT data
centers and data warehouses. The fact is, our IT systems are still
largely unexploitable and unreachable until someone makes them
available in format easily consumable within our browsers and by the
vast landscapes of partners and suppliers that exist in the giant
network cloud of the Internet. Astoria is a solid example of how major
software companies are now committing serious and disciplined effort to
“WOA-ify” our traditional enterprise datastores and bring them into the
21st century to play in the world’s largest ecosystem, the Web.

Along with Project Astoria, Microsoft has improved its WOA story considerably of late. Read a detailed (and technical) new piece on how Windows Communication Foundation (WCF) has extensive REST support.

But WOA is but one aspect of the SOA and Web 2.0 story. Another key one is the emergence vs. planned debate.
So to is the role that users play, which is not a great one in SOA but
a vitally important and central one in Web 2.0. The upshot is that the
Web has provided a more proven model for how to integrate our systems,
design our products around our customers and communities, and focus on
the aspects that are most important to our businesses. SOA provides a
more engineered, predefined, and formal view, that satisfies perhaps a
larger number of important technical criteria but often seems to miss
the very point about what matters; that people are central to software
and it’s our data that is irreplaceable and of supreme market
advantage. And our software or services — necessary as they are — are
like electricity and network bandwidth are to our IT systems; essential but not the primary value.

Powered by ScribeFire.

tags « 

Technorati Tags: google, web, business, internet, design, software, blog, blogger, man, microsoft