Platform as a Boat Anchor
As a veteran in the enterprise business applications space, it is interesting to see the long-held paradigms of software development being blown up with the commoditization of infrastructure and development tools. Many of the traditional views of optimizing R&D investment no longer hold true, yet I see technology organizations continuing to cling to creaking platforms and wondering why they can’t hire the best engineers out there.
On a conceptual level, platforms provide a way to scale up engineering resources, allowing engineering teams to leverage shared capabilities and resources for greater productivity. It should also make it easier to integrate processes and data.
That’s all great - motherhood and apple pie kind of stuff.
However, from what I’ve seen, it’s very hard to execute well. If not managed properly, a platform team becomes more of a shared service team where any little piece of functionality that could be shared, whether it is or isn’t, ends up being pushed to this team. Soon, the platform team is the largest R&D team in the whole company.
Okay, fine, so it’s the largest team — that in itself isn’t a problem. However, what can spiral out of control is the increasing reliance on this team to build out some missing part of the platform to enable new functionality. These dependencies kill the ability for product teams to innovate quickly.
Why does that happen?
Since platform isn’t always considered a “real product,” the proper packaging of platform capabilities is often the first to go when it is time to cut scope. No proper documentation resources allocated. Inadequate or missing APIs/services for other teams to leverage.
The end-result is that all innovation becomes dependent on engineers on the platform team to do their part to make things work.
Furthermore, platform always has the image of doing the “cool/difficult/innovative stuff,” and the best engineers often end up joining the platform team. Capabilities that are on the fringe of being platform migrate with those engineers to the platform team. The platform becomes one big hairball of functionality that only platform engineers can decipher.
Consequently, roadmaps become blocked on “required” platform work. The platform team becomes the arbiter of all development for the entire organization. Great for the owners of platform, but not so great for the rest of the company.
That’s why I always say “a platform that requires platform engineers is not a platform at all”
How can an R&D team ensure that development work doesn’t get sucked into the Platform Black Hole?
Platform as a product. Ensure that the proper packaging is done so that capabilities by platform can be consumed by other engineering teams efficiently. If these capabilities aren’t fit for customer consumption, why would it be ok to send it off to the engineer in the next cube?
This focus is especially important if your technology organization is, say, a cloud/SaaS provider that is reliant of internal services to get customers up-and-running. I don’t know how many times I debated with engineers who just said “let’s just let the services guys configure it.”
Strict definition of platform. Does it really need to be in platform? For example, given how much closer the app teams are to customers, it makes sense for those teams to own business-related objects and processes, even if they are shared among multiple solutions.
Of all the technology companies I’ve worked, I have to say that PeopleSoft had this part nailed. It wasn’t entirely perfect, but it was more clear here than anywhere else what belong to PeopleTools and what needed to be in my products in SCM/SRM.
Innovation at the edges. From my experience on both the app side and platform, a lot more innovation happens on the app side. Give the freedom (and architecture) to app teams to innovate and do interesting things without being shackled to the legacy way of doing things.
Again, I speak from my experience trying to build and innovate an employee-facing app in a back-office focused company. The engineering team ended up having to do a bit of hacking of the platform to incorporate better UI elements and create our own workflow engine. Yes, my counterpart in engineering made sure it was sanctioned by the platform team, but we did all the work.
In the end, having an effective platform is as much a management priority as it is a technology one.
