Skip to main content
FromNine
Menu

Advice

Architecture decisions that stand up to scrutiny.

We help you settle on a direction before the budget is committed: a clear picture of the systems you run today, options set out with their trade-offs, recorded decisions, and a roadmap your delivery teams can really work to.

For boards, ministries and family business owners in Malta who have to decide on platforms, AI and cloud.

Start a conversationRead our AI Act guide
Architecture & Consulting: the layers of our adviceThree layers shown one behind the other. Top to bottom: a roadmap organised in waves, the decisions with their records, and the goals and present situation on which both rest.01Roadmap organised in waves02Options and recorded decisions03Goals and present situation
  1. 01Reviews of your present systems that bring technical debt and risk into view
  2. 02Options weighed on value, feasibility, risk and total cost, and recorded as ADRs
  3. 03Roadmaps ordered by dependency and business value, with assurance during delivery

01 Common problems

When organisations want a second opinion

  1. 01

    A major decision is close and every option seems sensible

    Platform or bespoke, buy or build, which cloud, which vendor. Each option has a champion, and no one has compared them on equal terms.

  2. 02

    Twenty AI ideas and no portfolio

    Departments put forward use cases. No one has ranked them by value, feasibility and risk, or checked which ones fall into the stricter categories of the AI Act.

  3. 03

    The programme is behind and no one knows why

    Every status report is green, milestones keep slipping, and the board or steering committee wants an independent assessment.

  4. 04

    A call for tenders is due and the specification is not

    The contracting authority knows what it needs in business terms, but not how to write it down so that bidders can respond well.

02 Delivery scope

Our delivery scope

  1. 01 Architecture review

    A structured look at what you run today: applications, data, integrations, infrastructure and contracts. Technical debt becomes visible and is ranked in a risk register. Where your organisation uses ArchiMate and TOGAF, so do we.

    Our work

    • Interviews with architects, system owners and operations staff
    • An inventory of applications and integrations
    • Assessment of technical debt and risk
    • A review of costs and contracts

    What you get

    • An architecture of the present situation
    • A risk register with an owner for each risk
    • Findings presented to those who decide

  2. 02 AI readiness and a portfolio of use cases

    A ranked list of AI use cases, scored for value, feasibility and risk, with a first classification under the EU AI Act and a view for each on whether to build, buy or partner.

    Our work

    • Gathering use cases from every department
    • Scoring for value, readiness of the data and risk
    • A first AI Act classification for each use case
    • An analysis of building, buying or partnering

    What you get

    • A portfolio of use cases in order of priority
    • Three first use cases ready to begin
    • The data and platform conditions they depend on

  3. 03 Target architecture and roadmap

    Choices between Odoo, SAP, Salesforce and custom software, arranged in waves with their dependencies, the total cost of ownership and the organisational change each wave requires.

    Our work

    • A capability map and principles for the target
    • Analysis of options for each domain
    • Total cost of ownership over several years
    • Planning the waves and their dependencies

    What you get

    • A target architecture
    • A roadmap organised in waves
    • Input to the business case for each wave

  4. 04 Cloud strategy and sovereignty

    Analysis of lock-in, decisions on where data is kept, and exit plans, so that your choices of cloud and SaaS can be reversed where it counts.

    Our work

    • Analysis of dependencies and lock-in
    • Classification of data and options for its location
    • Estimating the cost of an exit
    • Contract clauses to go through with procurement

    What you get

    • A sovereignty position for each class of data
    • Exit plans for critical services
    • A paper setting out the cloud strategy

  5. 05 Support for contracting authorities

    Preliminary market consultation, functional specifications and award criteria for calls for tenders published on ePPS. We are open about the rule on prior involvement: under Article 41 of Directive 2014/24/EU and the Public Procurement Regulations (S.L. 601.03) that govern Maltese procedures, helping to prepare a call can affect whether we may later submit a tender, and we settle this with you at the start.

    Our work

    • Analysis of needs and preliminary market consultation
    • Functional and non-functional specifications
    • Award criteria and scoring models
    • Help with clarification requests while the call is open

    What you get

    • A specification ready to publish
    • A framework for evaluating tender submissions
    • A written agreement on any later participation

  6. 06 Decision records and assurance during delivery

    Architecture decision records, design authorities and independent assurance reviews for programmes already under way, so that every decision can be traced and risks come to light early.

    Our work

    • An ADR practice with templates
    • Setting up and facilitating a design authority
    • Assurance reviews at agreed intervals
    • Health checks on programmes in difficulty

    What you get

    • A decision log that is actually used
    • A charter for the design authority
    • Assurance reports with recommendations

03 Architecture

How we arrive at a decision

Our advice follows a single line: from your goals and the present situation, through options measured against criteria agreed in advance, to decision records your design authority approves, and then on to a target architecture and a roadmap organised in waves.

Constraints accompany each step: sovereignty and exit, the AI Act classification, the procurement rules under S.L. 601.03 and the capacity of your own staff.

Layers shown in the diagram

Understand
Business goals, constraints, the systems in place today and the risks they carry.
Decide
Criteria, options, the design authority and the architecture decision records.
Plan
The target architecture, the roadmap in waves and assurance while delivery runs.
Illustrative example

  1. Understand

    • Business goals and constraints
    • Review of the present situation
    • Risk register

  2. Decide

    • Criteria: value, risk and cost
    • Options
    • Design authority
    • Recorded decisions

  3. Plan

    • Target architecture
    • Roadmap organised in waves
    • Assurance during delivery

  4. Constraints

    • Constraints: exit and sovereignty, AI Act classification, procurement under S.L. 601.03
From goals to a roadmap by way of recorded decisions

A method shown for illustration; this is not a client engagement.

Read the diagram as text

The main route leads from business goals and constraints to a review of the present situation, then to options, then to architecture decision records, then to the target architecture and lastly to a roadmap organised in waves.

The review of the present situation yields a risk register. Criteria agreed for value, feasibility, risk and total cost shape the options. The design authority, where your architects take the decision, approves the decision records. Assurance reviews during delivery track the roadmap.

Beneath, a band of constraints covers sovereignty and exit, the AI Act classification and the procurement rules.

04 Choices and limits

Choices and their limits

  • Independence

    Our approach

    We build and operate systems too, on Odoo, SAP and Salesforce among others. When we advise, we compare options on criteria agreed with you before any vendor is considered, and we document why each option received its score.

    Limits and what we rely on

    If you need advice from a firm that will not deliver the work afterwards, say so. We will agree that at the outset, or suggest that you engage a purely advisory firm.

  • Rules and the law

    Our approach

    Our architecture decisions draw on working knowledge of the AI Act, the GDPR, the NIS2 Order and Maltese procurement rules.

    Limits and what we rely on

    We do not give legal advice. Our classifications and readings are input for your legal advisers, who reach the legal conclusion.

  • Roadmaps meet practice

    Our approach

    We order roadmaps by dependency and capacity, and review them when each wave ends.

    Limits and what we rely on

    Every roadmap changes along the way. Its worth lies in the decisions it spells out, so we keep it current through assurance reviews instead of handing it over as a document.

05 Our method

Our method

Brief, structured and based on evidence, with your own architects taking part throughout.

  1. 01

    Settle the question

    What must be decided, by whom and by when, and which criteria carry weight.

    ResultA decision brief

  2. 02

    Collect the evidence

    Interviews, documents, system data and cost figures, enough to support the decision and nothing beyond it.

    ResultAn evidence base and a picture of the present situation

  3. 03

    Weigh the options

    Two to four realistic options scored on the agreed criteria, including their risks and costs.

    ResultAn analysis of the options

  4. 04

    Decide and document

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

    ResultDecision records with a roadmap

  5. 05

    Keep delivery on course

    Regular reviews that check whether delivery still reflects the decisions, and signal when one should be reopened.

    ResultAssurance reports

06 People in control

Who takes the decisions

Our role is to advise. The decisions remain with the people answerable for them.

  • Your design authority gives approval

    Each architecture decision record is approved by your design authority or by the owner you appoint, never by FromNine on its own.

  • Criteria are fixed before the options

    You agree the criteria and their weights before any option is scored, so the result cannot be adjusted afterwards.

  • Disagreement goes on record

    Where stakeholders do not agree, the decision record lists the alternatives and the reasons they were set aside.

07 Illustrative case

An illustrative case

Illustrative example

An ERP choice for a Maltese family business

01Starting point
A family business with companies in distribution, retail and logistics runs an ageing in-house ERP, a separate accounting package and spreadsheets. The next generation wants one system; the founders worry about cost and disruption.
02The system we would put in place
An option analysis comparing a single ERP for all companies, a shared finance core with lighter systems for each company, and integration of what exists, each with its costs, risks and a roadmap in waves.
03Where staff decide
The family board sets the criteria and takes the decision; the managers of each company review the effect on their operations before approval.
04How we would judge success
Total cost of ownership over the planning period, days to close the monthly accounts for the whole group, and number of interfaces left to maintain.

08 By sector

Sector by sector

  • Government & Public Entities

    Target architectures for ministries and their departments in line with Malta Diġitali, specifications for calls for tenders on ePPS, and roadmaps that fit shared Government platforms such as Malta e-ID. More on our work for Government & Public Entities.

  • Financial Services

    Architecture decisions recorded so that licence holders can show them to the MFSA, with ICT third-party risk and exit strategies included from the start.

  • Manufacturing & Industry

    ERP and plant system landscapes simplified for Maltese plants within European groups, with a roadmap that respects the production calendar.

Malta

Decisions measured against Maltese rules

An architecture decision in Malta is tested against several rule sets at once. At EU level there is the AI Act, with the MDIA as lead authority in Malta, and the NIS2 Directive, to which the NIS2 Order (S.L. 460.41) has given effect since 23 January 2026. Maltese procurement runs under the Public Procurement Regulations (S.L. 601.03), with calls published on ePPS, and public bodies must also consider the Interoperable Europe Act’s requirement to assess cross-border interoperability before binding requirements are set.

We turn these constraints into explicit criteria in each option analysis and record how every decision meets them, so the same reasoning can be put before a board, an auditor, the MFSA or a contracting authority.

Common questions on architecture and consulting

How much time does an architecture review need?

That depends on the scope. A focused review of a single domain or decision takes a few weeks; a review of everything you run takes longer. Before we begin, the decision brief sets out the scope, the questions and the timeline.

How can you stay independent when you also deliver?

We make our reasoning open: criteria set before options are looked at, scores documented, alternatives recorded. If you need advice and delivery kept fully apart, we agree in advance not to tender for the delivery, or we recommend another adviser.

Do you prefer Odoo, SAP or Salesforce?

We are a partner of all three (Salesforce Summit Partner, SAP Gold Partner, Odoo Gold Partner) and we also write custom software, so there is no single platform we need to sell. Each suits different situations, and at times the best answer mixes them, for instance SAP for a European group and Odoo for its smaller company in Malta.

Could you help us prepare a call for tenders and then bid for it?

Perhaps, but not as a matter of course. Directive 2014/24/EU permits prior involvement only where the contracting authority makes sure competition is not distorted, for example by giving every bidder the information we prepared. We raise this openly before work starts, and the contracting authority decides.

What is the right starting point for AI?

A portfolio rather than one isolated pilot: gather candidate use cases, score them for value, data readiness and risk, and begin with two or three that are worthwhile, achievable and low enough in risk to learn from. In Malta, the MDIA is the authority to keep in mind for AI Act questions. Our AI Engineering & GenAI teams then build those use cases with evaluation in place before the first release.

Which people will we be working with?

Senior architects who have delivered systems themselves, joined when a question calls for it by specialists drawn from our 2,400+ colleagues, whether in security, data, AI or a particular platform.

Tell us which decision is waiting for you

We will suggest how to frame it, which evidence it calls for and how long a well-founded answer would take.

Start a conversationGovernment & Public Entities