Six Questions for Every Technology Request

Technology requests arrive as “can we buy X?” Answered one at a time, by whoever happens to be free, they produce inconsistent decisions, three tools that do the same job, and evidence nobody can find a year later. The fix is boring on purpose: ask every request the same six questions, before anyone signs anything, and write the answers back onto the request.

First, check that it's real

Before spending architecture time, confirm the request has a sponsor and a budget behind it. A request without either is a wish. Reviewing wishes is a perfectly good way to spend a quarter, if that is what you were hoping to do with it.

The six questions

1. Terminology. What is it, really? The plain technical term, the service model (SaaS, PaaS, on-premises) and the technology domain. The vendor's marketing name is not terminology; it is a mood.
2. Standards. Does an existing standard, approved product or pattern already cover it? If yes, how well does the request conform, and which guardrails come with it? If no, what is the gap, what interim controls apply, and who should write the standard?
3. Technical class. What does it do, technically? Declare one primary technical class, list the tools already in that branch, and give a verdict: net-new or overlap.
4. Business capability. Which business capability does it support, at the lowest level you can map?
5. Fitness. Security, scalability, cost and fit, ending in a recommendation someone could act on.
6. Stakeholders. Who has to review, approve or contribute, even when a standard already exists?

Question three does the heavy lifting

The technical-class question is where duplication gets caught. If the technical tree gives every application exactly one primary class, a new request lands in a specific branch, and that branch already has a list of incumbents. A request in a crowded branch has to explain why the incumbents won't do. A request in an empty branch is net-new, and gets to say so with a straight face.

Declare one class, list the incumbents, and “why not reuse?” asks itself.

Add why and when explicitly

The six questions cover what, how, who and where. Two questions slip through unless you name them:

• Why buy instead of reuse? The overlap verdict from question three is the evidence. A weak why means reuse before buy.
• When? The budget window, and the end-of-life date of any incumbent the request would replace. Timing decides more of these than fit does.

Write the answer where the request lives

Put the findings on the request itself: a short summary with one section per question, a decision and next steps. Decide there which records the request will create — a software product record, a business application, or both — so whoever fulfils it doesn't have to guess. Material decisions earn a decision record of their own; the rest stays on the request, which is where an auditor will look first.

Copy this: the review summary

ARCHITECTURE REVIEW - <technology> (<request id>)
Sponsor and budget: <who> | <yes / no>

1. Terminology: <plain term> | <SaaS/PaaS/IaaS/on-prem> | <domain>
2. Standards: <standard or "none"> | full / partial / non-conformant
   Guardrails: <...>   Gap and interim controls: <...>
3. Technical class: <ONE primary class>
   Incumbents in this branch: <list or "none">
   Verdict: net-new / overlaps <incumbent> because <...>
4. Business capability: <lowest-level capability>
5. Fitness: security <...> | scale <...> | cost <...> | fit <...>
   Recommendation: approve / approve with conditions / reject / defer
6. Stakeholders: <groups that must review or approve>
Why buy, not reuse: <...>
When: budget window <...> | incumbent end of life <...>
Records created: software product yes/no | business application yes/no
Decision and next steps: <...>