Managed Data Services
Operational support for the data systems your business depends on.
Monitoring, incident resolution, optimisation, controlled change, documentation and specialist escalation for production data platforms.
Discuss this requirement →Start with the environment, risk and required outcome.
Monitoring, incident resolution, optimisation, controlled change, documentation and specialist escalation for production data platforms. 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 platforms decay without an owner
A data platform is not a finished thing. Sources change, volumes grow, definitions shift and jobs fail. Without someone accountable, decay follows a predictable sequence.
Month three
A pipeline fails on a Friday. Nobody is watching the alert channel. It is noticed on Wednesday and the intervening data is backfilled, mostly.
Month seven
A source system upgrade changes a field. The load still succeeds and one column is now empty. A report showing that column has been wrong for six weeks before anyone asks.
Month eleven
A definition changes in the business and nobody tells the data team. Two reports now disagree and confidence starts to erode.
Month eighteen
The person who built it has moved on. Nobody fully understands the model. Change requests are declined because the risk is unknown, and the platform ossifies.
Month twenty-four
People are back in spreadsheets.
Nothing in that sequence is dramatic and none of it is a technology failure. It is what an unowned platform does, and it is why the operating arrangement matters more than the build quality.
What managed data services covers
Pipeline operation
Job monitoring, failure alerting, variance and row-count checking, failure remediation, backfill and duration trend so a load that is growing towards its window is visible before it breaches.
Warehouse operation
Load monitoring, capacity and growth management, index and statistics maintenance, performance and the model changes that follow source system changes.
Reporting layer operation
Refresh monitoring, performance, access and licence management and the semantic model maintained rather than frozen. Covered on data analytics and BI.
Managed database services
Administration of the databases underneath, covered in more depth on database services.
Quality monitoring
Rules running, thresholds watched, trend reported, quarantine queue worked rather than accumulating. Covered on data quality.
Change handling
Source system changes, new fields, new subject areas, definition changes. This is the part that keeps a platform useful rather than merely running.
Documentation maintained, including the definitions, which is what stops the model becoming something only one person understands.
Data operations in practice
Monitoring that distinguishes a failure from a suspicious success. A load completing with zero rows has succeeded. Row count and variance checks against the historical norm catch that category, and it is the one that causes real damage because reports keep rendering.
Alerting into a channel someone reads, routed to a person by severity. A pipeline failure that stops daily reporting is different from one on a monthly extract, and treating them the same trains people to ignore both.
Runbooks for the recurring failures. The source that times out during month-end. The file that arrives in a different encoding twice a year. Documented, so resolution does not depend on who is available.
Backfill as a defined procedure rather than an improvisation. When a pipeline has been down for three days, the recovery has to be re-runnable and it has to not duplicate.
A monthly report worth reading. Load success and failure counts, quality trend by dimension, capacity and growth, report usage and refresh performance, and what changed. Report usage is the underrated one, because it identifies what to retire.
How the arrangement works
Fully managed where you have no internal data capability. We operate everything and report.
Co-managed where you have an analyst or a small team. We take the operational load, monitoring, failures, maintenance and platform work, and your people keep the business-facing analysis and report building. This is usually the better arrangement, because it puts your people on the work that needs knowledge of your business.
Monitoring only where your team operates the platform and wants coverage and a second pair of eyes. Low commitment and a reasonable way to find out how we work.
Response commitments follow the managed IT agreement on managed IT services: P1 in 30 minutes for a business-stopping failure, P2 in 4 business hours, P3 next business day.
Remote delivery nationally. Onsite in Gauteng where needed.
Common questions about Data Managed Services
What are managed data services?
Ongoing operation of your data platform: pipeline monitoring and failure remediation, warehouse and database operation, reporting layer maintenance, quality monitoring and handling the changes that source systems introduce.
It is the answer to the question every data project raises at handover. A platform without an owner decays quietly, and the decay is not technical failure so much as accumulating small gaps that eventually cost trust.
Why does our data platform need managing? It works.
It works today. Sources change, volumes grow, definitions shift and jobs fail, and each of those needs someone to notice and act.
The failure mode is not a crash. It is a load that succeeds with an empty column after a source upgrade, a report that has been wrong for six weeks, a definition that changed in the business and not in the model. All of those are cheap to catch and expensive to discover late.
Can you manage a platform somebody else built?
Yes, and it is most of what we take on. Assessment first: what runs, what monitors it, what has been failing, what is documented and where the definitions live.
The common findings are no failure alerting, no variance checking, a quarantine queue nobody has worked in months and documentation that stopped being accurate at handover. All of that is addressable without rebuilding.
Do we still need our own data person?
Usually yes, and doing different work. The arrangement that works is co-managed: we take the operational load and your person keeps the business-facing analysis, the report building and the relationships with the people asking the questions.
That split puts your internal person on the work nobody external can do as well. It is also the work they generally prefer, since operational monitoring and failure chasing is the part of a data role that makes it unsustainable.
What does the monthly report cover?
Load success and failure, quality trend by dimension, capacity and growth, report usage and refresh performance, and what changed in the environment.
Report usage is the section people find most useful and least expect. It identifies which reports have not been opened in months, which is what lets you retire the estate down to something maintainable and trustworthy.
What happens when a source system changes?
We handle the impact assessment and the change. A new field, a renamed column, a changed data type or a new version all affect pipelines and the model, and the work is to establish what breaks and adjust it.
The gap this closes is the notification one. Source system changes are typically driven by the application team or a vendor, and the data platform finds out afterwards. Being in the change conversation rather than downstream of it is a large part of what the arrangement buys.
When do we not need managed data services?
Where the platform is small, stable, built by someone still with you who monitors it, and the source systems are not changing.
That combination is rarer than it sounds, mostly because of the last two conditions. If it describes you, what is still worth having is failure alerting into a channel someone reads and a documented definition list. Those two cover most of what goes wrong and they cost nothing to set up.