IT Platform and IT Services Are Antonyms

The examples of common IT platforms in the previous chapter make the concept of in-house platforms more tangible. However, enterprises might also consider their existing data center or IT services a platform, or at least face the temptation to apply that label. After all, they provision virtual machines on demand, which sounds a bit like a cloud, which in turn is a platform. As so often, things that might appear similar from far away reveal important differences upon closer inspection. Let’s take a closer look at what makes a platform deserve the name and why traditional IT services are unlikely to pass that test.

When we draw high-level diagrams of platforms (including the diagrams in the Technology Platform Overview), they tend to look like a big box of “common things” with another box (or multiple boxes) of diverse things on top of it. Such a picture looks oddly familiar to anyone who has spent time in large-scale IT:

Much of IT is structured into a common infrastructure and operations layer, on top of which diverse applications are deployed. So, where’s the difference between that model and all the excitement about platforms?

There are huge differences, but this structural model cannot show them. That’s because this model is static—it shows only the pieces but not the interaction between them. Platforms are anything but static, so explaining the difference requires a new mental model.

The issues with the traditional “Dev and Ops” model are well known. Application developers (“dev”) push for higher levels of flexibility and independence to release new functionality and meet customer expectations. They are also keen to try out new technologies to make sure that they use the best tooling possible, and that their resume remains up to date. Infrastructure and Operations, on the other hand, are more conservative and perhaps more resistant to change given that they are tasked with maintaining stable and secure operations.

Putting the two together results in a classic conflict of interest: developers throw half-tested software over the wall because the operations team has to wake up when the pagers go off. In return, operations can’t do much to address outages besides rebooting a server and logging a defect for the development team to fix. This negative cycle is decorated with ample finger-pointing in both directions.

A dynamic model makes the issue clear:

As the left side of the diagram shows, the loop across deploying software, detecting its operational characteristics (or usage metrics), and correcting them, spans two organizational units whose opposing incentives pit them against each other. Often referred to as the “outer loop” of software delivery (the “inner” comprising the code/test/debug), modern software approaches like continuous integration place higher demands on making the outer loop spin faster and with less friction. In a traditional organizational model, the outer loop crosses organizational boundaries and inhibits these new ways of working.

Placing operational responsibilities in the development team, thus avoiding the organizational boundary, is one way to reduce this friction. This “you build it, you run it” model does indeed align the incentives into a single team, but it also burdens that team with a broad set of tasks and responsibilities. This means that cognitive load for teams increases (every developer now must also be a cloud and ops specialist) or team members will specialize (some folks are ops-heavy and others dev-heavy), which essentially reverts the state of affairs to the starting point, just under a common team label.

Placing operational responsibilities within the development team is the correct setup, but those teams must have the matching tools to perform these tasks as efficiently as possible. That’s where platforms come in. Developer/engineering productivity platforms can be depicted as the axle that helps the outer loop spin faster.

The platform team is part of another loop, though: the loop that takes input from development teams to evolve the platform. This loop spins much more slowly and does not directly affect the delivery teams’ velocity.

Understanding that developer platforms are a stark departure from the traditional operational model, it’s easy to see how existing teams might believe they’re building a platform when in reality they’re not.¹

That’s why a set of key characteristics that qualify an in-house project as a genuine platform is needed. Consider these like a checklist that helps you determine whether something you’re building is a platform or not:

Large organizations traditionally view common elements (including platforms) as an opportunity to avoid duplication and achieve efficiency by doing things just once instead of multiple times. Such Economies of Scale helped traditional enterprises lower their unit costs, but software platforms are different. The traditional focus on efficiency through reuse leads to a dangerous side effect called out by Professor Jan Bosch his article “Platforms should focus on speed, not efficiency”:

Slowing things down is deadly in Economies of Speed, but that’s what happens with reuse because it requires coordination. Platforms, in contrast, speed things up.

Platforms deliver value indirectly via other projects. Value is realized by the platform users; for example, by reducing projects’ development effort. Platforms can also deliver value centrally, as well; for example, by providing better transparency across an IT organization’s project portfolio, which in turn allows better decisions or more effective resource allocation. Just like multisided markets, IT platforms also serve multiple user groups:

• Project developers who can speed up software delivery
• Component developers who can find more users for their functional blocks
• Management who gains more transparency into workloads and resource utilization
• HR who can attract talent who are interested in working in a modern technology environment

Delivering value indirectly implies that a platform can deliver value only in combination with other projects. Running the risk of stating the obvious, this means that platforms without users generate no value. Platforms are indirect value enablers, not direct value creators.

Something created as a one-off to support another project isn’t a platform. Platforms are built to host a wide variety of other projects, reducing duplication of common components while enabling diversity in project implementation. Platforms thrive on scale—the more users are on the platform, the more attractive it becomes to be on the platform. In comparison, popular in-house IT systems (to the extent they exist) become victims of their own success, resulting in a bottleneck. They end up slowing the organization down, which is exactly the opposite of what a platform should do.

Successful platforms grow because new customers can sign up with minimal effort for both the user and the platform, meaning the platform’s marginal cost for an additional customer is near zero or low.

Successful IT platforms inherit this property from e-commerce platforms like Airbnb. Airbnb doesn’t have to build any new rooms to sign up a new host, allowing it to scale almost infinitely. For in-house IT platforms, automation, self-service APIs, and building on an elastic infrastructure are common mechanisms to achieve the same effect. Platforms that ignore this aspect are bound to become victims of their own success.

Low friction extends beyond user sign up. Traditional IT processes require would-be users to submit complex ticket requests that trigger a time-consuming and often manual provisioning process. Such cumbersome interactions stem from local optimizations within the team that shift the burden to users.

Low friction doesn’t always equate to a low barrier. In-house platforms and base (cloud) platforms can have low technical friction but require users to adopt a different mental model. Users who are already familiar with the new way of working—for example, using declarative scripts for infrastructure provisioning—will find the friction to be low. Others will encounter a steep learning curve at first.

Self-service is the default mechanism through which IT platforms assure low friction. Instead of filing a ticket, teams directly provision a virtual machine. Transparency forms the other half of making a team self-sufficient: they need to have a good read on what’s going on, so that they can pick the appropriate course of action through self-service. This way of working leads to a shared responsibility model (see below).

A platform can’t be built by gathering requirements, implementing them, and calling it a day. We have seen how platforms can evolve user behavior and thus unlock additional opportunities, leading to a fruitful cycle of continuous improvement. A product must target a well-understood market, meet specific customer needs, and evolve alongside those needs. That’s how platform teams must operate.

Successful IT platforms evolve both in the depth of the services they offer and in the scope of services they provide. Users benefit from standing on a platform that continually grows and lifts them up.

So-called common services restrict users to a given set of software libraries, third-party products, or specific processes. While the motivation is easy to understand—organizations are looking to harmonize, reduce complexity, and boost compliance—these goals can’t stand in the way of platforms enabling their users. Recall that “platforms enable” was the very first benefit described in Chapter 1.

Platforms therefore must find a way to serve their customers ahead of the platform stakeholders. After all, without customers the platform will provide no value whatsoever. Companies that are extremely successful with the platform model tend to be customer centric. Amazon even adopted “customer obsession” as one of its leadership principles and has managed to build not one but two successful platform businesses.

Platform users don’t need to concern themselves with the operations of the platform, because it is operated by a dedicated team. Platforms are available as an always-on production service that pools resources for standardized and automated management. This property is key to reducing the friction of teams operating on top of the platform.

Platforms have a shared responsibility agreement with their client projects. Whereas the platform takes care of certain operational qualities like security or compliance, the client projects carry other aspects of the same qualities, such as availability, security, and compliance. You can’t just deploy any old crappy application to a platform and expect miracles.

Self-service can be an important part of the shared responsibility, allowing client teams to perform operational tasks like monitoring resource usage or performing restarts. An apt analogy is cars: a manufacturer can equip the car with a seatbelt and an airbag, but you still need to be a responsible driver. AWS articulates their expectations clearly in their Shared Responsibility Model for security and compliance.

IT platforms should be extensible by platform users; for example, to share functionality they have developed. This approach stands in contrast to traditional IT-services organizations that are looking to maintain central control and give users very limited influence over the services that they provide. Platforms are open, whereas IT services are generally closed.

A few additional characteristics are considered essential by some but debated by others, so they aren’t part of the previous list but instead get an “honorable mention” here.

Voluntary platform usage is generally the preferred way because it builds more engagement and also provides better feedback to the platform teams. Mandated usage conflicts with customer centricity—only a tax authority might claim to be both, but that’s outside the scope of this book. At the same time, a large organization isn’t a democracy—whether you like it or not, hierarchies and decision powers exist for a reason.

As a pragmatist, I caution teams wanting to make their platform mandatory that it’s nearly impossible to enforce things in large, federated organizations. There are one-thousand-and-one ways to work around “required” tools and even if things come to a head, you won’t have sufficient political capital to fight and win every battle. This isn’t a Hollywood movie where the heroes prevail. It’s enterprise IT and the hallways are littered with skeletons of those who fought the noble battle.

What you can do, though, is make people’s lives easier if they use the platform and harder if they don’t. If that sounds slightly mischievous, just think of it as a core property of multisided markets. Successful platform businesses commonly subsidize early users or charge a third party to provide a valuable product at near-zero cost—until they reach scale and flip the model. If it works for the “giants”, why shouldn’t you get a slice of it?

Platforms are typically managed by a dedicated team that acts like a small business of its own. This approach makes good sense, but I am reluctant to call it a defining characteristic. If your platform exhibits all the aforementioned characteristics but is managed in a community model, more power to you! You may also find the opposite, a platform team that doesn’t actually build a platform.

As elaborated at the beginning, IT platforms often evolve (or are occasionally re-labeled) from more traditional IT Services, but have entirely different characteristics. A side-by-side comparison summarizes the contrast between developer platforms and traditional IT Service Management (ITSM):

This list can help debunk lipstick-on-a-pig maneuvers that re-label existing processes and operational systems as platforms. The one common property (and therefore not included in the list) is that both IT services and platforms are centrally operated. Platforms depart from the traditional model by separating operational control from user control.

The table also highlights how drastic the change from traditional IT services to a platform model is, which explains why so many IT teams struggle to build successful platforms.

A collection of characteristics is a great start but ignores that they support one another. As architects, we don’t see characteristics as a simple checklist but also want to understand how they are connected—again the lines are as interesting as the boxes (see “Drawing the Line” in The Software Architect Elevator²).

• A shared responsibility model enables continuous evolution, as described in the earlier anecdote.
• Self-service is a key contributor to low marginal cost, the ability to thrive with scale, and low friction.
• Making a platform user extensible is the ultimate form of being customer centric.

As a side note, a similar effect applies to good pattern languages: individual patterns are useful, but a cohesive language that shows how the patterns relate is much stronger. The best description of designing pattern languages I have seen is in the fifth volume of the Pattern-Oriented Software Architecture (POSA) series.³

The platform model extends far beyond the technical aspects to also include organizational and operational aspects. That’s why this book contains an entire part on Organizing for Platforms.