Ten principles on a slide, a paragraph of rationale under each, reviewed by the board twice a year and opened by nobody else in between. That’s how most architecture principles documents live out their existence. Then a $2M platform RFP goes out the door, gets scored on cost, feature checklist, and vendor references, and the principles document never enters the room. Nobody decided it didn’t matter, and that’s kind of the point, nobody did the work required to make it matter to an evaluator holding a scorecard.
TOGAF actually tells you what that work is. Every architecture principle in the framework has four parts: name, statement, rationale, and implications. The Open Group is explicit that the implications section is where a principle stops being a value statement and starts describing what has to be true, of a system, a contract, a vendor, for compliance to be real. Most teams write the first three parts with care and quietly skip the fourth. I get why, it’s the hardest one and the least fun to write. It’s also the one procurement actually needs.
The part of the principle nobody finishes
A statement like “systems interoperate through documented, versioned interfaces” and a rationale explaining why point-to-point integration creates long-term risk will get nods in any ARB meeting. Neither one tells an RFP scorer what to look for in a response. Implications are the translation layer, they take a value the board already agreed on and turn it into something with a pass/fail line or a point value attached. Skip that translation and the principle stays exactly where it started: true in the abstract, invisible in practice. Every evaluation defaults back to price and feature checklists, because those are the only criteria anyone bothered to operationalize.
The cost of leaving it unfinished
That gap costs more than it used to. Verizon’s 2026 Data Breach Investigations Report found that third-party involvement in breaches now sits at 48% of all breaches, up 60% year over year. A vendor you select today is close to a coin flip’s worth of your future breach exposure. If your security principle lives as “we favor vendors with a strong security posture,” it will lose to a proposal that checks every functional box and undercuts on price, because nobody wrote down what “strong security posture” is worth in points, or where it stops being a deduction and becomes a disqualifier.
And it’s getting easier to skip the step without anyone noticing. Gartner’s Predicts 2026 research on AI in IT sourcing and procurement expects agentic tools to take on more of supplier evaluation and RFP scoring directly. A generic AI-drafted scorecard will reliably cover price, functional fit, and references, because that’s what public RFP templates optimize for. It will not know your organization requires SCIM-based deprovisioning or a documented API covering a minimum share of read and write operations, unless architecture handed over that criterion explicitly. No implications, nothing for procurement to inherit, human or automated.
Running the interoperability principle through it
Take the interoperability principle from above and finish the fourth part. The rationale is easy to write and everyone agrees with it in the room, that part was never the problem. The implications are what protect you three years into the contract, once the vendor is the only party who can touch the integration and every change request routes through their professional services queue. Turned into RFP language, that principle produces criteria like:
- Vendor publishes a versioned REST or GraphQL API covering a stated minimum share of the read and write operations required for this use case, not just a reporting export.
- Real-time event delivery, webhooks or a message bus, is available without a separately purchased middleware add-on.
- Full data export in a documented, non-proprietary format is contractually guaranteed on termination, at a defined SLA, without paid professional services.
The first two get a weight, say 15% of the technical score, scored 0 to 5 against the API coverage the vendor demonstrates live in the demo, not the coverage claimed in the written response (written responses are optimistic by nature, demos are where you find out). The third is a gate, not a deduction. A vendor that won’t commit to exit terms in writing doesn’t score lower, it comes off the shortlist, because that clause is the one thing standing between a bad three-year decision and an unrecoverable one.
Running vendor identity through the same process
Given the third-party breach number above, this is the principle I’d push any architecture team to finish next if it’s still sitting unfinished: vendor platforms inherit enterprise identity and access controls, they don’t maintain a parallel identity model of their own. The rationale writes itself. The implications are what let an evaluator actually score it:
- SSO via SAML or OIDC, federated to the enterprise identity provider, with no local password store as the only login path. Gate, not a score.
- SCIM-based provisioning and deprovisioning, with a stated maximum lag between an HR system change and access revocation. Scored against the vendor’s committed SLA.
- Audit log export to the enterprise SIEM in near real time, retained on the same schedule as your internal log retention standard. Scored on format and latency.
- Sub-processor disclosure and a contractual right to audit. Gate.
Notice the pattern repeats: some implications are pass/fail gates guarding decisions you can’t afford to relitigate, and some are weighted criteria that separate vendors who all clear the gate. Blur that distinction and the whole exercise degrades into unenforceable box-checking. A vendor who scores well on SCIM latency but fails the SSO gate has no business averaging its way onto the shortlist, and if your scoring model lets that happen, the model is broken, not the vendor.
Where this belongs, and where the interoperability example lands
None of this survives as a one-off spreadsheet built for a single RFP. I’ve seen that spreadsheet, we all have, it lives on someone’s laptop and dies with the project. The next platform evaluation starts from a blank page, a different architect translates the same principle into slightly different language, and the ARB spends its meeting re-litigating criteria that should already be settled. I map principle to implication to scored criterion in LeanIX as part of the same fact base that holds the application and capability inventory, so the next vendor evaluation starts from an approved, reusable set of criteria instead of institutional memory and whoever happens to be running the RFP that quarter.
And when a vendor wins despite failing a gated implication, because the functional or commercial case is strong enough that the board accepts the deviation, that decision needs a record with an owner and an expiration date. Same discipline I’ve argued for on ADRs generally, and I’ll keep arguing for it because the alternative is worse than having no principle at all. An accepted exception without a documented owner is just a principle you’ve quietly stopped enforcing.
Go back to the interoperability example one more time. The gate wasn’t “prefers open architecture,” it was “full data export, documented format, no professional services fee, or you’re off the list.” That’s the difference between a principle and a mission statement: a mission statement sounds right in the room, a principle survives being turned into a line item a vendor has to answer with a number, not a sentence a committee nods at once a year.
Photo by Denys Nevozhai on Unsplash