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.”