Building truly scalable cloud services takes more than cobbling together code onto the cloud.

As someone who has worked for many years building and operating large scale on-demand services, I never cease to be amazed at all the misconceptions I hear about the Cloud and cloud services. The ones that I find the most painful are those that seem to believe that you can just acquire some tools and/or a cloud services provider and then seamlessly deliver highly scalable on-demand services using traditional IT service delivery approaches.

What most miss is that traditional IT and the way it is delivered has long carried a heavy load of baggage that reduces team effectiveness and decision making accuracy. When the delivery ecosystem is relatively small scale and consists of mostly static elements the architecture, data handling, process, configuration, performance, staffing, and security problems that create hazardous minefields of pain in the constraints of a large or dynamic world are not entirely obvious. 

In order to build scalable cloud-enabled services effectively, it is important to first understand how traditional IT delivery became so broken in the first place. 

The Tyranny of Value Misattribution 

When IT first became a typical organizational fixture, it was viewed as little more than a tool to make existing teams and processes more efficient. For instance, the Finance team might acquire an IT finance system and some desktops that can run spreadsheet programs to make it far easier to share and and accurately track accounting details than traditional paper ledgers. Similarly, a business might buy some IT-based customer relations tools better track sales pipelines or the profitability of various products to guide strategic decisions.

While on the surface this all might seem reasonable, the problem is that it becomes far easier to separate the value the IT service is providing from the team and ecosystem providing it.  Just as you probably don’t attribute many of the efficiencies you gain from your desk at work to the facilities people who likely built and maintain it, few bother to do the same with the services IT provides. 

This has the unfortunate effect of making IT appear as a low value “cost center”, and an expensive one at that. Being seen as a cost pushes organizations to focus on how best to “control” (i.e.- reduce) it. In fact, this was the reason that, for a long time, it was far from unusual to have IT report up into the CFO. Who better to control costs than Finance?

The IT industry quickly got the hint, and in the process learned the wrong lesson. Rather than fixing the attribution issue by understanding what outcomes users wanted to achieve and then ensuring the solutions they delivered were instrumented to factually demonstrate and track the added value they were providing, IT instead took the path of embraced anything that could be seen as becoming ever cheaper.

Resource Interchangeability

The best way to appear cheaper is to give the illusion of getting “more” for less money.

One way is to be seen “sweating” the resources you have to get “more” for your money. This might be in the form of more features, more people, more tasks performed, more “points” or whatever per unit of money. More often than not this approach turns into a game that has absolutely no connection with value. 

The second approach is to relentlessly strip out as much top-line cost as possible. They may swap out more expensive staff for cheaper ones, outsource functions, or buy lower quality but cheaper hardware/software/services. Increasingly, I see drives to cram lots of software services onto virtualized servers with overcommitted resources (what I call the “clown-car effect”). I also see funny accounting tricks being played, such as equipment leasing, or moving services out to a cloud provider, in order to smooth out the up-front budget hit or to move items from the cap-ex budget line to an op-ex one.

In either case, the end result is that the value of interconnected parts of the IT service ecosystem is severed, giving each element the appearance of being an interchangeable resource no different than your desk or the office water cooler. While people know each element has capabilities that provide some sort of value, knowledge of how everything fits together, its fitness, knowledge, and criticality to the quality of the service is discounted away.

This makes it easy for management to look for opportunities to remove, more cheaply acquire, or outsource those resources in the name of cost savings. 

So what does this have to do with cloud services?

The problem of Interchangeability & Lost Awareness

Being considered interchangeable has a number of significant downsides. For starters, if a given resource behaves as generically expected, there is little incentive to understand how well it is contributing to the overall desired outcomes of the services it is contributing to, let alone whether adjustments can be made to improve its overall fitness. At best, management might try to use measures like uptime, response time, throughput velocity, and “customer satisfaction” to get some sense. However, such measures are often too coarse and disconnected from the actual service outcome value. Also, remediation is typically swapping out of suspected troublesome resources rather than first understanding what is going on.

By not creating any incentive to understand what is going on in the IT service ecosystem, let alone how effectively it is contributing to the outcomes it is meant to be delivering, all sorts of problems can silently build up. Regularly, I see organization that fall into this trap end up with:

 

• A rise of increasingly costly technical debt that reduces service quality and the ability of the organization to respond adequately to demand
• Increased risk of poorly architected solutions being put and left in place
• Poor data handling and weak security that creates dangerous levels of unknown legal, commercial, regulatory, and reputational risk
• Problems from poorly led/managed staff who feel uninspired and disconnected from the success their work can enable for the organization and its users
• A rise in people not realizing that a perceived interchangeable resource is actually an unknown critical single points of failure
• A failure to recognize the cost and dangers of maintaining long obsolete technologies and processes that are no longer fit for purpose
• Poor communication flow

and most importantly

• Failure of IT services helping achieve their desired outcomes 

These failures make it impossible to ascertain what is hindering IT effectiveness. They also make it difficult to reliably make decisions to enhance or scale the services effectively to meet demand.

Applying Golden Bandages to Gaping Wounds

Increasingly, organizations reach out to tools, cloud service and transformation solutions providers to help them sort out degrading IT service delivery conditions. This might seem sensible at first, but what most don’t realize is that sorting out these sorts of problems is really hard.

The reason comes back to the cost-focused resource interchangeability mindset about IT. Trying to get an organization to fundamentally change the way they approach IT delivery and its value is incredibly difficult to do. This is especially true when negative feelings about IT are running high and people are looking for a quick way to neatly replace the mess they currently have.

I find that few organizations are both willing and able to make such changes. The biggest source of resistance is typically from those at the highest levels. Few executives have the time, let alone the patience, to let a vendor completely overhaul how IT is managed, budgeted for, and have its value assessed. Even fewer vendors have the people with the skills, experience, and scale to actually pull it off.

So, with making a profitable sale being top of mind, most vendors do not even try.

Instead, they claim that their tools, services, or pre-packaged change programs can fix all their ills, all while leaving their current views on IT firmly intact. While their solutions might help improve any number of existing problems, they ultimately end up as little more than expensive golden bandages superficially covering up existing hazards. Eventually, these hazards will pop back out to create another round of mayhem. The organization might try another solution, but ultimately will return to old patterns. Any lessons learned will continue to be lost, and the rot and unpredictability will remain.

Escaping the Cycle

Ultimately, any organization that wants to deliver reliably scalable on-demand IT services in a predictable way needs to find a way of escaping this cycle. 

The first step is to discover the value of learning how to see the real dynamics of your delivery ecosystem.