Start with a measurable baseline: users, sites, integrations, data volume, critical workflows, recovery expectations and operational ownership. Then select the simplest architecture that demonstrably meets those constraints. For manufacturing operations, the decision is less about adopting a fashionable pattern than preserving tenant and site isolation, handling unreliable operational interfaces, and producing evidence for how AI-assisted outputs were generated, reviewed and changed.
Baseline first: what must the architecture support now?
Before comparing monoliths, modular systems or distributed services, record the operating facts that the system must satisfy in the next planning period. A useful baseline is measurable rather than aspirational: active organisations and users; plants or warehouses; peak concurrent usage; transaction and event volumes; data retention; external systems; expected onboarding frequency; and the number of people available to operate the platform.
For a manufacturing product, also identify where work happens. A planning user in an office, a supervisor on a factory floor and an integration process receiving machine or ERP data do not share the same network conditions, permissions or tolerance for delay. Distinguish business-critical workflows, such as production decisions or traceability records, from useful but deferrable reporting and AI assistance. Architecture can then allocate reliability and recovery effort where it matters.
Create one baseline document owned jointly by engineering, product, operations and security. It should describe assumptions, evidence sources, named owners and a review date. This becomes the starting point for architecture decisions and for an auditable AI operating model.
- List each critical workflow, its business owner, availability expectation and acceptable data-loss window.
- Map every inbound and outbound integration, its protocol, data owner, failure behaviour and reconciliation method.
- Record the current operational team’s ability to manage deployments, incidents, access requests and data corrections.
- Classify data by tenant, site, production line, user and sensitivity where relevant.
- State which AI-assisted actions may inform users, which may execute changes and which must always require human approval.
Buyer question: are we building SaaS, shared internal software, or both?
SaaS is a delivery and business model in which the provider operates the software for customers. Multitenancy is an architectural approach in which some components are shared by multiple tenants; it does not require every component to be shared. Treating these as separate decisions prevents an unnecessary all-or-nothing choice.
A manufacturer may begin with a platform used by several business units, then offer it to external customers or suppliers. Conversely, a commercial SaaS product may need isolated components for a particular tenant or workload. The relevant question is which resources can be safely and economically shared while meeting contractual, security and operational requirements.
Ask the product team to define tenant personas rather than assuming all customers need identical treatment. A small site, a group operating several plants and a customer with strict integration or data-boundary requirements may use the same product differently. Prefer product-wide configuration over a bespoke branch when possible; one-off versions create a growing operational burden.
- Define the tenant boundary: customer, legal entity, group, plant or another agreed unit.
- Identify shared components and explicitly document exceptions.
- Define how a tenant is created, configured, suspended, exported and removed.
- Test whether pricing, support and operations can work with the proposed tenant model.
- Reject designs that depend on manual, undocumented onboarding steps for every new tenant.
Buyer question: what isolation must hold at every layer?
Tenant isolation is not a database setting alone. The tenant context should be bound to the authenticated identity and available through the application path so that access checks, logging, metrics and data operations consistently use it. A dashboard filter is not an isolation control.
Review isolation across identity, authorisation, APIs, storage, background jobs, search indexes, caches, exports, analytics and support tooling. In a manufacturing setting, site-level boundaries may matter in addition to tenant boundaries. An operator should not gain access to another site’s records simply because both belong to the same group, unless the role and policy explicitly permit it.
Make the secure path the easy development path. Shared libraries, standard middleware and tested access patterns can reduce the chance that each team implements tenant checks differently. This is particularly important as the application gains modules and integrations.
- Require tenant and, where needed, site context in every request, event and audit record.
- Use authorisation decisions that are enforced server-side, not only in the interface.
- Prove isolation with negative tests for APIs, asynchronous processing, exports and administration flows.
- Give support staff time-bound, traceable access rather than broad standing access.
- Review AI retrieval and tool access against the same tenant and site boundaries.
Buyer question: which application shape fits the present team?
A modular application can be an appropriate starting point when the product has a manageable scope, a single delivery team and limited need for independently deployed components. Clear module boundaries, a disciplined domain model and automated tests retain options to separate workloads later. The aim is not to avoid future change; it is to avoid paying operational complexity before there is evidence it is needed.
Independent services can be justified when particular capabilities have materially different scaling, isolation, release or ownership needs. For example, high-volume integration processing may have a different failure profile from an interactive planning interface. Splitting components only because the organisation expects growth can make tracing, testing, incident response and change coordination harder for a small team.
Use workload evidence to decide. Measure which paths consume capacity, which failures recur, which releases need separation and where tenant tiers have different needs. Keep interfaces explicit regardless of deployment shape, so that later change is deliberate rather than a rewrite.
- Choose a modular application when one team can own end-to-end changes and workloads scale together.
- Separate a component when its load, isolation requirement or release cadence differs materially and persistently.
- Define failure handling before introducing asynchronous flows: retries, idempotency, dead-letter handling and reconciliation.
- Avoid distributing a business transaction across services without a clear consistency and recovery design.
- Budget for observability, access control and incident runbooks for every additional deployable component.
Buyer question: can manufacturing integrations fail without corrupting operations?
Manufacturing operations depend on systems that may be old, vendor-managed, intermittently connected or updated on a different timetable. An architecture should therefore regard integrations as operational products, not merely technical connectors. Define data ownership, expected latency, validation, duplication handling and the process for correcting mismatches.
Separate the arrival of an external event from the business decision that uses it where appropriate. Store enough context to explain what was received, when it was processed, which transformation was applied and whether a human correction occurred. This supports troubleshooting and enables a credible history for AI-assisted workflows.
Do not make the web interface depend synchronously on every external system for routine work. Where the business permits, provide a clear status, queue work safely and reconcile later. Where the business does not permit delay, make the dependency and its recovery procedure visible in the operating model.
- Maintain an integration catalogue with interface owner, schema version, authentication method and service expectations.
- Use stable identifiers and idempotent processing to reduce duplicate-event damage.
- Quarantine invalid or incomplete records with a named business resolution path.
- Expose freshness and processing status to users when it affects operational decisions.
- Test degraded operation and recovery with representative integration failures.
Buyer question: what makes the AI operating model auditable?
An auditable AI operating model is a set of controls and records that lets the organisation reconstruct an AI-assisted outcome: who initiated it, what authorised data was available, which model and prompt configuration were used, what output was returned, what tools or actions were invoked, and who approved or overrode it. It is not achieved by keeping chat transcripts alone.
Start by classifying AI use cases. A retrieval-based assistant that drafts a maintenance summary has different risks from a system that changes a production parameter, creates a purchase request or routes an exception. For consequential actions, place a policy and approval boundary between the model output and the business action. The system should be able to explain that an action was proposed, approved, rejected or executed under a defined rule.
Architecture should preserve evidence without indiscriminately retaining sensitive operational data. Define retention, redaction, access rights and deletion rules with legal, security and product stakeholders. Evaluate model and provider changes as controlled changes: compare intended behaviour, document approval, deploy gradually where appropriate and retain the version references required for investigation.
- Create an AI use-case register with purpose, owner, permitted inputs, prohibited inputs, action authority and review cadence.
- Log correlation IDs, user and tenant context, policy decision, model or configuration version, tool calls and approval state.
- Keep human review mandatory for actions that can materially affect safety, production, contractual commitments or access rights.
- Measure output quality and operational impact using agreed review samples and exception signals.
- Provide a means to disable an AI feature or tool integration without disabling unrelated core workflows.
Evaluation rubric: score architecture choices against evidence
Score each candidate architecture from 1 to 5 for the criteria below. A score of 1 means the design relies on an untested assumption or manual workaround; 3 means the design is documented and demonstrably workable for the baseline; 5 means it is automated, tested and has a named operational owner. Weight criteria according to the baseline rather than using a universal score.
The winning option is not automatically the highest-scoring technical design. It is the option with no unacceptable risk, a credible operating model and the least avoidable complexity. Record dissenting views and assumptions alongside the score. That record is valuable when scale, regulation or team capacity changes.
- Tenant and site isolation: can the team demonstrate enforcement across application, data, jobs, exports and AI access?
- Operational fit: can the current team deploy, monitor, support and recover the system without constant specialist intervention?
- Integration resilience: are ordering, duplication, downtime, reconciliation and ownership defined?
- Growth path: can onboarding and common configuration remain repeatable as tenants and sites increase?
- Observability and cost: can operators inspect performance, errors, utilisation and cost by tenant or workload?
- AI auditability: can the system reconstruct high-impact AI-assisted outcomes and enforce approval policies?
- Security and lifecycle readiness: are identity, access reviews, dependency management, vulnerability handling and secure development practices owned and evidenced?
Decision scenarios for manufacturing operations
Scenario one: a product is serving a limited number of plants, the engineering team is small, and most workflows share the same release cadence. A modular web application with strong internal boundaries, central identity, tenant-aware data access and a dedicated integration processing capability may be easier to operate than a broad service estate. The decision should be revisited when measured integration load or organisational ownership diverges.
Scenario two: one customer requires strict data separation while other customers can use a shared environment. Do not assume the entire product must be duplicated. Evaluate isolation per component and document the boundary, operational consequences and support process. The key test is whether the design can demonstrate that customer data and AI context never cross the agreed boundary.
Scenario three: an AI assistant summarises production exceptions from approved operational records. Start with read-only retrieval, a displayed source context where appropriate, tenant-scoped access and human review. Expand action authority only after the organisation can review quality, trace a recommendation and operate a reliable approval path.
Scenario four: a legacy MES interface sends duplicate or delayed events. Use an ingestion design that records receipt, validates payloads, processes idempotently and offers reconciliation. A fast-looking integration that cannot explain or correct discrepancies is a higher operational risk than a deliberately asynchronous one.
Risks to challenge before commitment
The most common architecture risk is designing for an imagined future while underfunding today’s operational controls. A second is treating AI governance as a separate policy document even though model access, data retrieval, tool use and approvals are implemented in the application. Both gaps leave teams unable to demonstrate what the system did during an incident or customer review.
European manufacturers should also assess applicable cybersecurity and product obligations with qualified legal and compliance advisers. The EU Cyber Resilience Act has lifecycle cybersecurity requirements for products with digital elements, while the scope for cloud-native SaaS can depend on the offering and how it relates to a product. Do not infer applicability from an architecture label alone.
- Cross-tenant exposure through background jobs, analytics, support tools or AI retrieval.
- Manual onboarding and customer-specific code paths that make releases and incident response harder.
- Unowned integration failures that silently produce stale or contradictory operational data.
- Logs that omit the context needed to investigate an AI-assisted action, or logs that retain unnecessary sensitive data.
- A distributed design whose monitoring, testing and recovery needs exceed the team’s capacity.
- Compliance assumptions made without a documented assessment of the actual product, market and operating model.
Next steps: run a short, evidence-led architecture review
Use the checklist as a working session, not as a procurement exercise. Invite engineering, product, operations, security, data and the owner of manufacturing processes. The output should be a decision record that separates facts from assumptions, names owners and creates a limited set of validation tasks.
If the baseline is unclear, discovery is the architecture work. Map workflows, tenant boundaries, integrations and AI use cases before selecting infrastructure or committing to an application pattern. This reduces the chance that an implementation decision becomes a substitute for product and operating-model decisions.
- Complete the baseline with production, support and integration evidence; mark unknowns explicitly.
- Draw a context diagram showing tenants, sites, users, external systems, trust boundaries and AI components.
- Score two or three viable architecture options using the rubric and agree any non-negotiable controls.
- Prototype the highest-risk paths: tenant isolation, event recovery, identity propagation and AI approval logging.
- Write runbooks for access incidents, integration backlog, data correction, model or prompt rollback and AI feature disablement.
- Set a review trigger based on a measurable change, such as a new tenant class, a new critical integration or a sustained capacity constraint.
Decision scenarios
- Choose a modular application when current workloads, team ownership and release needs are shared; preserve module boundaries and measure the signals that would justify separation.
- Use component-specific isolation where a customer, site or workload has a demonstrably different requirement; document the boundary rather than cloning the whole product by default.
- Keep early AI assistance read-only and human-reviewed when it informs operational decisions; introduce tool execution only with policy enforcement and traceable approvals.
- Treat delayed, duplicated or unavailable factory-system events as normal operating conditions and design reconciliation before automating downstream decisions.
Risks and limits
- Assuming a shared database or a UI filter alone provides tenant isolation.
- Creating customer-specific product branches instead of governed, reusable configuration.
- Adopting distributed services without the observability and operational capacity to support them.
- Allowing AI tools to act on operational systems without tenant-scoped authorisation, approval boundaries and sufficient evidence.
- Failing to reconcile unreliable operational interfaces, leaving users to act on stale or conflicting records.
- Equating a cloud deployment pattern with a complete cybersecurity or regulatory assessment.
Practical next steps
- Measure the present baseline for users, sites, integrations, workloads, recovery needs and operating ownership.
- Create a tenant, site, identity and data-flow map that includes asynchronous jobs and AI retrieval or tools.
- Assess viable options with the evaluation rubric, documenting assumptions and rejected alternatives.
- Validate the riskiest controls through targeted prototypes and negative tests.
- Assign owners for incident response, integration reconciliation, access reviews and AI change approvals.
- Review the architecture when the agreed measurable triggers occur.
FAQ
Is multi-tenancy required for a SaaS product?
No. SaaS describes how software is delivered and operated, while multitenancy describes sharing some components among tenants. Many SaaS products use multitenancy, but the appropriate sharing and isolation model depends on customer, security, operational and commercial requirements.
Should a manufacturing SaaS product start with microservices?
Not by default. Start with the simplest application shape that the current team can operate while meeting isolation, resilience and integration needs. Separate components when measured differences in load, isolation, ownership or release needs justify the additional operational overhead.
What should be logged for auditable AI-assisted decisions?
Log enough to reconstruct the controlled workflow: tenant and user context, correlation ID, authorised data scope, model or configuration version, policy decision, tool calls, output reference and the human approval, rejection or override. Apply defined retention and access controls to those records.
How do we protect data between manufacturing sites within one customer?
Treat site as a distinct authorisation attribute where the business requires it. Carry it through identity, requests, jobs, data access, exports and AI retrieval, then test that users and processes cannot access another site’s records without an explicit policy.
How should we assess AI features before allowing automated actions?
Classify the action’s consequence, define permitted inputs and tool permissions, establish a human approval rule where needed, test failure modes and make the action traceable. The ability to disable the feature and recover from incorrect actions should be part of the design.
Related Cubicfox pages
Sources
- SaaS Architecture Fundamentals - AWS Documentation (2026-07-17)
- Principes fondamentaux de l'architecture SaaS (2026-07-17)
- General design principles - SaaS Lens - AWS Documentation (2026-07-17)
- Software as a service (SaaS) Workload Documentation - Microsoft Azure Well-Architected Framework (2026-07-17)
- Essential Guide to SaaS Architecture: Best Practices and Key Features (2026-07-17)
- SaaS and Multitenant Solution Architecture - Azure - Microsoft Learn (2026-07-17)
- Web Application Architecture Guide (2026-07-17)
- Enterprise SaaS Architecture Playbook (2026 Edition) - ThinkEra247 (2026-07-17)
- Saas Architecture Microsoft (2026-07-17)
- Common web application architectures - .NET | Microsoft Learn (2026-07-17)