Your Architecture Practice Won't Scale Through Hiring Alone

A Guide for Chief Architects Who Want Decisions to Matter More Than Diagrams

Toyota’s production system, shaped in large part by Taiichi Ohno, gave frontline workers a way to flag a quality problem and pull help towards it. Pulling the cord brought a team leader over to fix the problem where it happened, and the line only stopped if the two of them couldn’t resolve it before the work moved on. Stopping a production line costs time and money. Most factories try hard to avoid it. Toyota accepted that short pause because a defect left unresolved creates more waste, more rework, and more delay later.

The point was to fix the cause before the same problem came back. Toyota built quality into the work by letting people raise problems where they happened and bringing support to the spot. It did not rely mainly on finding defects at the end of the line. Quality became everyone’s job.

Many architecture teams do the opposite. Demand rises, so they hire more architects, write more documents, and add more review steps. The team gets more visible but more stretched and more worn down. But it has not scaled. It has simply expanded the queue. A practice scales when people across the organisation can make sound architectural decisions within clear guardrails, without waiting for an architect. Hiring more architects helps with capacity. It does not solve the scaling problem.

You know the moment this becomes real. The practice earns trust. Demand rises. Every programme or engagement now asks for an architect. Every delivery team wants quick advice. Soon, the central team becomes the bottleneck it was created to remove.

Nearly ten years ago, I was hired to build an architecture practice from scratch. The company worked in data and marketing. The brief from leadership was clear: build security into the enterprise architecture and put the right controls in place so larger and more regulated clients could have confidence in the business.

Before I designed anything, I asked my sponsor one question:

What are we really trying to achieve?

A deliverable is the thing the work needs to produce. Purpose explains why the work matters. It guides the decisions that follow. For us, the purpose was to make the business easier to trust, especially for larger and more regulated clients. The business already had an architecture. It just was not managed in a clear, shared way. We were building the way architecture would work, plus the standards and rules people could rely on.

I wrote about that experience in a May article on building an enterprise architecture practice. This article takes the next step. Building a practice and growing one are different jobs. This is about pushing the domain decisions into teams while the centre keeps the few that carry enterprise-wide risk, regulatory consequences, or commitments that are hard to reverse. This is for Chief Architects who want to grow a strong practice without sitting in every decision.

Welcome to The Foresight-Driven Enterprise. A newsletter for chief architects and forward-thinking leaders building what comes next

---

Better decisions when the future is unclear, that's the whole point. As leaders, we know the hardest calls arrive before the facts do. If that's the seat you sit in, this is for you. There's a new piece almost every week. I write about how to think clearly about the futures ahead, and how to create the future, by which I mean building toward the one you want while staying ready for the others that arrive. It's plain language and real methods, the ones I use with the leaders I work with. You get applied foresight and strategy execution, no-nonsense mental models from the field. If you want to think like a futurist, plan like a strategist, and build like an architect, subscribe below

First, get clear on what you are scaling

Do not try to scale architecture until you are clear about what you mean by architecture. Ahlemann and colleagues describe enterprise architecture management as a management practice. Van de Wetering looks at the capabilities EA helps an organisation build over time, using David Teece’s concept of dynamic capabilities. Both views matter, but the practical point is not about the school of thought you subscribe to.

Do not try to scale your repository or try to scale the number of diagrams your team can produce. Scale the organisation’s ability to use architecture, governance, information, and shared practices to make better change decisions. That ability grows through use. It gets stronger when people use it in planning, delivery, investment, and risk decisions. It gets weaker when architecture only appears at a monthly architecture review board.

In some organisations, EA mostly means diagrams, standards, documents, and approval gates. Those things have a place but they are not enough on their own. A strong practice has real backing from leaders, clear governance, a roadmap for improvement, regular communication with stakeholders, and architects who can influence the decisions that matter. No framework builds that for you.

Svyatoslav Kotusev’s exploratory study of a TOGAF-based EA practice found that none of the TOGAF-specific recommendations proved useful in that organisation. What actually worked was largely homegrown, the ways of working the company had built for itself, with a few established EA ideas sitting alongside them. That does not prove TOGAF is useless. It proves something more useful: a framework is not the practice. A framework can give you shared language and useful structure. The capability comes from what your organisation builds around it and how consistently it uses it. Think of it this way: a framework is scaffolding and the actual EA capability is the building.

The shift that changes scaling

Whether you lead an internal EA function or advise external clients, the challenge is the same. Demand for experienced architectural judgement will eventually exceed the capacity of a small expert team. Stakeholders may ask for diagrams. What they really need is clearer choices, better trade-offs, and less uncertainty.

That changes how you define the product of the practice. The product is the organisation’s ability to make sound architectural decisions when it matters and the diagram and the repository are a means to it. Principles, reference architectures, decision records, standards, guardrails, and advisory services all matter, but they matter because they help other people make better decisions without needing a central architect in every meeting.

Adding architects increases capacity but it does not create a scalable architecture capability. Your practice scales when teams can make the decisions closest to their work, within clear guardrails, and know exactly when to escalate. If diagrams, repositories, standards, and review boards become the point, they limit the practice to the size of the central team.

Think back to Toyota.

Scale does not come from pulling every decision back to the centre. It comes from pushing the right decisions closer to the work, with a clear route to raise the decisions that are too big, too risky, or too connected to decide locally.

Five moves make that happen: purpose, governance, people, context, and measurement. But before you make any of them, earn the right to do so. If you do not have an executive mandate, do not begin by asking for control of every architecture decision. Start with one visible business problem that leaders already want fixed. It could be duplicated technology spend, slow regulatory change, a failed integration, weak data quality, or delivery risk that keeps coming back.

Bring evidence and show the cost of the decision gap. Offer a small, time-bound intervention and deliver a result. Then use that result to ask for a defined mandate over the next set of decisions. That political capital is proof that architecture helps the business make a hard choice and live with the outcome. Without it, decision-rights work looks like a power grab.

Move 1: Start from the purpose

Start with purpose and name the business outcome the practice exists to improve, then secure an executive mandate tied to it. It might be faster transformation, lower risk, more reuse, better regulatory resilience, or shorter time to market. Pick the outcome leaders already care about right now. Then name the decisions. Write down where architecture decides, where it assures or recommends, and where it only provides input. Do not leave this to custom, personalities, or whoever speaks loudest in a steering committee. The list usually covers technology standards, target-state guardrails, capability sequencing, major investment cases, and exceptions. Each decision needs an owner, a decision path, and an escalation route.

Do not spend a year modelling the whole enterprise before improving a single decision. Start with two to four decisions where fragmentation, duplication, risk, or delay is already a pain point. It could be application rationalisation, customer-data integration, regulatory-control design, or post-acquisition integration. Build only the architecture information those decisions need. Then expand from proven value.

This is where strategy meets execution. Architecture turns strategy into the capabilities, principles, roadmaps, priorities, and constraints that delivery teams can act on. A strategy without priorities, investment choices, accountability, and delivery action is simply an ambition. Delivery without strategic direction keeps teams busy without moving the enterprise where it needs to go.

Move 2: Make governance part of the work

Governance is how an organisation makes decisions, handles accountability, manages risk, and resolves conflict. In fast-moving software organisations, governance gets a bad name when it is experienced mainly as slow approvals, bureaucracy, or control that feels detached from delivery. That is a reason to design governance properly, not to remove it.

Good governance makes the rules clear, keeps the right decisions close to the work, and gives teams a fast route to escalate the choices that exceed their authority. That is how teams move quickly without creating a mess for everyone else.

Beese and colleagues followed enterprise architecture management at Commerzbank from 2008 to 2018. Their study shows architects using a portfolio of formal and informal controls, then changing that portfolio as the bank’s strategy changed. That is the real work of governance. Standards, forums, patterns, assurance, relationships, and informal influence all work together. Governance is not a rulebook you write once and freeze. You have to change the controls when the strategy, risk profile, technology, regulation, or enterprise design changes.

On the other side of the governance argument, a common fear is chaos. Give teams more authority and they will make local choices that create duplication, poor integration, and future cost. The answer is federated guardrails. Set a small number of enterprise rules where consistency matters such as identity, data classification, interoperability, security, regulatory controls, and selected core platforms but let domains own the broad set of decisions they can make safely inside those guardrails. Give them a fast, clear route to the centre for decisions with cross-domain dependencies, material risk, major cost, regulatory impact, or consequences that are hard to reverse.

Hold those few decisions tightly, because a bad architectural choice rarely announces itself the way a defect on a line does. It hides inside a working system and surfaces later as duplication, a broken integration, or a control gap someone finds in an audit. So you don’t wait to catch drift after it happens. You draw the guardrail around the choices that are expensive or impossible to reverse, and you leave the decision space wide wherever a wrong call is cheap and easy to see. That is the Toyota andon cord again. Authority sits close to the work and escalation exists for the decisions that exceed local authority.

Move 3: Put architects near decisions

Where architects sit affects what they can see, who they can influence, and which decisions they can help shape. Even in agile environments, EA helps organisations balance team autonomy with enterprise-wide coordination. Do not bury your architects in isolated teams and expect enterprise coherence to appear by accident. Do not place them so far above delivery either that they lose touch with how work gets done. Put them where they can see connections, build relationships, and influence decisions before teams make expensive commitments.

Architects in those roles need more than technical knowledge. They need foresight, systems thinking, stakeholder engagement, facilitation, communication, negotiation, and enough technical and domain credibility to help teams work through hard trade-offs. Tools support an architecture practice but it’s your people who transform it. Collaboration turns a design into changed behaviour. Also, your frameworks and tools matter, but they cannot replace people working well together. So, invest early in communication, engagement, and collaboration, especially when it feels less concrete than a new model or repository. Keep investing as the practice grows.

People do not change how they make decisions because you published a target state. They change when they understand the reason, have a role in the change, practise the new behaviour, and see leaders reinforce it. Much of enterprise architecture and transformation involves understanding human psychology, and you need it to make adoption real.

Leadership cuts both ways here: your managers need enough EA knowledge to back the work, and architects need real communication and leadership skills. Transformation failure rarely has a single cause. But weak knowledge, communication and collaboration make every other problem harder.

Move 4: Grow in stages

I showed you how the German bank, Commerzbank ran governance as a shifting portfolio of controls. It is tempting to lift another organisation’s approach wholesale. Don’t. Instead, build one that fits your organisation. A large enterprise with deep legacy, autonomous domains, and regulatory exposure needs a different path from a smaller company with limited change capacity. Public-sector organisations face different constraints again: public accountability, procurement, statutory duties, and continuity of service. Context matters.

Start with the organisation you have. Shape the EA transformation pace, scope, governance, and support model around its strategy, operating model, technical estate, resources, and risk. Phase the distribution of decision rights as deliberately as you phase capability delivery. Start teams with a limited decision space, clear guardrails, and strong feedback loops. When they demonstrate sound judgement, widen the space. That is how delegation becomes capability-building instead of abdication.

Track the maturity of the practice as well. Look at the mandate, governance, skills, engagement, information, tooling, adoption, and outcomes. Maturity models differ. Use one that helps you see what needs to improve next and don’t be fixated on maturity scores.

Your own path might look like this:

• Establish the mandate and foundations

• Standardise the core methods and governance

• Delegate suitable decisions with guardrails

• Embed architecture in investment, portfolio, risk, and delivery processes

• Adapt continuously using feedback, measures, and changing strategic needs

This is not universal law but treat these points as a practical path.

Move 5: Measure what changed

If you only measure the wrong things, the team will focus on being busy instead of being useful. Models, reviews, standards, and training numbers show activity. They help you run the team but they do not prove that architecture changed anything that matters.

When teams make more decisions themselves, measure what happens next.

Did they work within the guardrails?

Did they decide quickly enough?

Did they need rework, exceptions, or late escalation?

Did delivery, risk, reuse, cost, or stakeholder confidence improve?

You test distributed governance this way by checking whether the decisions made outside the core team held up.

Talk to your executives in terms they use: strategic outcomes, financial impact, risk, delivery performance, compliance, and organisational capability. Track relevant measures such as reuse adoption, delivery lead time, duplicate systems retired, cost avoided, risk reduced, decision speed, exception rates, and stakeholder confidence. Set a baseline, give someone ownership, and be honest about attribution.

Architecture rarely causes a business outcome on its own. It contributes to the enterprise alongside product, delivery, operations, finance, security, and leadership. Show that contribution clearly. A benefits scorecard does more for the practice than the most beautiful EA repository you will ever build. EA repositories still matter, but they must give people reliable information for real decisions, governance, and change planning.

Enterprise design, business architecture and strategy skills matter for the same reason. They help architects connect technology choices to business capabilities, investment priorities, customer outcomes, and enterprise trade-offs. Get your architects to hone these skills because when budgets tighten, evidence of contribution to cost, risk, resilience, and delivery outcomes gives leaders a far stronger basis for sustaining the practice.

The future-ready practice

The most mature architecture practices do more than explain today’s IT landscape. They protect the organisation’s ability to act tomorrow. That means making deliberate choices about what to standardise, what to keep modular, what to defer, and which dependencies to remove before they become traps. It means testing major commitments against more than one plausible future, because applied strategic foresight exposes the early warnings a single-future plan would miss.

Your exceptions log is where a lot of that early warning lives. A single exception is a waiver. A pattern of them is telling you something, and it pays to think critically about it. It may point to delivery pressure, outdated standards, a missing capability, legacy constraints, or architecture debt building in plain sight. Read it next to your delivery, risk, financial, and operational data, and it turns into an early warning system for the options you are losing. That is the detection layer sitting behind your guardrails. The guardrails contain the decisions you can’t afford to get wrong, and the log tells you where the ones you did delegate are starting to bend.

If you do EA advisory work, the same logic scales your practice too. You productise the repeatable parts of your judgement into methods, diagnostics, reference architectures, templates, and playbooks, and you keep yourself for the decisions that are high-stakes, novel, or specific to the client. That is the andon cord again, drawn around a consultancy instead of a factory floor.

A practice scales when people stop waiting for central architects to make every routine decision. You are not losing control. Scaling a practice to be future-ready means designing control properly with clear decision rights, guardrails, shared language, trusted information, and a fast route to escalate the choices that carry enterprise-wide risk.

The Chief Architect’s job becomes to build the system that lets good decisions happen close to the work, and to hold the few decisions that genuinely belong at the centre. That is the andon cord extended across the organisation. A defect on a line is obvious and repeatable. An architectural decision is neither, so the andon cord here is not a stop button, it is the authority to raise a problem and pull help to it before it hardens into rework. Teams have the mandate, guardrails, and confidence to spot misalignment and act before it becomes a bottleneck. Architecture stops being a central service that people wait for. It becomes a collective habit. That is what a future-ready architecture practice looks like: a team of architects enabling an enterprise that has learned to think architecturally.

I write The Foresight-Driven Enterprise, a newsletter about architecture, foresight, and growing as a practitioner. If you want more articles on building and scaling a future-fit enterprise, subscribe and I will send them to your inbox.

---

More on the research

• Ahlemann, F., Stettiner, E., Messerschmidt, M., and Legner, C. (2012). Strategic Enterprise Architecture Management: Challenges, Best Practices, and Future Developments. Springer

• Van de Wetering, R. (2020). “Dynamic Enterprise Architecture Capabilities and Organizational Benefits: An Empirical Mediation Study.” Open-access PDF

• Kotusev, S. (2018). “TOGAF-Based Enterprise Architecture Practice: An Exploratory Case Study.” Open-access PDF

• Beese, J., Haki, K., Schilling, R., Kraus, M., Aier, S., and Winter, R. (2023). “Strategic Alignment of Enterprise Architecture Management: How Portfolios of Control Mechanisms Track a Decade of Enterprise Transformation at Commerzbank.” European Journal of Information Systems. HSG publication link

• Van Wessel, R. M., Kroon, P., and de Vries, H. J. (2022). “Scaling Agile Company-Wide: The Organizational Challenge of Combining Agile-Scaling Frameworks and Enterprise Architecture in Service Companies.” IEEE Transactions on Engineering Management. Open-access PDF

• Gong, Y., and Janssen, M. (2023). “Why Organizations Fail in Implementing Enterprise Architecture Initiatives?” Information Systems Frontiers. Springer

• Ohno, T. (1988). Toyota Production System: Beyond Large-Scale Production. Productivity Press. For the andon mechanism, see Toyota’s official guide.