The Platform Paradox

The power of a platform is not one to wield lightly. One size can fit most, but rarely fits all. Here is our advice for identifying when to use one, and when to avoid.

I have been having some great conversations with clients this summer about ‘platforms’. “Is our e-commerce platform strong enough for our new digital Omni-channel same day delivery strategy”? “Don’t just build it for one side of the business, build it for the whole business, that’ll help the benefits and make sure we are aligned” and “how do we get off of this platform,  we had to customize it and now can’t afford the upgrade”.

Old school theory clearly favors a platform play, deploy and exploit, figuring it will pay back in the end. Whilst it may not quite be in the best interests of each group, if multiple groups step up and use it, it will benefit the whole company more than siloed efforts. Cue excited overzealous cult of the platform behavior.

Platform, to be successful, needs governance.  You need to force everyone to use it. But one man’s tech homogeneity is another man’s vendor lock in. And the cost of these platforms can be eye watering.

There’s also a line where it costs so much to develop something new on a platform, that it would have been more efficient, even in the long run, to build it separately. Short lived systems, for example, often cross this line. Governance can force too much onto the platform, which ultimately can bring it down. Does this mean a better platform is required?

And what about innovation?  Whilst exploiting a sunk cost is seen as ‘innovative’ in some organisations, most are trying to foster novel, out-of-the box (…or platform) approaches… Platforms don’t help with that, and can even culturally limit thinking.  Dave Aron’s post on

Pace layering is Gartner’s way of keeping stable things stable and innovating in the place it makes a difference. I like it, but I believe that’s a narrow view; “innovate here”. A former colleague and I grappled with this and came up with the following matrix that we think describes how things should work, for your average

A life cycle can go a bit like this…

  • Your big ERP system fits firmly in the bottom left. But ERP systems are slow to evolve. A common behavior is for users to dump out data, and drop it into a spreadsheet, reorder, filter, append more information etc.
  • These are the spreadsheets that run businesses just across the world. They are typically ephemeral but not always, they are built to change, but still really just a hygiene factor. So we have shifted from bottom left to bottom right.
  • Add a few more fields and sometimes your spreadsheet can start adding real value, not just time saving, but changing the way teams work. Criticality increases, but the need for flexibility remains, processes are still bedding down. Top right.
  • Then the new way of working gets rolled out to other teams, other offices, etc – now, maybe, it makes sense for these teams to be accessing the same data, working in the same way. It’s no longer built to change, it’s built to last, and integrity is paramount. That puts us top left.
  • Then the sleepy ERP vendor wakes up and builds the functionality into its main product. Everyone moves to working that way. It no longer differentiates.

ERP and platform are not synonymous of course. But hopefully you can see the cycle still works for an ESB or E-commerce platform too.

What does this mean for platforms and governance?

Adopting this view of the world helps governance boards work out where to promote platforms. It helps architecture and service management demonstrate when small user developed spreadsheet apps need to be reworked into something more robust. And it helps break all stakeholders from the too good to be true – ‘one size fits all’ approach. Real life is much more nuanced, rightsizing is a key architectural requirement.

What does this mean for innovation?

There is a role of ‘platforms’ in innovation. On the right hand side of the model you will find rapid development platforms and frameworks – Outsystems, Mendix, and Kony for example play in this space. Things that enable the business to extract data from systems of record and play with it in new ways usually rendering it to mobile devices. Partitioning these off – into walled gardens enables controls to be put in place that help rather than hinder.  Put another way – enabling the ‘citizen’ developer using a platform that allows IT to set the boundaries, and watch what’s going on from a distance is of huge value.

Concluding thoughts

Platforms have their place, they’re expensive and require governance, but don’t try to force everything onto them, think about on-boarding and departure.

Related Reading