Service Oriented Ambiguity Redux

I've been neglecting this blog in favor of my non-tech screeds for far too long now.  When I have posted, I've done so only to point out some particularly interesting (to me) ideas and opinions from others.  It's high time I put something out there that I'm particularly passionate about, so here goes ...

One of the things that has irked me over the past five or so years are the many myths and misconceptions around Service Oriented Architecture (SOA) (or, as Martin Fowler rightly labeled it, Service Oriented Ambiguity).  I'm pretty much in agreement with Fowler (as I usually am) that SOA has long become a hopelessly sprintered term that means everything from "SOAP" to "Business/Technology Organizational Transformation" and should be abandoned to the dustbin of techno history (not necessarily the things people mean when they say "SOA" but simply "SOA" itself).  Still, though the rampant hype has died down and replaced as the buzz word de jour by the equally ambiguous "Cloud Computing", SOA has stuck around.  So I'd like to at least state what it means to me, strictly from an technology architecture perspective.

Generally, I tend to follow Tom Erl's literature when it comes to service orientation, particularly his principles and the manifesto he spearheaded.  It quite literally means that your architecture is built and operates through the consumption and production of services.  Yeah, yeah - services don't necessarily mean web services.  Except that 99.9% of the time they do.  They certainly don't mean just any web services: RPC-based SOAP "services" are too often simply procedure calls wrapped up in http and XML dressing.  RESTful Services tend to be the most pure when they are really RESTful rather than just labeled that way (they all too often degenerate into "returning a bunch of shit wrapped in JSON/XML in response to a random http request").  Of course, the best RESTful services often follow a Resource Oriented Architecture (ROA), which is somewhat different.  REST != SOA.  REST is an architectural style, not an architecture.  Read RESTful Web Services for more details on ROA.  And check out the Web Oriented Architecture (Un)-Manifesto, which is not just about REST, but WOA is to my mind much more interesting than "SOA" ever was.

To get back to the point I'm trying to make, service oriented architecture means that the architecture of the system/platform/application itself is oriented around and talks services internally.  It does not necessarily mean that the system/platform/application exposes services for use by external entities.  You can have an architecture that exposes all kinds of wonderful web services for use by external clients and it might still be an ages-old monolith or a modern and perfectly reasonable component-based model. It's not necessarily service oriented.  I'd call it service exposed.  Likewise, you may expose no interfaces outside of the system itself, or you might publish an RPC API, but the internal architecture itself could still well be service oriented.  The interfaces exposed to the client should be orthogonal to the architecture of the underlying system implementing them.  Now, practically speaking, the two are likely to influence one another strongly, but the point is that they do not have to.

Software as a Service (SaaS) - and its offspring, Platform and Infrastructure as Services - also get intermixed into this equation. SaaS as a term predates SOA by many years but is more popular than ever now, while its much-hyped children, PaaS and IaaS, are even more the rage with Cloud Computing at the forefront.  But each of these qualities of architecture have their own inherent characteristics, many not necessarily the most paramount or even applicable to service orientation (multi-tenancy, availability, scalability).

Too often I see all these architectural characteristics lumped together or used interchangeably and thought that at least for my own clarity, I'd get my 2 cents on the matter down "on record."

What I want to be when I grow up? Well ...

I've made a recent move from full-time information technology architect for an e-commerce solutions provider back to the role I played for the seven years prior to joining that company in 2007: technology consultant.  Probably I'll be asked by clients to perform duties that on the surface seem pretty similar to those I was doing for my full-time employer; however, appearance can be deceiving.  A lot of what you end up doing in a full-time gig, especially if you're in a senior role, only marginally relates to your "primary" responsibilities.  These "secondary" duties often consume a large chunk of the day (project management, procurement of hardware, software, etc.).  A consultant, on the other hand, is often hired to perform a very specific role for a very specific time period.  Sometimes organizations bring on consultants for an unspecified period of time to essentially fill a full-time position, but I'll be specifically shying away from those engagements this go-round.

I'm not suggesting that one role is better than the other.  Both clearly have their pros and cons.  But I'm ready to focus more on the task(s) I feel I'm good at and that I like doing and consulting gives me what I feel is the best opportunity to do that.  Or to go broke trying. :-)  Of course, it'll also land me in places I'd rather not be (but I'll ensure that this only happens for short periods of time by keeping the contract lengths short).  With consulting, I have to keep on my toes over a broad spectrum of technologies so that I can be 'the expert' on short notice.  I like that.  I also have to deal with the uncertainty of (un)employment from time to time and the possibility of significant travel, which I don't like so much.  Still, on balance, the siren song of consulting finally won out, at least until I can find out what I really want to do when I grow up. :-)

If I have my druthers, I'll be focusing on large scale web capacity, scalability and concurrency challenges and resulting solutions for clients.  That's where my passions are these days and will be how I orient my marketing message to potential clients.  But whatever the gig, I'll do my best to make the most of each engagement, always on the look-out for that next special domain and/or organization that I might want to stick around with on a more permanent basis.