A software review, often called an architecture review, can mean anything from a quick look through the code to a months-long study full of diagrams. The format matters less than what you get out of it. A useful review helps the people making decisions understand how their system really works, where it’s fragile, what’s limiting their options, and what to fix first.
Agree on the question first
Every review should start with a clear reason. Is the business about to grow quickly? Has the system been unreliable? Is someone proposing a rebuild? Have you bought a company and inherited its software? Are projects taking far longer than they should?
Without a clear question, a review turns into a list of everything that’s interesting instead of what actually matters. I also agree on the limits up front: which systems are included, who I’ll talk to, and how much time we have. A short review can’t check everything, but it can be honest about what it did and didn’t look at.
Follow real work through the system
Diagrams are helpful, but they show how a system was meant to work, not necessarily how it works today. So I follow a few important everyday jobs from start to finish: an order being placed, a shipment being scanned out, month-end being closed. I look at every system and step involved along the way, and what has to be working for that job to succeed.
I also look beyond the code. How are updates released? Are backups taken, and has anyone actually tried restoring one? Who gets the call when something breaks at 2 a.m.? These everyday habits often decide how reliable a system really is. A tidy diagram doesn’t help much if nobody knows whether the backups work.
Separate facts from guesses
A good review is clear about what it found, what it suspects, and what it couldn’t confirm. “Nothing tries again automatically when the connection drops” is a fact. “Orders might be lost if the connection drops” is a likely risk. “We haven’t tested what happens when the connection drops” is an open question. Keeping these apart stops guesses from being treated as confirmed problems.
Where I can, I back findings up with evidence: a test, a log, a past incident, the relevant piece of code. Where I can’t, I say so. That lets the business decide whether to dig deeper, accept the risk, or fix it.
Put things in order of importance
A long list of problems isn’t a plan. I group issues by what they could cost the business, how likely they are, how urgent they are, and how much they’d cost to fix. Security and data accuracy sit alongside speed, ease of change, and reliability. A bit of messy code may be a real issue, but it matters far less than a backup process nobody has ever tested.
I avoid scoring systems that look precise but aren’t. A plain description of what could happen, how bad it would be, and how sure I am is usually more useful than a number. I also point out where one fix depends on another, so the order of work makes sense.
End with clear next steps
A good final report covers how the system works, the key day-to-day jobs, the strengths worth keeping, the problems in priority order, the options, and a step-by-step plan. Each recommendation should say what it’s meant to achieve and how you’ll know it worked. “Improve monitoring” is too vague. “Get an alert if an order hasn’t reached the warehouse within an hour” is something you can check.
The report should also say what not to do yet. A big rebuild or a move to a new platform may be premature until you understand your data and how things tend to fail. Sometimes the most valuable conclusion is “hold off, and do these three smaller things first.”
What it comes down to
The value of a review is in the decisions it helps you make. You’re not after a perfect diagram or a longer to-do list. You want a shared understanding of your system, an honest view of the risks, and a clear, sensible path to making things better.