Standards in the Age of Acceleration

Why standards bodies are falling behind – and how large corporations can still standardize

Anyone responsible for digitalization in manufacturing knows the reflex: we need a standard. A protocol for connecting machines, a platform for data analytics, a tool for shopfloor management. Not out of dogmatism, but out of sober economics: every additional solution in the stack costs operations, maintenance, security patches, training and, at some point, the colleague who is the only one left who knows how it works.

So the question is not whether to standardize. The question is what to orient yourself by. And this is where the problem starts. Anyone looking for a reference today either finds none, because the technology is too young, or one that describes the state of things five years ago. Neither helps with the decision due next week.

And yet there is no shortage of standards. There are far too many of them. For machine connectivity alone, OPC UA, MQTT, Modbus, PROFINET, MTConnect and a dozen vendor-specific protocols compete with each other. The picture repeats itself on every layer of the stack. And then, reliably, someone comes along and develops a new standard to unite all the existing ones, and the count goes up by one. This reflex is so familiar that it has become a classic comic, and it shows the real problem: it is not a lack of standards that paralyzes companies, but the missing decision about which one applies.

This affects two levels at once. On the shopfloor, it is about communication protocols and data models: how do machines, sensors and systems talk to each other? At the company level, it is about the entire tech stack: which software solutions do we use, and how many of them are allowed? On both levels, the gap between what standards describe and what the market has long been doing grows wider every year.

This article is an attempt to name this gap honestly and to propose a practical way of dealing with it. Not as a farewell to standardization, but as a call to rethink it.

A standard describes the generally recognized state of the art. That is its mandate and, at the same time, its structural problem: “generally recognized” presupposes that a technology has already prevailed, that a committee has discussed it, processed objections and reached a consensus. At DIN, VDI or IEC, this usually takes three to five years. In a world where AI models are released every six months, a standard is therefore almost inevitably a thing of the past by the time it is published.

While a standardization process runs from identifying the need to publication, several versions appear on the technology side. By the time it is published, the standard at best describes the state it started with.

OPC UA is the textbook example. Available as a base standard since 2008, it took well over a decade until companion specifications for individual machine types were ready for practical use. In parallel, MQTT, Sparkplug B and the Unified Namespace have become established in factories worldwide without any standard ever having required them. The market decided before the committee was done.

On top of that comes a second problem: standards are closed standards. They cost money, come as PDFs, are not machine-readable and do not come with a reference implementation. A developer who wants to adopt a protocol today expects a repository, an SDK and a community. A standard delivers none of that. Anyone who wants to implement it first has to buy it, then interpret it, then build it alone.

The standards organizations know this. Two answers are already on the table, and both are meant seriously:

• DIN SPEC is the fast track: a specification that a small consortium develops in a few months without a full consensus process and that is usually available free of charge. It does not have the status of a standard, but can later be turned into one. In practice, it often remains a niche product: few know it, few use it, and the transition to a standard takes years again. Even this fast track cannot keep up with the pace of large technology companies: Anthropic developed, published and equipped MCP with SDKs with considerably more resources and in less time than a DIN SPEC consortium needs for its first draft.
• SMART Standards are the initiative by DIN and DKE to make standards machine-readable and machine-interpretable. The goal is right: content should flow directly into engineering tools and testing systems. The pace is not. The initiative has been running for years, while most of the body of standards is still available as PDFs. Here, too, reality has already outrun the committee: while standardization defines XML as an intermediate step toward machine readability, open source tools such as Docling from IBM Research, freely available under the MIT license, have long been converting complex scientific documents into machine-readable Markdown. Once again, technology was faster than the process.

Both approaches show that the diagnosis has arrived. What is missing is the cultural change behind it. The self-image of many committees is still: we define what applies. The zeitgeist and the demands of a fast-moving technology world call for something else: we provide what works – openly, quickly and in a form that developers can actually use.

This cultural change is difficult, and you have to be honest about why: the business model of standards organizations is based on earning money from access to “what applies”. If your revenue comes from selling documents, you have little incentive to make those documents open, free and machine-readable. So it is not just about processes, but about the will to innovate your own business model. The open source world shows that you can make money with open standards, just not from the standard itself, but from certification, conformance testing, tools and consulting around it. Those who do not take this step will not be able to become faster, because they cannot afford to.

Two players are stepping into the gap that standards leave behind: technology companies and open source foundations.

At the end of 2024, Anthropic released the Model Context Protocol (MCP), an interface through which AI models access data sources and tools. Within a few months, it was adopted by the major software vendors, and at the end of 2025 its governance passed to a foundation under the umbrella of the Linux Foundation. In August 2026, the Model Hardware Standard (MHS) followed: standardized drivers through which AI agents control lab equipment, robotic arms or manufacturing equipment, with defined limits for safe operation. All of it model-agnostic, as a research preview, with an announced open source release. No committee, no consensus process, no price.

With Margo, the Linux Foundation is driving an open interoperability standard for industrial edge applications, backed by automation vendors who are otherwise competitors. With Sparkplug B, the Eclipse Foundation has given the MQTT protocol a data model for the factory. And the Industrial Digital Twin Association is developing the Asset Administration Shell as an open specification with a reference implementation before it becomes an IEC standard. That is the most interesting middle ground: consortium and standardization interlock instead of working one after the other.

The pattern is the same for all of them. What prevails comes with a reference implementation, is freely accessible, has a community and is developed by those who use it themselves. Document plus committee plus paywall loses against repository plus community plus openness. Not because the content is worse, but because adoption today is decided by usability.

Both models produce standards. Only one produces them in a form that a development team can put to use the same day.

This has a downside that decision-makers need to keep in mind. A standard controlled by a single company is, first of all, a product with a strategic interest. The touchstone is the handover of governance: does the standard move to a neutral foundation, as MCP did, or does it remain a tool for market lock-in? Anyone adopting de facto standards should include this question in their assessment.

To be fair: the committee model is not above this criticism, and it is not as independent as its self-image suggests either. Standards committees include representatives of precisely the companies whose products the standard will later affect. Examples have repeatedly shown how this turns into lobbying: a manufacturer writes its own technology into the standard, a consortium of established vendors defines requirements that newcomers cannot meet, or an industry effectively standardizes itself, with a business interest in the outcome. So the difference from a company-driven standard is not that one has interests and the other does not. The difference lies in transparency: an open repository shows who contributed what and when, while a committee’s negotiations stay behind closed doors. Neither model guarantees independence. It has to be checked in both.

The desire for company-internal standards makes economic sense. Fewer solutions mean less operational effort, fewer interfaces, less security attack surface and fewer skills you have to maintain. In mid-sized companies, this works, too. Decision paths are short, responsibilities are clear, and when management mandates a system, it gets introduced.

In a large corporation, exactly that is almost impossible. I have experienced several times how we tried to roll out a tool globally through a committee. Each time, the specific requirements of individual sites made adjustments necessary, and the one standard turned into three variants. That is not a failure of the people involved. It is the logic of a matrix organization: if departments and plants have their own budgets, you cannot take away their decision-making power and at the same time dispose of their money. Whoever pays has a say.

The biggest challenge – and anyone working in this field will agree with me – is scaling digital use cases worldwide. In heterogeneous groups with different production processes, maturity levels and local requirements, developing the one case that fits everywhere is practically impossible. Those who try anyway end up with a system that can do everything somehow and nothing properly. Nobody wants to introduce a second SAP that covers every requirement and, in doing so, loses the user-friendliness that made the use case valuable in the first place.

Top management cannot cut this knot, and that is understandable. An executive board will never go down to the last technology decision and say: “This is what you are using now.” It is too far removed from the technology for that, and in implementation, the devil is in the details. A mandate from the top therefore answers the question of what, but never the question of how.

In my experience, two things have proven themselves, but only for what they are made for. Overarching governance bodies are important for alignment: they create the framework in which decisions become comparable in the first place. Communities of practice are excellent for learning from each other and making solutions visible. They cannot bring about decisions, and anyone who expects that of them will be disappointed. Standardization in a large corporation therefore needs a process that combines both and works with budget authority instead of against it.

The way out starts with a distinction that is missing in many companies: not everything called a “standard” needs the same degree of bindingness. Three levels can be clearly separated.

The first level is the area where standards keep their justification. This is about liability, approval and legal certainty, and here slowness is a feature, not a bug. The second level is the real lever: if you make protocols and data models binding, you can open up the choice of tools. A plant that delivers its machine data via OPC UA into a Unified Namespace may build whatever it wants on top of it. Integration stays manageable because the interface is stable. The third level is not standardized, but made attractive.

This results in a process that works with the reality of the corporation instead of against it:

1. Tiering instead of bans. Every technology in the stack gets a status: Mandatory, Recommended, Tolerated or Retire. This results in an internal tech radar that gives every solution an expiration date. Every twelve months, it is reviewed whether the status is still right. A standard without a review date is not a standard.
2. Comply or Explain. Deviations from Mandatory and Recommended are allowed, but they are documented, justified and come with cost responsibility. Whoever deviates bears the additional effort for operations and integration themselves. This respects budget authority and makes the cost of fragmentation visible instead of hiding it at headquarters.
3. Platform team as enabler. A central team provides reference implementations, templates, integration building blocks and support for the golden path. The standard is not ordered, but offered: whoever uses it is faster. That is exactly the principle by which MCP or Sparkplug prevailed, just turned inward.
4. Governance body decides, community learns. The governance body sets the architecture framework and the tech radar and decides on status changes. The community of practice is the place where plants show solutions, share experiences and where proposals for the radar emerge. Both roles stay separate. Decisions are recorded as short Architecture Decision Records, not as an 80-page guideline.
5. Funding as a lever. Standard-compliant solutions are co-funded centrally, for example through integration, operations or licenses. Exceptions fund themselves. This is the only mechanism that works reliably in a matrix organization, because it leaves the decision where the budget lies and still sets a direction.
6. Measure adoption, not compliance. The success of a standard does not show in an audit, but in how many sites adopt it voluntarily. An adoption rate below 50 percent after two years does not mean the plants are wrong, but that the standard is not good enough.

Decision and learning run in a loop: the governance body sets the framework, the platform team makes it usable, the plants choose within it, and their experiences flow back via the community into the next decision.

The model does not fully solve the scaling problem, and it does not claim to. It accepts that the one use case for everyone does not exist, and instead ensures that local variants stand on a common foundation. What scales is the interface, not the tool.

I am not writing this from the outside. As chairman of the board of a VDI district association, I am part of an organization that develops guidelines, and I consider this work valuable. That is precisely why I see where it needs to change. Standardization has not lost its role. It has shifted it: away from defining what applies, toward safeguarding what has already prevailed. For safety and compliance, that is exactly right. For interoperability and tooling, it comes too late, and that will not change as long as the process stays the way it is.

So I have a concrete wish for the standards organizations: work with the foundations instead of alongside them. Adopt proven de facto standards into standardization instead of developing your own alternatives. Make content machine-readable and freely accessible from the start, with a reference implementation. And measure yourselves by the pace of technology, not by the pace of the committee.

For companies, I have a different one: stop treating standards as rules that have to be enforced. Treat them as products that have to be good enough to be adopted voluntarily. Standardize interfaces, open up tools, work with budget authority instead of against it, and give every decision an expiration date.

The acceleration of technology is not a phase that will pass. Agentic AI makes interoperability a basic prerequisite: without open interfaces, there is no agent that works across system boundaries. The pressure to standardize will therefore keep rising. The only question is whether we respond to it with processes from a slower era, or with a process that takes speed as a given.