Typical triggers: a system that grew over years has hit a limit and nobody can say exactly which one. A platform decision is due and every vendor is telling you the same thing. A team ships slower than it used to and no one can explain why. Or an acquisition needs to be integrated into an existing landscape.

In those situations we work our way into the specifics instead of pulling a reference architecture off the shelf. What you get is a written recommendation with reasoning, alternatives, effort estimates and risks. Including the recommendation to do nothing, when that is the right answer.

What you get

  • Architecture review

    An assessment of your system landscape with named bottlenecks, risks and dependencies, prioritised by business impact rather than by technical elegance.

  • Technology decisions

    A structured comparison of real options against your criteria, including running costs, availability of people who know the technology, and exit scenarios.

  • Modernisation roadmap

    A path from current to target state in stages that can be funded individually and leave a usable system after each one.

  • Implementation support

    We stay on as a technical counterpart if you want: reviewing architecture decisions and bringing your own team up to speed.

How we work

  1. Frame the question

    Which decision is due, who makes it, by when, and how would you know a year from now that it was right? We do not start without those four answers.

  2. Assess

    Conversations with development, operations and the business, plus a look at code, infrastructure and metrics. We look at what runs, not only at what is documented.

  3. Evaluate options

    Two to four realistic paths, each with effort, risk, running costs and consequences for your team. No recommendation without its downsides spelled out.

  4. Decide and record

    You decide, we record the decision and its reasoning so it still makes sense in two years when the people involved have moved on.

Technologies involved

  • Architecture review along coupling, data flows and operational risk
  • Architecture Decision Records as decision documentation
  • Assessment of build, test and deployment pipelines
  • Infrastructure as Code as the basis for reproducible environments
  • Observability as a precondition for reliable statements about system behaviour

Common questions about this service

How long does an architecture review take?

For a well-bounded system landscape, one to three weeks typically pass between kickoff and written result, depending on how many conversations are needed and how accessible code and operational data are.

Do you consult without doing the implementation?

Yes. The consulting engagement stands on its own and does not oblige you to anything afterwards. The result is written so that another provider or your own team can work from it.

What if your recommendation contradicts a project already under way?

Then we say so, with reasoning and with an estimate of what stopping costs and what continuing costs. Advice that only confirms the existing plan has helped nobody.

Goes well with