The Last Priesthood

Tuesday, December 16, 2008

The early days of computing were not a good time for lean processes to thrive. Cycle time was atrocious. It often wasn't possible to even run a program without manual intervention; you brought a stack of cards to the priests of the temple, who interceded with the computer god on your behalf and returned the answer.

Over time, as advances in computing brought steadily more power to developers and end users, such intercessionary roles in computing dwindled. Today, they are largely limited to the far end of the development cycle, where applications move out of dev / QA and into the data center. Hands-on installation and configuration are commonplace in bringing apps to production.

The advent of cloud computing will bring more than change; it is bringing disintermediation. In short order, the cloud model (whether outsourced or in-house) will eliminate a wide range of operations tasks, bringing an end to the last priesthood of software development. Automation will become pervasive in every area of the data center, and the power of the temple will be broken.

The Internet era is full of such examples of disintermediation -- Dell computer with direct-mail customized PCs, Orbitz and Travelocity with agentless travel booking -- but my favorite analogy for the effects of the cloud is from a still earlier time, when a different sort of priesthood fell before an onslaught of infidel machinery.

I was at university in the early 1980s, and had a part-time job in one of the computer centers. Every two weeks I collected my paycheck, made the half-mile pilgrimage to the bank, and waited with dozens of other supplicants for the temple keepers to summon us, at the tolling of a bell and the gleam of a holy light above the teller window, to receive our cash.

Then a curious thing called an "automatic teller machine" opened not far from my dorm, and the "bank" was now just three blocks away. Then another opened indoors, right across the hall from the pay office. Suddenly, I didn’t have to arrange deposits and withdrawals around class schedules anymore. I was no longer acting at someone else's convenience. They were now acting for mine. I abandoned the faith without a shred of remorse, never to visit the Keepers of Deposit and Withdrawal again.

Tom Peters described this disintermediation in consumer banking nicely in his Innovation Revolution seminar. (This was around the time he was starting to go off the deep end with self-branding, and much of the material is dated now, but this one quote has stayed with me for years)

"There could be nothing more humble than the two-foot-by-two-and-a-half-foot metal jaw of the ATM on the side of the bank or the grocery store. But assuming that ATM is powered by a state-of-the-art information system… it is a simple fact, ask your banker friends, that the ATM system of 1997 relative to the bank of 1970 is literally taking the place of three or four or five or six layers of management! What was a bank in 1970? It was exactly what you wanted it to be: a police station for your cash. Layer after layer of checkers stacked on top of checkers, keeping track of your bucks. And now they're gone. And now they're gone."
This is cloud computing in a nutshell. In the old world, project teams wait in the queue, applications in hand, for a limited staff to manually install and configure the machines (which may also be allocated to specific projects), manually install the apps, manually create all the rules needed for monitoring and routing.

In the new, capacity (cash) is delivered in bulk to the data center, and product teams lease it at their convenience. Application package metadata describes the needs for capacity, monitoring, routing, bandwidth and various quality-of-service details, and the cloud management software arranges it largely without intervention.

Now, the role of operations staff is clearly more advanced than that of bank tellers, and although the priesthood is clearly doomed, the personnel are not. Capacity and network planning are still in the picture, but the main focus will be on automation, and the marching orders were issued by Microsoft Chief Architect Ray Ozzie, in the 2008 PDC keynote that introduced Windows Azure: "The previously separate roles of software development and operations have become incredibly enmeshed and intertwined."

Operations must become more than a service bureau. It must be a deep and ongoing joint venture with development teams to create competitive automation that can bring applications to market as fast as possible, manage and scale them with infinite flexibility, monitor and analyze their behavior at a level of detail that turns production statistics into business intelligence.

Ops teams will also begin to draw on the highest level of development and architecture talent available in an organization, just as they do at leaders like Amazon and Google (and now, Microsoft.) Application teams will begin to see healthy competition for star programmers, who understand automation better than anyone. Management needs to present operations jobs as opportunities for innovation and career enhancement.

These changes in organization, staffing and process are imperative. If you can't accomplish them, you can be certain your competitors will. Or like as not, they will just buy salvation in a neat package like Azure or EC2.

(Disclaimer: The above opinions are mine alone and do not necessarily represent the views of current or former employers.)