Time for the Tail to Stop Wagging the Dog

Here’s a novel, but controversial statement, “it’s time for the CEO, COO, CIO to start to take joint responsibility for application platform decisions.” For too many years now technical meritocracy has led the decision-making for the business with regard to platform selection. This includes, but is not limited to, servers, operating systems, virtualization, cloud and application platforms. In many of these cases the decision has not worked in favor of the business with regard to agility and costs.

I see it now with clients. Senior technical leadership recommending approaches that are questionable with regard to longevity, maintainability, sustainability and growth of the business. While its true that we do not have crystal balls and cannot tell what might happen, it seems there is a leaning away from what has been termed “opinionated” platforms. These are platform that come with some restrictions with regard to implementation, but do so in favor of speed and simplicity. These decisions are increasing the amount of technical debt the organization is accruing and will one day require the business to pay to undo.

Of note, and to be fair, not all these decisions are based on engineering bias. Some of these decisions relate directly back to business concerns of vendor lock-in. This concern over vendor lock-in, however, is being liberally applied to emerging platforms that are rooted in open sourced development and strong support for programming interfaces; things missing from the products of decades ago that locked in your data and offered no means to easily migrate or exit from use of the platform. This concern is mitigated even with today’s opinionated approaches. While a wholesale shift to a new platform may require some rework, the cost and effort does not warrant the choice to select a more complex, do-it-yourself platform.

While at EMC, one of my responsibilities was to help sales and our customers understand the value proposition of developing internal cloud capabilities using VCE’s Vblock technology. One of the key value propositions, and one that I still agree with now, was that it removed the need for data center engineers to spend time developing infrastructure out of discrete components. Vblock is in the family of converged architectures, which means that it has contained within it, network, compute, memory and storage pre-integrated. Vblock was designed to be updated remotely and the updates were fully-tested against against the known components prior to being pushed out. Hence, there was a very high success rate for the update and no outages due to conflicts between the various components due to changes.

The net result of moving to Vblock was less time spent on engineering solutions to work together when using discrete components, fewer outages due to conflicts when one component is updated, and a lower total cost to operate.

Today, businesses can select from Infrastructure-as-a-Service (IaaS) and Platform-as-a-Service (PaaS) solutions that offer the same value proposition as the Vblock. By selecting certain IaaS or PaaS approaches business can save hundreds of hours and significantly simplify their computing environments in areas related to selection, configuration, and troubleshooting of internally integrated discrete components. This is the right choice for the business.

In cases where senior business-oriented executives have been party to selection we have seen them select the pre-engineered, opinionated approach due to the demonstrated ability to provide simplified operations, speed in time-to-market, and flexibility in deployment platforms. Examples of this include GE and Ford, which both selected Pivotal Cloud Foundry as a basis for delivering next-generation systems upon which their business will rely. A key reason for these decisions is that the platform takes an opinionated approach. The following is an excerpt of a blog that defines the differences well:

The Cloud Foundry community often proudly proclaims a key part of its current success and future lies in the fact that it is an opinionated platform. But what is an “opinionated” platform? The existential questions of how to deploy to the platform and run apps on the platform are answered in a specific, if not rigid, way. To boost productivity along a prescribed path, fewer options are exposed to developers and operators.

Less opinionated platforms optimize flexibility in the guts of the system, offering more freedom for “do-it-yourself” implementations that feature custom components. More opinionated platforms provide structure and abstraction—“the platform does it for you.” Users are then free to focus on writing apps on top of said platform. And free to rapidly iterate on their apps, and reducing time-to-value for new features.

Cloud Foundry is one such highly opinionated platform. Those opinions are formed and codified with the belief that platform decisions should help customers deliver new, high-quality software to production as fast as possible.

Now, some will say that being opinionated is an aspect of vendor lock-in. However, Pivotal is just one implementation of now three on the market. IBM and SUSE are other vendors that offer Cloud Foundry implementations based on the open source code base and are part of an organization responsible for ensuring openness of the platform. Moreover, Cloud Foundry can be acquired as-a-Service or implemented on self-managed infrastructure.

Back to my opening salvo. Software is eating the world and technology is touching every aspect of your business. Now, more than ever, it’s critical for C-level executives to fully understand the nature of platform decisions and to make sure that the decisions made are best for the longevity of the business and support the speed and agility they need to deploy new business capabilities and not progress the engineering prowess of its workers.

The opinions expressed here are my personal opinions. Content published here is not read or approved in advance by Perficient and does not necessarily reflect the views and opinions of Perficient nor does it constitute any official communication of Perficient.