Ever since my mid-career MBA, I’ve been wondering why large parts of the software industry ignore the basic lessons of production design. I still vividly remember when I first read The Goal during my class on operational efficiency, and later dove into Toyota’s (Lean) Product Development System. (Yes, this is a distinct system from the much better-known Toyota Production System. I actually find TPDS more applicable to software development than TPS.) Then I discovered my all-time favourite: Lean Software Development by Mary Poppendieck. Concepts like “Amplify Learning,” “Decide as late as possible,” “Empower the team,” and “See the whole” made so much sense that I couldn’t understand why everyone wasn’t doing it.

So when I was thinking about Whiteman’s “Back to Basics” article on Medium, contrasting the rush to adopt AI with the foundational principles of organizational systems, the InfoQ summary of Rachael Wonnacott’s talk at the most recent QCon London on platform strategy popped up. And even though at the surface they seem to be distinct, I felt that they were looking both at the fundamental truths that underpin making things work effectively.

Rob Whiteman’s article really struck a chord. He calls out the tendency for companies to chase the allure of shiny new technologies, particularly AI, without having a solid grip on their basic operations. He speaks from experience, having worked in consulting where the focus is often on selling the latest trend rather than addressing core needs. His key point: lasting value comes from getting your operational fundamentals in order. Coming from GE he brings up the Theory of Constraints (from The Goal) which states that every system has a bottleneck, and improvement efforts should focus there. As he puts it, the real wins are in ops fundamentals like constraints and consistency, and that “AI can’t fix what you won’t focus on.”

I tried to make a similar point first in my role as API Evangelist and later as CTO in formulating and promoting a Lean API Strategy. For me, it’s never been just about the technical act of creating an API. It’s about linking it to a genuine business need and a desired business outcome. You need to understand what you want the API to achieve for the business or organization before you even think about the code. This ties back to the concept of organizational domain design, rooted in and informed by Conway’s Law. It states that the design of a software system will reflect the communication structure of the organization that built it. Software mirrors people: Technical boundaries often reflect social or team boundaries. And APIs are simply the technical representations of such boundaries.

An architect will understand this and align the architecture with such visible and invisible social and cultural boundaries. This approach later gained popularity as Microservice Architecture (MSA). I still think that the name does not do justice to the fact that MSA was not primarily concerned about the size of services but was about making concious choices about business, social or team boundaries in the technical architecture of the platform or solutuon.

Then I read the InfoQ article from Rachael Wonnacott, and she echoes many of the same principles in the context of building developer platforms. She argues that platforms are fundamentally about delivering business value. While a good developer experience is crucial to achieving that, it’s secondary to overarching business goals. You can’t just introduce a modern platform into a large enterprise with existing legacy systems and expect immediate success.

What I found particularly insightful in this article was the idea that “the platform is also knowledge and support,” not just technology. It’s about fostering collaboration, having platform advocates, and building internal communities. Her point that “the platform’s real job is integration” is also key. It acts as a bridge between different stages of the software delivery lifecycle. This strongly aligns with a key tenet of Toyota’s Lean approach: always focus on the whole, not just the parts. She also highlights the inherent tension between the autonomy developers desire and the business’s need for predictability and control.

So, how do these pieces fit together when we think about platform design? Whiteman’s emphasis on identifying and addressing bottlenecks is absolutely relevant. If your software delivery pipeline is slow due to, say, manual security checks (as I mentioned in my Designing Systems article), then implementing a fancy new deployment platform won’t magically solve that. As Whiteman says, automating a broken process just makes the problems happen faster. The InfoQ article reinforces this: your platform needs to solve real, existing problems and integrate into current workflows.

Just as an API should have a clear business purpose, a platform needs to be driven by demonstrable business value. You need to understand the organization’s current state, the capabilities of its teams, and the friction points in getting software deployed. Yes, that whole organizational domain design aspect again. Mapping the developer journey, as Wonnacott suggests, is essentially about understanding the current “business process” of software development before trying to apply a platform solution.

And remember Whiteman’s focus on reducing variability? Platforms can definitely contribute to this by standardizing tools and processes. However, as he points out in the context of AI, you first need to understand the sources of that variability. Building a successful platform isn’t just about the technology itself—it’s about understanding the business context, the people involved, and those critical bottlenecks.