When the business decides without architecture: it is not a question of power, it is a question of mandate

The message arrives between two other topics. The sales division has chosen an online customer relationship management solution; the contract is signed, and roll-out starts in a few weeks. Architecture is asked to “see how to connect it” to the customer master data, to billing and to the directory. Nobody asked for its opinion on the choice. It is being asked to make the choice work.

Within a few days, the architect finds what the file never examined. The tool carries its own notion of a customer, which does not match the one in the master data. The data will be hosted outside the perimeter set by company policy. The contract’s exit terms say nothing about returning historical records. And another division already uses a tool that covers part of the same need. The architect raises all this. The reply, politely, is that the decision has been made, that the business has its budget, and that architecture is there to support, not to replay the game.

The most common reading among architects is familiar: the business does not understand what architecture is for, it has too much power, and senior management should impose a mandatory checkpoint. That reading is understandable. It is also almost always sterile. The business’s power is not the problem: it is legitimate, since the business carries the strategy, the budget and the results. The problem is that the architectural consequences of its decisions are visible nowhere at the moment it decides, and that nobody answers for them once the decision is made. The business does not bypass architecture; it decides in places and at moments where architecture is not present. What is missing is not power. It is a mandate.

A rational decision, seen from the business

Start by taking the decision-maker’s point of view seriously, because it is coherent.

The sales director is assessed on results with deadlines. The need is real, often long-standing, sometimes already promised upwards. The chosen solution meets it, the vendor is available, the spend falls within the director’s own budget. Everything in that environment rewards a fast decision.

The architectural consequences, meanwhile, have three properties that make them invisible from that position. They are deferred: the gap between two definitions of a customer will cost nothing until the first data reconciliation, the following year. They are paid by others: IT will maintain the interface, finance will reconcile two revenue figures, compliance will answer for the hosting. They are diffuse: none looks decisive on its own, and it is their accumulation, decision after decision, that sets the information system in stone.

Against that, architecture often shows up in the worst possible conditions: after the decision, as a reviewer, and with a vocabulary — standards, compliance with the reference framework, target architecture — that sounds, from the business side, like delay and cost. It asks to be consulted on a decision whose risk and benefit it does not share. It is hardly surprising that people do without it.

It is the same asymmetry that prevents organisations from switching applications off or funding technical debt: a benefit that is concentrated, immediate and owned by someone; a cost that is dispersed, deferred and owned by nobody.

Where decisions are actually made

The second observation is more structural. In most organisations, the decisions that shape the information system most durably do not pass through the circuit where architecture is installed.

They are made in the budget round, when a division is granted an envelope for “a tool”. They are made in the procurement circuit, when a vendor is selected and a contract negotiated. Sometimes they are made through a simple online subscription, below the threshold that would have triggered a tender. The project — the only circuit where architecture usually has a seat, because it reports into IT — starts only afterwards.

This is where the organisation chart matters. An architecture function that reports into IT sees projects; it sees neither budget decisions nor contractual commitments, which belong to other divisions. It can be competent, listened to and well equipped, and still arrive, systematically, after the decisions that count. We described the same mechanism for tenders: architecture is called in when only the implementation is left to decide.

One clarification avoids a false debate: no reporting line is right in itself. Placed alongside the executive committee or the strategy function, architecture sees the trade-offs, but drifts away from how systems really work and risks becoming a presentation exercise. Placed within IT, it knows the systems, but only sees decisions once they have turned into projects. The useful question is therefore not “where should architecture report?” but “at which decision points must it be present, whatever its reporting line?”.

Why asking for power does not work

The most frequent response to this situation is to ask for more authority: a mandatory opinion, a veto, a committee through which every investment must pass. It fails for three reasons.

It runs into a higher legitimacy. A business unit that carries a result and a budget will not accept being blocked for long by a function that carries neither. The first disagreement escalated to the executive committee is almost always settled in the business’s favour — and each lost arbitration weakens the next one.

It moves decisions instead of informing them. A mandatory checkpoint perceived as an obstacle teaches decision-makers to avoid it: splitting the spend below the threshold, calling the tool a “pilot”, submitting the file once the contract is signed. Governance then sees fewer decisions than before, not more. It is the effect of the committee that says no, facing a counterpart far more powerful than a project team.

It confuses the right to decide with responsibility for consequences. A veto gives architecture the power to prevent, without making it accountable for what preventing costs the business. It does not solve the underlying problem: it only moves the side on which consequences remain unowned.

The mandate: three things in writing

A mandate is not power. It is an explicit delegation, given by senior management, that states what architecture examines, at what moment, and with what effect. It comes down to three elements.

The decisions that trigger an examination. Not “every IT investment”, a formula that guarantees both congestion and avoidance, but a short list of criteria, each of which signals a lasting consequence: a new tool holding reference data — customer, product, third party; data leaving the controlled hosting perimeter; a multi-year contractual commitment, or one that is hard to unwind; an overlap with a business capability already supported elsewhere. Below those criteria, the business decides alone, and that is exactly as it should be.

The moment of examination. The mandate places architecture where money is committed — at the budget decision, then before a vendor is chosen — and not at project launch. It is a change of circuit more than an added workload: an examination carried out at the right moment is shorter, because it still concerns options rather than repairs.

The effect of the examination. This is the decisive point, and it is not a veto. The examination produces a short document setting out the consequences of the decision being considered; the decision-maker reads it, and decides. They can decide against architecture’s opinion. They cannot decide without that opinion having been given.

Speaking in consequences, not in compliance

A mandate is useless if what is examined remains unreadable to the decision-maker. “Not compliant with the reference framework” is not information for a sales director; it is an objection.

A useful examination is phrased in the terms the business already uses to make trade-offs. Capabilities: does this decision create a second tool for a capability that is already supported, and who will arbitrate between the two? The business capability map is the natural medium for that conversation, because it speaks the language of the activity rather than that of applications. Total cost: not the subscription price, but what integration, data reconciliation, operations and exit will cost — what total cost of ownership actually covers. Reversibility: what would it take to go back, and does the contract allow it? Risk: which data, hosted where, under which obligations.

Phrased this way, consequences stop being an architect’s opinion. They become part of the decision file, on the same footing as budget and schedule, and the decision-maker weighs them with the same tools as everything else.

There is a symmetrical discipline, less comfortable for architecture: examine quickly, and be able to say yes. A function that takes weeks to give an opinion, or whose every opinion ends with a reservation, recreates the bottleneck it is accused of. The mandate binds architecture too — to a turnaround time, and to keeping the depth of an examination proportionate to what is at stake.

The right to override, provided it is signed

That leaves the most frequent and most frustrating case: the business knows the consequences, and decides anyway. That is its right. Any mechanism that tried to stop it would fail for the reasons described above.

What can be required, on the other hand, is that the decision has an owner for its consequences. In practice, an explicit exception: what was decided, what had been flagged, who carries the responsibility, and on what date the situation will be reviewed. It is signed by the decision-maker, not by the architect, and recorded in the same register as other architecture decisions.

The gesture looks administrative. It nonetheless changes two things. First, it gives the opinion weight without creating a veto: signing that you were warned about a data hosting risk is not a neutral act, and many decisions are amended at precisely that moment — not because they were blocked, but because the decision-maker takes the measure of what they are agreeing to carry. Second, it makes consequences addressable: the day reconciling two customer master records starts to cost money, it is clear whom the question is for, and it does not fall to IT by default.

The review date is the most important part, for a reason that recurs throughout architecture: an exception without an end date becomes the rule. What was conceded to hold a schedule must be reviewed, then either regularised or knowingly accepted again.

What architecture has to hold

The mandate comes from senior management; architecture cannot award it to itself. It can, however, make it possible, and then make it hold.

Proposing the mandate rather than demanding it. A short list of criteria, a turnaround time, an exception format: a mechanism an executive committee can review and approve in a single meeting stands a far better chance of existing than a general request for a mandatory checkpoint.

Plugging into existing circuits. Budget rounds, the procurement process and approval of online subscriptions already exist. Adding a question to a form everyone already fills in is better than creating yet another body.

Keeping the exception register, with owners and review dates, and presenting it regularly to those who gave the mandate. That register, far more than the opinions given, is what makes governance visible at the level where it is decided.

Measuring its own contribution, not just other people’s deviations. Useful indicators cover both sides: what share of commitments meeting the criteria was examined before signature; how many projects architecture discovered only when an integration was requested; how many exceptions have an owner and a review date, and how many reviews actually took place; how long an examination takes; and how many opinions led to a decision being changed without any blocking being needed.

A mandate is given, not taken

None of the above works without a condition architecture does not control: that senior management wants to know. In an organisation where the executive committee deliberately prefers divisional autonomy to overall coherence, and owns that choice, no method can substitute for it. It is better to acknowledge that clearly than to exhaust yourself compensating for it with committees.

That case is less common than it seems, though. Far more often, senior management was never put in a position to choose: the consequences were written down nowhere, decisions were made in separate circuits, and architecture asked for power instead of proposing a mandate. Putting the question clearly — who decides, who is consulted, who answers for the consequences — is already architecture work. It is probably the first piece of it.