Seemingly a lifetime ago (2009!), I shared how security concerns have to be “baked into” any cloud platform, as well as a simple set of capabilities to consider when addressing said security concerns. Of course, information security is just one aspect of cloud readiness. There are others, and today’s post from Chris Curran’s CIO Dashboard made me ponder a couple of lessons learned from our cloud platform adventures of the past 2 years.
What I tweeted in response to Chris is that cloud-readiness comes down to a simple question: how robust is the middle tier of the system architecture? Specifically, how easy is it to integrate and how well instrumented is it? This can be problematic for most enterprise and SMB business applications. Very few of these were created with the forethought that both small and large grained chunks of functionality could ever be exposed as standalone applications themselves – outside of the safety of corporate networks. Add that integration and instrumentation are usually inadequate due to a combination of factors – project scoping/delays/failures, adoption of software design approaches that scorn architecture, and general lack of talent and experience at key positions – it is not surprising that Chris is advocating a comprehensive analysis of the total cost of moving to the cloud.
At the end of the day, lack of cloud readiness is a result of many factors and decisions that seemed sensible at the time to the decision makers. But we are where we are – and not being able to make a move to the cloud places organizations at a competitive disadvantage. That’s not hot air – the difference between our platform using cloud-based services and not using cloud-based services is easily quantifiable. I can’t expose the internal operating ratios, but that difference can be measured in several orders of magnitude in operational run rate.
There’s been a movement in Enterprise Architecture circles to talk about the vast amounts of technical debt that have been accumulated over the years in most organizations. That technical debt grows with every decision that is made for expediency sake or with full ignorance (or worse, in spite) of supporting information. And while I haven’t yet found many receptive audiences for the concept of technical debt, perhaps the hard numbers that force many IT organizations “out of business” over the next few years will finally convince the software architecture community of just how spectacularly they have failed at their job. And the total cost of moving internal applications to the cloud is just one of many quantifiable ways to measure that failure.