Skip to main content
FromNine
Menu

Advice

Architecture decisions you can defend.

We help you choose the right path before you commit budget: a clear view of your current estate, options with their trade-offs, decision records and a roadmap that delivery teams can actually follow.

For leadership teams deciding on platforms, AI and cloud for an organisation that operates in several European countries.

Architecture & Consulting: capability stackThree layers stacked in depth. From top to bottom: the roadmap in waves, the decisions and their records, and the understanding of goals and current state they rest on.01Roadmap in waves02Options and decision records03Goals and current state
  1. 01Current-state reviews that make technical debt and risk visible
  2. 02Options compared on value, feasibility, risk and total cost, recorded as ADRs
  3. 03Roadmaps sequenced by dependency and business value, with delivery assurance

01 Problems

When teams ask for a second opinion

  1. 01

    A large decision is due and the options all look reasonable

    Platform, build or buy, which cloud, which vendor. Each option has an advocate, and nobody has compared them on the same terms.

  2. 02

    Twenty AI ideas, no portfolio

    Departments propose use cases. Nobody has ranked them by value, feasibility and risk, or checked which fall under the AI Act’s stricter categories.

  3. 03

    The programme is late and nobody can say why

    Status reports are green, milestones slip, and the steering committee wants an independent view.

  4. 04

    A tender is coming and the specification is not ready

    The organisation knows what it needs in business terms but not how to specify it so the market can answer well.

02 Delivery ledger

What we deliver

  1. 01 Architecture assessment

    A structured review of your current estate: applications, data, integrations, infrastructure and contracts. Technical debt is made visible and ranked in a risk register. We use ArchiMate and TOGAF where your organisation does.

    What we do

    • Interviews with architects, owners and operators
    • Application and integration inventory
    • Technical debt and risk assessment
    • Cost and contract review

    What you receive

    • Current-state architecture
    • Risk register with owners
    • Findings presented to decision makers
  2. 02 AI readiness and use-case portfolio

    A ranked portfolio of AI use cases, scored on value, feasibility and risk, with an initial EU AI Act classification and a build, buy or partner view for each.

    What we do

    • Use-case collection across departments
    • Scoring on value, data readiness and risk
    • Initial AI Act classification per use case
    • Build, buy or partner analysis

    What you receive

    • Prioritised use-case portfolio
    • First three use cases ready to start
    • Data and platform prerequisites
  3. 03 Target architecture and roadmap

    Platform choices across Salesforce, SAP, Odoo and custom software, sequenced into waves with dependencies, total cost of ownership and the organisational changes each wave needs.

    What we do

    • Capability map and target principles
    • Option analysis per domain
    • Total cost of ownership over several years
    • Wave planning with dependencies

    What you receive

    • Target architecture
    • Roadmap in waves
    • Business case input per wave
  4. 04 Sovereignty and cloud strategy

    Lock-in analysis, data residency decisions and exit plans, so your cloud and SaaS choices stay reversible where it matters.

    What we do

    • Dependency and lock-in analysis
    • Data classification and residency options
    • Exit cost estimation
    • Contract clauses to review with procurement

    What you receive

    • Sovereignty position per data class
    • Exit plans for critical services
    • Cloud strategy paper
  5. 05 Procurement support for public bodies

    Market consultation, functional specifications and evaluation criteria. We are open about prior-involvement rules: under Directive 2014/24/EU article 41, preparing a tender can affect whether we may bid on it later, and we agree that upfront.

    What we do

    • Needs analysis and market consultation
    • Functional and non-functional specifications
    • Evaluation criteria and scoring models
    • Clarification support during the tender

    What you receive

    • Specification ready for publication
    • Evaluation framework
    • Written agreement on later participation
  6. 06 Decision records and delivery assurance

    Architecture decision records, design authorities and independent assurance reviews for running programmes, so decisions are traceable and risks surface early.

    What we do

    • ADR practice and templates
    • Design authority set-up and facilitation
    • Periodic assurance reviews
    • Health checks on troubled programmes

    What you receive

    • Decision log in use
    • Design authority charter
    • Assurance reports with recommendations

03 Architecture

How a decision is built

Our advisory work follows one line: from your goals and the current state, through options weighed against agreed criteria, to decision records your design authority approves, and from there to a target architecture and a roadmap in waves.

Constraints run underneath every step: sovereignty and exit, AI Act classification, procurement rules and the capacity of your own teams.

Layers in the drawing

Understand
Business goals, constraints, the current estate and its risks.
Decide
Criteria, options, the design authority and architecture decision records.
Plan
Target architecture, the roadmap in waves and assurance during delivery.
Illustrative example
  1. Understand

    • Business goals and constraints
    • Current-state review
    • Risk register
  2. Decide

    • Criteria: value, risk, cost
    • Options
    • Design authority
    • Decision records
  3. Plan

    • Target architecture
    • Roadmap in waves
    • Delivery assurance
  4. Constraints

    • Constraints: sovereignty and exit, AI Act classification, procurement rules
From goals to a roadmap through recorded decisions

Illustrative method, not a client engagement.

Read the diagram as text

The main route runs from business goals and constraints to a current-state review, then to options, then to architecture decision records, then to the target architecture and finally to a roadmap in waves.

The current-state review produces a risk register. Agreed criteria on value, feasibility, risk and total cost shape the options. The design authority, where your architects decide, approves the decision records. Delivery assurance reviews follow the roadmap.

A band of constraints underneath covers sovereignty and exit, AI Act classification and procurement rules.

04 Considerations and limits

Considerations and limits

  • Independence

    How we handle it

    We also build and run systems, including on Salesforce, SAP and Odoo. In advisory work we compare options on criteria agreed with you before we look at vendors, and we document why each option scored as it did.

    Limits and dependencies

    If you need advice from a party that will not deliver afterwards, tell us. We will agree that upfront, or recommend that you choose a purely advisory firm.

  • Regulation and law

    How we handle it

    We bring working knowledge of the AI Act, GDPR, NIS2 and procurement law into architecture decisions.

    Limits and dependencies

    We do not give legal advice. Classifications and interpretations are inputs for your counsel, who makes the legal assessment.

  • Roadmaps meet reality

    How we handle it

    Roadmaps are sequenced by dependency and capacity, and reviewed at the end of each wave.

    Limits and dependencies

    No roadmap survives unchanged. Its value is in the decisions it makes explicit, which is why we keep it alive through assurance reviews rather than hand it over as a document.

05 How we work

How we work

Short, structured and evidence-based, with your architects in the room.

  1. 01

    Agree the question

    What has to be decided, by whom, by when, and which criteria count.

    OutputDecision brief

  2. 02

    Gather evidence

    Interviews, documents, system data and cost figures, enough to support the decision and no more.

    OutputEvidence base and current-state view

  3. 03

    Compare options

    Two to four realistic options scored against the agreed criteria, with risks and costs.

    OutputOption analysis

  4. 04

    Decide and record

    Your design authority decides; we write the decision record and the roadmap that follows from it.

    OutputDecision records and roadmap

  5. 05

    Assure delivery

    Periodic reviews that check whether delivery still matches the decisions, and flag when a decision should be revisited.

    OutputAssurance reports

06 Human control

Who decides

We advise. Decisions stay with the people accountable for them.

  • Your design authority approves

    Every architecture decision record is approved by your design authority or the owner you name, never by us alone.

  • Criteria come before options

    You agree the scoring criteria and their weights before options are scored, so the outcome cannot be tuned afterwards.

  • Dissent is recorded

    Where stakeholders disagree, the decision record shows the alternatives and the reasons they were not chosen.

07 Example

An illustrative example

Illustrative example

One ERP direction for a group with subsidiaries in five countries

01Situation
A group runs four ERP systems across five countries after acquisitions. Each country wants to keep its own; the board wants one view of finance and supply.
02What we would build
An option analysis comparing one global ERP, a two-tier model with a group core and lighter local systems, and integration only, each with costs, risks and a roadmap in waves.
03Where people decide
The group design authority sets the criteria and makes the decision; country leads review the impact on their operations before approval.
04What we would measure
Total cost of ownership over the planning horizon, time to consolidated monthly close, and number of interfaces to maintain.

08 Sector lens

In your sector

  • Target architectures for digital government, tender specifications, and roadmaps that align with national interoperability frameworks. Read more about our public sector work.

  • Architecture decisions documented for supervisors, with ICT third-party risk and exit strategies built in.

  • ERP and plant system landscapes rationalised across sites, with a roadmap that respects production calendars.

International

Decisions that hold across jurisdictions

Architecture decisions for a European organisation are tested against several sets of rules at once: the AI Act and NIS2 at EU level, national transpositions and procurement law, and, for public bodies, the Interoperable Europe Act’s expectation that cross-border interoperability is assessed before binding requirements are set.

We make those constraints explicit criteria in every option analysis and record how each decision meets them, so the same reasoning can be presented to a board, an auditor or a supervisor in any of the countries involved.

Questions about architecture and consulting

How long does an architecture assessment take?

It depends on scope. A focused review of one domain or one decision is a matter of weeks; a full estate review takes longer. We agree scope, questions and timeline in the decision brief before we start.

Can you be independent if you also deliver?

We make our reasoning transparent: criteria agreed before options, scores documented, alternatives recorded. If you need full separation between advice and delivery, we agree upfront that we will not bid for the delivery, or we tell you to choose another adviser.

Do you favour Salesforce, SAP or Odoo?

We hold partner status with all three (Salesforce Summit Partner, SAP Gold Partner, Odoo Gold Partner), and we build custom software too, so we have no single platform to sell. Each fits different situations, and sometimes the right answer combines them, for example SAP at group level and Odoo in smaller subsidiaries.

Can you help us prepare a tender and then bid on it?

Possibly, but not automatically. Directive 2014/24/EU allows prior involvement only when the contracting authority ensures competition is not distorted, for example by sharing the information we produced. We discuss this openly before we start, and the authority decides.

Where should we start with AI?

With a portfolio, not a single pilot: collect candidate use cases, score them on value, data readiness and risk, and start with two or three that are valuable, feasible and low enough in risk to learn from. Our AI Engineering & GenAI teams then build them with evaluation in place before the first release.

Who will we work with?

Senior architects with delivery experience, supported by specialists from our 2,400+ colleagues where a question needs them: security, data, AI or a specific platform.

Tell us the decision on your desk

We will propose how to frame it, what evidence it needs and how long a sound answer would take.