Independent by design
The review is contracted separately from follow-on delivery. You receive the evidence and recommendations before deciding whether to implement them internally, with us, or with another partner.
Architecture Review
You know the system is constraining delivery, but stakeholders disagree on what the evidence supports. Before committing to a modernisation, platform, or microservices programme, CTOs and engineering managers need an independent view of the Java and Spring estate and a prioritised roadmap.
Fixed scope, fixed price, two-week turnaround.
The problem we are usually called about
Architecture decisions become expensive when stakeholders disagree on what the evidence supports.
-
You cannot see the system clearly
The people closest to the code hold essential context. An external review adds distance, tests competing explanations against evidence, and records uncertainty rather than smoothing it away.
-
You know something is wrong
Changes are slow, releases are risky, and every team has a different theory. The hard question is not whether there is technical debt. It is what to fix first.
-
A big decision is due
A modernisation, platform investment, or move to microservices is being discussed. The decision should follow evidence and operational constraints.
-
The investment needs a second opinion
Before funding a rebuild, acquisition, or major transformation, you want due diligence on the estate you already have. A two-week review tests key assumptions before a multi-year commitment.
What we review
We inspect the architecture as a working system, not as a diagram in isolation.
-
Boundaries and coupling
Module boundaries, dependency direction, change coupling, and whether the current shape supports independent work or release.
-
Domain model integrity
Where business rules live, where they leak, and whether the model reflects the language and invariants the business actually uses.
-
Test strategy and feedback
Test strategy and coverage quality, not just a percentage: feedback speed, meaningful boundaries, brittle tests, and unprotected risk.
-
Build and deployment
Pipeline design, release friction, environment drift, deployment safety, and the path from a commit to a monitored production change.
-
Dependencies and upgrades
Framework and library risk, upgrade paths, unsupported versions, transitive exposure, and the cost of staying where you are.
-
Operations and performance
Observability, failure behaviour, latency, throughput, resource profile, and whether production evidence can guide the next decision.
-
Security posture
Trust boundaries, secrets, authorisation, dependency exposure, data handling, and the controls that matter for your actual system.
-
AI-readiness
Data and domain boundaries, integration points, testability, observability, and the constraints that determine whether AI work can reach production with appropriate controls. See our agentic AI engineering service.
How the engagement runs
Four focused steps. Two weeks typical. You can stop after any stage with something useful in hand.
-
Scope
Half a day to agree which systems we review, which questions matter, and what a useful answer looks like. We fix the scope and price before the evidence work starts.
-
Gather evidence
We read the relevant code, pipelines, metrics, and operational material. We also interview engineers, technical leads, and product stakeholders so the report includes context, not just static analysis.
-
Analyse and report
We analyse boundaries, risks, and trade-offs, then write findings ranked by risk and effort. Each finding links to evidence and a practical next move.
-
Read out and hand over the roadmap
We walk the team and stakeholders through the report in a workshop, answer hard questions, and agree which prioritised actions belong in the next planning cycle.
What you get
A decision aid your engineering organisation can use in its next planning cycle.
- A written report with findings ranked by risk and effort
- Evidence and reasoning behind each finding, including acknowledged uncertainty
- A prioritised roadmap with concrete actions for the next sprint and the next quarter
- Clear trade-offs for modernisation, modular monolith, and microservices options
- A workshop with engineers, technical leads, product, and executive stakeholders
- An evidence-based view of the estate’s AI-readiness and the constraints to address first
- The report, roadmap, and reasoning handed over for your team to use
Who this is for
-
CTOs and engineering managers
You are responsible for Java and Spring systems in production and need a defensible view before committing budget and people to a major change.
-
Chief architects and platform teams
You need an external pair of eyes on coupling, reliability, upgrade risk, and the trade-off between a modular monolith and microservices.
-
Teams preparing for AI
You want to adopt AI without adding an ungoverned side stack. The review identifies the boundaries, controls, and operating gaps that should be addressed before delivery.
-
Leaders doing due diligence
You are assessing a platform before an acquisition, transformation, or large budget decision and want facts before the commitment.
Why us
The review is useful because it is independent, senior, and specific to the technology and decisions in front of you.
Senior eyes on the code
Patrick Baumgartner brings more than 20 years of enterprise Java experience and works directly with the source, pipelines, operational evidence, and stakeholder interviews.
Specific to Spring systems
We understand Spring, Spring Boot, Spring Modulith, and the real trade-offs between a modular monolith and microservices. We do not force a fashionable target architecture.
Teaching makes the advice usable
Our credentials include Oracle ACE, Microsoft MVP, VMware Certified Spring Instructor, Spring Certified Professional, ZHAW lecturer, and JUG Switzerland board member. We explain the reasoning so your team can act on it.
Meet the full team. If Spring Modulith is part of your direction, our Spring Modulith training can help your team build the skills to carry the roadmap forward. We also offer developer coaching when the constraint is how the team works.
Frequently Asked Questions
How long does an architecture review take?
Two weeks is typical from the initial scope session to the readout workshop. The review itself is fixed-scope, so we agree the systems, questions, and evidence before we start.
Do you need access to our source code?
Yes. We need read access to the relevant source repositories, build and deployment pipelines, and selected operational evidence. An NDA is fine.
What if we disagree with the findings?
That is part of the readout. We show the evidence behind each finding, test our assumptions with your engineers and stakeholders, and record dissent rather than smoothing it away.
Do you do the remediation work too?
Yes, when it is useful and you choose to continue. We contract the review separately from follow-on delivery, so you receive the findings before making an implementation decision.
Can you review a system that is not Java?
Yes, for systems adjacent to a Java estate or where the architectural questions are language-independent. Our deepest expertise is production Java, Spring, and Spring Boot systems.
What does it cost?
Fixed scope, fixed price. We confirm the scope and price before the review starts.
Ready for an independent view?
Book 30 minutes with Patrick. Bring the system, the decision in front of you, and the question that remains unresolved. We will assess whether a review is useful and what it should cover.