Many businesses are in the process of shifting toward digitization and faster time-to-market in order to strengthen their competitive advantage. Digitization of internal processes, products, services and customer interactions drives more software development, whereas faster time-to-market supports shorter, more agile software development cycles. Combine the two, and the old request-response interaction patterns and bureaucratic change management processes of IT Operations quickly break down. Ultimately, a new paradigm is required that empowers organizations to both reduce lead times to utilize infrastructure services and embrace constant change.

New technologies enable new dynamics

In a typical Enterprise IT organization, there are two major departments, one focused on Infrastructure and Operations, and the second on Applications. Traditionally, the Infrastructure team supported the Applications team in a request-response fashion when new hardware was required. A long provisioning cycle would ensue, followed by ongoing operations focused on a static deployment and avoiding change. With the move to virtualization, Infrastructure teams were able to provision faster in software and manage pooled capacity more efficiently across workloads and projects. However, IT largely kept the same processes, static architectures, and aversion to change as before.

New technologies and operating models are enabling IT Operations to transform in response to digitization and agile software development. IaaS and cloud computing provide infrastructure services as pools of capacity through an API and are accessible in seconds, rather than the days or months for traditional or virtual infrastructure. PaaS and microservices also provide common application services that can be assembled on demand to build apps rapidly. Infrastructure as code approaches enable developers to build entire hosting environments on the fly, which facilitates parallel blue-green deployments and rapid experimentation with new architectures.

The challenge is that each of these examples provides components of a solution rather than a coherent whole. Platform Engineering addresses this challenge by rationalizing these components into an enterprise architecture that application development teams can depend on.

Reorganizing around platforms

A platform is a set of services on which applications can be built and run on top of. Modern platforms blur the line between infrastructure architecture and application architecture, needing to address complex issues such as service discovery, resource coordination, container orchestration and usage reporting. Platform engineering, then, is the practice of designing, building and operating platforms for Application development teams to leverage.

Through this lens, the preferred future for Enterprise IT organizations is to evolve IT Operations and Enterprise Architecture teams into a shared Platform Engineering function whose charter is to support all the Application teams with a platform or set of platforms that they can build on top of. While many Internet and startup companies prefer a “full stack” approach, with the development teams creating or sourcing their own platforms, Enterprise IT is different. Rather than having one core application to manage with little technical debt, the typical Enterprise IT organization has a large portfolio of applications ranging from simple to complex, built on a cornucopia of legacy to modern technologies, interacting with each other in a complex web of integrations. If each Application team creates its own platform, the whole enterprise winds up with a large, complex architecture that is difficult to maintain, hard to staff engineers for and brittle to operate.

Making a successful shift

When shifting toward a platform engineering function, it’s important to maintain the strengths and shed the weaknesses of your old teams. For example, IT Operations knows how to build infrastructures that are shared by multiple applications, departments and projects. However, they must move beyond the artificial line of responsibility – typically drawn at the OS – and partner with application architects to determine which application-level components are required. Likewise, Enterprise Architecture groups know how to simplify and standardize across the full IT environment, but they often fall into the trap of focusing on onerous policy documentation and complex system diagrams rather than building real services that development teams can leverage. The new combined Platform Engineering team provides and operates services in addition to designing them. These services might span from core infrastructure (compute, network, storage and security) to application infrastructure such as service discovery, identity management, master data and databases. Companies can choose whether they want to build services in-house or broker them from cloud or managed service providers available in the marketplace.

As a result of its holistic charter, the Platform Engineering team requires both infrastructure and development skillsets, people who can architect and design services, and people who can build and run them. Because services are provided for their full lifecycle – and must continuously improve to meet new requirements and priorities – your organization must manage this group like a product portfolio, not a project management office. The Platform team must be extremely proficient at working with clients and Application teams to co-develop the product portfolio. Finally, team members must embrace dynamic change management, with continuous deployments and releases from many Application teams occurring in parallel. Stability through change avoidance is no longer practical.

Embracing change

In the end, the benefits of a Platform Engineering team are wide ranging. Application teams can rely on services not just as components to bring in and manage as part of their products, but as outsourced functions provided and maintained by the Platform Engineering team on their behalf. This allows Application teams to spend more time focusing on business functionality, increasing velocity and reducing time to market. Moreover, the enterprise can better scale across its applications with similar platforms and shared microservices, making it easier to staff engineer assignments, as well as access enterprise information.

While this shift for Infrastructure and Operations professionals may not be comfortable, it should be embraced. Many team members will find it empowering to be more fully involved in a product, as opposed to being handed a set of conflicting requirements for a siloed infrastructure function and expected to make magic happen.

In addition, learning about new technologies and application-level architecture can immensely help individuals grow their marketability and career opportunities. Just as virtualization before it, this new operating model increases the scale of what a single engineer can manage, subsequently growing his or her value to the organization.