Platforms: These days it seems like every business wants to either build or become one.
And no wonder, when 7 out of 10 of the top enterprises globally are platform-based models, underpinned by strong technology platforms. Research firm IDC is predicting that by next year, 60% of enterprises globally will have articulated and be in the process of implementing a digital platform strategy. A good number of companies already appear to be achieving a degree of success in platform-building; a study focusing on leading firms in the US and Europe defined 31% of them as “top performers” when it comes to platform thinking.
Largest global companies in 2018 vs 2008
But there are good reasons for businesses to approach the platform bandwagon with caution, mainly because it’s not always clear what a platform is. “Platform has become an ambiguous word,” says Thoughtworks Principal Consultant, Zhamak Dehghani. “It doesn’t mean the same thing in every context.”
“There’s a lot of confusion in the market about platforms because the word is used at multiple levels,” agrees Ryan Murray, Director of Digital Platform Strategy at Thoughtworks. Sometimes ‘platform’ is just a term for a suite of applications. There are platforms designed to support specific functions or industries. There are business model platforms (like Apple’s iOS, or Facebook) that provide a foundation for anyone to develop on; indeed, some platform business leaders believe effective platforms are defined by their ability to make other companies successful.
But what most businesses really need is a platform that contributes to their own success, by helping them navigate and excel in an environment where the forces of digitalization, change and competition are mounting by the day. This environment requires, as Murray puts it, “a foundational technology platform that really accelerates the enterprise’s ability to deliver value for clients.”
Built and applied correctly, this kind of platform powers a more agile approach to business – as it did at Sonic, an iconic US drive-in fast food chain that partnered with Thoughtworks to develop an enterprise-wide digital platform that underpins new channels and personalized offerings for customers.
“The platform has made Sonic nimbler because it can easily pull in and unite best of breed applications, databases and messaging. Moving to a flexible, and in this case, cloud-based architecture allows Sonic to plug in and launch new services and technologies quickly to meet business or customer demands.”
Guilherme Froes, Lead Consultant, Thoughtworks
Laying the foundations
For most enterprises, the platform journey should begin with a very basic question – do I really need one? In some cases, Murray says, “the answer is definitely no.” The decision typically comes down to scale. A small company or startup trying to vet an idea would likely be better off concentrating on building just enough software to bring that idea to market and evaluating the results.
As enterprises grow in size and complexity, however, systems evolve to serve certain business functions, like product development or inventory management. The business’s dependency on technology increases to the point that they’re “very much tangled together, even the very same thing,” says Froes. Because systems typically develop in functional silos, areas of friction begin to materialize. Processes may be repeated throughout the enterprise, or become more intricate than necessary.
Addressing these frictions becomes critical to the organization’s ability to perform and innovate. “Businesses want to move faster, experiment with new offerings, new markets, new capabilities,” Dehghani says. “At the same time, they deal with a lot of legacy systems that have trapped their data and capabilities in certain functions. To be able to get where they want to go, they need smaller building blocks that play well together.”
In platform strategy these ‘blocks’ represent separate capabilities, with steps taken to enhance efficiency and reduce complexity in each so they can be used more effectively by engineers and the business to build, deliver and measure customer experiences, and ultimately serve the enterprise’s growth ambitions. Rather than functional challenges to be tackled, the blocks become “great opportunities to accelerate time to market, bake in security and enable repeatability, for the rest of the organization,” Murray says.
The exact blocks in play may differ depending on the organization or industry. But they can be broadly grouped into focus areas like customer touchpoint technology, delivery infrastructure and ‘self-service’ data solutions (see diagram). According to Thoughtworks Digital Platforms Practice Lead, Vinod Santhanam, the modern deployment infrastructure, service capabilities and frictionless delivery mechanisms that define effective platforms create common - and powerful - outcomes.
Digital platform strategy blueprint
“(A platform) helps accelerate the time to convert concept to cash, either with experimentation or getting consumer insights,” he says. “Importantly it also increases your overall system stability - and that leads to happier, more productive teams, and improves the developer experience.”
The platform as a product
Satisfied people and more secure, robust systems - by now most businesses will be asking, where do I sign up? The temptation may be to leap for the first cloud ‘platform’ on offer, or overhaul the enterprise’s entire infrastructure strategy – but this effectively considers only part of the equation.
“The ‘build it and they will come model’ is very difficult to do well, and also leads to frequent disconnection between engineering and business, which needs to see the value,” Murray notes. “Business users may not understand the ‘how’ of the platform, but they sure as heck should be able to understand the value it creates for them over time.”
“Wiring a whole lot of technology together with the hope that people will come and use it as it’s intended, so it’s not outcome, value or use case-driven; and just executing a bottom-up architectural initiative – those are the main failure modes for building platforms,” adds Dehghani.
The surest way to avoid these missteps, Dehghani says, is “acknowledging and treating the platform as a product,” with internal ‘customers’ of its own.
“Not only is it supposed to hide complexity, to remove friction, but also it has to delight its customers in an easy to use way, better than whatever you implemented previously,” she says. “That’s one of the main attributes that should be considered from day one.”
“Every team should be running as a product team,” agrees Murray. “Their product might be technology, but they’re looking to understand the internal customer’s goals and figure out how to make them successful. We see that mentality at (external) customer touchpoints, but really you need to bring it to every level of the organization. The infrastructure engineers should care about how easy it is for their customers to check the health of the systems, or to self-service their reports. That passion for serving the internal customer at every level is the essential ingredient to how platforms evolve and scale.”
As a product the platform will ultimately be judged on its ability to “boost” or improve the capabilities of the business, as opposed to technology that is designed to solve specific, preexisting problems, notes Froes. In this sense the platform is making positive contributions rather than keeping the lights on, or “doing new stuff, not just helping with the old stuff.”
Simply improving infrastructure is unlikely to be enough to achieve this kind of impact. “Infrastructure is absolutely one of the more common places to start because obviously creating speed for engineers is always an advantage,” Murray explains. “However, engineers moving faster in the wrong direction won’t create a lot of value.”
“The ‘build it and they will come model’ is very difficult to do well, and also leads to frequent disconnection between engineering and business, which needs to see the value. Business users may not understand the ‘how’ of the platform, but they sure as heck should be able to understand the value it creates for them over time.”
Ryan Murray, Director of Digital Platform Strategy, Thoughtworks
A better way to build
Platform strategy therefore needs to incorporate analysis of the business’s strategic priorities, and how technology can contribute to them.
“We look at where key business initiatives are going, and where engineering teams support those,” Murray says. “What help do those teams need, where would they benefit from having access to business or infrastructure capabilities? As we look out at the portfolio over the next year, where are the future opportunities for acceleration?”
The typical enterprise has a diverse strategic portfolio that different parts of the organization, and different technologies – infrastructure, data, or business functions like order management – are tasked with serving in various ways. Platforms should reflect this diversity.
“Looking at the platform as monolithic is a problem because it’s an assembly of things,” Murray says. “There are key parts of the business that you’re trying to represent, but they may be very different from each other. While there are a few principles or practices you would use across them, you need to see this as a lot of different cells working autonomously.”
Autonomously means each block is given the authority – and, crucially, the resources - to drive improvement in a specific domain, and together these improvements “ladder up” to overarching business outcomes.
Recognizing infrastructure as an intricate assembly of moving parts bolsters the argument against trying to replace it with a shiny new platform in one fell swoop. As Dehghani points out, legacy systems are really “reality systems,” addressing the everyday needs of the business. In many cases they’ve conditioned customers – internal and external – to expect functions to be handled in certain ways, and massive changes risk confusion, alienation or worse.
A better approach is to build a platform incrementally, by identifying the specific capabilities legacy systems are designed to support; mapping them to business priorities; and targeting specific areas for upgrades or enhancements that make the most of existing assets.
“Let’s say we’re operating in a data center and we want to move to a cloud platform,” Dehghani explains. “We won’t build the cloud on top of the data center. We set the platform to one side, and slowly move the workload over.” Platform components may be layered on to a payment system that’s business-critical but a pain to use or introduces a lot of friction to a supply chain, before the more tangled back-end is phased out.
In evaluating areas for platform enhancement, enterprises will also need to consider the relative merits of external and in-house solutions.
“One good rule of thumb is: does the software match your existing business process, or will you have to customize the hell out of it?” says Santhanam. “If the answer is the latter, you don’t get the benefit of buying the off-the-shelf product, and your support might not last long.”
According to Dehghani enterprises should differentiate between ‘commodity’ capabilities like cloud infrastructure or identity management, for which solutions are well-established and widely available, and capabilities linked to core services – the ‘secret sauce’ - which are best built in-house.
“Things like my customer registration or product catalog belong, and are perhaps unique and strategic to, my organization, so I would build those,” she says. “There are also things people don’t share or don’t sell, for example in machine learning or artificial intelligence. You wouldn’t be able to just get a price optimization intelligence service as a building block from somebody else.”
Whatever platform ‘parts’ the enterprise begins to assemble or tweak, the emphasis according to Murray should remain on relatively quick incremental gains –- rather than end-to-end transformation. “Pick the highest value things, create a road map for making them better, start to work, measure and then constantly keep deepening and broadening the strategy.”
“Looking at the platform as monolithic is a problem because it’s an assembly of things. There are key parts of the business that you’re trying to represent, but they may be very different from each other. While there are a few principles or practices you would use across them, you need to see this as a lot of different cells working autonomously.”
Fostering a platform culture
Early progress is vital because it can serve to validate the platform strategy with the broader enterprise. Effective platforms may be built on technological pillars and the pursuit of technological excellence, but they rely heavily on buy-in from the business, as well as feedback or decisions that point the way to further improvements. “That needs to happen with a lot of brains in the game from different domains,” Murray notes.
“When I’m working with infrastructure, I shouldn’t be thinking about a specific technical problem; I should be thinking about the developer that needs to deliver the software and ultimately the goals of the company,” agrees Froes. “It’s about being outcome-focused and not focused on your process or your technology, because those are just a means to an end.”
The platform, then, should be viewed as something owned and powered by the entire organization – an idea that can be reinforced by the creation of a platform team that encourages functions to work together in the fight against points of organizational resistance.
“In order to be successful a platform needs to engage the business as a whole and the right kind of stakeholders within it,” says Santhanam. “There are certain functions that tend to inhibit smooth delivery flows, like security, compliance and infrastructure. Identifying those inhibitors, engaging them upfront and bringing them together as part of the platform team is important.”
Yet, as Dehghani points out, the broad platform team is still made up of smaller groups organized around specific capabilities that retain the autonomy to improve them.
“To my mind it’s an ecosystem of building blocks that work well together but still have a distributed nature. Once you architecturally distribute to smaller units, you organizationally distribute your teams around them. You have to think about what the building blocks, or pieces of the platform, are, and organize teams accordingly.”
The line between autonomy and shared purpose can be a tricky one to navigate. According to Murray it requires strong leadership from a central point – typically the C-level - to serve as the “forcing function” that says “this is the direction we’re going, and I’m going to be the champion as needed to insist on cultural change and organizational cooperation.” But skilled leadership at the operational level is also needed to ensure the “day to day” decisions in specific functions or capabilities are on point, and that legacy practices aren’t holding back progress.
These platform product owners ensure their teams are both focused on the specific tasks at hand and maintaining organizational alignment. “They have to do all the things that a product owner does – think about the users, the overall roadmap, usability, and evangelize their successes,” Dehghani says.
It’s this delicate interplay of the non-technological aspects of platform strategy that organizations most often struggle with. “One thing I’ve noticed is that change management often doesn’t have enough of a vision component, it’s more about execution,” says Murray. “Having a transformation leader focusing not necessarily on the platform itself but the cultural and human dimension of the change is very powerful to making sure that a vision is being set and everyone involved is aligned to the same goal - delivering on the capabilities within the platform. Otherwise it’s quite easy for, say, HR to go off and do things in a way that’s not aligned to the platform leadership’s objectives.”
Execution also depends on mobilizing the right talent. Just as with infrastructure, the initial temptation may be to launch a desperate hunt outside the organization for next-generation platform developers. But particularly in a hot labor market, most enterprises will inevitably also need to leverage existing resources – even if these have to be applied in a different way. As Murray puts it, in trying to create a “2.0 world” enterprises can’t leave those who were around for “1.0” behind.
“You can’t afford not to bring along the people with aptitude, because they know so much about the business, how it functions, the systems that you need to extract the value out of. Hot digital developers are not going to be able to help untangle the complex back-end architecture of a larger organization successfully, so it’s essential to have a blended strategy. There will be people that won’t come along, and that’s to be expected. But you need to embrace the people who have been there all along, as well as the legacy technology if you’re going to make the fastest progress.”
“When I’m working with infrastructure, I shouldn’t be thinking about a specific technical problem; I should be thinking about the developer that needs to deliver the software and ultimately the goals of the company. It’s about being outcome-focused and not focused on your process or your technology, because those are just a means to an end.”
Measuring and sustaining performance
Demonstrating results can foster alignment and engagement throughout the platform journey, but particularly initially, defining value can prove elusive, and is one area where enterprises can benefit from outside support.
“One of the big problems early on in any transformational activity is that it’s very hard to quantitatively measure success because things move in fits and starts,” notes Murray. “You don’t necessarily have enough samples or things moving in parallel. That’s where culturally you may need to be willing to accept an experienced third party as an expert ‘Sherpa’ if you will, and allow them to lead until you’re able to measure results or develop strong instincts of your own.”
As the platform progresses, leadership should be stoking momentum by identifying and communicating early signals of success. In fact, Murray identifies storytelling as one of the primary platform skills behind any transformation – and given the scope and impact, platform building is always a transformational endeavor.
“Leaders at various levels of the organization need to be able to identify the signals that show you’re going in the right direction and tell those stories on an ongoing basis,” he says. “If you’re doing a good job of prioritizing things that will move business-valuable metrics, then you’ve got a story to tell.”
Metrics, much like the platform itself, should be cross-functional and include qualitative and quantitative factors linked to overall platform goals, and the individual capabilities the platform ‘blocks’ are enhancing – since it is these capabilities that measurement efforts should concentrate on, rather than the platform as a whole. Typical examples according to Santhanam include the platform’s impact on independent deployments, or mean times to identify the root cause of production issues.
Infrastructure-centric metrics like these are easy to gauge, but the ultimate measure of success for any platform as a product is to what extent it’s being adopted. “As a product you want the platform to have a net promoter score,” Dehghani notes. “What percentage of developers would recommend your platform to the rest of the organization?”
Naturally, the results of these metrics should inform ongoing platform development - but Santhanam points out stakeholders should also accept that what is measured may not remain static. “The technology landscape is moving fast, so what you define as a metric today may change tomorrow. It may be a good signpost, but it’s going to move, and you need to keep up.”
No platform is future-proof
The constant reshaping of the technology landscape means today’s cutting-edge product capabilities “are likely to be standard issue in a year’s time,” as Santhanam says – and platforms are no exception. That means however skillfully a platform is assembled and managed initially, it will need to evolve.
The continued vitality of a platform depends to a large extent on applying the same concepts that govern product development. “Like any product, a platform needs to be nurtured and cared for,” Santhanam says. “The build-measure-learn feedback loop, and a focus on continuous improvement needs to be applied to each capability”
“Evolution and scaling are critical,” says Dehghani. “Longstanding teams that are responsible for different functions within the platform should have a roadmap, as you would for any product. If you have that vision and also consult your customers within the organization on what they need, as with any product you’ll be continuously evolving accordingly. And that sometimes means you make a leap to the next generation and retire the previous one.”
Rapid delivery of value
Yet even as it changes, Murray points out the platform should be consistently oriented toward the Northstar of internal effectiveness.
“It’s important to keep focused on both the business benefits and foundational aspects, so you can tell both stories,” he says. While celebrating gains like faster delivery times, “you need to be putting the work in on the foundation to make sure that you continue to accelerate. Creating one big bang and then nothing afterwards obviously won’t keep up the funding and enthusiasm for the platform longer-term.”
As in other aspects of platform strategy, this means there’s a lot to juggle at once. But then, platforms are all about building (or assembling) smaller blocks to drive much larger, transformational results. “Our customers will sometimes say, ‘There are so many things to look at. We can’t boil the ocean. How do you do it?’” Murray says. “Well, the way you boil the ocean is one saucepan at a time.”
Perspectives delivered to your inbox
Timely business and industry insights for digital leaders.
The Perspectives subscription brings you our experts’ best podcasts, articles, videos and events to expand upon our popular Perspectives publication.