An entry on the ZDNet blog from today reminds us – via a piece by David Chappell – that although service-enabled reuse offers obvious business benefits, the internal political landscape is an important obstacle to any potential games gains. To which I would reply – truer words were never spoken, amen to that, pick your cliche of choice.
However, I do think it’s important to put that in the proper context: internal politics are always an obstacle, whether we’re talking about reuse, consolidation, organizational streamlining, etc. Businesses – like people – fear change. Anyone who’s worked for big organizations knows this.
More importantly, services (using my broader definition) have an increasing ability to route around top-down mandates or organizational silos. How’s that? Well, as Jonathan Schwartz is fond of saying – how many CIO’s mandated Google?
That may seem a bit flippant, and it’s certainly true that Google as a service is a slightly different animal than, say, the retention service as supplied by an internal data warehouse. But what they have in common – ideally, anyway – is the ability to be consumed on demand, in an ad hoc fashion, without a ton of engineering. As a result, I try to remind people – developers especially – is that if services are readily available with known and streamlined APIs, I don’t believe any organizational strong-arming or mandates will be necessary.
Why is that? Because if services are made available via a simple mechanism, they will almost inevitably be consumed, whether or not their presence has been pre-authorized. Services are likely to be pulled in early in an application’s life cycle – if only because it makes prototyping a simpler process, and allows the developer to focus on the application functionality unique to that application. And once they’re in there, who’s got the time to pull them out and duplicate what already works? Not many.
By no means am I contending that services as an approach or SOA are a silver bullet for your (or anyone else’s) fiercely departmental organization, but I do believe that services will corrode singular ownership of technologies that are best delivered as services. That will bring – and in some cases, compel – organizational change, but not for a while in most cases.
In the meantime developers, sit back, take a look around, and see if anyone’s done your work for you already in the form of a service. As the Beastie’s would say, “It’s much easier on the constitution.”
