Much of contemporary SOA thinking is centered around the notion of very loose coupling. So thinking goes, tight coupling leads to nasty brittle enterprise systems which resist change and over time become a costly legacy. Conversely loose coupling allows individual systems (applications, databases, etc) to be evolved much more readily.
And to be fair, this seems like a sensible notion - if our systems are decoupled from each other then localised changes should be a breeze. Indeed most of the SOA bookshelf currently blighting your local bookstore carefully build towards to the notion of loose coupling of systems as the default and desirable state of an enterprise system.
I beg to differ. (But you might have expected that if you follow this blog.)
You see, back in the day, I attended a class or two at university and had the good fortune to be taught elementary software engineering by Prof Pete Lee (who was, despite my best attempts to get thrown off my undergraduate course through general laziness and ineptitude, later to become my Ph.D. supervisor). Now Pete is an old hand at this software stuff and he duly taught us that loose coupling is one of the keys to good software design and by extension good enterprise systems. But Pete didn't get caught up solely in loose coupling because he was sensible enough to see it as just one of the axes against which good software design can be measured. A further key metric, much forgotten about in the rush for loose coupling, is cohesion, which can be usefully defined as the "measure of the extent to which related aspects of a system are kept together in the same module, and unrelated aspects are kept out."
In fact good software tends to be both loosely coupled and highly cohesive which is really easy to visualise:
As the graph shows, software which is both loosely coupled and highly cohesive tends to be good. Software which is neither loosely coupled nor cohesive is superbad, and I really mean superbad (don't click if you're at work or easily offended) in most sincere sense - it's so gross, messed up, and adolescent it's actually funny.
Which brings us to the merely bad software - including all that loosely coupled stuff.
Some software is highly cohesive in design, but tightly coupled. This means though it may be logically laid out, it's tough to change because of tight interdependencies. That's pretty bad, and unfortunately also common for enterprise applications. Remember that software which really wowed you a few years ago but is much more of a pain to maintain than you'd like? That's because it's tightly coupled.
The other kind of bad software is loosely coupled but lacks cohesion. That means that there are few explicit interdependencies between modules, but none of the modules are necessarily authoritative about any particular aspect of the system. This in turn results in a scattergun approach to ongoing system evolution as even minor changes ripple through multiple components or systems. Or SOA as we have come to know it nowadays.
Now have a look back at the first diagram where we have our wonderfully loosely coupled SOA. Go on, have a good old stare at it.
On the one hand we're inclined, and indeed encouraged by the SOA brigade, to think of this architecture as a good fit for purpose because it is very loosely coupled. Since every component or service is decoupled from every other component or service it should be possible to arrange and re-arrange them in a Lego-style in a myriad of useful ways. Building out "business services" from some more fundamental set of services is how the books tell us to do it. In fact we could even do that quite easily with point-and-client BPM tools, ruling out such overheads as developers and change management along the way. Right?
No. In fact absolutely wrong. It falls victim to the what I'll call the Ford-Lucas paradox[*]: while you can write books about it, this is an architectural fantasy that has no place in real world enterprise systems. In fact a service that does not address a business problem has no right being in an SOA (and yes, security is a business problem so there!).
Take a look at the SOA diagram again and try to pick out where there is high cohesion between the services and databases. Even though it's a low resolution diagram, it's obvious that there isn't much about SOA du-jour that encourages cohesion - in fact low cohesion is a by-product of this architecture to keep those services and databases general enough to be recomposed by the BPM toolkit. And we all know how successful that is: Not very.
But there is a more sensible way to SOA, which maintains loose coupling and drives high cohesion and the secret is this: build your services to implement business processes. Don't let the data guys scream at you that you need an enterprise data model (you don't) and don't let the application portfolio guys demand that you buy everything and stitch it together later (you can't, this only gets you Frankenstein systems). Instead talk to the business guys and understand their processes, their workflows. Help them to prioritise which of those processes or workflows are most important, and then build out a service that implements that process. Don't forget to include the business-centric messaging (if you're SOAP-y) or resources (if you're Web-y) that the process uses to enable it to be consumed by other processes across the enterprise (or even more widely).
If you're confused about how to build such a service, it's just an instance of MVC:
Now find the next highest priority business process and do the same again, and again, incrementally driving out your enterprise architecture and tying back each part of that architecture to a crisply defined business requirement. You'll start to drive out a set of services which can be pinned back to business processes, which leads to a scenario where process composition and service composition are one and the same.
At this point now doubt I have irked a few people who would love to thrown in a couple of "governance grenades" about how this kind of loosely-coupled/highly-cohesive architecture is hard for architects to govern. And you know what? I agree wholeheartedly. Well, sort of.
An SOA isn't for governing by architects, not if it's done right. Sure I expect my architects to guide teams towards making excellent technology choices as part of service delivery. I also expect that my enterprise architects have a duty of care to the long lifespan of the enterprise over and above any one system or service. But this isn't where I want to govern my SOA, in fact I don't want to govern it at all: I want my business stakeholders to do that, because they own those business processes that I host in my services. In effect they own the services.
It might sound like a pretty dumb idea that my business stakeholders are to become (inadvertent) IT architects. After all these are generally people whose knowledge of complex IT systems barely extends past "turning it off, then turning it on again." Yet in reality they are the authoritative source of truth for business processes - those same processes that we reflect in our services. So when a process changes or is retired in the business world, the business folks (inadvertently) govern the SOA world - we change our services to continually match the business-level processes.
And all of this is possible because we thought about cohesion, not just loose coupling. Now just imagine if we used all those other metrics too...
[*] I coined this term from the crew's banter in the production of the original Star Wars film where Harrison Ford said to George Lucas, "You can type this shit, George, but you sure can't say it." It is amazing how often enterprise architects, SOA authors, and middleware vendors play the George Lucas role leaving delivery teams to pick up the slack and belt out a jolly good Han Solo anyway.
Update:Steve Vinoski's written about this too, although as usual somewhat ahead of me!