Start with the business function
My background includes more than 20 years in IT, with software, hardware, architecture and development leadership. That breadth shapes my approach: I examine how the parts of a system work together. Begin with the business function, the information it uses and the people who depend on it. Identify where decisions and responsibilities pass between groups.
Follow changes through development
I recommend tracing requirements into design, implementation, tests, release and support. Ask who approves changes, what is checked and how operators know which version is running. Review relevant build and deployment controls alongside application behavior. A finding should explain the path by which a business requirement becomes a technical decision and how that decision is maintained.
Connect architecture and infrastructure
Map identities, interfaces, data flows and dependencies. Consider the relationships between software, hardware and the operating environment. Check the assumptions behind storage, capacity and network behavior against the agreed evidence. For microservices or a monolith, establish ownership of interfaces and data. For high-load and Big Data systems, include operational constraints and the consequences of unavailable dependencies in the review questions.
Keep the conclusions within the scope
A whole-system perspective helps choose the right questions. The depth of examination still needs an agreed scope, relevant evidence and visible limitations. I conduct all consulting myself and connect technical findings to the decisions the client needs to make. My recommendation is to present dependencies and uncertainty clearly, so the next action has an owner and a reason. Record the assumptions behind each conclusion.