To lower IT operational costs and/or to become more agile, the business must simplify the processes to deliver and manage infrastructure and the applications running on that infrastructure. Focusing on one without the other is simply applying yet another band-aid to an already hampered environment. Delivering IT as a service requires transformative efforts across all of IT and a re-evaluation of the metrics currently used to judge success. Achieving these goals demands a new platform and approach to delivering data and applications to users.

I was recently reviewing a reference architecture for Infrastructure-as-a-Service (IaaS) and was confounded by the sheer complexity still required to deliver what amounts to a starting point for the higher level task of deploying software. Perhaps I set the bar too high, but if I were a CIO, any new infrastructure investment I made today would need to be part of a self-aware automatically elastic resource pool. That is, when I plug in the new hardware (e.g. server, storage, network) I’m asked a couple of basic questions about allocation and voila the hardware is automatically incorporated into one or more resource pools. Moreover, there’s software that sits on top of that pool that allocates it out to users on a metered basis. Any further time spent on operational configuration, engineering and deployment is simply wasted effort.

This vision of elastic and automated configuration is not a pipe-dream otherwise it would be too costly for a business like Amazon to deliver its service at the price point that it does. If Amazon required the amount of human involvement in managing the infrastructure that most IT organizations currently require the cost of delivering their EC2 and S3 services would not be sustainable let alone continue to shrink.

As CIO of Company A, it then occurs to me, I have two choices: a) change the way I operate to look more like Amazon, or b) let Amazon do what they do best and subscribe to their services. The former is a daunting task for sure. Transforming IT to deliver as a service has an impact deep into the DNA of the business itself. There’s a whole lot of risk and no guarantee of success. Moreover, the key metric to demonstrate success is elusive at best as it needs to be a combination of productivity, costs and agility weighted against a number that is very difficult to compute based on the current architecture. Hence, how can I demonstrate to executive management and the Board that their investment in transformation was money well spent? The latter is interesting, but I need to overcome internal perceptions surrounding lack of security and the issues related to CapEx versus OpEx spending. Either way, or maybe I choose a combination of both in a hybrid architecture, all I have to show at the end of the day is a better way to allocate infrastructure for purposes of deploying and managing applications; at which point we encounter a whole new set of complexities.

One of the biggest hurdles surrounding application management is the diversity and lack of integration of the application stacks. Consider a basic financial application workload that is used companywide. There’s a database, which must be able to handle hundreds of transactions a minute. There’s the application itself which is comprised of some core executable modules and a bunch of business rules that are defined within the application. The core executables probably run in some form of middleware that enables it to scale, which is a separate layer that must be individually deployed and managed. Of course, this is the bare minimum to make the application work. There also needs to be some security layers made up of anywhere from five to ten applications and tools for managing disaster recovery, high-availability and extracting data for external reporting. All these layers must be integrated to work seamlessly. Moreover, this is just one of many applications an enterprise operates.

Now, imagine that entire integrated application stack just described is a complete package (workload) that must now be made to work with a given hardware infrastructure, usually chosen by a separate team that has little to no experience with the application architecture or worse selected by procurement off an approved vendor list. Moreover, it requires a combination of skills from both application and operations teams to figure out how best to scale the application over time as demand rises. As George Takei, of Star Trek fame likes to say, “oh myyy”! In short, there’s just too many moving parts requiring too much human intervention and too much engineering and configuration relative to the value received. It’s no wonder business is seriously considering alternative means of acquiring IT services, such as Software-as-a-Service (SaaS). For this reason over the next few years IT must and will start to seriously consider Platform-as-a-Service (PaaS).

Most times I recommend evolution over revolution as it is usually more palatable by the business. However, continuing to deliver IT in this manner is unsustainable and is not delivering the agility and speed require by the business. PaaS changes the way we think about building applications and leveraging PaaS capabilities will require applications to be rewritten or migrated. These applications will not directly implement a unique instance of application infrastructure, but will leverage services that are designed to meet stated service levels. In turn, this simplifies the deployment and operation of that application as well as opens the architecture up to leverage services with better economics over time. It will remove the requirement for an infrastructure and operations team to figure out how to optimize a selected set of hardware to meet the goals of a single application and let them focus instead on how to deliver services.

Moreover, PaaS delivers a shared common platform, which is where PaaS becomes such a critical component to tying together ITaaS, IaaS and DevOps into a singular goal of design, build, test, run and terminate. IaaS is merely a commodity layer that offers high value compute services and can support the selected PaaS. DevOps provides the framework and structure for configuration of the application support services, such as networking, security, authorization, backup, etc.

In the end, instead of multiple disjointed teams each focused on their own specializations, there will be a single team focused on the goal of delivering IT services to the business. This is all driven by the focus and perspective fostered through a move toward PaaS.