If you’ve fielded a Honeywell manufacturing software proposal in the last year or so, you’ve probably noticed the branding has changed faster than the underlying diagrams have. Honeywell has spent the past two years pulling a string of acquisitions and its long-standing manufacturing operations management (MOM) and asset performance management (APM) products under one umbrella: Honeywell Forge. Executives have leaned on the Forge name consistently in recent earnings calls and product launches, positioning it as the connective tissue across Honeywell’s industrial software portfolio — plant historian, MES/MOM, APM, and various point solutions picked up through acquisition.
That’s the corporate narrative, and there’s a real strategic logic to it. What matters for a plant engineer or MES admin evaluating a quote is a much narrower question: when a Honeywell rep says “Forge,” are you buying one coherent architecture, or a portfolio of separately-built products wearing a common skin and a shared login page? Those are very different purchases, with very different implications for integration cost, upgrade risk, and — critically — who picks up the phone when something breaks.
Why this is a live question right now
Large automation and industrial software vendors have all been doing versions of this consolidation play — Honeywell isn’t unique in that respect. What makes it worth scrutinizing right now is timing: Honeywell has been actively folding acquired industrial software capability into the Forge umbrella while simultaneously message-testing “unified platform” language to the market. When a vendor is mid-consolidation, the marketing typically outruns the engineering. Sales collateral gets updated before data models get unified. That’s not a knock on Honeywell specifically — it’s just how every large-scale software integration goes, whether the acquirer is Honeywell, Siemens, Rockwell, or anyone else assembling a platform from parts.
The practical risk for buyers is straightforward: you sign a contract believing you’re getting a single MES/MOM environment with one data model, one historian, and one support organization, and you actually end up integrating three or four products that happen to share a dashboard shell. That’s not automatically a bad outcome — sometimes best-of-breed components stitched together perform better than a monolithic platform. But you need to know which one you’re buying, because the implementation plan, the total cost of ownership, and the support experience differ enormously depending on the answer.
The core question: shared data model, or shared skin?
The single most important technical question to ask isn’t about features. It’s about the data layer. Ask the sales engineer, in writing: does this Forge-branded MES module write to and read from a common historian and a common data model — ideally aligned with something like ISA-95 for the manufacturing hierarchy — or does each module maintain its own database with a middleware layer translating between them?
A genuinely unified architecture will typically be built around a single time-series historian or a Unified Namespace (UNS)-style broker structure, where MES, APM, and quality modules are essentially different views into the same underlying data, often exchanged via MQTT Sparkplug B or OPC UA. A bundled architecture will have separate databases per acquired product, with point-to-point integrations or an ETL layer stitching them together. Both can work. But the second one means every future upgrade risks breaking an integration point that the vendor didn’t originally design, and every new site rollout means re-validating those connections.
Questions to put in writing before you sign
- Which specific product or acquired codebase underlies each module in this proposal, and what was its origin — organic Honeywell development, or an acquisition?
- Do all proposed modules write to a single historian, or does each maintain a separate database with integration middleware in between?
- Is the manufacturing data model aligned to a documented standard (ISA-95, ISA-88 for batch), and can we see the schema, not just a marketing diagram?
- If we add a module later, does it require a new database instance and a new integration project, or does it plug into the existing data layer?
- What happens on upgrade — do all modules move to new versions together, or does each acquired product follow its own release cadence?
Support ownership is where this gets real
The architecture question matters technically. The support question matters operationally, on the day your line goes down. When you open a ticket against a Honeywell Forge-branded MES deployment, which team actually owns it? Acquired product lines often keep their original engineering and support staff for years after a deal closes, even as the front-end branding changes. That can be a good thing — those are the people who actually know the codebase. But if your contract doesn’t specify escalation paths and SLAs by module, you can end up in a loop where a ticket bounces between teams that don’t share full visibility into each other’s systems.
Ask for this in the contract, not in a sales conversation: a named support organization (or clearly defined internal group) responsible for each module, defined SLA terms per module, and — this is the part people forget — clarity on what happens when a problem spans two modules at once. A tag alignment issue between the historian and an MES quality module is exactly the kind of cross-boundary problem that falls into a gap when support is organized around legacy product lines rather than the unified platform the sales deck described.
What to actually do with this
None of this means walk away from a Honeywell proposal. Forge covers real capability, and large-vendor consolidation is often preferable to managing a dozen point-solution contracts yourself. The point is to negotiate from an informed position. Ask for the data model lineage in writing. Ask which modules genuinely share a historian versus which ones call out to a separate database. Get the support ownership question answered contractually, not verbally. And treat any claim of a “unified platform” the same way you’d treat any vendor claim in this industry: verifiable, or it’s marketing. If the vendor can produce a real architecture diagram with named systems and data flows, that’s a good sign regardless of the brand on the slide. If all they can produce is a logo-and-arrows diagram, budget for integration work whether or not the contract calls it that.
This scrutiny isn’t specific to Honeywell — it’s the right posture for evaluating any large industrial software portfolio mid-consolidation. Honeywell just happens to be the one actively running this play in front of buyers right now, which makes it the timely example rather than the exception.
This article was written with the assistance of artificial intelligence. While we aim for accuracy, the information may be incomplete, out of date, or incorrect, and should be independently verified before you rely on it for any decision. It is provided for general information only and does not constitute professional advice.
