Business intelligence
in the AI era.

Leadership looks at earnings and liquidity, sales teams at customers and orders, and operations at quality and lead times. These perspectives are connected. When they come from separate spreadsheets and differently defined metrics, the meeting often starts by reconciling the figures. Business intelligence should reduce that friction and provide a foundation on which different teams can act together.

In the AI era, access is changing. Employees can ask questions in everyday language, request an explanation of an unusual movement or have an analysis prepared for them. This also exposes existing ambiguities: what does “revenue” mean in this report? Which period is closed? Are returns included? A fluent answer does not resolve those business questions. It needs a data foundation in which their meaning is made explicit.

Good BI connects three tasks: making the current position understandable, helping people interpret change and supporting a specific decision. A dashboard might show where on-time delivery is declining. Further analysis identifies the product groups and process stages involved. Choosing a response is a separate step, with owners, assumptions and a later review of its effects. Correlation alone does not explain a cause.

The starting point should therefore be recurring decisions. What information is missing today, who needs it and when must it be dependable? Value can be assessed through less manual reconciliation, shorter preparation time, traceable decisions and better feedback on actions. More charts or more AI answers are not progress in themselves.

A BI architecture starts with authoritative business systems, such as ERP, CRM, inventory, production and digital sales channels. These systems record operational activity. For analysis, relevant data is transferred under controlled conditions, standardised and given the required historical structure. The data warehouse provides an organised analytical dataset. It reduces the load on operational applications and enables analysis across their individual boundaries.

The business meaning layer builds on this foundation: the semantic or metric layer. It defines metrics, dimensions and permitted combinations. An API makes selected queries available to dashboards, applications and AI tools. An optional graph layer adds explicit relationships, for example between a metric, its data model, its owner and a business process. Figures and their context can then be explored together.

These layers describe responsibilities, not a shopping list. One existing system may fulfil several roles. A small starting point can consist of a dependable data pipeline, maintained models and a BI interface. Additional access methods and stores are introduced when more applications or more complex relationships justify them. Clear ownership and stable handovers between the layers matter more than the number of components.

The following overview shows one possible arrangement. Access uses governed definitions and approved interfaces; the graph supplies additional context. This does not give a language model unrestricted access to every table. Nor must every BI query pass through a graph or a custom API. Existing BI tools can use governed SQL connections or semantic models directly. The appropriate route depends on the question and the permissions.

A graph layer, an API and a data warehouse perform different jobs. Connecting them creates reuse: the same governed metric can appear in a dashboard, a business application and an AI-assisted analysis.

A data warehouse is a dataset modelled for analysis. It brings selected data from different sources together and preserves the history required for the intended questions. It is neither simply a large database nor automatically the company’s only data store. Raw files, documents and operational transactions can remain in other systems. The central question is which statements the analytical model must support reliably.

The first decision is grain: what does one row represent? An order line, a delivery or a daily inventory balance? Measures and descriptive dimensions are defined only after this is clear. Facts might contain quantity and amount, while dimensions describe product, customer, location or time. Uncontrolled joins between datasets at different grains can count the same amount more than once. Inventory balances also cannot be summed across days in the same way as sales.

History is a business design choice. A customer may belong to a different sales region today than when an earlier order was placed. Should the report show the historical or current assignment? Both can be useful, but they must remain distinguishable. The model must also handle corrections, late postings and closed periods. Without explicit rules, an apparently clear time series can change unnoticed.

ETL and ELT describe different processing sequences: data is transformed before or after it is loaded into the analytical platform. Both approaches need defined sources, traceable transformations and quality checks. A lakehouse can combine storage and analytical processing on a different technical foundation. It does not remove the need for business modelling or dependable metric definitions.

Freshness has a purpose and a cost. Monthly reporting has different needs from an operational inventory view. Instead of requiring real time everywhere, teams agree the update intervals their decisions actually need. Completeness, key relationships, duplicates and unexpected volume changes are checked during ingestion. A visible data timestamp helps users distinguish a current observation from a period whose data is still incomplete.

“How much have we grown?” sounds simple, but leaves many choices open. Does it refer to orders received, invoiced revenue or cash collected? Are returns and cancellations included? Which legal entities, currencies and periods are in scope? The semantic layer makes this meaning explicit. A metric layer focuses particularly on reusable metric definitions. The exact division depends on the tools used.

A metric needs more than a formula. It also needs scope, filters, time basis, units, permitted dimensions, freshness and a business owner. Changes are versioned and checked for their impact on existing reports. This allows someone to understand why a value differs from an earlier report. The same definition can also be offered to AI as an approved tool.

The interactive example uses invented euro amounts excluding VAT: confirmed sales of €120,000 and associated returns of €10,000 produce €110,000 of net revenue. Against comparably scoped net revenue of €100,000 in the previous period, growth is ten per cent. Comparing the current sales figure directly with that previous-period value produces twenty per cent. This unchecked comparison does not measure the same properly defined metric.

The example is not a universal revenue definition. It illustrates why the current value and its comparison base must follow the same rules. In practice, allocating a return to a period and handling exchange rates require business decisions. A good interface displays the definition, data timestamp and relevant limitations alongside the result, including when the question was asked through chat.

An API layer exposes selected data and calculations through defined interfaces. An application might request an approved metric for a period and an authorised organisational scope. The interface checks inputs, permissions and limits, then returns a structured response. It makes a data model usable without exposing its entire internal table structure to every consumer.

The interface contract includes required parameters, units, time basis, data freshness and error states. An empty result is different from a failed data connection. A response should therefore contain both the value and the information needed to interpret it. Versioning prevents a changed definition from silently altering the behaviour of existing applications.

The interface enforces the rights of the requesting person or application. These may include row filters for legal entities and column rules for sensitive data. Cached results must respect that context too. A broadly privileged service account without additional, effective enforcement of user permissions would defeat the intended separation. Access checks and query limits therefore belong in the execution environment, rather than only in a prompt.

An API can provide an approved metric, a graph query or a narrowly defined search function. It is not automatically another data store. GraphQL is a language and execution model for API queries; its name does not imply that a graph database sits underneath it. Keeping these concepts separate helps architectural decisions: interfaces describe access, data models describe business structure and stores provide technical persistence.

The warehouse primarily answers quantitative questions: how large is a value, how has it changed and how is it distributed? A graph layer adds explicitly modelled relationships. A metric is based on a data model, the model uses particular sources, a team owns its definition and a process uses its output. These connections can be queried across systems and organisational boundaries.

One useful question follows a change in a source system: which data products and reports depend on it, and who needs to review the change? Another concerns interpretation: which definition applies to this metric, what process is behind it and which policy limits its use? Maintained connections reduce repeated manual research and make existing knowledge accessible to other teams.

This requires stable identifiers and evidenced relationships. Matching product names alone does not establish that records refer to the same entity. Business relationships, technical data lineage and organisational ownership are different relationship types and should remain recognisable as such. Automatically suggested links can help maintain the graph, but they need a review and approval process appropriate to their risk.

The graph does not replace the warehouse. Large aggregations and time series can still be calculated there, while the graph reveals connections. A relationship or a shared trend also does not establish causation. Showing that a process step causes an outcome requires an appropriate business analysis. A graph is only as complete and current as its maintained sources; a missing edge is not evidence that no dependency exists.

Language models can structure a question, suggest suitable metrics and explain a result in accessible language. They are particularly useful when people do not know the data model. Dependable calculation should still happen in the data tools designed for it. AI formulates and coordinates; the warehouse or an approved calculation function supplies the checked value.

Text-to-SQL translates a question into a database query. It is one possible access method, but not a guarantee of a sound analysis. Syntactically valid SQL may use the wrong table, an inappropriate join or an unsuitable period. Bounded data models, known metrics, read-only permissions and query validation reduce that freedom. Runtime and volume limits protect operations; evaluation shows which questions the interface actually handles reliably.

An agent can connect several steps: clarify the question, establish the correct data timestamp, retrieve a metric, break down a variance and add context from the graph. The result is a traceable analysis draft with sources and open questions. The agent should ask when “last month” could mean the calendar month, the last closed accounting period or the preceding 30 days. It should not conceal uncertainty behind a persuasive assumption.

A useful quality assessment covers the complete task: business correctness, appropriate permissions, necessary clarifications, processing time and review effort. A correctly calculated value can still disclose information improperly or provide the wrong basis for a decision. Actions that change data, such as updating a plan, therefore need their own approved workflow. Explaining a trend is initially an analysis; it does not automatically authorise a response.

Self-hosted primarily describes responsibility for operating software. It can run on infrastructure the company owns or on rented cloud infrastructure. Cloud describes a delivery and service model in which computing resources become available on demand and providers take on different amounts of operational work. Physical location is a separate question. These concepts are therefore not complete opposites. A useful decision identifies who operates each component and which data that component actually processes.

In a self-managed environment, the company or its service partner handles tasks such as updates, backups, recovery, monitoring and capacity planning. This allows custom design and integration, but requires available skills and dependable processes. A managed cloud service can take over part of that work. Definitions, access roles, data quality and responsibility for business use still remain with the company.

A hybrid architecture deliberately distributes components. Sensitive source data and the warehouse might remain in a controlled environment while a cloud application receives only approved, sufficiently bounded results. Alternatively, a managed warehouse can be combined with self-hosted integrations and a local model. “Hybrid” does not describe one fixed architecture. What matters is the approval of each concrete data flow, including logs, caches, backups and model requests.

The comparison should consider total cost and operational capability: infrastructure, licences, people, on-call cover, development, data transfer and expected load. Switching services and recovering after a failure also belong in that assessment. A low entry price may behave differently under high query volumes or frequent data movement than a predictable steady workload. Equally, existing infrastructure is not free simply because it has already been purchased.

The interactive comparison shows three possible allocations of responsibility. It does not award an overall winner. Region and data location alone establish neither compliance nor security; actual processing, contracts, access and implemented measures matter. The appropriate option is the one whose boundaries and operational duties the company can understand, fund and sustain.

A sound starting point is small enough to verify end to end and important enough to be used in daily work. Select a recurring decision with the business teams involved. Together, document the metrics, source data, required freshness and current reconciliation effort. The first success is a reliably answered question whose definition is understood beyond the project team.

Next, implement a complete slice from source through transformation and modelling to the output. Check data quality and permissions along that path. An appropriate reference analysis provides a basis for comparison. Add more queries or AI features only once freshness, calculation and interpretation are sound. This makes it easier to identify whether an error comes from the source, the model or the language-based processing.

Operations need a named owner for every important dataset and central metric. Business teams decide meaning and permitted use; data and engineering teams maintain models and interfaces; operations teams support availability and recovery. Changes to sources or definitions are announced, tested and published in a traceable way. A catalogue and graph relationships can support this collaboration.

Privacy and confidentiality are reflected in both the data model and its access rules. Which personal data is necessary for this analysis, how long is it needed and who can see the detail? Aggregation alone does not guarantee anonymity, particularly for small groups. Exports, logs, backups and AI inputs also fall within the processing scope. Business and legal requirements are established for the specific use and then implemented technically.

Further development follows use and impact. Are definitions accepted, is manual reconciliation declining and are decisions recorded clearly? Which questions recur, where are relationships missing and which data feeds are unreliable? These observations guide the next steps. BI can then grow into a shared foundation for people, applications and AI, with quality that remains visible in daily operations.