IT/OT Convergence Could Lighten Biopharma's Automation Burden
A conversation between Enzo Birindelli at Italia Automazione, Frank Maurer at Boehringer Ingelheim, and Life Science Connect's Jon O'Connell
Here's an idea that may make some automation engineers wince. Integrated automation tech stacks that take years building and tuning are probably far less efficient than converged architecture.
Most biopharmaceutical and pharmaceutical manufacturing plants rely on a distributed control system (DCS) alongside a network of programmable logic controllers (PLCs). The components can talk to each other, but they run on different frameworks. It's a bit like talking through a translator. Beyond that, every component update means more maintenance.
Converged architecture, by contrast, brings those components under a single platform. At the 2026 ISPE Pharma 4.0 and Biopharma Conference in December in Berlin, Frank Maurer of Boehringer Ingelheim will join consultant Enzo Birindelli from Italia Automazione, an automation consulting firm, to explain how integration and convergence differ and why investing in convergence can make good business sense even for manufacturers that have invested heavily in custom integration systems.
Ahead of their talk, they answered a few of our questions.
What's the functional difference between integration and convergence? If my integrated tech stack does what I need it to, why would I take on the additional burden of converging?
Integration connects separate systems through interfaces, middleware, and point-to-point mappings - each system keeps its own lifecycle, data model and validation. Convergence brings them onto one shared platform with a common data model, deployment pipeline, and lifecycle. An integrated stack may work today, but its cost shows up over time: every change, update, site rollout, or product transfer means doing integration and validation work again. With convergence, you stop paying that cost over and over. Integration connects systems; convergence makes them one.
For readers who work with traditional DCS and PLC architectures, how would you describe SDA and CNA and their role in convergence?
Software-defined automation (SDA) and cloud-native automation (CNA) separate control logic from proprietary hardware. The logic runs as containerized software on standard compute — in the control cabinet, in an on-premises data center, or at the edge — while deterministic, real-time control is preserved. What changes is that control software is built, tested, deployed, and updated the way IT runs critical software. It is the technical foundation of convergence: operational technology (OT) and IT share one platform and one operating model.
When control logic is deployed and updated like software, how does that affect the way we approach tasks such as validation, qualification, and change control?
Validation moves from the single installation to the platform: A global template is validated once, and each site validates only the delta — local adaptations, equipment integration, site-specific configuration. The real shift is in the evidence. When control logic is a versioned artifact, the version itself becomes the record: who changed what, when, and why. A wired PLC patched by hand is hard to prove still validated six months later; a versioned deployment is not. Change control stays risk-based, but each change is small, traceable, and reversible — which is exactly what a CSA, risk-based mindset asks for. The open questions the industry is still working through — qualifying standard compute for GxP-critical control, periodic revalidation under the revised Annex 11 — are real, and worth facing honestly rather than declaring solved.
Don't open standards solve the vendor lock-in issue, or does SDA risk moving lock-in to a new layer?
Open standards are necessary but not sufficient. Module Type Package (MTP), OPC Unified Architecture (OPC UA), NAMUR Open Architecture (NOA), and container standards reduce lock-in at the interfaces. The risk does move up a layer to orchestration, fleet management, and the app marketplace. The answer is to demand open, community-governed standards at that layer too (for example,the Linux Foundation's Margo interoperability initiative) and to keep workloads portable across hosting options, so that the platform supplier remains replaceable.
Most manufacturers spend decades and large sums on integration layers. How should they weigh the business case for convergence against those sunk investments? Does the calculation differ between new buildouts and retrofits?
Sunk costs should not drive the decision. What matters is the total cost of ownership going forward: repeated validation, local life cycle management, slow site rollouts, cybersecurity patching (NIS2 Directive, Cyber Resilience Act), and time-to-market. For new builds, convergence should be the default — the incremental cost is small and the benefits compound over the plant's life. Retrofits are different: converge step by step at natural lifecycle points such as obsolescence, capacity expansion or new lines — not via a big-bang replacement.
How do IT and OT teams, which often operate independently with discrete priorities, need to change? Is there a clear owner for the converged team?
Both sides have to move. OT adopts DevOps, platform engineering, and security by design; IT accepts that availability, determinism, and GMP compliance come before release speed. The model that works is one joint technology stack with shared ownership: a platform team owns the stack, while process and automation experts own the use cases. This is a jointly governed IT/engineering platform, not one side taking over the other.
Where do integration layers fall short for applications like real-time process monitoring and verification? Can you give an example where that gap has limited (and convergence would solve) what a manufacturer could do?
Integration layers are, by design, largely polled, translated, and delayed. Tight real-time control itself stays local, the controller does its job. What suffers is the decision that depends on several systems at once. Take an in-process control (IPC) that gates a batch step: the decision to proceed waits on an analytical result that lives in the lab information management system (LIMS), while process state sits in the historian and equipment status in the control system — three systems, three clocks. In an integrated landscape you reconcile them after the fact, so the “in-process” check is really a near-time check with a lag: fine for the record, too late to act on while the step is still open. On a converged platform with one time-consistent data layer, process, equipment, and quality context, including the IPC result, are evaluated together in the moment, so the gate decision happens while you can still act on it, not after.
For a manufacturer that wants to move toward convergence, where's the sensible starting point? Given your different vantage points, is there anywhere the two of you disagree on how fast or how far the industry should go?
Start with one well-defined greenfield use case: a skid or package unit, for example, based on MTP. Build the platform, the deployment pipeline and the validation approach there, then scale via templates. Where our vantage points differ: Frank, on the owner/company side, moves fast on the platform but stays deliberately conservative wherever GMP-critical control is involved, and he's right to. Enzo sees it from the outside, across many plants, and his caution is a different one: The technology is usually ready sooner than the organization is. The hard part is rarely the software; it's the operating model and the people. So if we disagree, it isn't on how fast the technology can go; it's on what actually holds a site back.
About The Experts:
Enzo Birindelli is an engineer and chief executive officer at Italia Automazione, an automation consulting group based in Milan. Previously, he worked as an instrument and automation engineer at Foster Wheeler Italiana and Steril. He received a master's degree in industrial automation engineering from Polytechnic University of Milan.
Frank Maurer is global head of automation strategy and technology at Boehringer Ingelheim, where he has worked for more than 20 years on the company's automation agenda. He leads the company's global OneAutomation vision, driving scalable automation strategy and technology. He studied automation and industrial IT at Offenburg University of Applied Sciences.