Strategic Standards Decisions for Industrial Data Platforms: Where to Standardize and Where to Innovate

Most data and analytics leaders understand that standards matter. But knowing which standards to adopt, which standards organizations to engage with, and most critically, where in your architecture to standardize versus where to differentiate—these decisions directly impact your ability to deliver value over the next decade. Claude Baudoin, who has spent 46 years navigating technology standards across organizations from OMG to the Industrial Internet Consortium, offers a pragmatic framework for making these strategic choices.

‍

Why Standards Matter: The Build vs Buy Decision for Your Data Stack

‍

When you're architecting an industrial data platform, you're building a layered stack. At the top sits your proprietary analytics, AI models, and business logic—the differentiated capabilities that create competitive advantage. Below that are communication layers, middleware, databases, and at the bottom, sensors and hardware. The strategic question isn't whether to use standards, but where.

Baudoin frames this clearly: "You don't want to reinvent the entire stack. You want to focus on the top level, where you've put your IP into developing unique capabilities, but below that, you want to be able to buy building blocks on the market."

For data leaders, this translates to concrete decisions:

• Don't reinvent data ingestion protocols: Use MQTT, OPC UA, or other proven standards rather than building proprietary connectors for every device type
• Don't create custom database structures for time-series data when proven formats exist
• Don't build proprietary APIs between your data platform layers when standard interfaces provide the same functionality

The payoff is speed and cost. By standardizing the foundation, your team focuses engineering resources on the analytics and AI capabilities that actually differentiate your platform. You buy or use open source for the rest, and because it's standardized, integration works without custom development.

‍

Understanding How Technologies Become Standards

‍

Not all "standards" are created equal, and understanding the difference helps you evaluate which ones deserve your investment. Baudoin identifies three distinct paths:

De facto standards through market adoption: A company develops a technology that gains widespread adoption. Eventually, to encourage broader use—especially by competitors—the company transfers it to a neutral foundation. This is how many open source projects evolve into industry standards. The advantage is that these standards are already proven in production. The risk is that early adoption means you're investing before it's clear whether broad industry support will materialize.

Formal ISO standardization: A proposal goes through International Organization for Standardization committees, with voting processes that can take six to eight years. These standards carry international authority and are often required for regulated industries. But the long timeline means they can lag behind market needs, and the process can be cumbersome for fast-moving technology areas like AI and edge computing.

Industry consortium standards: Organizations like IEEE, OMG (Object Management Group), and the Industrial Internet Consortium provide a middle ground. The process takes two to three years—faster than ISO but with more structure than organic adoption. These consortiums bring together vendors, end users, and technical experts to develop standards collaboratively.

For data leaders at companies like Toyota or Novo Nordisk, understanding these paths helps you time your adoption. Formal ISO standards may be necessary for compliance, but industry consortium standards often provide the agility you need for competitive data platform development.

‍

Vendor vs End User: Different Standards Engagement Strategies

‍

Your standards strategy should differ based on whether you're primarily a technology vendor or an end user building internal capabilities. This matters even for internal data platform teams, which often function as internal vendors to business units.

For vendors (or internal platform teams selling capabilities internally):

• Active participation in standards development: Join working groups where standards are being created, especially in areas core to your platform's value proposition
• Early adoption for competitive advantage: Implement emerging standards before they're fully ratified to influence direction and gain first-mover advantages
• Contribute use cases and requirements: Share your real-world implementation challenges to ensure standards address actual problems
• Investment horizon: Plan for 2-3 year cycles to see returns on standards participation

For end users implementing data platforms:

• Wait for proven adoption: Let vendors work through the initial implementation challenges before committing your architecture
• Focus on vendor-neutral standards: Prioritize standards supported by multiple vendors to avoid lock-in
• Participate in testing programs: Join Industrial Internet Consortium test beds or test drives to evaluate standards in practice before committing
• Selective engagement: Focus participation on standards that directly impact your ability to integrate systems or extract value from data

A critical insight from Baudoin: end users often benefit most by waiting until a standard reaches critical mass, then leveraging it for vendor negotiations. You gain the advantage of proven technology without the risk of early adoption.

‍

The Architecture Decision: Drawing Your Standardization Boundary

‍

Perhaps the most actionable advice for data leaders is Baudoin's "colored crayon" exercise for your architecture diagram. Take your data platform architecture and identify:

• Green zones: Areas where you need unique, differentiated capabilities that create competitive advantage
• Red zones: Areas where standardization reduces costs and accelerates delivery without sacrificing value

This isn't a one-time decision. As Baudoin notes, the boundary shifts over time. Consider the evolution from SCADA to modern IoT platforms:

What changed from proprietary to standard:

• Operating systems: From proprietary PLC code to Linux and Windows
• Communication protocols: From proprietary networks to TCP/IP and UDP-based protocols
• Hardware platforms: From specialized controllers to commercial computing infrastructure
• Data storage: From proprietary databases to standard time-series and relational databases

What remains differentiated:

• Analytics algorithms specific to your processes
• AI models trained on your operational data
• Business logic that reflects your manufacturing methods
• Integration patterns that connect to your specific enterprise systems

For a Head of Data and Analytics, this means actively managing which parts of your stack to standardize. The data ingestion layer? Almost certainly standardize. The machine learning pipelines for predictive maintenance? Probably differentiated. The message broker connecting edge to cloud? Evaluate based on whether vendor-specific features genuinely provide value versus lock-in risk.

‍

Making Smart Participation Decisions: Test Beds and Test Drives

‍

The Industrial Internet Consortium (300+ member organizations) provides concrete mechanisms for evaluating standards before committing architecture decisions. Two programs deserve attention:

Test beds are collaborative implementations where 3-5 companies each contribute components to build a complete IoT solution. A typical test bed might include:

• A sensor manufacturer
• A software platform vendor
• An AI/analytics company
• An end user with a specific problem

The consortium's first test bed tracked tools in an aircraft manufacturing facility—demonstrating how to prevent losing electric screwdrivers used on airplane wings. For data leaders, test beds provide proof points that standards actually work in production environments similar to yours.

Test drives are simpler—a company offers their implementation for other members to evaluate. Think of it as trying before buying. You can assess whether a standards-based platform meets your data integration, performance, and analytics requirements before committing to adoption.

Both mechanisms reduce the risk of standards adoption by letting you evaluate real implementations rather than betting on specifications alone.

‍

Practical Takeaways for Data and Analytics Leaders

‍

Here's how to apply these insights to your industrial data platform strategy:

Map your architecture and identify standardization zones: Document your current and planned data platform architecture. Mark which components should be standardized (communication protocols, data formats, storage systems) versus which should remain proprietary (analytics algorithms, AI models, business logic). Review this quarterly as standards mature.

Time your standards adoption appropriately: If you're building internal platform capabilities, wait for standards to prove themselves through vendor adoption. If you're a technology vendor (or an internal platform team competing with external solutions), engage earlier to influence direction. The difference is 1-2 years in adoption timing.

Invest selectively in standards participation: You can't participate in every working group. Focus on 2-3 standards that directly impact your ability to integrate data sources or that vendors are using to lock you in. Budget one senior architect's time for meaningful participation.

Use consortium programs to de-risk decisions: Before committing your architecture to a new standard, participate in an Industrial Internet Consortium test drive or observe a test bed. The time investment (a few days to weeks) prevents costly architectural mistakes.

Plan for the boundary to shift: Standards that are differentiating today become table stakes tomorrow. Review your "green zones" annually. As standards mature, move capabilities from proprietary to standard implementations, freeing engineering resources for higher-value innovation.

Evaluate standards organizations for agility: ISO standards provide global authority but move slowly. Industry consortiums provide faster cycles that match the pace of data platform evolution. Choose based on whether you need regulatory compliance or competitive speed.

Conclusion

The decision about which standards to adopt isn't about choosing between standardization and innovation—it's about strategically choosing where to do each. For data and analytics leaders building industrial platforms, standards provide the foundation that lets you innovate where it matters most: in the analytics, AI, and insights that drive business value.

The question isn't whether your data platform should use standards, but which ones, when to adopt them, and where in your architecture they belong. By understanding the standards landscape, timing your participation appropriately, and maintaining clarity about where you differentiate, you build platforms that are both flexible and focused—capable of integrating diverse data sources while delivering unique analytical capabilities that competitors can't easily replicate.

Your architecture decisions today determine whether you're fighting integration battles in 2030 or delivering AI-driven insights. Choose your standards carefully, adopt them strategically, and focus your innovation where it creates lasting competitive advantage.

‍

‍