Data Warehousing and Warehouse Design
Create a governed foundation for reporting and analytics.
Design data models and warehouse platforms that provide consistent definitions, historical context and trusted reporting.
Discuss this requirement →Start with the environment, risk and required outcome.
Design data models and warehouse platforms that provide consistent definitions, historical context and trusted reporting. Namandla Consultants begins with evidence and recommends a proportionate engagement rather than a generic technology package.
Connected expertise for the wider environment.
Clear steps. Visible decisions.
Why data warehouse projects fail
The failure pattern is consistent and it is not technical.
Scope set at enterprise level
A model covering every subject area takes a year, delivers nothing until late and by the time it lands the requirements have moved and the sponsor has changed. Most abandoned warehouse projects were abandoned for this reason.
Definitions unresolved before modelling
If three departments calculate revenue differently, the warehouse either picks one and generates an argument, or holds all three and generates confusion. Neither is fixable in the model.
Built for completeness rather than for questions
A warehouse designed to hold everything is considerably harder than one designed to answer the twenty questions people actually ask. Start from the questions.
No owner after handover
Sources change, a load fails, a definition shifts and without an owner the warehouse drifts out of trust. Once people stop believing a number they do not come back easily.
The alternative is incremental
One subject area, taken end to end, in service, being used. Then the next. Each one delivers on its own and the model extends rather than being designed in full upfront.
Data warehouse design and dimensional modelling
Dimensional modelling remains the right default for analytical warehouses. Facts hold the measurements, dimensions hold the descriptive attributes people filter and group by, and the structure is comprehensible to someone who is not a data specialist. That last property matters more than it sounds, because self-service reporting depends on a business user being able to navigate the model.
Grain declared first
What one row in a fact table represents, stated explicitly before anything is built. An ambiguous grain produces double counting that is difficult to find later.
Conformed dimensions
One customer dimension, one product dimension, one date dimension, shared across subject areas. This is what makes a second subject area cheaper than the first and it is what a warehouse built subject-area-by-subject-area has to get right early.
Slowly changing dimensions handled deliberately
When a customer moves to a different region, does last year’s revenue follow them or stay where it was reported? Both answers are legitimate and the business has to choose. Implementing type 2 history everywhere by default adds complexity that most attributes do not need.
Surrogate keys rather than source system keys, so that a source system change or a merge does not break the model.
A date dimension with the fiscal calendar in it, including South African public holidays and your financial year structure. Trivial to build and it removes a surprising amount of report-level logic.
Scope: warehouse or data mart
A data mart is a warehouse scoped to one subject area or one department. For most South African mid-market organisations, two or three data marts sharing conformed dimensions is the right shape and it is what an enterprise warehouse would have become anyway.
The distinction matters commercially. A data mart is a six to twelve week engagement that delivers something in use. An enterprise warehouse is a programme. Presenting the second when the first would serve is how these projects acquire their reputation.
Platform
On-premises SQL Server or Oracle where the volume is moderate and the licensing is already held. This covers a large share of mid-market requirements and it uses capacity organisations already own.
Azure SQL, Synapse or AWS equivalents where volume, elasticity or a cloud-first position argues for it.
Volume sets the answer more than anything else. Below a few hundred gigabytes of analytical data, an existing SQL Server instance with reasonable storage will serve, and a cloud analytical platform is expense without benefit. Above a few terabytes with heavy concurrent query load, the position reverses.
What Namandla delivers
Requirements from the questions people actually ask. Definition workshops with the business. Dimensional model design, grain, conformed dimensions and slowly changing dimension strategy. Warehouse build and load. Incremental delivery by subject area. Documentation of the model and the definitions. Ongoing operation under managed data services.
Remote delivery nationally. Onsite in Gauteng for the workshops, which work considerably better in a room.
Common questions about Data Warehousing
Do we need a data warehouse?
Where reporting needs span several source systems, or analytical queries are slowing your operational systems, yes. Where one system holds the data and its native reporting answers the questions, no.
The clearest signal is people exporting to spreadsheets and combining by hand every month. That manual process is already a warehouse, just an unreliable one that depends on a specific person. Formalising it is usually the first subject area.
How long does a data warehouse take?
One subject area end to end is six to twelve weeks, including definition workshops, model, load and a first set of reports. An enterprise-wide model is a programme and we would generally advise against starting there.
Incremental delivery matters because it puts something in use early, which is what tells you whether the organisation will actually adopt it. A warehouse that delivers nothing for nine months is a warehouse that risks being cancelled in month eight.
What is a data mart and should we build one instead?
A data mart is a warehouse scoped to one subject area or department. For most mid-market organisations, two or three data marts sharing conformed dimensions is the right shape.
It is also what an enterprise warehouse tends to become. Starting there is faster, cheaper and lower risk, and provided the shared dimensions are designed properly from the first mart, the marts combine into something coherent rather than into three disconnected models.
What is dimensional modelling?
A design approach where facts hold measurements and dimensions hold the attributes people filter and group by. It is the standard for analytical warehouses because it performs well and because business users can navigate it.
That second property is underrated. Self-service reporting depends on someone who is not a data specialist being able to find their way around the model. A technically elegant model nobody can use produces a queue of report requests, which is the situation the warehouse was meant to remove.
Should our warehouse be in the cloud?
Volume decides it more than anything else. Below a few hundred gigabytes of analytical data, an existing SQL Server instance will serve and a cloud analytical platform is expense without benefit.
Above a few terabytes with heavy concurrent query load, cloud elasticity earns its cost. The middle ground is genuinely a judgement call, and the existing licensing position and where the source data sits usually tip it. Covered on cloud architecture.
Why do our reports still disagree after building a warehouse?
Almost always because the definitions were not agreed before modelling. The warehouse then either picks one definition and generates an argument, or holds several and generates confusion.
This is a governance problem rather than a technical one and it cannot be fixed downstream. The definition workshops are the part of a warehouse project most often compressed and they are the part that determines whether the output gets trusted.
When is a warehouse the wrong answer?
When the real requirement is one report from one system, when nobody has agreed what the numbers mean, or when there is no owner for it afterwards.
The third is the one we check for hardest. A warehouse without an owner can drift out of trust quickly as sources change, definitions move and loads fail unnoticed. If nobody in the organisation will own it, the operating model is incomplete and we say so before the build starts.