What it takes to change IT
The sad truth is that successful leadership often isn't pretty, as a recent post by a Google engineer makes clear
Follow @EricKnorrA couple of weeks ago Steve Yegge, a Google engineer and former Amazon employee, wrote a long, impassioned, internal blog post for Googlers only -- and accidentally made it public.
It's an extraordinary document. Most of the reaction in the blogosphere has focused on Yegge's stinging critique of Google+ (which, ironically, was what he was using when he accidentally opened the rant for public view) and his characterization of Amazon CEO Jeff Bezos as "an infamous micro-manager" who "makes ordinary control freaks look like stoned hippies."
[ See Eric Knorr's post "Message to IT: Modernize or else." | Read the Private Cloud Deep Dive by InfoWorld's Matt Prigge. ]
But there's a lot more to Yegge's trenchant analysis.
Yegge's main focus is on something Amazon did very well -- that is, enforce SOA (service-oriented architecture). According to Yegge, in 2002 or thereabouts, Bezos mandated that all Amazon teams had to expose their data and functionality through service interfaces, and that those teams needed to use those service interfaces to communicate. Period. Or else.
It was a forced march to SOA that took several years. But the result, according to Yegge, is that Amazon is now an extensible, programmable platform -- and that Amazon Web Services could not have been built without it.
Having covered SOA intensively for several years, I can tell you that the kind of transformation Bezos was able to pull off is quite rare. SOA is one of those initiatives that's for the greater good: Going forward you can build applications using shared services instead of one-off code -- and when you need to improve what a service delivers, every application that uses it is gets the benefit of that improvement. But in the short term? Typically, SOA doesn't do the service owner much good.
That's why so many organizations struggled with SOA. When each fiefdom in an organization has its own agenda, getting all of them to march to the same SOA tune is not easy, especially when the benefit takes a while to arrive.
When I read Yegge's post, I was reminded of George Glass, chief architect at BT, who also used a hardball approach to roll out SOA in his organization. If developers, instead of using service interfaces to access existing functionality, duplicated that functionality by building it from scratch, they would lose part of their compensation. And guess what? BT ended up with a broadly successful SOA implementation.
