Every engagement starts with a map of the system as it actually is. Architecture before implementation never means instead of it.
When a review is useful
A review is useful when a team needs a clearer view of a running system before making a difficult platform decision. It establishes shared evidence about the system as it operates now and makes the questions behind that decision visible.
How the review proceeds
Architecture done at a distance from the code drifts into fiction. I work from the running system, document open questions, and make the architectural position explicit.
What the review produces
The useful result is not a diagram for its own sake. It is a current-system map and a documented position on the decisions that matter. Open questions remain explicit rather than being papered over.
From review to action
The architectural position stays close enough to implementation for the team to act on it. Evidence from the running system informs the decision, and the resulting position remains available to the people responsible for carrying it forward.
Relevant work
An event-driven AWS estate of some forty Lambda services was consolidated around a small set of platform services, shared deployment and observability practice, and a decision record for every seam kept or removed. Cold-start latency halved, and incident diagnosis moved from mornings to minutes.
An external API platform introduced consumer authentication, an explicit versioning policy, and a developer portal treated as a product. The first external integration shipped within a quarter, built by a partner team using only the documentation.
Working with the team
I work independently, usually embedded with an in-house team. The map, documented position, and open questions stay with the team. The measure of an engagement is what the team can do after it ends.
Based in Tauranga
I am an independent solution architect and senior developer based in Tauranga, New Zealand.