Composable Enterprise: Comparing Traditional MES to a Platform as a Service

So far in our blog series on our position as a challenger in The 2022 Gartner® Magic Quadrant™ for Manufacturing Execution Systems (MES), we’ve covered a lot of specifics on the concepts of composability and how it applies in different industries.

Now it’s time to think about why Tulip’s frontline operations platform was chosen as a challenger in the MES Quadrant, and what we believe that says about traditional MES.

The key difference between a platform as a service (PaaS) and traditional MES is that the architecture of the first enables a composable solution.

There are four pillars of composable architecture.

Agility

Agility requires that you can adjust processes to fit what needs to be done, vs. the other way around. This pillar is characterized by rapid implementation, updates, and iterations and by flexible and accessible data structures.

Extensibility

A composable architecture is modular in its ability to connect with other solutions, offering open API with pre-built connectors. It should also feature no-code edge connectivity and low-code capabilities.

Accessibility and Scalability

A composable architecture should allow you to replicate solutions for similar sites and situations. It should be reliable and perform as it grows. And the right data should be accessible from anywhere, not just a certain station or even site, in the data structures people need.

Human-Centric

Composability is human-centric in its nature. A composable architecture needs to feature intuitive interfaces and streamlined workflows with data from worker devices. These requirements represent the desires and expectations of today’s manufacturing workforce. People want to work for innovative companies that value their experience.

Traditional MES can’t handle composability the way a platform can.

Imagine you want to role out a traditional MES to a certain site. You go through requirements processes and operational flow diagrams and choose a vendor. The vendor begins rolling out the MES.

Almost always, customization on your end is required. You have to adapt to the system’s requirements for integration or process.

In the best of circumstances, you’re right about everything in your requirements, and nothing changes between when you selected the MES and when you fully implemented it.

Now, you want to deploy to another location. Things are different there. You need to make additional accommodations. (Maybe you don’t have any machines at that location, whereas your first implementation was all about machines, for example.) Then you want to add this to a third location. In each implementation of the same MES, each change and customization you make to the core codebase is a bit different from the last.

Now, let’s say you want to identify a best practice from your second site that is directly applicable to your third. You encounter a problem. The very concept of a monolithic codebase necessitates customization for each site implementation.

A microservices approach doesn’t.

So what is holding anyone back from switching to this approach, now that cloud hesitancy is, by and large, dead?

Legacy. Manufacturers still have to deal with the consequences of the architectural decisions that were made when all software was built for on-prem use. You can’t simply lift that codebase and ship it to the cloud and expect it to run.

It’s tough to re-create the way cloud-native architecture allows you to build if you didn’t start building there.

So you’re stuck. If you didn’t start cloud-native, it’s too hard to take best practices and move to the next site. It’s perhaps even more difficult to upgrade, from MES 1.0 to MES 2.0, or 2.1 or 2.2. It’s painful and slow.

That’s from your perspective. But imagine what it’s like for a traditional MES vendor. What are the implications for them?

If they’re managing 12 customers with 12 sites each, they need to maintain 144 different versions of their codebase. Any changes they make to their core offering has to be reverse compatible with 144 different forks of that code. That makes for a complex, difficult solution.

And this explains the slow speed of change in innovation we see in MES. A day zero architectural decision dictates everything.

To recap, the traditional MES model is:

• Focused on systems, not humans

• Difficult to upgrade

• Slow and costly to update

• Complex and siloed

In comparison to the previous architecture we described (which, again, was born on-prem), a cloud-native architecture makes things easier and faster.

The Tulip platform has one codebase and apps are configurations, not coded customizations. Thinking back to the pillars of composable architecture, agility, and extensibility demand this.

A single codebase allows for regular, fast updates across that codebase, which amount to bi-weekly or quarterly platform upgrades across all of your sites, rather than overhauls and customization. You get access to new capabilities sooner.

This also means you can easily replicate your best practices across sites via apps.

Remember Sofiya, who built a solution for her frontline operators at Stanley Black & Decker? If she saw the opportunity to roll that application out across ten more sites that could benefit, she could do so trivially. That would be virtually impossible if SB&D had begun its journey to application development with the previous architecture and a traditional MES.

To recap, the advantages of a cloud-native platform and a composable model:

• The same codebase runs across all sites

• Best practice app sharing

• Global view across operations

• Silent upgrades every two weeks

• Access to innovation sooner

• No-code apps allow flexibility

In The 2022 Gartner® Magic Quadrant™ for Manufacturing Execution Systems (MES) we see a lot of thoughtful commentary on the implications of the change in the market. And we see the introduction of the MES Architectural Innovation capability, which assumes the vendor provides a microservices architecture that supports the level of agility and speed of development we believe today’s successful manufacturing enterprise requires.

Traditional MES doesn’t allow that. That’s why Tulip is a challenger.

Even so, it’s important to note that the change from traditional MES to composability isn’t Tulip-specific.

It’s more fundamental. It’s about how we think of software development and where it should and can happen: Traditional solutions were built on on-prem architectural decisions, but composability requires cloud-native architecture. We’re ready to move manufacturing ahead.