The Freak Parade

First, I should say I am a total neophyte when it comes to SOA or ESBs. I just stumbled into this SOA party, with my fanny pack and my walking stick and my perpetually bewildered expression. But as a neophyte struggling to understand concretely what I instinctively understand is a vitally important concept or movement or architectural style or religion or whatever SOA is, I must say my bewildered expression isn’t out of place. Many blog posts or articles on the subject open with a comment on how notoriously undefinable SOA seems to be – at least to the extent that experts in the field, whoever they are, can agree on something. There are some things everyone seems to agree on, though. The most prominent of these is “SOA is not a technology.” This is often followed with a stern warning about how you can’t “buy it”, it doesn’t come “in a box”. There also seems to be consensus among those who do a lot of thinking (or at least writing) about SOA that it is about “Business-IT alignment.” That sounds like a catch phrase to me that doesn’t communicate a whole lot of useful information, but I take it to mean that the practice of SOA is a holistic practice, business wise one that seeks to understand the larger strategic goals of the organization as a whole and organize and coordinate its myriad software systems and the business processes they support in service of the Big Picture, the Big Picture ultimately and inevitably being profitability (what else is there in this glittering capitalist wonderland of ours?)

And then there is the ubiquitous prejudice (bordering on hatred) that SOA and its practitioners seem to universally hold against the poor beleaguered “Silo”. (Oh Silo, who weeps for thee?)  And finally, to finish up the things everyone seems to agree on, it seems that SOA is definitely not JBOWS.

Oh, and SOA is loosely coupled. It is definitely loosely coupled.

However, none of those aspects of SOA says much about services or architecture, except maybe the loosely coupled part. Business alignment, agility, “not technology” – those seem like outcomes or goals of a particular type of architecture rather than a description of an architecture – or even a description of an architectural style (like the mud hut or Victorian mansion). Nevertheless, SOA is about architecture, because architecture is in its name – but it is the concrete part of the thing that seems to be in such hot contention – do you need WS-*, an ESB, must you have a regipository, should messaging be asynchronous, Request Response, point to point, brokered, RESTful, Queued, should services be layered, data oriented, process oriented oh goodness, just don’t buy it in a box! Because that WON’T be it!.

Well, it is all very confusing. You kind of have to pick a camp and do your designs that way, when you’re fresh meat like me and haven’t been seasoned in the fires. I myself have selected from the shelves a nice, fresh Bus based, business unit centric sort of approach to SOA a la Udi Dahan, but am still very curious about the others, the ones with repositories and registries and that use WCF and WS-* and REST and dynamic routers and whatnot.

Anyway I was reading Sam Gentile’s educational SOA series  and it led me to reading some other thingsand I came across a metaphor for SOA that finally made it click for me in a real way, and now I’m not so perplexed about all the various hotly debated approaches because they are just (very important but equally valid) different approaches to a unified, relatively stable vision of what SOA is – because SOA is technology, of course, and it is architecture, but it isn’t a style of architecture, like mud huts VS Victorian mansions, it is a scope of architecture, like Building Design VS Urban Planning. SOA is about turning ad hoc communities of software and process into an integrated economy composed of towns that are part of larger counties that are part of larger states, and so on. SOA is about the design and execution of the master plan, the infrastructure and government and laws that all of an organizations IT entities must follow to enable peaceful, productive commerce all around. And what isn’t mandated by the law of the land is left up to the organizational units to rule themselves and their component sub communities as they please. How autonomous of them. All very hierarchical and organized. I also suspect (based on what I’ve read, mind you, not what I’ve experienced) that SOA’s often tend to grow like many cities, patches of disorganized systems agreeing to abide by a common set of rules, setting up transit systems and infrastructure between them, and these become cities which become models for other areas of the organization to follow suit.

What I like about this metaphor is that it captures many of the individual desired outcomes of SOA pretty nicely in your brain, and this is important because trying to picture what “driving increased strategic business agility and alignment into the enterprise” looks like in a way that can help you build it is a rather tall order.

For instance, perhaps each LOB application is something like an individual business or even a person who has some autonomy, makes some decisions for himself, but for the most part he must communicate in a language common to his local community and must follow the local customs, such as a specific technology stack. The larger communities to which each citizen belongs have more autonomy as a group. Maybe these are Services. They have their own culture, their own customs, and by and large they do things their way. But as a unit they must participate in the larger economy, they must import and export goods and services to other communities in an organized, coordinated way and report progress and pay taxes to the governing body and so on. Therefore at least those members of each community (endpoints) charged with conducting business on behalf of the community must,  in addition to understanding local culture and customs, also speak the national language, convert local money into a common currency, understand the global business protocols.

Clearly, you can’t “buy” something like this – you don’t march into to the wild west and order your “city” from the Sears catalog (or your favorite vendor), complete with a set of laws and a functioning government. You can buy a bunch of concrete and tools (such as WCF), or even a fully functioning subway system (such as an ESB), but the thing itself, the transformation of wild tribal cliques into a coordinated, modern, centrally governed “society” of connected systems, must be built piece by piece, tailor made, using many different kinds of physical infrastructure along the way as appropriate while implementing appropriate rules, laws, protocols, etc. For the whole rogue crowd to work together in a single, functioning digital economy you really need to gather the tribal chiefs and understand their needs and get participation and buy in because if you don’t then if not an outright revolution at least a certain amount of subversive activity is certain to undermine the functioning of your new society. No vendor can sell the solution to that.

Incidentally and off topic, this paints me a nice image for JBOWS. I like to imagine taking disparate groups of people over a wide geographical area who all speak different languages and dialects and have totally different cultures and giving each of them a telephone and a set of phrase books and expecting them conduct meaningful and efficient commerce. Throw a phone book in the mix and you have JB
OGS.

So anyway, this may or may not resemble what people mean when they talk about SOA, but it is what I have managed to glean, academically speaking, from all the shrapnel that is flying around.