MTN EVA 3.0 on Azure Databricks: Telco Cloud Modernisation at Scale

  • Thread Author
MTN’s migration of its Enterprise Value Analytics (EVA) platform to Microsoft Azure represents a decisive step in telco cloud modernisation: a move that promises faster analytics, broader scale, and tighter integration of AI into customer and operational workflows, while also resurfacing familiar telco concerns about vendor lock‑in, data governance, and the complexity of at‑scale cloud operations.

Futuristic control room with a holographic EVA 3.0 data hub and analysts at screens.Background / Overview​

MTN and Microsoft announced a strategic alliance in 2022 that set the stage for a wave of cloud-first initiatives across MTN’s markets, with South Africa and Nigeria among the first targets for migration and modernisation. That partnership has explicitly positioned Azure as MTN’s primary public‑cloud partner for transforming core and analytics platforms, and MTN has executed multiple proofs‑of‑concept on Azure (including early 5G core experiments) as part of that longer program. The recent upgrade — reported as the launch of an EVA 3.0 platform running on Azure Databricks and secured by Microsoft security tooling — is presented by MTN and its partners as a flagship telco analytics migration and a blueprint for regional rollouts. Azure Databricks has been a focal technology for enterprise data‑lakehouse initiatives on Azure for several years, and both Microsoft and Databricks have continued to reinforce that service as the recommended foundation for large analytics workloads. This article summarises the public claims about EVA 3.0, evaluates the technical and business implications for telcos and enterprise IT teams, cross‑checks available public information, and highlights the strengths and risks that organisations should weigh when attempting telco‑scale data modernisation on Azure.

What MTN says it built: EVA 3.0 in brief​

  • EVA 3.0 is described as a cloud‑native re‑implementation of MTN’s Enterprise Value Analytics platform, rebuilt on Azure Databricks and integrated with Microsoft security services (the public reporting names Microsoft Defender specifically).
  • Reported scale metrics (from the announcement) include processing roughly 22 billion records daily, executing more than 800 analytics workflows, and ingesting over 1,700 data feeds.
  • The modernised stack is claimed to deliver improved speed, scalability, and near‑real‑time analytics that help MTN detect service issues earlier, surface customer trends faster, and enable more tailored, AI‑driven experiences.
  • MTN frames EVA 3.0 as a reusable pattern for other markets within the MTN Group, backed by its Cloud Centre of Excellence and a major internal push on Microsoft Azure certifications (the announcement cites over 1,350 Azure certifications achieved by MTN engineers).
These features align with the telco use‑case for a lakehouse model — continuous ingestion, streaming and batch ETL/ELT, collaborative model development, and governed access to analytic outputs. Azure Databricks, Unity Catalog, and the broader Azure data ecosystem are common components for these architectures.

Technical architecture: what to expect under the hood​

Azure Databricks as analytics backbone​

Building a telco analytics engine on Azure Databricks is a well‑worn pattern: Databricks provides scalable Spark compute, Delta Lake table semantics for ACID‑like operations on analytical tables, and orchestration features that can support hundreds of jobs and thousands of tasks. Databricks’ tight integration with Azure services (AD authentication, Data Lake Storage, Synapse / Power BI connectivity) reduces integration friction for enterprises standardising on Microsoft cloud services. Recent Databricks product releases further expanded job scale and AI workloads on Azure, making it a natural fit for very large telco pipelines. Key platform characteristics MTN likely leverages:
  • Distributed Spark clusters for bulk and streaming processing.
  • Delta Lake for storage, schema enforcement, and incremental ETL.
  • Job orchestration and operational monitoring (Databricks Jobs, Unity Catalog, Metrics/Alerts).
  • Integration points into Azure services for identity, storage, and downstream reporting (Azure AD, ADLS Gen2, Power BI).

Security and governance layer​

The public report highlights Microsoft Defender as part of the security control plane. In practice, telco analytics workloads need layered protection:
  • Endpoint, workload and data‑plane threat detection (Defender for Cloud/Endpoint).
  • Identity and access controls via Azure Active Directory and role‑based access control.
  • Data governance and lineage (Unity Catalog or Microsoft equivalents) to meet regulatory and audit needs.
  • Network segmentation (private peering, ExpressRoute) for sensitive telemetry flows.
Microsoft and Databricks both publish guidance on enterprise security patterns for analytics workloads; integrating Defender dashboards, Sentinel/SiEM pipelines, and Zero Trust principles is consistent with contemporary cloud security architecture.

Operational scale claims: what they imply​

If the numbers reported (22 billion records/day, 800+ workflows, 1,700+ feeds) are broadly accurate, EVA 3.0 is operating at very large event ingestion and processing scale. That scale implies:
  • High degrees of parallelism and autoscaling policies to manage bursty telco telemetry.
  • Mature data‑quality, schema‑evolution, and back‑pressure handling to avoid pipeline collapse.
  • Advanced monitoring, cost governance, and observability to keep cloud spend predictable while meeting latency SLAs.
  • A robust orchestration and retry model that supports dependencies across hundreds of jobs.
These are non‑trivial capabilities and typically require sustained investment in platform engineering, test automation, and run‑book maturity.

Business and operational benefits MTN highlights​

  • Faster detection and remediation: Real‑time or near‑real‑time analytics can detect network incidents earlier, reducing mean time to repair and improving customer experience.
  • Personalisation and relevance: Better analytics feeds into customer experience teams, enabling targeted offers, contextual support, and fewer spurious interactions.
  • Operational efficiency: Automation of recurring analytic jobs and predictive models can reduce manual workload for data teams and network operations.
  • Responsible AI posture: MTN emphasises “responsible AI” — a claim paired with stronger governance and controls in the platform narrative.
  • Scalability and reusability: MTN positions the new EVA as a blueprint that other country operations can adapt, reducing duplicate engineering effort across the group.
These are precisely the business outcomes telcos chase with cloud modernisation: improved NPS, reduced churn, faster time‑to‑market for offers, and the ability to monetise data via new enterprise products.

Cross‑checking the public record​

There are several independent, credible confirmations for the broader fact pattern: MTN and Microsoft formed a strategic alliance and have jointly piloted cloud and 5G core workloads in Azure; Databricks is widely used as an analytics backbone for enterprise lakehouse deployments; Microsoft positions Defender and the Azure data ecosystem as a recommended stack for large analytics programs. However, specific operational metrics reported in the EVA 3.0 announcement (for example, the exact daily record count, number of workflows, and number of feeds) appear primarily in the announcement itself. Reputable public pages from MTN and Microsoft confirm the partnership and the technology choices but do not independently publish the precise numerical tallies cited in the EVA 3.0 description. Therefore those numeric claims should be treated as company‑provided metrics that were not broadly corroborated by independent third‑party telemetry or public dashboards at the time of reporting. Independent verification would require: audit logs, third‑party monitoring, or follow‑up technical briefings with data access — none of which are currently public.
Where multiple public sources corroborate design choices and high‑level benefits:
  • Microsoft’s published case studies and press material describe MTN’s strategic use of Azure for network and digital platforms.
  • Databricks and Microsoft promotional and technical material describe Azure Databricks as a scale target for large analytic workloads, and recent Databricks updates continue to increase job and task scalability.
Where single‑source claims need caution:
  • Exact volume metrics (22 billion records/day, 800+ workflows, 1,700+ feeds) — these appear in the announcement and should be considered MTN’s operational metric snapshot, not an independently audited figure.

Strengths: why this is a meaningful telco move​

  • Platform standardisation: Moving a critical analytics platform to Azure Databricks establishes a standard, repeatable architecture across markets that can shorten deployments and reduce integration drift.
  • Hyperscaler partnership leverage: Deep alignment with Microsoft brings direct access to engineering, security, and commercial programmes that can accelerate feature adoption and provide faster remediation channels.
  • Skill investment: MTN’s reported push to certify thousands of engineers on Azure reduces the classic “skills gap” that stalls cloud modernisation projects and helps operationalise the platform at scale.
  • Data‑driven operations: A mature lakehouse enables predictive maintenance, demand forecasting, and more informed productisation of telco services — all potential sources of revenue uplift and cost avoidance.
  • Security posture: Using Microsoft Defender and Azure-native security tooling can centralise controls and improve the baseline security of sensitive telco telemetry, provided those controls are configured correctly and governance is enforced.
These strengths make the migration more than a lift-and-shift: it’s a transformation of workflows, organisational capability, and product delivery potential.

Risks and trade‑offs (what operators and CIOs should evaluate)​

  • Vendor lock‑in and portability
  • Deep use of Azure‑specific services (Databricks as a managed service, Unity Catalog, Defender integrations) increases the cost and complexity of moving to another cloud later. Telcos must balance short‑term speed with long‑term portability strategies (open formats, multi‑cloud patterns, and exportable data architectures).
  • Data sovereignty and regulatory exposure
  • Telco datasets often contain personally identifiable information and metadata governed by strict regulatory regimes. Cloud regions, contractual data residency guarantees, and auditability must be explicit in supplier agreements.
  • Operational complexity at scale
  • Handling billions of records per day requires mature pipeline observability, back‑pressure control, retries, and incident response playbooks. Without those, pipelines degrade, costs spike, and SLAs fail.
  • Cost governance
  • Cloud compute and storage can scale fast — and cost faster. Effective tagging, budgets, and optimisation (spot instances, right‑sizing) are required to keep run‑rates sustainable.
  • Security surface expansion
  • A larger, cloud‑exposed analytics estate increases the attack surface. Defender and other controls mitigate risk, but require continuous tuning, threat hunting, and incident response capability.
  • Dependence on internal capabilities
  • Certifications are a strong signal, but retaining staff and evolving skills (platform engineering, observability SREs, data governance) is a multi‑year commitment.
  • Verification of claims
  • Public announcements frequently emphasise scale and capability. Independent verification of high‑impact figures (records/day, workflows) is uncommon in marketing material; customers and partners should request performance KPIs and proof‑of‑value pilots. (Flagged as single‑source claims earlier.

Practical checklist: what enterprise buyers and telco CIOs should ask next​

  • Ask for measurable KPIs from the pilot/production rollout:
  • End‑to‑end latency percentiles for critical analytics queries.
  • Ingest reliability and failure rates.
  • Cost per million events processed (or similar unit economics).
  • Validate compliance and residency:
  • Request data residency documentation, contractual SLAs, and audit access rights.
  • Demand operational runbooks and breach exercises:
  • Review runbooks for incident detection, escalation, and recovery; run joint tabletop exercises.
  • Probe for portability:
  • Require canonical data formats (Apache Iceberg / Delta Lake / Parquet), documented ETL patterns, and export procedures.
  • Check governance:
  • Review Unity Catalog (or equivalent) usage, lineage tools, and role/attribute‑based access control configurations.
  • Insist on a staged migration:
  • Start with low‑risk or read‑only use cases, measure the platform, then expand to critical workloads.
These are practical steps to avoid common pitfalls while realising the benefits of cloud modernisation.

EVA 3.0 as a blueprint for other telcos: realistic or aspirational?​

MTN positions EVA 3.0 as a replicable model across its country operations. The blueprint argument is credible where telcos share similar backend systems, regulatory regimes, and product models; a centralised analytics backbone can reduce duplicate engineering and accelerate rollouts.
However, replication is contingent on:
  • Local compliance constraints (data residency, cross‑border transfers).
  • Local skills and operational maturity.
  • Network topology differences that affect latency or data egress patterns.
  • Commercial and procurement arrangements with the hyperscaler and SI partners.
A practical approach is to document the blueprint as a configurable reference architecture with country‑specific adapters for compliance, connectivity, and cost constraints — not a one‑size‑fits‑all copy. This reduces the risk of failed rollouts and encourages reuse where it genuinely fits local realities.

Skills, skilling, and organisational change​

MTN’s reported focus on Azure certifications (the announcement cites more than 1,350 Azure certifications) is important: technology alone does not modernise an organisation. Platform engineering capability, SRE practices, and data stewardship all require sustained investment in people.
How skilling unlocks value:
  • Reduces dependency on external contractors for run‑time optimisation.
  • Lowers risk of misconfiguration and cloud waste.
  • Improves time to resolution when incidents occur.
However, certification counts are a proxy metric: the true indicator of readiness is measured by the ability to run production‑grade pipelines, maintain SLOs, and iterate product features without repeatedly invoking external integrations.

Final analysis and verdict​

MTN’s EVA 3.0 migration to Azure Databricks is an important, high‑profile example of telco cloud modernisation in Africa. The move aligns with broader industry trends where operators co‑design with hyperscalers to unlock AI, analytics, and new revenue opportunities. Databricks on Azure, coupled with Microsoft security tooling, is a credible and widely supported architecture choice for large analytics workloads. Strengths are clear: a repeatable modern architecture, better analytics velocity, potential customer experience improvements, and an investment in internal skills. But the story is not purely technical: successful long‑term value depends on careful governance, cost control, clear contractual guarantees on data residency and access, and continued investment in platform engineering.
A note of caution: some headline metrics in the EVA 3.0 announcement (daily record counts, workflow counts, number of feeds) are presented as company metrics; these were not independently corroborated in public third‑party telemetry at the time of reporting. They should therefore be treated as MTN’s operational statements that prospective partners, customers, or analysts should validate via hands‑on pilots or contractual evidence before relying on them for procurement or architectural decisions.

What this means for WindowsForum and enterprise IT audiences​

For IT leaders and Windows/Cloud practitioners, MTN’s EVA 3.0 provides a concrete case study of how a large, legacy‑oriented network operator can:
  • Consolidate telemetry into a governed lakehouse.
  • Use managed cloud services to scale analytics workloads rapidly.
  • Combine hyperscaler tooling for security and compliance while building internal operational muscle.
Readers planning similar journeys should prioritise:
  • Proofs‑of‑value that measure both technical and commercial metrics.
  • Strong contractual controls for data, auditability, and service resilience.
  • Investment in people and organisational change, not just technology migration.
MTN’s rollout is an example worth studying — for what it delivers and for the governance questions it raises — and it will be instructive to watch how the company operationalises EVA 3.0 across other markets and how independent performance and compliance measurements evolve as the platform matures.
Conclusion
The EVA 3.0 announcement underscores a pragmatic reality: telco transformation at scale requires cloud platforms with proven analytics capabilities, a serious investment in governance and skills, and realistic expectations about the operational complexity involved. Standardising on Azure Databricks and leveraging Microsoft security tooling brings immediate speed and capability gains, but it does not eliminate the need for disciplined architecture, financial controls, and legal clarity — especially where sensitive customer data and regulated services are involved. The best outcomes will come from pairing technical ambition with the operational rigor to sustain it.

Source: CIO Africa MTN, Microsoft Complete Telco Cloud Migration
 

MTN’s decision to rebuild its Enterprise Value Analytics (EVA) platform on Microsoft Azure — branded internally as EVA 3.0 — marks a major inflection point for telco data platforms in Africa: the platform is now reported to run on Azure Databricks, secured by Microsoft Defender, process roughly 22 billion records per day, operate more than 800 analytics workflows across some 1,700 data feeds, and serve as a reusable blueprint MTN intends to roll out across other markets in the Group.

Two analysts in a high-tech control room monitor MTN EVA 3.0 on Azure Databricks with a glowing Africa map.Background / Overview​

MTN’s cloud-first push has been public for several years and is anchored by a strategic partnership with Microsoft announced as part of Project Nephos and a formal Cloud Centre of Excellence that consolidates governance, tooling and skills across its operating companies. The recent EVA 3.0 rollout is positioned by MTN and Microsoft as the largest telco cloud implementation in the Middle East and Africa, and is being promoted as a repeatable reference architecture for other MTN markets. The move sits within a broader regional trend: global hyperscalers have been expanding capacity and services in South Africa and across the continent, while large telcos have been modernising OSS/BSS and analytics backbones to build real‑time operations and AI-driven productisation. Microsoft’s multi‑billion‑rand investment in South African cloud and AI infrastructure in 2025 created the regional capacity and commercial incentives that make large, cloud‑native telco deployments feasible.

What MTN says it built​

EVA 3.0 at a glance​

  • A cloud‑native re‑implementation of Enterprise Value Analytics (EVA) on Microsoft Azure.
  • Core compute and analytic fabric: Azure Databricks (Databricks lakehouse pattern).
  • Security and runtime protection: Microsoft Defender and Azure security controls.
  • Headline scale metrics (company‑reported): ~22 billion records/day, 800+ analytics workflows, ~1,700 data feeds. These figures are repeatedly quoted in MTN/Microsoft coverage and trade reporting.
  • Talent and operations: MTN reports more than 1,250–1,350 Microsoft Azure certifications among its engineers, a targeted skills push to operate and sustain the platform.

A careful note on the headline numbers​

MTN and partner coverage consistently publish the ingest and workflow counts as metrics of scale. These are company‑reported operational figures and, at the time of writing, there is no publicly released, third‑party audited technical case study that independently validates every throughput and latency claim. Readers and procurement teams should treat the numbers as declarations of capacity and architectural intent until MTN or Microsoft publishes telemetry or independent benchmarks that substantiate the claims.

Why Azure Databricks (and a lakehouse) makes sense for a telco​

Telco analytics workloads share three persistent demands: continuous high‑velocity ingestion, parallel analytical processing for both batch and streaming use cases, and governed access to sensitive datasets (billing, location, subscriber PII). The modern lakehouse model implemented on Azure Databricks + Delta Lake + ADLS Gen2 addresses these needs:
  • Databricks scales Apache Spark for both streaming and batch, enabling massively parallel ETL and ML model training.
  • Delta Lake provides ACID semantics, time‑travel and schema evolution for analytic tables, essential for reliable incremental pipelines.
  • Unity Catalog (Databricks) centralises governance, lineage and fine‑grained access control across workspaces and data assets — a critical capability for a multi‑market telco.
Taken together, these components reduce integration complexity vs. dozens of bespoke point solutions and provide an integrated path from data ingestion through to model productisation and operational dashboards. This is precisely the pattern MTN describes for EVA 3.0 and what many large telcos adopt when they shift telemetry and OSS/BSS analytics to the cloud.

Technical anatomy — expected components under EVA 3.0​

MTN’s public description maps to a standard Azure/Databricks lakehouse reference architecture. The likely technical stack and responsibilities look like this:
  • Ingest and transport
  • High‑throughput collectors and probes ingesting network telemetry (packet/flow), call detail records (CDRs), OSS/BSS events and application logs.
  • Managed streaming (Azure Event Hubs / Kafka) for low‑latency ingestion; Azure Data Factory or similar for scheduled batch loads.
  • Storage and table semantics
  • Azure Data Lake Storage Gen2 (ADLS Gen2) as the object store with Delta Lake tables for transactional semantics, partitioning and time‑travel.
  • Compute and orchestration
  • Azure Databricks for autoscaling Spark clusters, Databricks Jobs / Workflows to orchestrate hundreds of analytics pipelines and ML jobs.
  • Governance, catalog and security
  • Unity Catalog for unified metadata, lineage and fine‑grained access control across workspaces; Azure Active Directory / Entra for identity; Microsoft Defender for workload and data‑plane protection.
  • Consumption and productisation
  • Feature stores and model registries (Databricks model registry), APIs and Power BI or custom NOC consoles for dashboards and operational playbooks.
These are the practical building blocks for a telco lakehouse that needs to support closed‑loop automation (detect → correlate → remediate) and product‑grade AI services.

Strategic upsides: what MTN and partners will likely gain​

  • Faster incident detection and shorter mean‑time‑to‑repair (MTTR): real‑time ingest and streaming analytics mean network anomalies can be correlated and surfaced earlier. MTN claims exactly this operational uplift.
  • A repeatable blueprint for group‑wide rollout: centralising architecture and codifying it in a Cloud Centre of Excellence creates a template that can be adapted to local compliance and operational conditions, reducing duplicated effort.
  • Talent multiplier and operational maturity: the certification drive (1,250–1,350 Azure certifications reported in 2025) increases internal capability and reduces dependence on external integrators — a practical and often under‑appreciated element in successful large migrations.
  • A platform for responsible AI and productisation: a governed lakehouse with model registries, versioning and monitoring provides the scaffolding for deploying AI models in customer‑impacting workflows while maintaining auditability. MTN emphasises responsible AI as an explicit outcome.

Risks, trade‑offs and open questions​

Large-scale telco migrations to hyperscale clouds unlock capabilities — but they also concentrate risks. Below are the practical trade‑offs IT leaders and telco buyers should weigh.

1. Vendor lock‑in and portability​

Deep integration with managed Azure services (Databricks managed runtime, Unity Catalog, Defender) can increase switching costs. Exportable data formats (Delta, Parquet) help, but architectural gravity remains. MTN’s blueprint must embed clear exit/export plans and data portability routines.

2. Data sovereignty and cross‑border transfers​

Centralising telemetry and subscriber metadata across multiple African jurisdictions raises regulatory questions. Although Azure provides regional hosting options, MTN will need country‑specific architectures or contractual safeguards to meet telecom regulators and national data‑protection laws. The blueprint’s replicability is constrained by local legal frameworks.

3. Operational complexity and SRE maturity​

Processing tens of billions of events daily requires mature SRE practices: observability, congestion/back‑pressure management, chaos testing, automated retries and on‑call runbooks. Without this muscle, pipelines will degrade or develop intermittent correctness issues. MTN’s Cloud Centre of Excellence and certification push address people, but systems and process maturity must follow.

4. Cost governance and FinOps​

Spark workloads can scale cost faster than value. Long retention windows, heavy ML training, and misconfigured autoscaling can create runaway bills. Effective tagging, job‑level cost accountability and quota management are essential from day one. MTN will need robust FinOps practices to keep the blueprint affordable across markets.

5. Security surface and control plane risks​

Centralising the analytics control plane increases the blast radius for misconfigurations or cloud control‑plane outages. Defender and Azure tooling harden runtime protection, but only when integrated into active SOC operations, regular red‑team testing and hardened deployment pipelines. The industry has seen high‑impact outages caused by configuration errors; telcos must plan for identity and portal resiliency as first‑class concerns.

6. Verification gap on headline metrics​

As noted earlier, the headline throughput figures (22B/day; 800+ workflows; 1,700 feeds) are reported by MTN and partner coverage and have not, at the time of writing, been matched to an independent telemetry audit in the public domain. For procurement decisions, buyers and partners should request proof‑of‑value reports: latency percentiles, event retention economics, ingest reliability and SLO attainment.

Governance, compliance and responsible AI — practical controls MTN should make visible​

For telco analytics platforms with AI in the loop, governance is not optional. The following are essential controls that should be documented publicly or shared with enterprise customers and regulators:
  • Fine‑grained access controls and separation of duties via Unity Catalog and Azure AD/Entra.
  • Model registries with staged deployment gates (canary → pilot → wide), explainability checks and post‑deployment monitoring.
  • Data lineage and audit trails for any PII‑linked processing, plus documented data‑retention policies aligned to country rules.
  • FinOps dashboards and job‑level cost attribution exposed to platform users to prevent runaway expenditures.
MTN has publicly stated the platform supports responsible AI and governance, but the operational details (audit artefacts, audit certifications, ML lifecycle policies) are the levers that convert that claim into trust for customers and regulators.

What this means for Microsoft, other hyperscalers and the African cloud market​

MTN’s commitment to Azure for a flagship, mission‑critical analytics backbone is a commercial win for Microsoft in the region. For Microsoft, the EVA 3.0 deployment demonstrates hyperscaler viability for telco‑grade workloads — a reference that can be showcased to other operators and regulators. Microsoft’s broader investments in local infrastructure and skilling in South Africa amplify the commercial incentives for large customers to adopt Azure services. For competitors (AWS, Google Cloud, and regional providers), the deployment raises the bar: telcos will evaluate not just raw compute and storage, but the availability of telco‑specific patterns, managed integrations (Databricks on Azure being a common design) and local commercial terms. The result could be more competitive offers, but also deeper vendor coupling if customers prioritize frictionless integration over portability.

Practical recommendations for telcos and IT leaders considering a similar migration​

  • Start with a narrow, high‑value pilot that demonstrates both technical feasibility and commercial uplift (for example, proactive NOC anomaly detection or a churn prediction service).
  • Require proof‑of‑value metrics in procurement: ingest latency percentiles, cost per million events, job reliability, and SLAs for key pipelines.
  • Institutionalise FinOps from day one: job tags, budgets, autoscaling policies and monthly cost reviews tied to business KPIs.
  • Bake portability into the design: use open file formats (Delta/Parquet), exportable metadata and documented exit routines.
  • Treat governance and SOC integration as a deployment prerequisite: Unity Catalog, identity hardening and continuous threat monitoring must be operational before sensitive datasets are joined.

The next milestones to watch​

  • Publication of an MTN or Microsoft technical case study with audited telemetry: this would substantiate the headline ingest and workflow metrics and provide engineering teams with concrete operational benchmarks.
  • Evidence of cross‑market rollouts: MTN plans EVA 3.0 as a blueprint; the first non‑South Africa operating company to run a production instance will be a practical proof of repeatability.
  • Third‑party audits or independent benchmark reports around cost efficiency, MTTR improvements and responsible AI controls. These artefacts will determine whether EVA 3.0 is a durable competitive advantage or an impressive but costly experiment.

Conclusion​

MTN’s migration of EVA to Azure Databricks — promoted publicly as EVA 3.0 — is a consequential and credible step in Africa’s telco cloud evolution. The architecture is sensible for telco workloads: Databricks’ Spark scaling, Delta Lake’s ACID semantics and Unity Catalog’s governance map well to the reality of high‑velocity telemetry, regulatory sensitivity and the need for reproducible ML workflows. MTN’s emphasis on skills (large numbers of Azure certifications) and a Cloud Centre of Excellence demonstrates an appreciation for the people and process work that must accompany any technical migration. At the same time, the rollout crystallises familiar trade‑offs: deeper hyperscaler coupling, cross‑border compliance questions, operational complexity at scale and the need for transparent verification of headline claims. The transformational promise is real — earlier detection of faults, faster operational responses and new AI‑driven products — but the long road to sustainable value depends less on a single migration and more on disciplined governance, cost control, SRE maturity and independent validation. MTN’s EVA 3.0 is a powerful blueprint; the industry will now watch whether it becomes a repeatable model across diverse regulatory and commercial contexts or a single market success that is hard to port.
Ultimately, EVA 3.0 signals that large telco analytics platforms in Africa are ready for cloud‑native scale — provided customers, engineers and regulators insist on the operational detail and hard evidence that turn announcements into resilient, auditable production systems.
Source: htxt.co.za MTN gives Microsoft Azure keys to rest of Africa - Hypertext
 

MTN’s migration of its Enterprise Value Analytics (EVA) platform to Microsoft Azure — now branded EVA 3.0 — is a decisive escalation of cloud-first, data‑driven strategy in African telecommunications, promising radically faster analytics, real‑time operational visibility, and a platform designed to underpin responsible AI use across MTN’s markets.

A glowing cloud icon rains data onto a futuristic city, symbolizing cloud computing and analytics.Background / Overview​

MTN Group’s announcement that it has completed the migration of EVA to Microsoft Azure marks a milestone in a multi‑year push to modernise telco analytics and operational intelligence. The South Africa rollout is positioned by MTN and Microsoft as a repeatable blueprint for other MTN markets in Africa and the Middle East. Company statements emphasize scale, speed, and security as the principal benefits of the new cloud‑native environment. This move sits inside a larger strategic partnership between MTN and Microsoft that began in 2022 and has focused on cloud adoption, upskilling, and joint go‑to‑market initiatives. MTN says EVA 3.0 is built on Azure Databricks with runtime protections from Microsoft Defender, and that it now processes around 22 billion records per day, executes 800+ analytics workflows, and ingests data from ~1,700 feeds. Those headline metrics appear in multiple press reports and in MTN’s own media communications.

Why EVA 3.0 matters​

A step-change for telco analytics​

Telcos operate at scale: huge volumes of event‑level telemetry from base stations, signalling systems, core network elements, and customer‑facing services create a data velocity and diversity that outstrip traditional BI platforms. EVA 3.0 is MTN’s attempt to convert that raw stream into real‑time, actionable intelligence — shortening detection‑to‑remediation time, enabling personalised offers, and supporting predictive operations. The architecture chosen (Databricks lakehouse on Azure) is aligned with modern best practices for combining streaming, batch, and machine learning workloads.

Operational and commercial levers​

MTN frames EVA 3.0 as delivering three business‑level outcomes: improved customer experience through faster detection and resolution of service issues, greater operational efficiency (faster analytics and automated workflow execution), and a foundation for responsible AI — models and features that are governed, auditable, and secure. If realised in live operations, these outcomes map directly to reduced mean time to repair (MTTR), enhanced customer retention, and opportunities for monetising new AI‑based services.

What EVA 3.0 actually is — the technical picture​

Core components and design pattern​

EVA 3.0 is described by MTN as a cloud‑native analytics lakehouse implemented on Microsoft Azure and using Azure Databricks as the principal compute and orchestration fabric. Microsoft Defender and Azure security controls are reported to provide runtime protections and strengthen the platform’s security posture. This combination is typical for enterprises that need both high‑throughput streaming processing and an ACID‑compliant analytical store for large, evolving datasets. Key architectural elements implied by MTN’s description:
  • Azure Databricks as the primary compute layer for Spark‑based streaming and batch processing.
  • A lakehouse / Delta Lake storage layer (Databricks native), enabling streaming writes, time travel, and schema evolution.
  • Runtime security and threat protection via Microsoft Defender and Azure native controls.
  • Integration into MTN’s broader cloud tooling and identity framework (Cloud Centre of Excellence, cross‑market engineering network).

Why Databricks + Lakehouse is a sensible choice for telco​

Databricks scales Apache Spark effectively for both high‑velocity streaming and large batch jobs — a requirement when an operator claims billions of records daily. The Delta Lake format provides transactional guarantees and schema management that simplify pipeline evolution in production. For telcos that must blend streaming telemetry with historical context for correlation and ML, a lakehouse reduces the friction between data engineering, analytics, and data science teams. Industry implementations (not limited to MTN) show this pattern is now a common foundation for large telco analytics modernisation projects.

Scale claims and verification — what MTN is reporting​

MTN reports EVA 3.0 processes approximately 22 billion records per day, executes in excess of 800 analytics workflows, and ingests data from ~1,700 feeds. The company also calls the deployment “the largest telco cloud implementation in the Middle East and Africa.” These figures are consistently stated in MTN’s press materials and have been echoed in independent trade coverage. However, these are company‑reported operational metrics; they have not been independently audited in public disclosures and should be treated as claims until independent telemetry, third‑party audits, or regulatory filings provide corroboration. MTN also highlights a human‑capability milestone: more than 1,350 Microsoft Azure certifications awarded to MTN employees in 2025. The company positions this as evidence of the workforce readiness required to operate and sustain a cloud‑scale analytics platform. Certification counts are a useful signal of investment but are not a substitute for demonstrable operational maturity (runbooks, SRE practices, incident metrics).

Business and customer impact: claimed benefits​

  • Faster issue detection and remediation: Real‑time analytics enables earlier visibility into network and service problems, reducing downtime windows and improving overall service reliability.
  • Personalisation and relevance: Near‑real‑time customer behaviour signals feed decisioning systems to tailor offers, promotions, and network resource allocation.
  • Operational efficiency: Consolidating analytics on a cloud lakehouse can reduce silos, improve pipeline maintainability, and accelerate model retraining cycles. Industry case studies show substantial cost and time savings when enterprises rationalise on modern analytic fabrics.
  • Responsible AI foundations: MTN positions the platform as enabling governed AI — implying model registries, monitoring, lineage, and security controls that are necessary for accountable deployments. The claim signals an intention to operationalise model governance, but concrete implementation details (tooling, policies, audit mechanisms) are not exhaustively described in the company statement.

Security, compliance, and “responsible AI”​

Security posture​

EVA 3.0 is reported to use Microsoft Defender for cloud runtime protections and Azure’s native identity and governance tools. This product set provides workload protection, threat detection, identity management, and data‑access controls — essential for a telco handling personally identifiable information (PII) and regulated network telemetry. While platform‑level security controls are necessary, they are not sufficient on their own: secure design also requires encryption‑at‑rest and in‑transit, strict key management, segmented networks, strong role‑based access control, and continuous compliance monitoring. MTN’s public statements assert enhanced security, but independent security assessments are not published alongside the announcement.

Responsible AI — aspiration versus practice​

MTN explicitly ties EVA 3.0 to “responsible AI” — a phrase that encompasses model fairness, transparency, data minimisation, bias testing, and operational monitoring. A platform that centralises data and model operations can make responsible‑AI practices easier to implement (cataloguing data lineage, enforcing access policies, centralised model registries). However, the presence of tooling does not guarantee responsible outcomes without robust governance processes, diverse training data, continuous model evaluation for fairness, and regulatory compliance across jurisdictions. MTN’s commitment to responsible AI is notable, but independent verification or published governance frameworks would strengthen confidence in the claim.

Strengths: what MTN and Microsoft have set up well​

  • Scale‑first architecture: Choosing Databricks on Azure maps well to telco needs: streaming ingestion, scalable compute for Spark jobs, and a unified lakehouse for analytics and ML workloads. This is a proven design pattern for large data volumes.
  • Enterprise security tooling: Running under Microsoft Defender and Azure’s control plane gives MTN integrated security telemetry and a single vendor stack for patching, identity, and threat detection.
  • Investment in skills: More than 1,350 Azure certifications signal real investment in cloud skills — a critical enabler for operating at scale and for migrating complex OSS/BSS and analytics stacks to the cloud.
  • Repeatability: MTN’s framing of EVA 3.0 as a blueprint suggests potential for rapid roll‑out across multiple markets, unlocking economies of scale and consistent operational practices across the Group.

Risks, tradeoffs, and what could go wrong​

Vendor lock‑in and architectural rigidity​

Opting for a Databricks + Azure‑centric implementation ties many operational components to a single vendor ecosystem. While integration and time‑to‑value are faster, the tradeoff is reduced flexibility and potential long‑term cost exposure. Telcos should weigh the faster delivery against future negotiating leverage and the ability to move workloads between clouds if commercial or geopolitical conditions change. Industry discussions repeatedly flag vendor lock‑in as a strategic risk to manage.

Cost and cost predictability​

Large streaming workloads and high compute in Databricks can be expensive if not tightly governed. The initial migration often reveals hidden costs: long‑running clusters, inefficient Spark jobs, unoptimised storage formats, and excessive retention of raw telemetry. Effective cost governance requires tagging, automated cluster scheduling, model cost accounting, and constant optimisation — none of which are automatic just because the platform is cloud‑native. Case studies of other telcos show material savings when optimised, but also caution that costs can balloon without discipline.

Data sovereignty and regulatory complexity​

MTN operates in many African countries with diverse data‑protection regimes. Centralising analytics in a single cloud region or architecture can run into compliance friction if local laws require data to remain in‑country or impose strict cross‑border transfer rules. MTN will need fine‑grained data residency controls, a defensible data‑governance framework, and likely a mapping of each market’s regulatory obligations to platform features. The company’s Cloud Centre of Excellence will be central to managing this complexity.

Operational maturity and SRE practices​

Certification counts are positive, but sustaining a platform of this scale demands mature Site Reliability Engineering (SRE), runbooks, and incident response playbooks. The hardest proof of success will be measurable operational metrics: reduced MTTR, high pipeline SLAs, and robust fault‑isolation across the lakehouse. Without SRE maturity, the platform risks firefighting, brittle models, and missed SLAs despite advanced tooling. Industry commentary highlights that certification does not equal lived experience in managing large, complex cloud systems.

Model governance and AI risk​

Deploying models at telco scale introduces specific risks: unfair targeting or exclusion in pricing/crediting, leakage of sensitive profiling features, amplification of historical bias in churn or credit‑scoring models, and model degradation when network or product conditions change. Responsible‑AI tooling must be paired with human governance, regular bias testing, thresholding for model intervention, and clear escalation paths when models behave in unexpected ways. MTN’s public statements promise responsible AI, but effective governance will require transparent policies and continuous evaluation.

Practical suggestions — how telcos should approach similar modernisations​

  • Start with a focused set of production use cases that deliver measurable business value (e.g., MTTR reduction, fraud detection, personalised retention offers). Validate with pilots before full migration.
  • Treat governance, security, and compliance as first‑class requirements — embed data residency, encryption, and least‑privilege access into the platform design.
  • Invest in SRE and runbooks as early as cloud migration work — certifications should be accompanied by hands‑on incident simulations and playbooks.
  • Adopt a cost governance program with automated enforcement (cluster shutdown, job scheduling, budget alerts).
  • Implement ML observability and model‑risk frameworks from day one: model lineage, performance monitoring, bias testing, and rollback procedures.
These steps reduce the “build it and hope” risk and turn a modern analytics stack into a sustainable operational asset. Industry case studies from other large telcos show meaningful gains when these practices are applied.

What to watch next​

  • Proof in production: Look for published metrics on MTTR, customer‑facing performance improvements, or independent case studies showing business outcomes from EVA 3.0. So far, scale and capability claims are public but operational KPIs are not yet fully disclosed.
  • Cross‑market roll‑out: MTN has indicated EVA 3.0 will be used as a blueprint across other African markets. The real test will be how MTN adapts the architecture to local regulation, connectivity constraints, and market‑specific operational models.
  • Governance artifacts: Public release of policies, audit results, or compliance attestations would strengthen confidence around the “responsible AI” claim. Watch for whitepapers, compliance reports, or third‑party audits that detail the governance model.
  • Cost and vendor management: As usage grows, observers will be watching for evidence of cost optimisation, multi‑cloud strategies, or negotiations that reduce long‑term vendor exposure. Industry commentary suggests telcos should monitor lock‑in and cost trajectories closely.

Verdict: meaningful progress, conditional on governance and execution​

EVA 3.0 is a bold, well‑aligned technical move for a major telco: leveraging Azure Databricks and integrated Microsoft security services positions MTN to exploit real‑time analytics and accelerate AI use cases at scale. The investment in skills and a Group‑level Cloud Centre of Excellence addresses a major historical blocker for telcos: the shortage of cloud‑native expertise to operate modern data platforms. However, the announcement is primarily a statement of capability and intent rather than a full audit of results. The most consequential questions are now operational: will EVA 3.0 measurably reduce incident resolution times, enable new revenue streams, and maintain compliance across multiple jurisdictions? Will MTN demonstrate robust model governance, cost control, and resilience in the face of cloud outages or adversarial attacks? These are the outcomes that will separate a successful modernisation from an expensive platform migration.

Final thoughts for the WindowsForum audience​

MTN’s EVA 3.0 is a case study in how a major operator and a hyperscaler can jointly deliver a large, cloud‑native analytics platform. For operators, enterprise IT leaders, and cloud architects, it offers both opportunity and a checklist of challenges that must be managed: security, governance, cost discipline, SRE maturity, and clear metrics for business impact. For Microsoft and Databricks, it’s a high‑visibility win in a strategically important region, but one that will be judged on operational outcomes as much as on implementation scale. The next six to twelve months — when live metrics and market roll‑outs begin to accumulate — will determine whether EVA 3.0 is a landmark technical achievement or an infrastructure milestone whose true value is only revealed in downstream business outcomes.

Source: Businessamlive https://businessamlive.com/mtn-microsoft-partner-on-eva-3-0-to-strengthen-ai-capabilities/
 

Back
Top