In our work with government agencies, we routinely encounter interest in internal platforms: partially-completed attempts at developer platforms, disparate piles of applications that could benefit from a platform, and customers who know they need a platform but don’t know where to start.
The complexity and variability of platforms can make them difficult to talk about. The term platform is used in so many contexts that people often talk past each other when working to define the scope and strategy of any one particular platform. This confusion is so predictable that it’s become a trope: in any platform conversation, someone will eventually ask, “so what do you mean by a platform, anyways?”
When we look in the marketplace, we see that others also acknowledge the variability of platforms. Platform Hunt describes 9 different types of platforms that vary by user type and use case. In our work, we most commonly encounter internally facing technology platforms. According to Platform Hunt, “Technology Platforms provide building blocks or services that are reused in a large number of products.”
Restricting our scope to technology platforms helps us ground a crowded discourse and focus on two key concepts for designing platforms:
-
Reuse of services. Building common functionality once and reusing it widely to accelerate application teams, letting them build on a foundation of already-solved problems.
-
Separation of responsibility. Defining boundaries between the platform team responsible for that common functionality and the application teams using it helps narrow each team’s scope and reduces cognitive load.
Together, these concepts give us a framework to talk about what’s important for a platform, which leads to our definition:
A platform is one or more technology building blocks offered to application teams as a product with documentation, support, and governance.
Let’s break this definition down to gain a better understanding of how the two key concepts listed above play a role in discussing platforms.
Building blocks
A platform is one or more technology building blocks offered to application teams as a product with documentation, support, and governance
Our first critical concept is reuse of services. This is the core value proposition of a technical platform: building common functionality once so each application team who needs it isn’t reinventing the wheel! Ideally, this reuse accumulates benefits across the organization. Specifically, reuse:
-
Accelerates application development by solving common problems once.
-
Improves system security and stability by consolidating best practices for infrastructure, observability, and data security into central platform infrastructure.
-
Creates long-term maintainability by reducing overall complexity in the software ecosystem.
-
Increases focus on shipping business value by narrowing application team scope.
All of these benefits enable developers to spend less time creating and maintaining infrastructure and more time iterating on features that deliver value to users.
So, we’ve made a case for effective reuse. But what services can and should be reused to make a platform? When we look at the platforms our teams support across different organizations, we find recurring tooling, infrastructure, and services. We call these our platform “building blocks,” categorized into functional groupings.
- Operational infrastructure: core developer infrastructure that applies to most software projects. This covers services across source code management, build and deploy pipelines, runtime serving infrastructure (often in the cloud), and observability tooling.
- Developer enablement: libraries and tools to support application development. This category includes libraries for performing common integrations and solving recurring development problems, static code analysis tools, and other services for improving developer workflows.
- Shared services: internal business services that address specific problems within the business. These might be things like an identity service for an organization’s users or a messaging service for notifying customers — services that another application can depend on to avoid re-solving a business need.
- Finally, we also find that platforms for mobile, web, APIs, and data solutions each have their own building blocks specific to their use cases.
When we frame each technology solution as one “building block” for a platform, we have a framework to identify the platform’s scope and boundaries. Most organizations have their own cornucopia of building blocks, so part of designing a platform involves selecting the ones that make sense for the platform’s users. The goal is to identify a cohesive set of building blocks that function together, are maintained together, and are offered as a product to application teams within an organization.
As a product
A platform is one or more technology building blocks offered to application teams as a product with documentation, support, and governance
Our second critical concept is separation of responsibility.
This means having clear boundaries between platform services and applications, defined ownership of the platform services, and systems and processes to support a healthy relationship between platform and application teams.
Boundaries emerge naturally from selecting the building blocks that make up the platform, but the clearness of those boundaries can vary. A platform service with a well-defined interface for using it, such as a user interface or API, provides a natural boundary. But other platform services may have fuzzier boundaries. Your platform’s monitoring-as-a-service offering may raise questions like “who responds to alerts – the application team or the platform team?” and may require extra definition to make sure everyone shares the same understanding. Clear documentation can help here — documentation isn’t a substitute for a well-defined interface, but it can help clarify intentions and reduce the support burden on the platform team.
Next, defined ownership is about making sure that platform services have a staffed platform team (or teams). As Matthew Skelton and Manuel Pais write in Team Topologies, “Team structures must match the required software architecture or risk producing unintended designs.” To manage a platform as a product, a team needs to own and support it, define and measure its success, and work to intentionally understand its users’ needs. Those product aspects are difficult to prioritize when a platform service is a shared resource with unclear ownership and maintenance spread across its users.
Finally, separation of responsibility benefits from systems and processes that support the relationship between platform and application teams:
-
Documentation and support channels help to define the boundaries between platform and application teams and make it easier for application teams to actually use the platform. After all, a platform service that application teams struggle to use loses the biggest benefits of platformization!
-
Feedback loops help ensure the platform team understands the needs of application teams using their services. Public-facing products with large user bases may use analytics to understand user behavior in ways that technical platforms often can’t. Because platform teams have more direct access to their audience, they can instead lean on surveys, user interviews, and one-on-one relationship building with application teams to ensure a platform team regularly hears from their users.
-
Governance lets the platform team create consistency across applications in a way that benefits the organization as a whole. Governance may come in the form of documented rules about how to use the platform, automated tooling and design choices that force the platform to be used in intended ways, or manual review processes with human sign-offs. Examples might include restricting programming languages that can be used in a given build system, enforcing consistent use of a design system across user interfaces, or verifying that accessibility requirements are met.
Not all platform services require all of these components, but their absence often results in tension between application and platform teams. Clear definitions and interfaces can ease that tension by ensuring everyone is working from the same understanding and expectations. Processes that support those definitions can make a smoother platform experience for everyone involved. All of this is part of understanding the separation of responsibility in a platform ecosystem.
Putting this into practice
At Ad Hoc, we use these concepts of reuse of services and separation of responsibility to shape how we talk about existing platforms and plan future work. The “building blocks” model has resonated with teams across Ad Hoc and is helping us better articulate platform strategy to our customers.
We use our list of commonly seen building blocks as a map for evaluating a platform’s current state. When talking with stakeholders, we ask several key questions:
- Which services does the platform already have?
- At what level of “productization” does each platform service operate?
- Based on their user needs, which services should they prioritize maturing, and which should they consider adding?
This exercise can illuminate an existing platform and become a jumping-off point for other conversations, or it can help create a plan for growing a new platform. Breaking down platforms thinking into reuse of services and separation of responsibility can also help focus the sprawling complexity of platforms. With these concepts, we can begin to have more focused and strategic conversations about platformization within a given organization.
As we continue our platform blog series in the coming months, we’ll dive deeper into various aspects of platform thinking, and how we can use them to drive digital modernization in large organizations.
