Building an Architecture Practice from Level 1

The Preliminary Phase is where the architecture capability itself is defined and the organisation prepared to do architecture: scope of the enterprise, sponsorship and governance, architecture principles, an Architecture Board, the architecture function's roles and skills, tooling and repository, and a tailored ADM. That is the correct content - the question is sequencing under an already-live mandate.

First, before anything else, contain the PMO mandate. It creates demand immediately with no intake or definition of what sign-off means. Define a lightweight architecture compliance gate, a service catalogue (quick consult, review, full architecture engagement) and a single intake route. Without this the team's remaining 30% disappears and everything else on the list becomes undeliverable.

Second, principles and a Board. Three to five principles with statement, rationale and implications, endorsed by the executive committee, plus a Board with terms of reference and decision rights. This is what makes sign-off mean something and gives the function authority rather than the role of an adviser.

Third, repository and a single tooling standard. Not a tool selection exercise - a decision to standardise and a governed place to put models so that reuse replaces the ad-hoc request pattern.

Fourth, roles and skills. A capability plan with role descriptions and a skills matrix baseline, since with four people the allocation of their time is the real constraint.

The judgement is that capability precedes delivery, but an unfunded mandate in flight must be absorbed first or it will consume the capacity you need to build the capability.

A single maturity number is unusable as a target because it hides which dimensions are moving and lets the organisation declare victory on the easy ones. Break it into the dimensions the capability actually has: principles and governance, process (the tailored ADM actually followed), content and repository, people and skills, tooling, stakeholder engagement, and the value the function delivers.

For each, define what level 3 would look like locally, in observable terms. 'Governance at level 3' is not 'we have a Board'; it is 'every significant project passes a compliance review at defined checkpoints, and outcomes are recorded'. Baseline each dimension now - the current picture suggests governance and content are the weakest, while demand management is actively negative.

Measure both leading and lagging indicators:

• Proportion of projects with a signed architecture contract at each gate.
• Median elapsed time to produce a view once requested.
• Reuse: proportion of solution artefacts built from repository content rather than created new.
• Number and age of open standards exceptions.
• Time from decision request to Board decision.

Two cautions for the executive committee. First, maturity models sit alongside TOGAF rather than inside it; TOGAF's Architecture Capability Framework describes the capabilities, but the scoring scheme must be defined locally or it becomes an industry-average conversation. Second, twelve months with four architects will move some dimensions and not others - state which will lag and why, rather than promising a uniform level 3.

The ad-hoc requests are not simply waste. In an organisation with no intake process they are the only channel through which project managers reach the architecture function, and refusing them destroys the relationships the team will need to make a compliance gate work at all. They are also the raw evidence for what the repository should contain.

The response is classification, not refusal. Triage each request: is this a decision that needs architecture judgement, a view that already should exist and can be reused, or a drawing task that belongs to the project? For the third category, publish templates and a self-service convention so the request disappears. For the second, the answer is to populate the repository so the second identical request costs nothing - measure this, because the repetition rate is the clearest signal of whether the repository is working.

For the first category, formalise it into a service with a defined turnaround, an owner and a named stakeholder, so it stops being informal. Tier the services and publish the tiers; a two-week architecture engagement and a two-hour consultation should not arrive through the same channel.

Finally, map the stakeholders you are actually serving and prioritise deliberately. The four architects cannot serve every project manager equally, and pretending otherwise means the loudest requester sets the function's agenda for another year. Publishing the intake and the tiers is what allows the inevitable refusals to be explained as a policy rather than as personal unhelpfulness.