Examining Composability: What Should it Look Like in Real Life?

Composable thinking and the citizen developer, conceptually, fit together well. Composable thinking—the idea that anything is composable—both values creativity and inspires it. But for anything to be composable, developers need to be everywhere. Let’s talk about how that can become a reality.

As we know, composability is already in play in other business functions and industries through next-generation platforms. Web developers use modularity and workflows with ease. Legal forms may be built from key building blocks and structured based on the solution required. These are practical examples of the defining characteristics of a composable business.

But the defining characteristics of traditional manufacturing technology have made composability a challenge to implement on the floor and across facilities.

That doesn’t have to be the case. In fact, we’d argue that the defining traits of manufacturing operations are exactly the reason technology should reflect composable thinking.

Now, for reasons you can explore here, manufacturing is finally coming around.

In the report “Becoming Composable,” author and analyst Yefim Natis posits that four personas are involved in the composability experience:

• Creator — someone who designs building blocks
• Curator — someone who makes templates for the composer’s use
• Composer — someone who puts it all together
• Consumer — someone who uses it

While this is an appropriate mental model for understanding the roles played while fielding software that facilitates execution across multiple systems and we agree with it in principle, this sort of linear creation model rarely holds up in practice.

Oftentimes, these roles overlap within different personas within the organization. Additionally, there’s a feedback loop that emerges.

We propose a slightly different model that captures the unique nature of frontline operations and rolls in something that’s invisible, but critical: an ecosystem.

We can start our examination of real-world composability by drilling in on the central personas: the citizen developer and the end user. In other words, we want to consider the composability model from the bottom up to better clarify what it looks like in manufacturing.

Most often when we describe the citizen developer we’re talking about the frontline engineer: the person who is responsible for doing the work. When empowered by a set of tools, they can solve the problems they — and end users — are facing.

In a composable business, people who are closer to the work have the ability to create solutions from actual building blocks and composable logic to solve the needs of end users, from guiding a complex workflow to tracking defect data. Sometimes, those are the same people.

Where do those building blocks come from?

• Vendors - Traditional MES may or may not offer these sorts of building blocks. But those who view composability as a tenet of their product will. By providing best-practice templates, widgets, connectors, and other components, vendors can equip people in creation, curation, and composition roles.

• An ecosystem of developers - Communities emerge in spaces. As more vendors and their partners commit to composable business, and more citizen developers and developers will use composable vendor architectures, more feedback and more solutions are created that contribute to the greater ecosystem. Components, connectors, templates, and ideas can come from anywhere. Vendors can facilitate this sharing on content via libraries or marketplaces.

Now information, components, and capabilities are flowing dynamically, from the developers and users to one another and to the vendors and ecosystem and back. But there’s one more major player in the success of composability: The Center of Excellence.

As a central coordinator, the CoE works with developers across sites. They drive the enforcement of standards.

Of course, that’s not all they do. They identify best practices and find opportunities to share best practices across the organization, even in organizations with 50-plus sites. The CoE acts as a central curation mechanism to share learning back and forth — and again, that learning is further facilitated by the ecosystem.

This is what a dynamic, feedback-driven circle of information in a composable manufacturing operation looks like.

Now that we know how the various roles interact within a composable business, we can move to the right of the graphic and take a look at some examples of how the individual personas might interact with an individual application.

Consumption of End User Apps

End users have expectations. They expect bespoke applications that streamline work.

Consider the example of a mobile application that includes work instructions plus tracking. It’s delivering the content that’s guiding a process, tracking data through that process, and coordinating with the consumption of materials.

Where on the surface it appears this mobile application is a simple set of work instructions, it’s actually extended into MES because it understands the flow of materials and information through the process.

Requirements for Consumption

An app is a way of thinking of a complex system in a modular fashion. That’s why an application like this example has to be focused in its scope, lightweight, and loosely interconnected (but not prohibitively interdependent) with other apps.

Additionally, data collection should be automated (so the user doesn’t have to address it) but structured — again, so the user doesn’t have to address it, but also so other people and applications can use it.

To review, consumer requirements include:

• Single, intuitive interfaces that streamline work

• Automated / structured data collection

• Process guidance

• Up-to-date information in context

Application Composition

Remember, we’re examining composability from the bottom up. So, end users consume, and composers compose. They have certain requirements for success, too; first and foremost, the application they build needs to be a true solution for the problem at hand, which requires that they speak directly to the consumer.

Requirements for the composer include:

• Ability to create/edit apps without coding expertise

• Access to end-user feedback

• Guardrails for standardization and app starting points

• Reliable connectors

Sofiya Baran, Continuous Improvement Engineer at Stanley Black & Decker, sums it up well.

“I built an application to capture production visibility…Throughout this process, the operators were my number one customer. I took into consideration that after working at a company for many years, welcoming change in their process will be challenging. With their support, I made sure the app was easy to use and I had 100% of their buy-in.”

How did Sofiya get started with that process? How do citizen developers know where to begin?

Today’s engineering workforce is familiar with coding — especially logic. Now, those self-taught coders are your citizen developers. They interact with applications every day, so they understand how to think about a front-end user interface and build a flow that makes sense. They also interact with forms regularly, so they understand how data might be captured on the backend.

When you make tools available to this workforce, they don’t need a lot of explanation in order to get things done. In Sofiya’s case, for instance, she was so ready to compose that she couldn’t believe everyone wasn’t doing this type of development every day.

Even though composers don’t need a lot of guidance around what makes sense, giving them a place to get started still counts. Plus, curation allows you to capture the best practices that they give rise to. That’s where the Center of Excellence comes in.

Curation: Standardization and Strategy

Centralized teams (sometimes "Centers of Excellence") are formed to empower the composers. They should provide the right set of tools, deliver the appropriate guidelines, help enforce the appropriate governance, and capture the best practices for standardization across other sites. They also "curate" templates and pre-built apps for citizen developers to tweak – sometimes using sanitized versions of solutions developed by other citizen developers. Through this team, curation efforts support both standardization and strategy.

Requirements for curation include:

• Granular permissions and approvals

• Way to curate content for local teams

• Customized components

• Enterprise visibility for enforcement

Component Creation

When we move up the model to the “creation” of these components, it’s important to note that software development creators may exist inside of the CoE but not at the site level. That’s why creators may want to extend no-code to low-code technologies.

Requirements for creators include:

• Low-code capabilities

• Clean, reliable APIs for connectors

• Access to the developer community

The dynamic nature of manufacturing operations necessitates a dynamic set of interactions between the four key personas in composable business. As we mentioned in the beginning of this post, in order to successfully implement the “anything is composable” mentality, developers need to be everywhere. A framework for success like the one described here can make that a reality for manufacturers of all types.

To learn more about how composability looks within specific industries, read the next pieces in this series, focused on General Manufacturing and Life Sciences.