Technology Architecture Review Checklist
A checklist for reviewing a technology architecture: what depends on what, how change reaches production, how it recovers, who owns it and what it costs to leave.
Free to download. You do not need to share an email address.
What the review covers, area by area
- Dependencies and boundaries: a current map with an owner, what crosses each boundary, and the outside suppliers that would stop the business
- Data and integration: one system of record for each kind of data, a rule when systems disagree, and integrations with owners
- Change and release: the same steps every time, a release that can be reversed, and an emergency route reviewed afterward
- Reliability and recovery: a restore proved from backup into a clean environment, and recovery steps someone other than the author has followed
- Security basics: access by person and role, secrets in a managed place, and logs someone can read
- Ownership and knowledge: decisions written down, named owners, and debt recorded and ranked
- Cost and exit: what each major system costs to run and what it would cost to leave
- Questions to put to the team in every area, and a review record with a line for each finding, its cost if it goes wrong, its owner and the decision
How to run a review with it
- 01
Review with the people who run the systems
Ask to be shown the evidence. A statement is true when someone other than its author can demonstrate it today.
- 02
Write a line for every box you cannot tick
Give each a cost if it goes wrong, an owner and a date for the decision.
- 03
Read the questions out, not only the statements
A statement lets a good deal pass. The questions ask which system nobody would dare to change and which integration nobody could repair.
Limits
A review shows what was reported to you, not what is true of every system. This checklist asks questions. It does not test any system, and it is not a security assessment or a penetration test.
On this page
What should you ask to see, and what does a gap sound like?
Every statement in the checklist can be answered with an artifact or with a shrug. The artifact is the evidence. The table gives one request for each area and the answer that tells you the box stays empty.
| Area | Ask to see | A gap sounds like |
|---|---|---|
| Dependencies and boundaries | The dependency map, and the list of suppliers the business could not run without | Nobody has a current picture, and we find out when something breaks |
| Data and integration | The rule for which system wins, and the log of differences it has found | Finance reconciles it by hand at month end |
| Change and release | The last release that had to be reversed, and how long that took | We batch changes because each one needs a meeting |
| Reliability and recovery | The record of the last restore into a clean environment | The backups run, and nobody has restored one |
| Security basics | Who can change production without a second person seeing it | A leaver's access lingers until someone notices |
| Ownership and knowledge | Where decisions are recorded, and who could run the system if its expert left | Only one engineer knows how that part works |
| Cost and exit | A recent estimate of moving off the largest supplier | We have never costed leaving |
What follows a review?
The Technology and Architecture Risk Assessment on this site scores the same ground as a quick reading. The Technical Debt Register records what the review finds and ranks it. Where the findings need an independent view, our technology and architecture advisory begins from the review record.
What do people ask before running an architecture review?
Who should be in the room for a technology architecture review?
The people who run the systems, not only the people who describe them. Ask to be shown the evidence, because a statement is true only when someone other than its author can demonstrate it today. Read the questions to the team as well as the statements.
What should I do with the boxes we cannot tick?
Write a line in the review record for each one, with its cost if it goes wrong, an owner and a date for the decision. The record becomes your list of findings, which a technical debt register can rank and an outside adviser can start from.
Does the checklist test whether our systems are secure?
No. It asks questions and tests no system. A review shows what was reported to you, not what is true of every system. The checklist covers security basics only, and it is not a security assessment or a penetration test.
Which item should I ask to see first?
The restore into a clean environment. It is the easiest statement to assume and the costliest to get wrong, because a backup nobody has restored is a hope held in storage. Ask for the record of the last restore and see who can produce it.
Reviewing a real architecture?
Describe what you are weighing in a few lines. A senior practitioner replies with a suggested first conversation.