Data Architecture 101: A leaky tale of plumbers, builders and planners

plumber vs architectsPrelude

Though the role of architecture in the built environment is well understood, it has more than one meaning – Wikipedia. It is, therefore, not surprising that data architecture means different things to different people. I have been to several data architecture job interviews where the conversation quickly pares down to either data modelling, data migration, data warehousing, data quality, data governance or {insert your favourite technology platform here}.The latter irks me: what happened to the idea that architects must be technology agnostic? Was that perhaps too high an ideal to aim for? Did we delude ourselves?

Of course it does not hurt to be a polymath -in fact being an architect demands it – but at times I feel that a disservice is being done to the enterprise architecture profession as a whole and to data architecture in particular.

This, then, is the first in a series of posts that I hope will clear – or perhaps even further muddy – the water.

A Leaky Tale of Plumbers, Builders and Planners

Imagine you were a janitor at a block of high-rise residential flats.

Who do you call when there is a leak?

For most of us, the obvious answer is … a plumber. A plumper would locate, discover {or, worse, misdiagnose} the source of the leak and proceed to repair it. The fix might take one of several forms, from patching the hole in the pipe to replacing a piece of the pipe or perhaps replacing the entire pipe.

Let us now assume that after the initial repair, the leak re-occurs, and hopefully not, heaven forbid, in the same place. Chances are that you would re-call the same plumber or, if trust has been lost at this stage, for most of us, yet another plumber.

If this scenario repeats itself for the umpteenth time, short of overhauling/replacing the entire piping, a typical plumber would offer little further assistance.

This is because, a plumber, in fixing the problem, would typically replace like-for-like. For example, a plumber, depending on local regulations governing their trade, might not specify a pipe bigger in diameter or length than what he/she found or replace, say, a copper pipe with a PVC pipe without re-thinking the design and purpose of the pipe.

On the other hand, you, or a great plumber, after tearing your hair out, might consider bringing in, depending on local practise, a consulting/contracting/construction/building civil/mechanical engineer/architect, in other words, the people that erected building.

For the sake of simplicity (and for the sake of the comparison to data architecture that I wish to make later), let us call this layer of people, engineers.

A plumber, relative to an engineer, is generally seen as an artisan, a technician whereas an engineer is deemed to have a deeper theoretical/academic training and knowledge.

Thus, in attempting to fix the problem, an engineer would investigate aspects of the problem beyond what an average plumber might take for granted. Among other things, an engineer could question the usage, design and layout of the pipes. What is the operating pressure of the fluid being pumped through the pipe(s), he/she might ask? What is the thickness of the pipe wall? What material was used in the manufacturing of the pipe and how was it fabricated?  How much vibration is caused by the water gushing through the pipe? Is the pipe positioned within or against the wall? It is adequately supported? The list is endless.

A good engineer would, of course, consider factors beyond the pipe. Could it be a seasonal occurrence? Does the leak depend on the weather or maybe when there are more occupants than normal in the building?

What if our engineer fails to solve the problem?

As was the case with the plumber, short of tearing down the whole edifice, an exceptional engineer might begin to question the very purpose of the building, its locale, its history, its culture and that, my friends, in especially the built-environment, delivers us straight into the hands of the people that conceived and turned the initial concept – the dream house – into form and function.

For the sake of simplicity let us call this group of people, depending on local practice, planners or architects.

Just to make things a bit more interesting, let us assume the original architect(s) are long gone.

A good architect would not delve into the problem like a bull in a china shop. A good architect would revisit what was originally reported by the janitor, what the plumber did to resolve the problem and the considered opinion of the engineer.

Let us also assume that all the actors preceding the architect took the correct measures. Then the architect would be left with no option but to pick the baton from where the engineer left off.

An architect would consider the history of the building. Was it originally an office block that was converted into a residential flat? If so was the piping changed to accommodate the kitchen sinks and showers? Who are the primary dwellers? Old-age pensioners or twenty-something sports-mad millennials?  For younger dwellers are prone to opening showers heads to the max that would strain the system while older folk, with thinning skin, would prefer softer shower heads or run bath tubs. How about the design of the shower heads? On what terrain is the building located? Perhaps it was built next to an industrial park or maybe the industrial park was built too close to it?

At this stage you might well ask, what has that got to with a leaking pipe? Maybe nought but what else can you NOT QUESTION at this stage?

So it is with data architecture.

If a system is performing slowly or there is poor quality data or there is poor data governance or there is not enough storage or untimely business intelligence or lack of metadata or a spider-web of point-to-point integration , the initial response, depending on how a company’s operations are set up,  would be to log an incident or request that is typically dealt with by so-called first-line or front-line support staff who typically do not have the requisite depth and breadth of knowledge to resolve the root cause of the problem  – have you ever tried to resolve an unsolicited insurance premium debit order deduction with a call-centre agent?

When the first-line of support fails, the problem is typically passed to the back-end staff. In an IT environment these would be your hardware, network, system or database administrators/engineers, application/software/web/etl/integration developers, system/business/data analysts, application/system/data modellers/designers, you name them.

As with our leak, if the problem keeps recurring and/or is not resolved, and just like our fictional building/construction engineer, exceptional back-end staff would begin to question the very purpose to which the data is being put to use; when, where, why and how is  the data captured, stored, processed, disposed of; who has access to it; and, most importantly, whether the data is needed at all and if it is, whether it supports the strategic goals of the company.

That is where the role of an architect comes in.

An architect is required to get to the very bottom of a problem and question all fixes implemented to date; an architect would rephrase the question, knowing that a problem well defined is a problem half-solved; an architect would propose interim (transitional) and/or long lasting (target) solutions that directly lead to achieving the company’s strategic goals.

This role does not need to be held by an “architect”. It can reside with whoever links strategy to tactical and operational imperatives in the company – and that, typically, would be a senior or managerial level position in most companies.

This is not to say an architect must disavow plumbing and engineering. That would be placing yourself at a disadvantage if you do not know the different between a wrench and a spanner.


The word “architecture” is among a plethora of words, phrases, constructs etc., that the computing profession and its concomitant information technology discipline has unashamedly borrowed from the more established professions and disciplines such as engineering, medicine, etc.

My own experience informs me that the usage of the word “architecture” in IT is rooted in the build-environment rather than in engineering “design”.

The next article will explore how the word “architecture” has evolved in usage from hardware and software design to its present usage in enterprise architecture in general and data architecture in particular and sketch a path to a career in enterprise architecture.

This is the first in a series of expositions on data architecture in particular and enterprise architecture in general that will form part of a proposed curriculum being developed by Myt Technologies. If you are interested in further developing and delivering this curriculum contact the author at

Proposed further reading about Data Architecture: