Beyond data

Data-driven decision-making is widely accepted as good business practice. If you want to maximize the return on any investment, your actions need to be grounded in reality. That connection to the real world is what gives your decisions the most leverage and the greatest chance of success.

But data alone doesn’t get you there.

To make meaningful decisions, organizations need to move beyond raw data and translate it into higher forms of understanding: information, knowledge, and even wisdom. This is often referred to as the DIKW hierarchy. And while climbing that hierarchy is essential, it also introduces complexity.

The problem? As you move from data to insight, interpretation becomes more subjective and multifaceted. Different stakeholders bring different goals, constraints, and expertise to the table. The same data can lead to very different conclusions depending on who’s looking at it and why.

That’s why digital transformation isn’t just a technical challenge; it’s an organizational one. This article explores how architectural decisions help manage complexity, align stakeholders, and foster a more thoughtful, organization-wide approach to smart manufacturing.

The bumpy road to smart manufacturing

During the Industry 3.0 era, data was smaller, data flows were more localized, feedback loops were tighter, models were simpler, and advanced decision-making often relied on humans in the loop. Rapid advancements in data communications, storage, and computer power ushered in the fourth industrial revolution — promising gains in operational efficiency, product quality, sustainability, and even business continuity.

The hallmark of the smart manufacturing revolution is an explosion of technical options — algorithms, approaches, and technological solutions. An important driver of these advancements has been the widening of the circle of stakeholders invested in these advanced technologies. Once limited to specialized roles like process control engineers, logistics experts, or finance teams, smart tools now give a broader range of users, including business analysts and product designers, the ability to contribute directly to digital initiatives. With the rise of generative and agentic AI, the barrier to entry has dropped even further, making advanced capabilities accessible to nearly any role in the organization.

However, this explosion of possibilities presents not only an opportunity but also risks increasing organizational and technical complexity. This risk stems from both the relative novelty of smart manufacturing and the broad scope of its potential applications.

Legacy approaches targeted a limited set of business processes and matured gradually over decades. While Industry 4.0 reference architectures do exist (like RAMI 4.0, IIRA), there are no dominant, universally applied blueprints. That’s no surprise; the range of use cases is so broad that practical 4.0 solutions almost always need to be tailored to a company’s specific maturity, goals, and ecosystem.

Complexity is the enemy

It’s common to find large companies with substantial industrial assets that are still in the early stages of their 4.0 industrial revolution journey. One organizational challenge they often face is the strong incentive to increase the interconnectivity and interdependency of business processes that were previously siloed.

As teams begin to recognize the potential of modern IIoT and cloud technologies, particularly the access to rich data streams and powerful processing capabilities, they’re naturally inclined to take advantage of them. However, without careful planning and thoughtful architecting of the digital transformation effort, this can lead to an uncontrolled rise in complexity.

For example, imagine Acme Industries, a manufacturing company that owns two nearby factories. The factories are connected to the internet, and data is flowing. One in-house software development team is tasked with building an advanced predictive model to optimize the flow of source materials into the shared warehouse. Meanwhile, a second team is developing a dashboard for top-level executives that presents high-level production efficiency analytics.

Both teams quickly realize they don’t fully understand the data stream — data points that use descriptors and taxonomy that have evolved over time and now appear disorganized. Yet, to OT personnel, the data structure makes perfect sense.

Now Acme Industries is faced with choices. Should the teams approach the control systems team to normalize and structure the tags in advance? What if the new structure works well for the warehouse management team, but not for the dashboard team? Should the dashboard team be required to reuse the modules developed by the warehouse team (or vice versa)? Does it mean that the warehouse team now has to design their use case with the dashboard team's needs in mind? And how can all of this be planned and estimated without stepping on each other’s toes?

Eating the elephant

When planning an Industry 4.0 digital transformation project, it’s important to recognize that for some organizations:

1. It may be hard to design and negotiate a company-wide technical standard for the new smart systems.

Teams whose requirements and goals significantly differ will prefer significantly different ways of doing things — different data structures and data pipelines, different tools, models, algorithms, and deployments. This flexibility and autonomy can be a feature of the organization, not a bug.
Companies with vertical decision-making and decision-enforcement structures may be able to design and impose a "common denominator," but it is not likely to be good for everyone. Companies with more horizontal, consensus-based structures may become bogged down in analysis paralysis.

2. It may be hard to introduce large-scale changes, such as implementing a company-wide standard.

Company-wide standards, specially designed by a committee, may excessively constrain development, canceling any benefits connected to unification.
This challenge is especially hard to do on the factory floor of Acme Industries. The cost of error is high, the amount of assets is large, and the incentives of the application teams are foreign — the trade-off is therefore strong on the side of "don't fix what's not broken."

Architecture to the rescue

To maximize success, the planners of a digital transformation strategy for a large industrial company should take these non-technical considerations seriously. If organizational change is possible, there are technical approaches that can help. In particular, these classical architectural tools of abstraction and modularization — both in technical and organizational domains — can offer meaningful solutions:

Abstractions enable multiple, unlimited views of the same underlying data or system. This means teams don’t have to try to design and implement a single view that fits all — each stakeholder can have their own.
Modularization, powered by these abstractions, will limit the scope of changes and reduce the impact of potential issues.

As an example, building a data abstraction can look like this:

You could design your universal data schema to be minimal and decouple data from metadata. For example, avoid embedding information into identifiers, putting metadata into data messages, or "baking" unnecessarily descriptive hierarchies into MQTT topic names. This avoids single interpretation and instead supports multiple, flexible views of the same data.

You could then design the solution to allow multiple, flexible, independent, and unlimited planes of metadata for the same data, which will let different teams easily look at data from their unique angle.

Of course, there will have to be a system for metadata management, and a minimal data model carries performance risks. Even so, this approach provides choice: Each team at Acme Industries can decide what systems will be independent and where it makes sense to share resources. This kind of modularization supports more agile R&D and helps contain the impact of mistakes or bugs.

There is one caveat: The more sophisticated your data model becomes, you’re less likely to find support from established tools, standards, and specifications. For example, most commercial digital twin platforms (especially from big vendors like Siemens, PTC, IBM, or Microsoft) typically expect structured and semantically enriched data upfront that follows a fixed object model. And if you build a bespoke model instead of adhering to OPC UA object models, you may lose plug-and-play compatibility. It’s possible to resolve this clash with additional translation layers; many vendors now offer integration middleware or semantic‐model adapters. Still, these measures could negate any simplicity or flexibility gains in the first place.

Organizational realities as architectural drivers

As we’ve explored throughout this article, digital transformation, especially in the complex world of smart manufacturing, is shaped as much by organizational realities as by technical ones. Team structures, legacy systems, communication patterns, and decision-making processes must all be treated as core architectural considerations. The good news is that many of these organizational challenges can be resolved through thoughtful technical design. Just as software architecture seeks to isolate concerns, manage complexity, and enable scalability, similar principles can be applied to structure data, interfaces, and internal tools in ways that modularize how teams work together.

This often requires greater upfront investments and can carry some additional technical risks. But the payoff can be substantial: faster stakeholder alignment, quicker technical wins, and a stronger foundation for long-term success, both within your organization and in collaboration with your clients.

Start a conversation with us

Yaroslav’s recent stories

The Road to Smart Manufacturing