Every manufacturing business has a systems stack. Most of them have not designed one.
What they have is a collection of systems acquired over time. An ERP that was selected when the business was a third of its current size. An HR system that HR purchased independently. An Atlassian environment that IT set up for the engineering team. A PDM system that engineering chose. A handful of spreadsheets and shared drives that grew into critical business infrastructure without anyone planning for them.
Each of these systems was selected to solve a specific problem. Nobody asked how they would work together as a whole. The result is a stack that does what the individual pieces do and does not do what the business needs the integrated system to do.
This is not a failure of the individual systems. It is a failure of architecture.
What Operational Systems Architecture Is
Operational systems architecture is the deliberate design of the technology systems that a manufacturing business runs on, as an integrated whole.
It is not a list of software. It is not an IT roadmap. It is a model of how information flows through the business: from the moment a sale is captured, through engineering, manufacturing, quality, installation, and after-sales service. And it is a design for which systems handle which parts of that flow, and how they connect.
A well-designed operational architecture looks like this: a sale is captured in CRM and flows to the ERP as an order. Engineering releases the BOM to the PDM, which syncs to the ERP. Manufacturing uses the ERP for work orders and the MRP for scheduling. Quality management tracks NCRs and CAPAs in Jira, linked to the Confluence document control system. HR data in the HRIS propagates access to every system through Microsoft Entra ID. Field service teams have access to installation and product history from the ERP through a connected service management system.
Every handoff is designed. Every integration is deliberate. Data enters the system once and flows to where it is needed.
A poorly designed stack looks like the opposite: each system is an island. Data is re-entered manually between systems. Nobody is sure which system is the authoritative source for a given piece of information. When someone leaves the business, there is a checklist of ten systems to revoke access from, and it is never complete.
The Cost of Unplanned Architecture
Unplanned operational architecture creates costs that are difficult to quantify in advance but undeniable in retrospect.
Integration debt. Every connection that should exist between systems but does not represents a place where someone does manual work, or where information is missing when a decision needs to be made. This debt compounds. As the business grows, the gap between what the integrated stack could deliver and what the disconnected stack actually delivers grows with it.
Data quality debt. When data is re-entered manually between systems, errors accumulate. When the authoritative source for a piece of information is unclear, different systems hold different versions of the truth. Manufacturing decisions made on incorrect or inconsistent data have operational consequences.
Change cost. A poorly architected stack is expensive to change. Replacing or upgrading any component requires manually accounting for every dependency that was never formally documented. Every major technology project carries unexpected scope because of integration surprises that architecture work would have surfaced.
Scale ceiling. The most expensive consequence of unplanned architecture is the scale ceiling it creates. Systems selected for the current size of the business that do not have the integration architecture to support the business at twice the size. The moment a fast-growing manufacturer hits this ceiling, they face the prospect of replacing multiple systems simultaneously rather than evolving them incrementally.
How to Design It
Start with the business processes, not the systems
Operational systems architecture begins with a map of business processes, not a list of software. How does a sale become a delivered, commissioned product? What information needs to be created, modified, and accessed at each stage? Who needs to see what, and when?
This process map reveals the information architecture that the systems need to support. It identifies the handoffs between functions where integration is essential, and the data that needs to flow across those handoffs.
Only once this is clear does it make sense to discuss which systems should handle which functions.
Define the integration architecture explicitly
Every integration point in the stack needs a defined architecture: which system is the source of truth for a given data object? How does data flow between systems? Is the integration event-driven or batch? What happens when an integration fails?
These decisions sound like technical details. They are business decisions. The system that is the authoritative source for product data determines which team has ownership of it and what processes govern changes. The event-driven or batch architecture for an integration determines how real-time operational data needs to be.
Make these decisions deliberately, before systems are selected or implemented, and document them.
Design for identity management from the beginning
Identity management is the connective tissue of an operational stack. Microsoft Entra ID (formerly Azure AD) is the standard identity provider for most manufacturing businesses operating on Microsoft 365. When it is designed into the architecture from the beginning, user provisioning and de-provisioning is automatic. When someone joins, they get access to every system they need. When they leave, every access is revoked from a single point.
When identity management is added retroactively, every system needs to be connected individually, and the provisioning logic for each is different. This work is expensive and the ongoing management of it is a security risk.
Sequence decisions by dependency
Not all systems decisions are of equal urgency. Some systems are foundational: identity management, the ERP, the document control system. Others are dependent: HRIS that integrates with Entra ID, service management that connects to the ERP, LMS that connects to the HRIS.
A sequenced implementation plan that respects these dependencies is both lower risk and lower cost than a plan that tries to implement multiple systems simultaneously. It also allows the business to validate that foundational systems are working correctly before building dependent systems on top of them.
Architecture Versus Consulting
There is a meaningful difference between architecture work and implementation consulting.
Implementation consulting starts with a system and asks how to configure it. The scope is defined by the platform.
Architecture work starts with the business and asks what systems are needed and how they should connect. The scope is defined by the operational requirements of the business.
Most systems consultants do implementation consulting. They are excellent at it. They are not doing architecture work, and the architecture work is what determines whether the implementation work produces a stack that works as a whole.
A Practical Starting Point
If you are a manufacturer with an operational systems stack that has grown organically rather than been designed, a current-state assessment is the starting point.
Map every system you have. Document what it does, how it connects to other systems, and where the manual processes fill the gaps that integrations should. Identify the data that is held in multiple places and the reconciliation effort that requires. Surface the integration points that do not exist but should.
This is not a technology exercise. It is a business operations exercise. The output is a clear picture of the gap between what your systems deliver today and what they would need to deliver for the business to operate effectively at its intended scale.
That gap is the architecture work.
Big Finish designs operational systems architectures for manufacturing businesses. If you are about to make a major platform decision, or if you have a stack that is not working as a whole, book a discovery call before you buy anything else.