Your company may have standardised its systems, with common data and processes across business units. Yet the architecture team still hears about a supplier choice after the contract is signed.
So how mature is your practice?
In 2006, Jeanne Ross and Peter Weill of MIT, with David Robertson of IMD, published Enterprise Architecture as Strategy. They described four stages a company’s architecture moves through: Business Silos, Standardised Technology, Optimised Core, and Business Modularity. The stages trace how a company learns to build a reusable foundation for executing its strategy. Ross and her colleagues at MIT CISR later added a fifth stage, the digital ecosystem.
LEGO is one of the companies Ross’s team studied. A 2016 MIT CISR briefing describes how the company used an enterprise resource planning system to improve its supply chain. Its enterprise platform expanded to cover human resources, manufacturing and product lifecycle management. Once that foundation was in place, management could focus on digital services.
That foundation changed what LEGO could do. To assess the practice behind that work, I would ask how the architects contributed to the decisions that produced it.
This piece separates your architecture from the practice that helps shape it. These belong together, but assessing them requires different evidence. An integrated platform tells you something about how the enterprise operates. To judge the practice, look at skills, relationships, and contribution to real decisions. A strong platform alone cannot tell you whether architects are helping shape the next investment.
When the CIO asks about maturity, do not lead with a score. Connect the assessment to that contribution. Explain which decisions architects helped change or confirm, where they became involved too late and what needs to improve. Use the assessment score to support that conversation and track the improvements you agree.
Established frameworks already address practice capability. Gartner offers an enterprise architecture (EA) IT Score; The Open Group publishes guidance on architecture maturity models; and CMMI offers a broader view of process improvement. They are useful, but they answer broader questions than the one explored here. This guide uses a narrower lens: four levels of influence on decisions. It is a practical guide, not a validated maturity model or a complete assessment of the function. The levels describe recording the architecture, reviewing choices, framing options and shaping investment. Each level comes with one test and a move you can take to improve your practice. The aim is to make one change and gather evidence of whether it helped.
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.
Level 1: Architects record what exists
At level 1, the practice mostly describes what already exists. The team maintains inventories, maps, standards, and the repository. That work matters: it helps people see what the company runs and how the pieces connect. Practices at every level need these foundations.
The limitation appears when the work ends there. Artefacts produced after a choice cannot inform that choice, though they may support later decisions. A model can be current and still make little contribution to the decision at hand. The team can explain what exists, but struggles to explain how its work informed a choice.
The test: pick recent decisions and reconstruct them with the people who made them. Ask three questions: what did you use, when did you receive it, and what did it help you understand, change or confirm? If people know the documents but cannot name a decision they influenced, use level 1 as a working description of that area.
The move: choose one live decision—a renewal, a platform choice, a supplier. Turn the relevant model into one page the decision owner can read before the meeting, with the dependency, cost, or risk that could change the outcome at the top. After the decision, ask: what helped, and what was missing? Use their answer to improve your next contribution.
Level 2: Architects review the choice
At level 2, the practice has a seat in governance. Designs reach the review board, architects assess them against standards, and exceptions are recorded. Done well, the review can identify risks and help prevent an avoidable mistake.
Timing limits what that review can change. Once the supplier is chosen and funding is committed, changing direction can require new approvals, cost or delay. The team can still improve the design, but changing the underlying choice may require reopening an earlier approval.
The test: take three recent initiatives and identify when the practice first became involved. At that moment, what was still open? And what, if anything, changed after the review? Bring in the project owners. Without the people who made the decision, architects are grading their own homework.
The move: pick one business area and negotiate an earlier point of involvement with its leader. Start with the problem. Then build two or three real options with the people who own cost, delivery, and operations. Agree with the governance owner how that work will satisfy the formal review. Remove duplicate paperwork while retaining the checks the decision needs.
Level 3: Architects frame the options
At level 3, architects help define the decision before the organisation commits. They put the options on the table with the cost, risk, delivery impact, and the consequences for future change. They recommend a direction and record the reasoning where the people responsible for the decision and its implementation can use it.
The contribution extends beyond assembling a list of options. Architects connect consequences across the enterprise. The cheapest choice for one team can become somebody else’s workload, a new vendor dependency or a constraint on future change. Make those consequences explicit while the choice is open, then retain them for implementation and review.
An Architecture Decision Record (ADR) preserves that reasoning for later use. At minimum, capture the context, decision, and consequences. Add options, assumptions, and detailed trade-offs when they help the owner act. Make accountability explicit: name who owns the architecture definition, who approves the decision and who contributed.
The test: take one recent decision and trace the practice’s contribution. Did architects identify a credible alternative, reveal a dependency, or help change or confirm the preferred direction with evidence? The options do not have to come from architects alone. Look for a contribution you can trace through the reasoning and the choice.
The move: as a starting exercise, add a review condition to your next few ADRs: “Revisit this when…” Name the trigger, who will watch for it and who can reopen the decision. Then look across the records for recurring assumptions and gaps in what the business can do. Bring those patterns into planning before the next projects are defined, and use them to inform which capabilities the organisation invests in next.
Level 4: Architects shape the portfolio
At level 4, the practice helps shape investment priorities before individual projects are defined. Architects start with strategy, examine the changes that could affect it and ask what the business would need to do. A capability describes something the business must be able to do—fulfil an order across channels, for example, or launch in a new market.
Strategic foresight contributes here by exploring plausible futures and their implications. In my approach, capabilities connect those futures to architectural decisions and roadmaps. They help leaders discuss what the business needs to do before choosing technology.
The practice should also equip people elsewhere in the business to use its reasoning. When product and finance can use and challenge the same assumptions in later decisions, architectural thinking is beginning to spread.
The test: find a planning decision where the practice helped change or confirm a priority, alter its timing or preserve a credible option. Being in the room proves access. The contribution lies in the reasoning and decisions that follow.
The move: before planning starts, choose one strategic question and build a small set of contrasting plausible futures around it. For each future, ask what the business would need to do and where today’s capabilities would fall short. Separate investments useful across the futures examined from choices that depend on particular conditions, and name the evidence that would prompt a review. Ask your sponsor to bring these choices into planning and agree when they will be reviewed. Treat this as a first exercise that you can deepen as the decision requires.
Assess what the team can repeat
One business area may involve the practice early while another sends over a finished design. Giving the whole function a single level can hide the difference. It can also mistake a well-connected architect for a mature practice.
Start with three recent decisions from different parts of the business. Choose a case where the practice contributed well, a routine case and a case where it had little effect. That is enough to start a conversation, but it does not establish the level of the whole function. Include more business areas, decision types and planning periods before making that claim.
For each decision, record when the practice became involved, what it contributed and the decision reached. Ask someone outside the practice to explain its contribution, and check that account against the relevant records. Look for work other architects can repeat without depending on a single person’s relationships. Where the contribution is limited, investigate constraints such as skills, timing, responsibility and work the decision owner could not use.
Each level describes a broader contribution to decisions. Broader reach alone does not establish better judgement, and these levels do not require the team to finish every activity at one level before starting another. You need enough knowledge of the current state to frame credible options. You can build that knowledge around a live decision while improving the wider records. Strategic recommendations at level 4 still need a sound account of the business and its current capabilities.
Assess the support the practice needs
The organisation’s priorities, authority and sponsorship affect how far the practice can contribute. Architects are responsible for the quality of their recommendations, how they explain trade-offs and how they follow through. Leaders shape access to planning, governance authority and attention across business boundaries.
I have worked in environments where leaders treated the practice mainly as documentation and late review, which limited where we could help. I have also worked where architects were brought into planning before budgets were set. Visible executive sponsorship made the practice’s role explicit, and a stated target gave the team a direction to work towards. The contrast reinforced for me how much leadership support affects where a practice can help.
In my experience, practices rarely fail on architectural quality. A practice needs sound architecture, and it gets adopted through people, culture and visible sponsorship. Start with the engagement model: who needs architecture, for which decisions and when. Develop governance around those needs, refining both together.
Act first on what the practice can improve. If the options are sound but the business owner cannot understand them, improve the explanation. If procurement begins before the practice is involved, agree an earlier point of engagement with the people who own the process. If a decision across business units has no clear owner, ask the sponsor to help resolve that responsibility.
Do not wait for perfect organisational readiness. Even from level 1, define the contribution the business needs from the practice and a route towards it. The leader’s job is to set that direction, develop the team and name the support it needs from others.
Next time the CIO asks for a maturity score, explain what it means for the decisions the practice supports. Describe where the team contributes today, support that account with evidence and name the next change and the help it needs. Set a review date and ask whether the change improved the reasoning, options or handling of risk in a real decision. Keep the longer-term ambition in view, but give the team a next step it can carry out today.
A mature architecture provides a foundation for business execution. A mature practice helps the business decide what that foundation must become next. If that is the practice you are building, subscribe to The Foresight-Driven Enterprise, where I explore how architectural thinking and foresight can help you make those decisions.
Save this list for when you want to dive deeper:
Jeanne W. Ross, Peter Weill and David C. Robertson, Enterprise Architecture as Strategy: Creating a Foundation for Business Execution (Harvard Business School Press, 2006). https://cisr.mit.edu/publication/enterprise-architecture-as-strategy
Jeanne W. Ross, Ina M. Sebastian and Cynthia M. Beath, “Digital Design: It’s a Journey”, MIT CISR Research Briefing No. XVI-4, April 2016. https://cisr.mit.edu/publication/2016_0401_DigitalDesign_RossSebastianBeath
Tracy Mayor, “MIT expert recaps 30-plus years of enterprise architecture”, MIT Sloan Ideas Made to Matter, 10 August 2020. https://mitsloan.mit.edu/ideas-made-to-matter/mit-expert-recaps-30-plus-years-enterprise-architecture
Gartner, IT Score for Enterprise Architecture, 12 August 2026. https://www.gartner.com/en/documents/8257557
The Open Group, TOGAF Series Guide: Architecture Maturity Models (G203). https://www.opengroup.org/library/g203
CMMI Institute, “What is CMMI?” https://cmmiinstitute.com/cmmi/intro
Michael Nygard, “Documenting Architecture Decisions”, Cognitect, 15 November 2011. https://cognitect.com/blog/2011/11/15/documenting-architecture-decisions
OECD, Strategic Foresight Toolkit for Resilient Public Policy (OECD Publishing, 2025). https://www.oecd.org/en/publications/foresight-toolkit-for-resilient-public-policy_bcdd9304-en