Skip to main content
FromNine
Menu

AI & data

Data you can base decisions and AI on.

We build data platforms in which every dataset has an owner, a contract and a measured quality. Reporting, daily operations and AI then all work from the same figures, and everyone can trust them.

For Maltese groups, licence holders and public entities that need one reliable view of data held in many systems.

Data & Analytics: the layers we buildFour layers shown one behind the other. Top to bottom: reporting and AI that use the data, owned data products with contracts, the lakehouse layers where data is cleaned and aligned, and governance covering everything.01Reporting and AI02Owned data products03Layers of the lakehouse04Lineage and governance
  1. 01Data products with a named owner, a contract and automated quality checks
  2. 02Governance that applies purpose limitation and retention, beyond keeping a catalogue
  3. 03A single set of KPI definitions approved by both the business and IT

01 Common problems

Data problems most organisations recognise

Many disappointing AI projects turn out, on closer inspection, to be data projects.

  1. 01

    Three reports giving three figures

    Finance, operations and the board each work out revenue or caseload in their own way. Every meeting opens with reconciling numbers rather than taking decisions.

  2. 02

    Data without an owner never gets fixed

    Mistakes surface further down the line, get patched in a spreadsheet and reappear the following month.

  3. 03

    Your AI team mostly searches for data

    Each use case opens with weeks of access requests, extracts and cleaning, and the next team will do it all over again.

  4. 04

    Archives that AI cannot use

    Scans with weak OCR, duplicate files and no metadata at all. Any retrieval over them returns mostly noise.

02 Delivery scope

Our delivery scope

  1. 01 Data foundations for reporting and AI

    Lakehouse architectures modelled in layers, from raw through conformed to ready for use, with data products that state their content, their freshness and who is accountable for them.

    Our work

    • Choices on platform architecture and storage formats
    • Conventions for modelling in layers
    • Designing data products around contracts
    • Ingestion in batches and through change data capture

    What you get

    • A lakehouse platform defined in code
    • The first data products running in production
    • A template for data contracts with a review process
  2. 02 Quality, lineage and master data

    Automated quality checks in each layer, lineage from the source system to the report, and master and reference data for the entities that count: residents, clients, products and assets.

    Our work

    • Quality rules with thresholds and alerts
    • Lineage captured down to column level
    • Matching and survivorship rules for master data
    • Management of reference data

    What you get

    • A quality dashboard for each data product
    • Lineage that can be queried
    • Golden records for the entities that matter most
  3. 03 Governance the platform enforces

    A catalogue, a classification scheme and access policies that the platform applies on its own. Purpose limitation and retention under the GDPR are built in, and data sharing follows the Data Governance Act wherever it applies.

    Our work

    • A classification scheme with tags
    • Access policies based on attributes
    • Automated retention and deletion
    • Agreements and technical controls for data sharing

    What you get

    • A catalogue filled from the platform itself
    • Access policies written as code
    • A retention schedule that runs in practice
  4. 04 Preparing unstructured content for AI

    Better OCR, richer metadata, removal of duplicates and tidier archives, so that document intelligence and retrieval start from content worth finding.

    Our work

    • An inventory of content with quality sampling
    • Improved OCR and layout extraction
    • Detection of near-duplicate files
    • Classification and enrichment of metadata

    What you get

    • A content store that is clean and enriched
    • A report on content quality
    • Rules for any content added in future
  5. 05 Reporting and BI that people actually open

    A semantic layer holding KPI definitions that the business and IT agree on, self-service within guardrails, and analytics embedded in portals and SaaS products.

    Our work

    • Workshops to define the KPIs
    • A semantic model with a metrics layer
    • Certified datasets and guardrails for self-service
    • Embedded analytics for products your clients use

    What you get

    • A KPI glossary with an owner for each entry
    • A certified semantic model
    • Dashboards that take the place of spreadsheets
  6. 06 Streaming for day-to-day operations

    Event streams and change data capture where a decision cannot wait for the overnight load: room availability, stock, the status of a case, signs of fraud.

    Our work

    • Latency needs set for each use case
    • CDC from operational databases
    • Stream processing with materialised views
    • A design for replay and backfill

    What you get

    • Streaming pipelines running in production
    • Operational views with targets for freshness
    • A procedure for replaying events

03 Architecture

A reference architecture, shown for illustration

Data travels from operational systems and documents through ingestion into a lakehouse built in layers: first raw, as it arrived; then conformed and checked for quality; then data products, each with an owner and a contract. No consumer ever reads the raw layer.

From the data products, one path supplies the semantic layer and BI, while others supply AI retrieval and features, and data APIs for other systems. Governance lies beneath everything and is enforced by the platform rather than by a policy document.

Illustrative example
  1. Sources and intake

    • Operational applications
    • Documents after OCR and enrichment
    • Change data capture and batches
  2. Lakehouse

    • Raw data layer
    • Conformed data layer
    • Lineage and quality checks
    • Reference and master data
    • Data products under contract
  3. Use of data

    • BI and the semantic layer
    • Features and AI retrieval
    • Sharing through data APIs
  4. Governance

    • Governance: catalogue, classification, access rules and retention
From lakehouse layers to owned data products

Shown for illustration only; this is not a client system.

Read the diagram as text

The main route leads from operational systems through ingestion by batch and change data capture, into a raw layer, a conformed layer and data products, and on to a semantic layer with governed BI.

Unstructured documents also come in through ingestion once OCR and enrichment are done. Quality checks and lineage cover the raw and conformed layers. Master and reference data flow into the data products. The data products also supply AI retrieval and features, and data APIs for sharing.

A governance band holding the catalogue, classification, access policies and retention stretches across the platform.

04 Choices and limits

Engineering choices and their limits

  • Owners come before tools

    Our approach

    Every data product has a business owner who decides what it means and a technical owner who keeps it running. We help you define both roles and the contract between those who produce data and those who use it.

    Limits and what we rely on

    No platform can create ownership. If your organisation does not appoint owners, the quality problems will come back, whatever tools you buy.

  • Purpose limitation, applied day to day

    Our approach

    We tag personal data with the purposes it may be used for, and access policies and retention follow those tags without manual steps.

    Limits and what we rely on

    Which purposes are lawful is for your data protection officer and legal advisers to decide, with the IDPC as the supervisory authority in Malta. We put the decision into practice; we do not make it.

  • AI needs its own data quality standard

    Our approach

    For AI use cases we measure what retrieval and models depend on: coverage, freshness, duplicates and how well text was extracted.

    Limits and what we rely on

    Some archives do not justify the effort of repair. An assessment on a sample will show this, and at times leaving them out is the sensible choice.

05 Our method

Our method

The platform grows around the first data products that matter, never the reverse.

  1. 01

    Choose decisions, not datasets

    Begin with two or three decisions or AI use cases, the data each one requires and the people who will own it.

    ResultA backlog of data products with owners

  2. 02

    Lay the foundation around them

    Platform, ingestion, quality checks and governance, sized to serve those first products well and no more.

    ResultThe first data products live in production

  3. 03

    Expand product by product

    Every new product builds on the same foundation, and the catalogue and KPI glossary grow alongside.

    ResultA product roadmap with measures of adoption

06 People in control

Where people keep the decision

A data platform automates the movement and checking of data. People decide what it means, who may use it and for what purpose.

  • Owners approve every definition

    A KPI or a data product changes meaning only after its business owner approves, and every change carries a version.

  • Policy owners grant access

    Data owners decide who may use which data and for which purpose; the platform applies that decision and records each grant.

  • A failed quality check halts publication

    When a contract check fails, the users of the data are informed, and the owner decides to publish, hold back or correct it.

07 Technologies

Technologies in our toolset

Platforms
  • Databricks
  • Microsoft Fabric
  • Snowflake
  • Open lakehouses on Delta Lake or Apache Iceberg
Pipelines
  • dbt
  • Apache Spark
  • Debezium and Kafka
  • The cloud provider’s own orchestration
Governance
  • Purview and Unity Catalog
  • Open-source data catalogues
  • Frameworks for data quality
  • Access control driven by policy
Analytics
  • Power BI
  • Metrics and semantic layers
  • Analytics embedded in products
  • SAP analytics in existing estates

We list a technology because our engineers have worked with it. The list does not mean that its vendor partners with or endorses FromNine.

08 Illustrative case

An illustrative case

Illustrative example

Shared occupancy and booking KPIs for a hotel group

01Starting point
A hotel group with several properties in Malta and Gozo runs a different booking and property system at each hotel. Occupancy, average rate and cancellations are calculated differently at each property, so management compares figures that do not match.
02The system we would put in place
Conformed data products for each property feeding one semantic layer, with KPI definitions agreed at group level and the detail of each property kept.
03Where staff decide
Each property’s finance lead approves the mapping of its data; the group owner of the KPIs approves definitions and any change to them.
04How we would judge success
Days needed to close the monthly report, number of manual reconciliations, and use of certified dashboards by management.

09 By sector

Sector by sector

  • Batch, quality and research data at pharmaceutical plants and private clinics, governed with strict purpose limitation, pseudonymisation and a log of every access.

  • Master data on products and assets joined with quality and production data at Maltese plants, for planning, traceability and AI, and for reporting to a European group.

  • Data that ministries and public entities reuse on the once-only principle, open data suitable for the national Malta Data Portal, and reports that auditors can follow back to the original record.

Malta

Data governed under Maltese and EU rules

An organisation in Malta handles personal data under the GDPR and the Data Protection Act (Chapter 586 of the Laws of Malta), with the Information and Data Protection Commissioner (IDPC) as supervisory authority. The Data Act adds rights over data from connected products and services, licence holders must deliver regulatory reporting the MFSA can rely on, and public entities can publish open data through the national Malta Data Portal, which MITA runs.

We design data products whose contracts record where the data may be processed, for which purposes and for how long. The platform then applies the correct rule for each use and each entity, without keeping separate copies of the data.

Common questions on data and analytics

Should we adopt a data mesh?

Adopt the parts that help: data products with owners and contracts. Complete decentralisation is worth it in large organisations whose domain teams are mature. Most organisations in Malta are better served by one central platform team, with the domains owning their products.

Can our data support AI today?

A brief assessment, based on samples from the sources one use case needs, gives the answer: coverage, quality, access rights and legal basis. It is usually “in part”, with a clear list of what to fix first. Our AI engineering teams work from the same assessment.

We have a data warehouse already. Must we start over?

Seldom. A warehouse that produces reports people trust is worth keeping. In most cases we add lakehouse capabilities for unstructured and high-volume data, and migrate only where cost or limitations make it worthwhile.

How do you share data with partners or other public entities?

Through data products offered over governed APIs, with agreements, purpose limitation and logging in place. Where the Data Governance Act or the Data Act applies, we design the technical controls to fit.

Tell us which decision your current data cannot support

We will follow what it requires back to the source systems and show what a first data product would involve.