⏱ 23 min read
There’s a point in many manufacturing transformation programs when someone says, usually with more than a little frustration, “architecture is slowing us down.”
I’ve heard some version of that in plants, in regional programs, and in corporate cloud offices. A line modernization is ready to move, but the integration to cloud MES has been sitting for three weeks waiting on an architecture board slot. A predictive maintenance pilot gets stuck because nobody can get a clear decision on whether plant data should flow through the approved edge pattern or through a vendor gateway. Local teams, under pressure to hit production deadlines, quietly work around standards because waiting feels worse than non-compliance.
And then TOGAF gets the blame.
Usually unfairly.
In real situations, TOGAF itself is rarely the bottleneck. The bottleneck is almost always the way governance has been set up: who can decide, when they decide, what needs formal review, what can be delegated, and how much process has been piled into a single checkpoint. I’ve seen organizations label something “architecture governance” when, in practice, it was really a pile-up of design review, budget approval, security sign-off, vendor risk management, and PMO stage gates. No framework was going to make that move quickly. ArchiMate for governance
The actual job of governance is fairly simple, even if doing it well isn’t: reduce enterprise risk without injecting delay into every delivery motion.
That matters even more in manufacturing than it does in a generic enterprise environment. Slow decisions do not just create paperwork friction. They collide with plant outage windows, OT constraints, supplier availability, regional compliance requirements, and uptime commitments. If you miss a narrow cutover window in a factory because an approval sat in a queue, the cost is not theoretical. It is immediate. So is the temptation to bypass the process next time.
My perspective here is the perspective of a cloud transformation architect who has had to balance standardization, platform integrity, cybersecurity, integration consistency, and delivery speed across multiple factories and regions. So I’m not arguing for less control. I’m arguing for more precise control.
That’s a very different thing.
Start by deciding what “good” governance actually looks like
A lot of architecture teams get this backward. They start by creating the board, the templates, the checkpoints, the review deck format. In other words, they start with governance activities instead of governance outcomes.
That’s a mistake.
Before you design a governance model, define what success looks like. In a manufacturing enterprise, good architecture governance should be fast enough that delivery teams do not see it as a schedule threat. It should be strict where operational risk is high, especially at the OT/IT boundary. It should stay lightweight for low-risk changes. It should be visible, measurable, and predictable. And it needs to be integrated into portfolio, platform, and delivery workflows rather than sitting off to the side like its own administrative universe.
Those traits sound obvious. In practice, they’re often missing.
The risks are also very specific. Manufacturing governance has to deal with things that can hurt the business quickly: unplanned downtime, cybersecurity exposure between plant and enterprise networks, conflicting data models across plants, duplicate cloud services purchased by local business units, and traceability gaps that become painful during quality or regulatory events.
So here’s the principle I keep coming back to:
Governance should scale with architectural risk, not organizational hierarchy.
Not every change needs enterprise-level scrutiny just because the enterprise architecture team exists. If a small, low-risk design choice inside an approved platform path still needs a senior review board, the model is already drifting toward bottleneck territory. Sparx EA training
Step 1 — Separate governance objectives from governance activities
One of the most common design flaws is bundling too much into one process. “Architecture governance” becomes the catch-all for everything even loosely adjacent to design control.
That’s how you end up with a single meeting trying to answer five different questions:
- Is this aligned to the target architecture?
- Is it secure enough?
- Is it compliant with standards?
- Is the funding justified?
- Is the vendor acceptable?
- Is the solution design actually good?
- Does the PMO want to release it this quarter?
That is not governance. That is a traffic jam with a calendar invite.
The better move is to break governance down into its actual objectives. Usually they include a handful of things: ensuring target-state alignment, controlling risk and standards exceptions, improving reuse, creating traceable decisions, and enabling escalation when trade-offs cut across domains.
Each of those objectives can, and often should, be handled differently.
Take a factory IoT rollout. It may need confirmation that the cloud landing zone is compliant, that historian integration follows the approved pattern, that plant network segmentation is respected, and that retention rules for telemetry are acceptable. Those are not necessarily one decision. They may involve different roles, different evidence, and different timing.
In a healthy model, cloud landing zone compliance might be handled through automated controls and platform checks. Historian integration could use a pre-approved reference architecture. Network segmentation might require a targeted OT security review. Retention may need a data governance decision. If you push all of that through one giant architecture forum, you have turned governance into a queue by design.
I’d strongly recommend mapping each governance objective to a specific artifact, role, and decision point. Keep it concrete. What is being decided, by whom, on what basis, and at what point in the flow?
And remove anything that is really procurement or PMO control disguised as architecture. I say that from experience. A surprising amount of “architecture review pain” is actually caused by adjacent functions using the architecture process as a convenient checkpoint for their own unresolved controls.
Step 2 — Decide what must be centralized, and what absolutely should not be
Over-centralization is the fastest route to governance fatigue.
The problem is not central standards. Most large manufacturers need some non-negotiable enterprise decisions. The problem is central review of too many decisions. Those are different things, although people mix them up all the time.
A practical taxonomy helps. I usually separate architecture decisions into four levels:
- Enterprise-wide decisions
- Platform-level decisions
- Domain-level decisions
- Team-level implementation decisions
Enterprise-wide decisions are the ones where inconsistency creates real cost or risk. In manufacturing, that usually includes cloud identity and access patterns, plant-to-cloud connectivity principles, master data ownership, integration standards around ERP/MES/SCADA boundaries, and cybersecurity controls affecting OT/IT interaction.
These should usually remain centralized.
Not because architects enjoy control, but because fragmentation here gets expensive very quickly. I’ve seen three plants implement three different remote vendor access models and then spend a year trying to explain to security and audit why none of them truly aligned. Same with IAM. If every manufacturing application team invents its own authorization model or machine identity handling, the cloud program becomes a museum of exceptions.
But not everything belongs at the center.
Service decomposition inside a bounded domain? Usually local. Reporting tool choice inside an approved analytics platform? Often local. Internal API conventions where enterprise contracts are preserved? Delegate. Deployment sequencing for individual plants? Definitely local, because operational context matters more than architectural purity in the abstract.
A good real-world example is a multi-plant predictive maintenance platform. Central architecture should define the eventing backbone, the asset identity model, the Kafka topic governance approach if Kafka is your backbone, and the security baseline for ingest and access. Local teams can then choose sensor polling cadence, edge buffering strategy, dashboard composition, and rollout sequencing based on plant realities.
That split works.
What usually does not work is this: centralized standards combined with centralized review of every design detail. It feels safe for about two months, and then it collapses under its own volume.
Step 3 — Stop using the architecture review board as the default answer
The classic architecture setup is familiar. Weekly board. Long slide deck. Mixed audience. Too many reviews. Half the items should never have been there. The urgent ones arrive late. The routine ones clog the agenda. Nobody leaves happy.
I don’t think formal review boards are useless. I do think they are massively overused.
A better model is tiered.
A practical tiered governance model
- Tier 0: Pre-approved patterns and guardrails
- Tier 1: Asynchronous architect review for standard changes
- Tier 2: Domain design review for cross-team impact
- Tier 3: Formal governance board for material risk, standards exceptions, or target-state divergence
That structure changes the default behavior. Instead of asking, “When does this go to the board?” teams start by asking, “Can this stay in Tier 0?”
That is exactly the right question.
TOGAF governance still fits here. You still need Architecture Contracts where they matter. You still need compliance assessments, stakeholder accountability, controlled dispensations, and a governance log. But those mechanisms do not all require a room full of people.
A manufacturing example makes it clearer:
- Adding another production line to an existing plant using an approved edge-to-cloud ingestion pattern should typically be Tier 0 or Tier 1.
- Introducing a new plant-wide data broker that affects MES, quality, and supply chain systems is probably Tier 2.
- Bypassing OT segmentation principles to connect directly to enterprise SaaS should be Tier 3, no question.
The threshold definitions matter. I’d use a blend of risk, blast radius, data sensitivity, safety impact, reuse potential, and precedent value. If a decision could create a new enterprise pattern, change a security posture, or introduce cross-domain coupling, escalate it. If it stays within known boundaries, don’t.
And publish these thresholds where engineers actually work. Not in a PDF buried under twelve SharePoint folders. Put them in engineering portals, workflow tools, pattern repositories, and delivery playbooks.
Here’s the model in a simple view:
If you build this well, most volume should stay in Tier 0 and Tier 1. If most of your changes end up in Tier 3, you have either weak standards, poor patterns, or a culture that does not trust delegation.
Probably all three.
Governance mechanism by change type
This is the kind of table teams actually use when it stays practical.
One opinion here: those turnaround times should be treated as service commitments, not aspirations. If governance cannot commit to timelines, delivery teams will assume the process is unpredictable, and they will behave accordingly.
Step 4 — Build governance into delivery flow, not around it
This is where many TOGAF implementations go sideways. Governance is designed as an overlay. Delivery happens over here. Governance happens over there. Eventually someone tries to reconcile the two with more checkpoints. TOGAF training
It never feels elegant because it isn’t.
Architecture governance works much better when it is embedded at the points where teams already need decisions: intake, backlog refinement, solution design, CI/CD controls, release readiness, and post-implementation review. If you place governance outside that flow, you create duplicate rituals. Teams then spend their energy preparing for governance rather than improving architecture.
For cloud-based manufacturing products, the strongest pattern is to codify as much as possible into the platform. If a standard can be expressed in infrastructure templates, network modules, identity integration, tagging policies, data classification controls, or deployment checks, then do it. Don’t ask for a meeting to validate something a pipeline can validate consistently in thirty seconds.
I’ll put it bluntly because this is one of the biggest unlocks:
If a standard can be codified, it should not require a meeting.
For example, on a cloud quality analytics platform, architecture guardrails can be embedded into approved IaC templates, standard connectivity modules for plant data ingestion, mandatory metadata and data classification, and automated policy checks covering region placement, encryption, route control, and identity integration. You still maintain a standards repository. You still keep governance records. You still use Architecture Contracts where they are useful. But you do not make teams produce every TOGAF-flavored artifact at full depth for every piece of work. ArchiMate in TOGAF
That is not governance maturity. That is ceremony.
Step 5 — Standardize the small number of things that create most of the delay
This is where architecture teams either become useful or remain theoretical.
In manufacturing transformations, the same issues create delay again and again:
- ambiguity in cloud landing zones
- inconsistent integration patterns between ERP, MES, and plant systems
- unclear ownership of asset, material, and quality data
- repeated security debates around remote access and edge connectivity
- bespoke vendor architecture every time a new plant tool is introduced
You do not solve these by writing more principle statements. You solve them by creating reusable assets that delivery teams can apply without interpretation gymnastics.
The set is usually smaller than people think:
- reference architectures
- approved patterns
- decision trees
- exception templates
- standard NFR baselines
- OT/IT integration blueprints
One pattern I’ve seen deliver immediate value is a pre-approved blueprint for connecting plant historians to a cloud data lake through an edge mediation layer, with buffering, protocol translation, IAM integration, Kafka or event-hub style streaming where needed, and explicit security boundaries. Once that pattern exists and has been tested, every new plant rollout gets faster. Governance shifts from “design this again” to “confirm this instance fits the pattern.”
That’s where you want to get to.
I’m fairly opinionated on this one: most enterprises have too many standards documents and too few usable patterns. If an engineer cannot apply the guidance inside one sprint, it is probably not helping governance very much.
Step 6 — Make exceptions fast, visible, and just uncomfortable enough
You need an exception process. Always.
Without one, governance becomes rigid, and people go underground. With a weak one, standards become optional. The balance matters.
A healthy exception process should require a business rationale, an explicit risk owner, an expiration date, a remediation or migration path, and documented compensating controls. It should also be visible enough that repeat exceptions become signals rather than forgotten artifacts.
The “slightly uncomfortable” part matters more than people admit. Exceptions should absolutely be possible. But they should not be easier than compliance.
A manufacturing example: a plant acquires a specialist machine monitoring package that is hosted in a cloud region outside corporate policy. The answer should not automatically be “no,” especially if the business need is real and production risk is involved. But the response should be disciplined: temporary exception, restricted dataset scope, segmentation controls, tighter access handling, and a supplier remediation plan with dates.
The common failure mode is permanent temporary exceptions. Every architect has seen them. Three years later the “short-term deviation” is part of the landscape, nobody remembers the original rationale, and now it is politically difficult to unwind.
Review exception trends quarterly. If the same exception keeps appearing, one of two things is true: your standard is outdated, or your delivery path is impractical. Both deserve attention.
Here’s a simple way to think about exception handling:
What usually goes wrong
I don’t think governance problems are mysterious. They are repetitive.
1. Reviewing too late
Architects first see the solution after the vendor is selected or the build has already started. At that point, governance becomes either rubber-stamping or disruption. Neither is healthy.
I’ve seen this with warehouse automation platforms and plant scheduling tools. By the time architecture got involved, contracts were drafted and integration assumptions were already baked in. The review felt painful because it was late, not because governance existed.
2. Treating every initiative as strategic
Not every line-side app change is architecture-defining. If minor dashboard enhancements and regional product master redesigns go through the same governance path, you have lost your sense of proportion.
This happens a lot in organizations trying to “raise architecture discipline.” What they actually do is over-govern routine delivery.
3. Confusing document completeness with decision quality
Sixty slides. Weak decisions. Everybody tired.
This one is almost universal. Teams are rewarded for producing review artifacts rather than clarifying trade-offs. In one manufacturing program I was involved in, a simple plant dashboard extension ended up with a massive review pack because people assumed more detail would reduce challenge. It just wasted time.
4. No service-level expectation for governance
Approvals happen “when the board can meet.” That is not acceptable if your plants operate on scheduled cutovers and constrained windows. If governance has no turnaround commitment, the process becomes calendar-driven instead of risk-driven.
I have seen production cutovers missed because architecture sign-off sat idle for days waiting for a quorum.
5. Governance without platform enablement
This is maybe the most damaging one. Teams are told what not to do, but they are not given an approved path to do the thing they actually need. So they improvise.
No approved OT data ingestion pattern. No identity integration module. No standard Kafka topic naming and access model. No edge connectivity blueprint. And then leadership is surprised when every plant creates its own variation.
That is not delivery indiscipline. It is a platform and governance design failure.
Step 7 — Measure governance as a delivery capability
Weak governance metrics are easy to spot. Number of reviews completed. Number of standards published. Number of board meetings held.
None of those tell you whether governance is actually helping.
The useful measures are operational and behavioral:
- average review turnaround by tier
- percentage of changes using approved patterns
- exception rate by domain
- recurring exception themes
- architecture issue discovery timing
- rework caused by late governance
- non-compliance remediation lead time
For manufacturing, I’d add a few very practical ones:
- percentage of plant deployments using the standard edge pattern
- number of MES integrations using the approved canonical event model
- reduction in unique vendor-hosted connectivity approaches
- percentage of cloud workloads integrated with enterprise IAM rather than local identity stores
Metrics change behavior. Once governance teams are measured on turnaround, pattern adoption, and rework prevention, they start operating more like a service organization. Delivery teams also become more willing to engage early because the process feels predictable.
Publish the metrics openly. If governance lead time is invisible, people will assume it is worse than it is.
And sometimes they’ll be right.
Step 8 — Clarify roles so decisions stop floating upward
A lot of bottlenecks happen because nobody really knows who can say yes. So everything gets escalated by habit.
That’s avoidable.
A practical role split in manufacturing usually looks like this:
- Enterprise architect owns principles, standards, strategic coherence, and major exceptions
- Domain architect owns business capability alignment and cross-solution consistency
- Platform architect owns cloud, integration, IAM, shared services, and reusable guardrails
- Security and OT architects own control decisions in sensitive zones
- Product and delivery teams own implementation choices inside approved guardrails
That is enough structure for most enterprises. You do not need a giant RACI matrix with forty swimlanes and nobody reading it. A one-page decision rights matrix is usually better.
For example, in a global smart factory platform, central enterprise architecture may own target-state patterns, regional architects handle localization constraints and regulatory realities, and the plant implementation team owns rollout sequencing and local operational fit. That is a healthy split. It prevents every design nuance from climbing to the top. Sparx EA guide
TOGAF supports this perfectly well, by the way. Governance works better when accountability is explicit across architecture development and implementation oversight. The framework is not the problem. Vagueness is.
A scenario that makes this real: MES modernization across 18 plants
Let’s anchor this in something concrete.
Imagine a manufacturer with 18 plants, several aging MES variants, fragmented quality data, and an active corporate cloud program. They need production continuity. They cannot freeze the network for a year while someone perfects target-state diagrams. And yet they clearly need more consistency.
Under a traditional board-heavy model, this program often bogs down. Every plant variation triggers a full review. Every integration question gets escalated. The architecture board becomes a scheduling bottleneck. Local teams either wait or work around it.
A better governance approach looks different.
First, central architecture establishes a small set of target-state principles: standard identity integration with enterprise IAM, approved plant-to-cloud connectivity patterns, canonical event exchange for MES and quality events, and a common integration boundary for ERP/MES interactions. Not hundreds of standards. A few high-leverage ones.
Second, approved patterns are published for plant connectivity, event exchange, and deployment baselines. If Kafka is the regional event backbone, the pattern includes topic ownership, schema governance, access control, retention guidance, and edge buffering options. If cloud deployment is standardized, the landing zone controls are codified.
Third, the pilot plant uses the standard path. Most governance stays in Tier 0 and Tier 1. The team deploys using the approved edge pattern, standard IAM federation, and the existing quality event model.
Then a plant asks for a local variation because a machine vendor only supports a constrained interface. That triggers an exception. It does not derail the whole program. The exception gets approved with expiration, compensating controls, and a migration plan.
Later, a cross-domain review is triggered because a new quality event schema would affect ERP and enterprise analytics. That is the right kind of escalation. It is architecture-shaping, cross-domain, and precedent-setting.
Meanwhile, automated policy checks validate cloud deployment baselines continuously rather than waiting for someone to inspect screenshots in a review meeting.
The outcomes are what you would expect if the model is working: fewer board escalations, faster repeatable plant rollout, better traceability of deviations, and less integration sprawl.
Under the old model, every one of those decisions might have ended up in the same weekly committee. That’s the difference. Not weaker governance. Better sorting.
Step 9 — Use governance to shape investment, but don’t trap every decision in funding gates
This is a subtle one, and it is easy to miss.
Some organizations tie all architecture decisions to investment approval gates. That sounds disciplined. In practice, it often turns architects into budget police and slows down ordinary delivery decisions that should stay close to teams.
There are really two motions here:
- governance for strategic investment alignment
- governance for solution delivery guidance
They overlap, but they are not the same.
A strategic decision like adopting a common industrial data platform across regions belongs in investment-aligned governance. It affects cost, roadmap, capability reuse, and long-term target state.
A delivery decision like whether one plant rollout uses batch or streaming ingestion within an approved architecture pattern does not need to wait for the capital cycle. It should be handled close to the team, with platform and domain oversight if needed.
My view is that architecture boards should focus on high-cost divergence, target-state trade-offs, and major standards shifts. If they become the place where all routine design choices go to gain legitimacy, everyone starts gaming the process. Teams frame ordinary decisions as strategic because that is how they get attention, or they avoid the process entirely because it is too tangled up with funding mechanics.
Neither outcome is healthy.
Step 10 — Evolve the governance model after six months or it will calcify
No governance design should be treated as permanent, especially at the start of a major transformation. You will get things wrong. Some reviews will be unnecessary. Some standards will be too vague. Some risks will have been underestimated.
That is normal.
I’d review the model after 90 days, again after the first major delivery wave, and then quarterly. Look at which reviews could become self-service, where standards still produce repeated interpretation debates, what teams keep escalating, whether architecture artifacts are too heavy, and where OT-specific constraints still need sharper treatment.
A very common pattern in manufacturing is that edge connectivity reviews start out formal because the enterprise is still learning. After several successful plant rollouts, those same reviews can often be downgraded to pattern-based approval because the controls are proven and the implementation path is stable.
That is maturity.
Retire governance steps as confidence rises. Add scrutiny only where incidents, repeated divergence, or changing risk justify it.
A short version of the principle is this:
Mature governance gets lighter in the common path and sharper in the risky path.
That’s the balance worth aiming for.
The real goal is not less governance
It’s less unnecessary decision latency.
That distinction matters because people often frame this as a choice between control and speed. In my experience, that’s the wrong framing. The better question is how to make governance precise, timely, and risk-aware enough that it protects the enterprise without slowing routine delivery.
If I boil the argument down, it’s this:
Centralize only the decisions that truly need enterprise control. Codify standards into platforms and reusable patterns wherever possible. Reserve formal boards for material risk, strategic divergence, and meaningful exceptions. Make exceptions visible and temporary. Measure turnaround and rework, not just compliance activity.
And in manufacturing, keep one thing front of mind: cloud programs do not happen in a vacuum. They meet plant operations, uptime constraints, machine realities, supplier limitations, and OT risk. Governance has to protect coherence and resilience in that environment without making every rollout feel like a bureaucratic negotiation.
The best architecture governance model is the one delivery teams stop talking about because it quietly helps them move faster.
FAQ: Practical questions architects ask when redesigning TOGAF governance
How often should an architecture review board meet?
Only as often as needed for high-risk or strategic decisions. Routine work should not depend on board calendars.
Can TOGAF governance work in agile product teams?
Yes. Very well, actually, if governance is embedded into flow, backed by patterns, and uses asynchronous review for most changes.
How do you govern OT and IT together in manufacturing?
Use shared principles, but keep specialized control points for safety, segmentation, connectivity, resilience, and operational recovery. The boundary matters.
What is the first sign governance is becoming a bottleneck?
Teams start bypassing it, delaying disclosure, or treating standards as optional because the process is slower than delivery pressure.
Should every standards exception go to the enterprise architecture board?
No. Only exceptions with material enterprise risk, cross-domain impact, or precedent-setting implications should go that high.
Frequently Asked Questions
What is TOGAF used for?
TOGAF provides a structured approach to developing, governing, and managing enterprise architecture. Its ADM guides architects through phases from vision through business, information systems, and technology architecture to migration planning and governance.
What is the difference between TOGAF and ArchiMate?
TOGAF is a process framework defining how to develop and govern architecture. ArchiMate is a modelling language defining how to represent architecture. They work together: TOGAF provides the method, ArchiMate provides the notation.
Is TOGAF certification worth it?
Yes — TOGAF Foundation and Practitioner are widely recognised, especially in consulting, financial services, and government. Combined with ArchiMate and Sparx EA skills, it significantly strengthens an enterprise architect's profile.