I confess that I haven’t kept myself abreast of SOA developments. I mean who really has the inclination to pursuing this subject when its very definition keeps changing with the wind. I checked and it appears that the last time I had blogged about the subject was way back in early 2007. I have always been more inclined to supporting a Web Oriented architecture. There was a time where I aggressively argued the advantages of ReST. Nevertheless I have always felt exasperated debating with SOA advocates in that it was never easy to pin them down on a definition.
Back in 2007, a Oracle and Gartner decided to co-opt SOA and christen a new version called “SOA 2.0″. That immediately created a massive uproar among the SOA community claiming that it was senseless to give a version to a concept even if at that time it remained quite nebulous and fleeting in its definition. At that time, I however argued that SOA 2.0 may in fact a good thing. It was an opportunity to pin down a SOA definition. My argument was that a 2.0 version implied that there indeed existed a 1.0 version and that version was in need of a healthy revision. The SOA community however never acknowledged SOA 2.0 thus never acknowledging the existence of 1.0 version. So it turned out there little sense to revise something that doesn’t exist.
In 2007 however I conjectured a different revision to SOA. It turns out that Oracle and Gartner were not the only one defining “SOA 2.0″. Richard Veryard in 2005 was defining something else. He wrote about a bottom-up decentralized process of building SOA that could potentially leverage Web 2.0 ideas. Gregory Hohpe, of Enterprise Integration Patterns fame, had his own insight that there was likely some value in pursuing agile ideas in combination with SOA.
By late 2009, the SOA community got together and finally agreed on a what they called the SOA Manifesto. It took close to a decade for SOA proponents to finally to draw the line in the sand and make a commitment to something that appears to be a definition. One cannot fail to notice the intellectual dishonesty here in that these folks have pitched SOA for years without ever clearly defining what it meant. Nevertheless, this development is a very good event for the Software Development community, SOA now has an established definition and it is no longer a moving target.
Let me attempt to deconstruct the SOA manifesto in attempt to gleam some insight into the its definition of SOA.
SOA according to the manifesto is the architecture that arises from applying service orientation. It is indeed curious that “service orientation” here is not a proper noun. The manifesto states a value system and a collection of guiding principles.
The SOA value system is paraphrased below as:
- Business Value. Technology for its own sake should be avoided.
- Strategic Goals. You can’t really talk about SOA if you aren’t looking at the big picture.
- Intrinsic Interoperability. There’s this notion of ‘intrinsic interoperability’ that needs to be achieved.
- Shared Services. Services are to be designed to be shared (note that reuse is not the termed used here).
- Flexibility is preferred over optimization (typical trade off is flexibility versus efficiency).
- Evolutionary Refinement. SOA doesn’t attempt to boil the ocean and an incremental approach is preferred
The remainder of the document describes guiding principles. Here’s a quick take for each of the principles:
Respect the social and power structure of
the organization. – Sounds like being mindful of Conway’s Law.
Recognize that SOA ultimately demands
change on many levels. – If you can’t convince everyone, then you could fail. This statement seems to run counter to the idea of evolutionary refinement.
The scope of SOA adoption can vary. Keep
and within meaningful
boundaries. – Look for low hanging fruit and quick wins to show success.
Products and standards alone will neither
give you SOA nor apply
orientation paradigm for you. – Don’t just buy technology, hire consultants as well.
SOA can be realized through a variety of
technologies and standards. – Breaks the bonds completely from WS-*.
Establish a uniform set of enterprise
standards and policies based
de facto, and community standards. – Don’t attempt to re-invent the wheel.
Pursue uniformity on the outside while
allowing diversity on the inside. – Some kind of notion of polymorphism and encapsulation going on here.
Identify services through collaboration with
technology stakeholders. – Don’t design in a vacuum, get people involve. What about the consumers, do they have a voice?
Maximize service usage by considering the
future scope of utilization. – Plan for change.
Verify that services satisfy business
requirements and goals. – Get customer feedback.
Evolve services and their organization in
response to real use. – YAGNI principle.
Separate the different aspects of a system
that change at different rates. – Probably the more interesting guideline here. Usually, architecture layering is the approach here, however I am unclear if there are other mechanisms to do this. If this is to imply the notion of ‘separation of concerns’, then I’ll be really disappointed.
Reduce implicit dependencies and publish
all external dependencies to increase
robustness and reduce the impact of change. – One of the better guidelines, a generalization of the idea of the utility of documenting or even exposing for machine consumption a services dependencies.
At every level of abstraction, organize each
service around a cohesive
unit of functionality. – A.K.A. Cohesion.
First observation is that I would have liked to see more coherence between the value system and the guiding principles. Which guiding principles encourage ‘intrinsic interoperability’, ‘shared services’, ‘flexibility’ or even ‘evolutionary refinement’? I mean, its disingenuous to claim a preference for an objective and then provide very few principles to help you achieve those objectives. Identifying separation of concerns, managing coupling and cohesion are all important, but could someone please provide some unique insight here?
Second observation is that most principles appear to be what any best-practice document for software development would recommend. Work in manageable chunks, technology doesn’t cure all ills, don’t re-invent the wheel, get customer feedback, layer your system, manage coupling and cohesion. The set of principles of the SOA Manifesto are stating the obvious and don’t lead to any better clarity or differentiation as to any other software development methodology.
So there it is, I’ve gone through the document and am feeling quite unimpressed. Most of what is contained in the guiding principle are practices that are well established. I can’t see why anyone would disagree on any of them. It is however disappointing that it is supposed to be
One would think this value set of Intrinsic Interoperability, Shared Services and Flexibility. Unfortunately, it isn’t new at all, it is as old as the concept of Modularity. I’ve written about this in “SOA and Modularity“. The value statement can thus be refined to a single statement, “We believe in building modular systems through evolutionary refinement (and intrinsic interoperability) to achieve business value and satisfy strategic goals“. Who can’t agree with this statement? Are we saying that there exists practitioners in software development who still subscribe to the complete opposite (i.e. believe in building monolithic systems taking a big-bang approach (and incompatible modules) with the intent of avoiding creating business value and compromising the strategic goals)?
I could be asking too much from this document. To its credit, SOA finally has a clear definition, that is any architecture that arises from a process that intends to achieve business value and strategic alignment though the evolutionary refinement of modular systems. Although this statement may appear to be obvious, I wouldn’t be surprised that there a few people out there espousing a big-bang monolithic solution. SOA may just turn out to be one of the more agile enterprise architecture frameworks in circulation.
The other beneficial conclusion I see is that SOA divorces itself from the requirement to support WS-* based standards in a SOA initiative. That in itself is reason to celebrate.