ArQiver logo

Information architecture

The information pretending to be software

Much of the knowledge that gives data meaning is embedded in the software built around it.

How we got here

Almost every generation of data architecture tried to solve the same problem: making data easier to access and reuse.

Operational systems were built to run processes. Reports were added to understand what happened inside those systems.

Then came ETL pipelines, data warehouses and data lakes. Each generation solved something real. Data became easier to extract, combine, store centrally and use for more than one purpose.

Data was increasingly opened up and made available for broader use.

But one kind of information often remained out of view: the knowledge needed to understand that data.

That knowledge remained hidden in software built for one specific application.

The missing piece

Data was made broadly applicable. Context often remained application-specific.

Data warehouses and data lakes made it possible to open up data once and make it available to multiple applications. That development remains essential.

But in the software built on top of data access, two responsibilities became intertwined.

The code moved data from A to B while also recording what that data meant within a particular application.

Data access became reusable. Interpretation remained coupled to application code.

Which data belongs together? Which relationships matter? Which categories does a department use? Which exceptions apply?

Once those responsibilities are distinguished, context becomes visible as information in its own right: information that can be recorded, managed and made broadly applicable.

Multiple contexts

The same data can be understood in several valid ways

The same data does not have the same meaning for every department. That is not an error to be fixed. It follows from different responsibilities and different ways of looking.

Take a bank transaction.

Finance sees money moving in and out. Credit and risk teams look for recurring obligations and whether they are paid on time. Compliance looks for suspicious patterns. Customer support may use the same transaction to answer a client question. An AI assistant may need it to explain a situation in plain language.

The problem is therefore not that multiple interpretations exist. The problem arises when those interpretations remain hidden exclusively inside software built for one specific application.

Finance

Sees flows, balances and financial explanation.

Credit and risk

Reads recurring payments as signals about obligations and reliability.

Compliance

Looks for patterns and exceptions that may require investigation.

Support and AI

Uses the same facts to answer questions in a meaningful way.

The aha moment

A SQL query often contains more than execution logic.

Open any SQL query.

At first glance, you are looking at software: selections, filters, relationships and calculations.

But look at the choices recorded within it.

Why do these records belong together? Why is a transaction given a particular classification? Why is an exception handled in this way?

Those choices reveal something about how an organisation understands its own reality.

A SQL query therefore does more than perform a technical operation. The query can also contain organisational knowledge: knowledge about meaning, relationships, groupings and perspective.

That knowledge often remains invisible precisely because it looks like software.

A change in responsibility

Maybe we have treated context as software for years.

Some of what we call software is in fact a description of the organisation.

It describes which data forms a dossier, which transactions belong to a mortgage, which classifications are used and from which perspective information is viewed.

We call this context.

When that context lives exclusively in software, it is difficult to find, difficult to share and difficult to reuse.

Context can also be managed explicitly as part of the information provision.

The architectural shift

The question is not where code runs. The question is where organisational knowledge lives.

In the traditional situation, some of that knowledge is recorded again for each application. When data and context are managed together, multiple applications can work from the same meaningful foundation.

Traditional architecture

Each application rebuilds enough organisational knowledge to do its own work.

Repeated 3×
Report
↑
Own interpretation
↑
Software
↑
Data
Dashboard
↑
Own interpretation
↑
Software
↑
Data
AI
↑
Own interpretation
↑
Software
↑
Data

ArQiver principle

Organisational knowledge is managed once and then reused.

Report
Dashboard
AI
Search
New application
Managed context
↑
Data

Where ArQiver fits

ArQiver was designed around data and managed context

ArQiver was designed on the principle that data and the context in which it is understood should be explicitly recorded, managed and made broadly applicable together.

That context can differ by department, application or collaboration. Finance can approach the same data differently from Compliance, without either perspective replacing the other.

Within ArQiver, data can be grouped, enriched and made available within a meaningful context. Applications therefore do not have to hide every relationship, classification and grouping exclusively inside their own implementation.

This keeps more than the data available. The knowledge through which an organisation understands that data also gains an explicit and reusable place.

The hidden information

Organisations already possess this information

This information does not need to be reinvented.

It already exists.

It is visible in the relationships people create, in the classifications departments use and in the choices currently recorded in software.

ArQiver brings that hidden world into the light.

Not by making the meaning of data the same for everyone, but by making different contexts visible, manageable and shareable.

The information was disguised as software. Now it can be treated as information again.