Ninja Turtles, Legos, and the Case for Composable Supply Chain Planning

‍

I’ve been sitting on this blog for almost a year now. I wrote the first draft right after a road trip to Orlando with my daughter, Ava. We were heading to her annual chorus competition with her elementary school.

For the entirety of the four hour drive, she had my phone in her hand, fully in control of Amazon Music, but very few songs seem to hold her interest for more than 30 seconds. Taylor Swift? Cringe. K-Pop Demon Hunters? Next. Steve’s Lava Chicken? Skip. Random Disney track? Pass…you get the idea.

 At some point I just said, “Ava, let’s make you a playlist. Put everything you want in there—whatever artist, whatever song, whatever vibe you’re going for —and we’ll save it.” She loved it and I finally got some peace and quiet.

It was that moment that reminded me of the concept of composability—how modern systems let users mix, match, and assemble experiences, just the way they want.

And then….. I closed the draft and forgot all about it for the next eleven months.

When I came back to finish it last week, two things had changed. First, Ava is now firmly an Ariana Grande fan. Taylor Swift is apparently “not cool anymore.” Second, my four-year-old son has now started coming on our school road trips trips too, and his taste is exclusively limited to Ninja Turtles, Paw Patrol and the GOAT soundtrack — on repeat, forever, until the end of time. So now instead of one kid skipping through songs, I have two kids arguing over who gets “their song” next.

Which honestly just makes the point better. Tastes change, needs change, but a good system changes with you.

‍

The Evolution of Music: From Vinyl, Cassettes, and CDs

Back in the 1960s, if you wanted to listen to a song from the Beatles, you had to buy the entire vinyl record, even if you only wanted one song. It was all or nothing. The format was beautiful—warm sound, iconic covers—but inflexible. There was no picking and choosing.

Then came cassettes. By the late ’70s and early ’80s, they offered a hint of modularity. You could make your own mixtapes, record over songs, and listen on the go. But you had to constantly rewind and fast-forward, deal with fragile tape, and players that “chewed” your favorite songs.

Still, for all their imperfections, cassettes marked the beginning of music personalization. They brought modularity, of a kind—your mix, your order, your vibe.

CDs took it further. With higher quality and the ability to skip tracks, they gave listeners more control. And with CD burning, you could finally curate your own compilations—though it was still time-consuming and not truly dynamic.

Each format added more user control, more modularity. But it wasn’t until digital and streaming that we truly hit composability.

‍

From Fixed Formats to Endless Flexibility

Today, we can pull songs across genres, artists, albums, and moods. In seconds, we can personalize the music experience to match exactly what we want. Mine bounces between Spanish rock, house music, R&B, classical movie scores, and '80s and '90s pop. My daughter mixes Disney pop, Ariana Grande, and K-pop, and can update as frequently as she wants. It’s hyper-personalized. It’s composable.

‍

That’s composability in action: the power to assemble, disassemble, and reassemble an experience that fits you.

The same principle applies in technology. You’re no longer stuck with one format or system. Just like you don’t have to buy a full album to get one song anymore, businesses no longer have to buy monolithic systems and hope they can stretch them to fit every use case.

Instead of being locked into a monolithic system, composable platforms let you build a solution tailored to your needs—mixing best-in-class components across vendors, tools, and architectures. It’s agile. It’s flexible. And it grows with you, just like my daughter’s ever-evolving taste in music.

‍

Composing Experiences for Multi-Users

Composable architecture gives SaaS companies the ability to move faster, scale smarter, and tailor their offerings to shifting customer skill sets, roles, and needs.

Here’s something I think gets glossed over in most composability conversations: different people in your organization interact with these systems at totally different levels. And that’s fine—as long as the platform is designed for it.

Think about the Lego product line for a second. You’ve got Duplo—the big chunky blocks made for toddlers. Then your classic and regular Legos. Then the advanced sets where you’re spending three weekends building a Star Wars Millennium Falcon with 7,500 pieces.

Your users work the same way:

•      Planners and business users are in Duplo territory. They need to be able to adjust things, configure their view, get self-service answers—without needing to understand what’s happening under the hood. No-code tools are built for them.

•      Citizen data scientists and super users are working with regular Legos. They’re composing applications, configuring AI agents, and building workflows. They’re not engineers but they’re definitely building something.

•      Your engineering team is deep in the Star Wars sets. They’re designing the building blocks themselves—the architecture, the APIs, the underlying logic that makes everything else possible. This is the work that takes weeks to months and has to be right.

A well-designed composable platform doesn’t try to collapse all three into one experience. It lets each group work at the right level without stepping on each other. The planner doesn’t need to file a ticket to update their dashboard. The engineer doesn’t need to babysit every configuration change.

You wouldn't ask the business to build their own Millennium Falcon 

The Architecture Behind Composability: Microservices and PBCs

Under the hood, composable systems are typically built on a microservices architecture—an approach that arranges an application as a collection of loosely coupled services organized around specific business capabilities. Unlike a layer within a monolithic application, each service is a self-contained piece of business functionality with clear interfaces.

These services are increasingly being packaged as Packaged Business Capabilities (PBCs)—modular, autonomous units that can be sourced from a vendor or built internally, exposed via APIs to different users according to their roles, and combined through an application composition platform to support more complex business processes. They also share data through an open data fabric, enabling integrated analytics, AI, and cross-system reference access.

It’s worth noting that not all vendors are equal here. Incorporating these architectural principles is simpler for vendors with newly built solutions. For older, legacy platforms, modularizing a monolith and breaking it into reassemblable components is significantly harder—and the results are often less clean. 

‍

From “Patchwork AI” to Composable Foundations: The Supply Chain Imperative

Many organizations today are running what I’d call patchwork AI—a collection of solutions and spot initiatives stitched together with good intentions but no coherent architecture underneath. A demand forecasting tool here. A warehouse optimization bot there. A generative AI experiment bolted onto an existing planning tool. Sound familiar?

The challenge is the foundation.  Writing scripts to stitch integrations together might work in the short term, but it creates tech debt, breaks on upgrades, and simply doesn’t scale. The new model is about abstracting logic at the semantic and ontology layer—assembling capabilities like Lego blocks that are maintainable, backwards-compatible, and extensible over time.

This is the critical shift supply chain leaders must drive: move from patchwork and spot AI initiatives to a composable, foundational solutions architecture. That means:

• Interoperability by design: Your supply chain platform shouldn’t be an island. Whether you’re integrating an enterprise-wide semantic layer, a third-party AI agent, or a best-in-class supply chain planning platform, the architecture should make integration additive, not disruptive.

• Modular capability building: Build or buy packaged business capabilities (PBCs) that can be assembled, upgraded, and replaced independently—without re-platforming your entire stack.

• AI as a composable layer, not a monolith: AI agents should plug into your architecture the same way any other service does—through APIs, governed by your data fabric, and composable with your planning logic. Not hardcoded. Not siloed.

• Enabling multi-role experiences: Your planners, citizen data scientists, and engineers all need access to the same underlying data and capabilities—but through appropriately granular interfaces. Composable architecture makes this possible without bespoke builds for every persona.

The companies that will capture the most value from AI in supply chain won’t be the ones with the most AI projects—they’ll be the ones who built the right foundation to compose, scale, and evolve those capabilities over time.

‍

Back to Ava’s Playlist

A year ago when I wrote the first draft of this, Ava was firmly team “Taylor Swift”. Now she’s team “Ariana Grande”. My son is crushing hard on Paw Patrol until further notice. The playlist keeps changing, the road trips keep happening, but somehow everyone still eventually gets to hear something they like.

Companies need exactly that from their technology. Not a system configured for the business you were three years ago, not a patchwork of 47 AI pilots that nobody can govern, upgrade, or connect, but an architecture that moves with them — composing new capabilities without breaking what works, adding what is needed, dropping what isn’t.

 The companies that will capture the most value from AI will be the ones who built the right foundation: modular, interoperable, and designed to evolve.  Because honestly, having to run your business on a rigid legacy stack is a pretty accurate description of being stuck on the same cringy Disney track on repeat.

‍

Appendix: The MACH framework

For anyone actively building composable systems, the MACH framework is worth knowing. It stands for:

• Microservices—small, independent services that each do one thing. If one breaks or needs updating, the rest keep running.

• API-first—every service communicates through documented APIs from the start, not as an afterthought. This is what makes interoperability actually work.

•Cloud-native—built to scale up and down with demand. You’re not buying infrastructure for peak capacity and letting it sit idle the rest of the year.

• Headless—the front-end and back-end are separate, so you can redesign the user experience without touching the underlying logic, and vice versa.

The MACH Alliance has a lot of good resources if you want to dig deeper: machalliance.org

‍