Engagement triage
Do you actually need an architect?
Teams waste weeks either queuing for a review they never needed, or discovering far too late that they needed one. Ten questions settle it: no engagement, a lightweight review by a single architect, or a formal review board.
The highest trigger wins, and answering “not sure” raises the level rather than lowering it. Nothing is sent anywhere — there is no name or email field, because there is nothing to send.
The three levels
No architecture engagement needed
Local, reversible work on approved technology with no sensitive data and no new integration. Decide it, record it, get on with it.
Proceed now — record the decision locally
One architect, lightweight review
Moderate scope, or something you are genuinely unsure about. A single architect can resolve this without a board, usually inside a week.
Around 5 working days
Formal review board
Enterprise impact, a standards exception, a significant commitment, or something genuinely new to the estate. This needs the board, a paper and a pre-read.
Next scheduled board — paper 48 hours ahead
How the level is decided
- 1. If any answer is a board trigger → board
- 2. If any answer is a single-architect trigger, or any answer is “not sure” → single
- 3. If otherwise → none
The 10 questions
1. New technology or supplier
Does this introduce a product, platform or supplier you do not already run?
Includes SaaS, cloud services, new runtimes, and suppliers not already under contract.
- none — Uses an existing approved tool, with no material architecture change.
- single — Adds a new module or capability to a platform or supplier already approved.
- board — Introduces a product, platform, service or supplier not already in use.
- unsure — Not sure, or not applicable — flag it so an architect can confirm.
Anything new to the estate carries integration, support and exit obligations that outlast the project that bought it.
2. Capability duplication
Could this duplicate a capability that already exists somewhere in the organisation?
Think of the capability, not the product name — content management, case handling, analytics, scheduling, identity.
- none — No overlap with anything we already run.
- single — Possible overlap with a local or team tool — needs confirming.
- board — Introduces a capability that demonstrably exists elsewhere in the organisation.
- unsure — Not sure, or not applicable — flag it so an architect can confirm.
Duplication is the single largest and most avoidable contributor to technical debt, and it is almost always invisible from inside one team.
3. AI and automated decisioning
Does the solution include AI, machine learning or automated decision-making?
Includes embedded vendor AI, copilots, predictive models, language models and agentic workflows.
- none — No AI, machine learning or automated decisioning.
- single — Vendor-embedded AI in an approved platform, used internally for productivity only.
- board — AI that shapes decisions, produces external-facing output, or operates in a regulated process.
- unsure — Not sure, or not applicable — flag it so an architect can confirm.
Automated decisions create explainability, bias and accountability obligations that conventional software does not.
4. Data sensitivity and regulatory exposure
What kind of data does this hold, and where does it sit?
Consider personal data, commercially sensitive data, regulated records, and where the data physically resides.
- none — Non-sensitive internal data only, held where we already hold it.
- single — Personal or commercially sensitive data, within existing approved boundaries.
- board — Regulated records, special-category data, or a new jurisdiction or residency requirement.
- unsure — Not sure, or not applicable — flag it so an architect can confirm.
Data classification and residency are cheap to design in and extremely expensive to retrofit after go-live.
5. Organisational reach
How much of the organisation does this touch?
Count the business units, functions or divisions that would use it or be affected by it.
- none — One team, or one business unit.
- single — Two business units.
- board — Three or more business units, or it creates an organisation-wide capability.
- unsure — Not sure, or not applicable — flag it so an architect can confirm.
A decision contained inside one team belongs to that team. The board exists for the things that cross boundaries.
6. Scale and geography
What is the scale and geographic reach?
Consider user numbers, sites, countries and whether it touches operationally critical groups.
- none — Single site or country, a small user base, no operationally critical groups.
- single — Multiple sites or countries within one region, or a mid-sized user base.
- board — Multi-region or global, a large user base, or it touches operationally critical functions.
- unsure — Not sure, or not applicable — flag it so an architect can confirm.
Scale changes the architecture. A design that works for one site and two hundred users frequently does not survive ten times either.
7. Integration surface
How many systems or integrations does this touch?
Count applications, interfaces and data flows — and note whether any pattern is new to you.
- none — One application, no integration, or a single existing pattern reused.
- single — A handful of applications or integrations, all using approved patterns.
- board — Many systems, a critical platform, a new integration pattern, or integration beyond the organisation.
- unsure — Not sure, or not applicable — flag it so an architect can confirm.
Integration is where most delivery overruns and most operational fragility originate, and it is rarely visible in a business case.
8. Standards deviation
Are you asking for an exception to any published standard?
Includes unapproved technology, bypassing a mandated pattern, or extending a tactical workaround past its agreed end date.
- none — Fully aligned with published standards and approved technology. No exceptions.
- single — A minor deviation with a clear remediation path, or genuine uncertainty about alignment.
- board — A formal exception — unapproved technology, a bypassed pattern, or an extended workaround.
- unsure — Not sure, or not applicable — flag it so an architect can confirm.
Declared deviations are usually accepted. Deviations discovered at the board rarely are, and they cost the team its credibility.
9. Estate displacement
Does this retire, replace or consolidate anything already running?
Any change that removes a system of record, displaces a platform, or merges several tools into one.
- none — An enhancement to something existing. Nothing is displaced.
- single — Retires or replaces a local or team application, or extends the life of one already marked for retirement.
- board — Replaces, consolidates or retires a major business capability or system of record.
- unsure — Not sure, or not applicable — flag it so an architect can confirm.
Displacement is where rationalisation actually happens — and where migration, data retention and cutover risk concentrate.
10. Commitment and reversibility
How large is the commitment, and how easily could you walk away?
Consider contract term, total committed value over the full term, and what it would take to unwind in eighteen months.
- none — No contractual commitment, or a short term that is cheap to reverse.
- single — A multi-year term or renewal of moderate value, unwindable with effort.
- board — A major or multi-year commitment, a significant renewal, or something effectively irreversible once started.
- unsure — Not sure, or not applicable — flag it so an architect can confirm.
Renewals are the most commonly skipped trigger. A multi-year renewal of a long-standing platform locks in yesterday’s architecture by default — review it before signing, not after.
Common questions
- How do I know whether my project needs enterprise architecture involvement?
- Ten triage questions answer it reliably: does it introduce new technology or a new supplier, could it duplicate an existing capability, does it involve AI or automated decisioning, what data does it hold, how many business units does it touch, what is its scale and geography, how large is its integration surface, does it need an exception to a standard, does it displace anything already running, and how large and reversible is the commitment. The highest trigger across those ten sets the level of engagement required.
- What are the levels of architecture engagement?
- Three. No engagement, for local reversible work on approved technology. A lightweight review by a single architect, for moderate scope or genuine uncertainty — typically resolved within a week. And a formal review board, for enterprise impact, standards exceptions, significant or irreversible commitments, or anything genuinely new to the estate.
- What if I am not sure how to answer a question?
- Answering “not sure” raises the engagement level to a lightweight architect review rather than lowering it. Uncertainty is itself a reason to talk to someone, and it is usually the cheapest conversation in the whole process. An unsure answer never reduces the recommended level.
- Does a contract renewal need architecture review?
- Multi-year renewals are the most commonly skipped trigger and one of the most expensive. Renewing a long-standing platform without review locks in the architecture you had when you first bought it, including any capability you have since duplicated elsewhere. Review before signing, not after — once signed, the decision is made for the length of the term.
Thresholds here are deliberately relative rather than absolute. Every organisation has to set its own numbers for cost, user counts and contract value — the structure is what transfers, not the figures.