Using a six-point plan for creating low-code digital thread

Digital threads can help in a manufacturer’s digital transformation, but it doesn’t have to be a complex process. A six-step plan for developing a low-code digital thread is highlighted.

By Rob McAveney November 10, 2022

Image courtesy: Brett Sayles

Learning Objectives

The digital thread eliminates typical organizational bottlenecks that stymie change, helping companies drive process improvement.
Users can upgrade continue building toward a digital thread as the organization evolves to realize new capabilities and technologies.

Digital thread insights

The digital thread is designed to help drive process improvements by eliminating potential bottlenecks.
Companies need to consider whether out-of-the-box is a good thing and how customizations are built.

Creating a digital thread of product design and manufacturing information is critical to enabling a manufacturing organization’s digital transformation. With such a digital backbone, benefits accrue quickly:

Cross-functional teams can more efficiently access and impact the information they need.
Different domains can collaborate
Data flows more easily between related.

In short, the digital thread eliminates typical organizational bottlenecks that stymie change, helping companies drive process improvements. Faster innovation, strategic focus and efficiency improvements follow naturally.

First, consider that what defines a digital transformation is unique to the company – as unique as the processes employed, the data generated and the products built. Out-of-the-box software alone will not meet every company’s needs. Rather, out-of-the-box capabilities must be delivered with the ability to evolve as business needs shift, making customization critical and inevitable.

Plenty of manufacturing enterprise software companies are touting the value of a digital thread to drive digital transformation, but it is critical to consider how companies will leverage their technology to create and optimize their own digital thread. Consider the following six points as a framework to ask on how to best create a digital transformation strategy.

1. Is it digital transformation or “best practices” in sheep’s clothing?

Can any out-of-the-box enterprise software tool build the unique digital thread? Generating, managing and connecting related information across any number of product lifecycles is a unique process defined by the organization in a way specific to the products the company create and the teams employed to create them.

Out-of-the-box software is a great starting point for any team, but also consider this. About a decade or so ago, “best practices” in product lifecycle management (PLM) were all the rage. This amounted to software companies encouraging organizations (in different industries they knew very little and employed few or no experts in) to change their unique, differentiated workflows to match the software development company’s idea of how they should run their business and build products.

Not coincidentally, those “best practices” matched the workflows and processes baked into the software. Changing existing processes to match software workflows “out of the box” meant the software, which was rigid and difficult to change, wouldn’t require customization.

2. Is the path to “out of the box” paved with good intentions?

In truth, out-of-the-box software alone is impossible to evolve with the unique needs and processes of our business. To be successful, out-of-the-box applications must be built for transformation, so they can quickly evolve with an organization’s needs and processes. Like a fingerprint, every company and its processes are unique — every team, every process, every workflow, down to every data point, because every company builds different products. The way one company’s product information must fit together, flow down, and relate in interconnected ways to build its unique digital thread must necessarily, be as unique as the processes used to create the data.

While the company’s product is the competitive differentiator, so is the process used to build that product. Leverage technology to enhance unique processes? Yes. Use it to accelerate processes, digitalize processes and connect more groups across the organization into their processes in an automated way? Also all yes.

Should these processes be replaced with rigid software that belies the complexity, uniqueness, and competitive differentiation of the team’s approach to product development? No. Never change what makes a team successful to conform to some software company’s idea of how things should be run.

3. How are customizations built?

In this light, it’s no wonder customizing enterprise software is inevitable. For companies investigating software vendors to support their digital transformation, the question should not be: “To customize or not to customize?” Rather, it should be, “How will your software help my organization keep pace with change?”

Companies need to find out how the software gets customized, who customizes it, how long it takes them, how easily they can continue iterating on customizations when they need to change, and how those customizations remain in sync with vendor updates and upgrades as they are released.

Spoiler alert: Most enterprise software is not built for transformation or designed with customization in mind. Yes, it can be done, but they must be knowledgeable developers who can access and change the code base, recompile the code, and launch the new system.

Once that’s done, the new code has branched significantly from the original code base, heading off in a new direction to meet and address the unique needs of the team. When an organization needs to add its own updates and improvements to that iteration, they must start from this new point: a branch that no longer allows any return to the original, out-of-the-box toolset.

At the same time, the vendor has been doing the same, but they’ve started from the last point the two sides had in common: their last released version. In a way, they’ve branched as well, except their branch is the one that matters when they release a software upgrade. When the organization’s team has branched from the vendor’s path via customization, their updates become inaccessible because the tool is not built to be customized and upgraded.

To move forward and upgrade, companies must back up to an earlier version, before the customizations, meaning the company has lost their changes and must add them in all over again from scratch or lose those processes forever.

4. Are you giving me branches or rungs?

In contrast to branches that can leave you stranded between versions like other PLM vendors offer, companies want to find a platform built with rungs meant to climb.

Customization through configuration in a graphical user interface (GUI) helps administrators easily configure (on the back-end) a customized user experience (on the front-end).

An easy, no-code, “configure to customize” path is the one most customers use to extend applications or build their own. However, additional low-code functionality exists for administrators and developers who know how to code, and who need the platform to achieve more.

Developers are able to include custom logic by creating methods (short snippets of code). Methods can be attached to events to achieve the desired function. For example, a validation method may be used to prevent an item from entering an approval workflow until all necessary digital thread links are included. Easy-to-use tools can keep customizations carefully organized without sacrificing the ability to access and extend our platform services to work as needed.

In short, upgrades can always be achieved, and quickly. With some software vendors, this is free of charge, taking an average of three months from idea to production versus the 11 to 14 months other packages require to complete. Development work is low-lift (hence, “low-code”), and this easy, intuitive, point-and-click configuration to customize the tool is available throughout every application on the platform.

Through this combination of GUI-high, low-code administrator user experiences existing applications be configured to work in new ways – with new workflows, capabilities, and connections. Also, new applications can be built from the ground up to ensure the digital thread works as needed: Connecting every new process, data point, team member and external tool across one seamless platform.

5. Can I build it as I go?

The old analogy of building the airplane while we fly it, or building the car while we drive it, seems apt during this time of inevitable digital transformation. The need to change the way digital systems work should involve adapting them to new needs along the way – not contracting again with system integrators, making a new purchasing decision or interviewing a new stream of vendors to replace legacy tools that don’t do what they need to anymore. By the time that’s been done, the opportunity has gotten away.

Changes administrators introduce should be visible at run-time: meaning users can see most changes happen live in the system as they’re made. There is no recompiling code or re-creating and redeploying executable files. To ensure the integrity of the current data in the live production system, teams will test changes in pre-production or sandbox environments and then deploy those changes to the live environment, where end-users can enjoy the nearly seamless introduction of new capabilities and start reaping their benefits.

The first benefit is increased agility, or the means by which teams can deploy changes rapidly, discover how they work out for end-users, and continue iterating on the environment. Evolve the feature set just the way it’s needed, then continuously improve functionality as new needs come online. Such changes may be minor, or they may be major, so this same agility allows teams to add new users, integrate new tools, update their processes swiftly, and rapidly adapt to changing business environments – even pursuing new strategies for the product, the organization, or the market by changing up the platform’s capabilities when needed, as demand dictates.

6. Is it designed for upgrades?

Low-code ensures agility. It ensures the data built on the platform matches the needs of the team and the organization and is not stuck in time where it can’t be accessed or built upon further. It ensures teams can take advantage of the upgrades offered when the platform is designed to be built upon.

Software should allow teams to choose (or not choose) to deploy vendor software changes; and, as functionality is added, improvements (to applications and to platform services) can be brought in alongside any customizations – at no additional cost. This level of choice should extend to enterprise software-as-a-service (SaaS) offerings: the same functionality and customizability exists in the cloud. Updates should be offered for the cloud environment on the customers’ schedules.

How to create and manage data

Don’t lock away the product data, which is the organization’s most valuable asset, in legacy systems where you can’t get at it, improve it, build on it and connect teams with it. An architecture should enable every application to run on a single software architecture to ensure data can flow seamlessly among applications in the way the teams need to consume and control it along its digital thread journey. No matter how much an environment has been customized, users can always upgrade and continue building toward a digital thread throughout time as the organization evolves to realize new capabilities and technologies.

Rob McAveney is chief technology officer, Aras. Edited by Chris Vavra, web content manager, Control Engineering, CFE Media and Technology, cvavra@cfemedia.com.