Do we have to rebuild everything?

No. The trigger is usually concrete: Finance and Sales use different revenue figures, the customer definition in the CRM differs from the one in the ERP, dashboards contradict each other. An architecture records which source and which definition is authoritative; building comes after, and only where it is needed.

How long does it take?

Five steps, with indicative lead times: initiation about two days, current-state analysis about two weeks, target vision about three weeks, implementation strategy about three weeks. The implementation after that depends on what your own team can take on and wants to learn. What it becomes in your situation, we establish together in step one.

What is a project start architecture?

The outcome of the target vision step: several scenarios, each with costs and consequences, so there is genuinely something to choose. Not a thick report that sits apart from the organisation, but a chosen scenario and an order with reasons.

What does the design always include?

Compliance in the design, not bolted on: authorisation, masking of sensitive data and the record-keeping that makes ISO 27001 and NIS2 questions answerable. Traceability of every figure to its source. And room to grow: replacing a source or adding an AI application should not mean rebuilding the whole.

What role does Twentynext play in delivery?

Adviser, director or building partner, depending on what your own team can take on and wants to learn. One thing we map out with you but cannot take over: ownership and decision-making have to be assigned within the organisation.

Who from our organisation needs to be involved?

The people who work with the figures, not only IT. In the current-state analysis we talk to them about which systems are in place, which links run between them and which definitions clash. And someone who can assign ownership and decision-making responsibility, because an architecture can map that out but not take it over.

Data architecture that lasts

Data architecture

Finance and Sales report different revenue figures, the customer has a different name in every system, and nobody can point to the number that leads. A data architecture is where the fix starts: sources connected, definitions recorded, origins traceable. In five steps: building comes after.

Schedule an introduction →

From recognisable problem to foundation

Five steps, from inventory to delivery

Where it starts

The trigger is rarely “we want a new architecture”. It is more concrete:

Finance and Sales use different revenue figures, and month-end starts with working out which number is right.
The customer definition in the CRM differs from the one in the ERP, so every link counts double or misses one.
Dashboards are technically correct and still contradict each other, because they were built on different intermediate layers.
No figure can be traced to its origin: lineage is missing, so every discussion ends undecided.

An architecture does not fix this by rebuilding everything, but by recording what is decided where: which source leads, which definition applies, and how a figure travels from source to report.

How we work

Five steps. The lead times below are indicative: what they become in your situation, we establish together in step one:

Initiation (±2 days): scope, the people involved and the question of what needs to improve. No architecture discussion yet: the problem first.
Current-state analysis (±2 weeks): which systems are in place, which links run between them and which definitions clash. We talk to the people who work with the figures, not only to IT.
Target vision (±3 weeks): a project start architecture with several scenarios, each with costs and consequences, so there is genuinely something to choose.
Implementation strategy (±3 weeks): what comes first and what can wait. Whatever shows visible results in the short term goes up front; the rest gets an order with reasons attached.
Delivery: as adviser, director or building partner, depending on what your own team can take on and wants to learn.

One caveat belongs here: an architecture records decisions, but ownership and decision-making have to be assigned within the organisation: we map that out with you; we cannot design it away.

What the design always includes

Compliance in the design, not bolted on: authorisation, masking of sensitive data, and the record-keeping that makes ISO 27001 and NIS2 questions answerable.
Traceability: every figure in a report can be followed back to its source and the operations applied to it.
Room to grow: replacing a source or adding an AI application should not mean rebuilding the whole. That is what we mean by built to last: nothing more than that.

What you will not get: a thick report that sits beside the organisation. Every step ends in something you can test: a map of the landscape, a chosen scenario, an order with reasons.