Composable vs. Monolithic Architectures

Why is Composable preferable to Monolithic?

A monolithic solution is characterized by the following:

• Built on a Top-Down Data Model
  • Process and Activity Models are defined by data in Tables and Monolithic Apps are used to execute the process or activity model. Data models in Tulip Tables provide an abstraction of the complexity of the operations in a one size fits all approach.
• Process-Centric
  • Monolithic Apps are built to serve a function based on a Functional Decomposition of the complexity of the operations. The finite set of Monolithic Apps are intended to provide the same function to frontline operators anywhere in the operation.
  • Monolithic solutions are commonly composed of two apps: a Configuration App and an Execution App, wherein the Configuration commonly includes Work Instructions & Process Routing in data tables rather than in the composable app(s) themselves.
• Designed for Centralized Maintainability
  • Monolithic Apps are designed to ease the maintenance and management of the solution by a central team by reducing the number and variety of Apps used. The monolithic solution is designed top-down in a rigid hierarchy where frontline operators serve the Apps with information by choosing which function is applicable vs being supported and enabled to do their work.

We strongly recommend against Monolithic solution approaches, and instead to follow a Composable approach since Tulip is not a traditional MES. Tulip is NOT designed to be used to build apps that are monolithic - i.e. one app to serve all industries, in all modalities, in all scenarios, with any machine, and for all operators. Monolithic solution results in what we call a JAM (Just Another MES).

Monolithic Solutions Inevitably Have Shortcomings

Monolithic solution approaches inevitably result in a solution that is, at best, “just as good” as the other MES and will inherently have all the associated shortcomings:

• Monolithic solutions take months/years and high effort to deploy - long time to value.
• Monolithic solutions make inherent platform capabilities such as Vision, IIoT, AI harder and sometimes not usable. Ie reducing ability to leverage native digital technologies.
• Monolithic solutions are not human centric, and tend to have a clunxy User Experience wherein the operator is serving the system vs. the more valuable where the system serves the operator. Thus inhibiting productivity gains.
• Monolithic solutions are inherently complex and hard to maintain, they require a dedicated team with unique knowledge of the solution - exactly like a custom built software solution
• Monolithic solutions do not scale well since they expect all operations to adhere to one standard data model.

It is a strict top-down approach that assumes changes are minimal and are generally known.

Monolithic solutions are built to automate a process where humans have to play by a strict set of rules. This assumes very little change and that all variation are known.

Building Composable Solution is Easy but Requires a Change in Mindset.

Composable solutions use the capabilities of the Tulip Platform to provide unique and specific way for frontline operators to interact digitally and enable them to be more productive. It provides to the operator a digital interactive solution where the physical and virtual world are interconnected. This is a critical principle in achieving productivity gains and is inherent to composable solutions.

Characteristics of Composability & Composable Solutions

• Solution broken into smallest logical blocks (Solution Components) that make sense for a given Shop Floor.
  • E.g. the Solution might be broken into separate Apps based on: Place, Time, and Persona
• Solution Components share a Common Table Model.
• Solution Components are developed with shared Customer-tailored Best Practices
• Solution and its Components can be understood and supported by another Citizen Developer
• Solution and its Components are parameterized where sensible

The Tulip Platform is a Software (SaaS) however Tulip apps should not be thought of as software. They are purpose built highly configurable digital content that should be continuously changed and adapted to the needs of the frontline operations. Modifying or enhancing an app is the same as changing master data, in fact apps are master data! The Tulip platform provides a way to manage app changes through a governed, version-controlled life cycle process to help manage this configurability. Apps are composed using no-code and the App Solution is composed of Apps. Building solutions in Tulip using a monolithic functional based approach, as if its a software solution, critically constrains the ability to rapidly build solution and gain the benefits of a composable system.

Other important benefits of Composable Solutions include:

• Provide Augmented frontline workspace for increased productivity
• Use of seamless integrated digital technologies including Vision, AI/ML, Smart devices, etc.
• Instrumentation/digitization of processes and frontline operations to enable data driven decision and CI.
• Guide production execution with shared information from Tables and external systems.

Composable solutions provide added value in their ability to easily integrate and collaborate with other systems. This is at the core of IIoT where different autonomous devices and systems easily communicate and interact. Tulip is an IIoT platform and natively provides that ability to build integration with other systems using its no-code approach. With the platform consuming and sending data to other IIoT, end-points can be achieved in hours by people with little IT background. This all requires a composable approach where Apps have specific flows and connections to the local physical world.

Common Solution Patterns in Tulip Solution Design

The high-level design of a Composable Solution can follow many patterns. Below are common patterns of Tulip solutions. Note that this is not an exclusive set nor are these mutually exclusive. Depending on the use cases at a given facility, many of these patterns and others might be used.

Implementation of a Traditional Monolithic System vs. Implementation of a Composable Citizen-Developed Solution

The traditional approach of implementing an enterprise system is commonly a long-term high-risk delayed-value approach as seen in 'The Old Way' below. It is commonly expected such an initial implementation to take years, and thus naturally it is expected for any subsequent critical enhancements to take nearly as long.

Implementation of a Composable Citizen-Developed Solution - Start Small and Grow Organically in Capability & Use Cases

By contrast to the slow implementation of a traditional monolithic solution, implementation of a composable solution can be done iteratively yielding very fast time to value and naturally supporting an Agile model of continuous improvement.

While deploying "version 2" of a solution developed via traditional Monolithic solution may take several months or longer, deploying a "version 2" of an app in a composable solution may be merely hours, days or weeks. The rapid iterations made possible by composable solutions improves adoptability by your operators - as they see for certain their feedback is not falling on deaf ears.