In a large financial institution, the network isn’t just cables and code—it’s the nervous system of the business. Yet many banks still operate this critical infrastructure through manual effort and tribal knowledge.
When people want to get fit, the first step isn’t running a marathon—it’s understanding their current health. Are you sedentary, moderately active or marathon-ready?
Network organisations face the same challenge. Before attempting large-scale automation or NetDevOps transformation, you need a clear understanding of where you stand today. A maturity assessment provides that baseline and helps determine the right path forward.
Why a NetDevOps Maturity Model Matters
There are many NetDevOps maturity models available, and any of them can serve as a starting point. The key is to adapt the model to your organisation and link it directly to business outcomes.
Without that connection, network transformation often becomes an expensive infrastructure refresh rather than a strategic capability.
Before evaluating technology, organisations should first ask a few foundational questions.
Key Questions
What business capabilities are we enabling?
Lower trading latency
Faster onboarding of markets or exchanges
Improved resiliency for trading platforms
Faster incident recovery
Regulatory and audit compliance
Cost optimisation
Which business functions depend most on the network?
Electronic trading platforms
Market data systems
Clearing and settlement
Client connectivity
Research and data science
What pain points does the business experience today?
Outages affecting trading operations
Slow deployment of connectivity
Inability to scale infrastructure
Limited visibility into network performance
Answering these questions helps anchor the maturity model in real operational outcomes, not just technology improvements.
Business Outcomes
A useful maturity model begins with clear value pillars. For example:
Every improvement in architecture, automation or operations should map back to one or more of these outcomes.
NetDevOps Maturity Levels
A typical NetDevOps maturity model progresses through five stages:
Each level reflects both technical capabilities and organizational behavior.
Level 1: Reactive (The Status Quo)
What it looks like
Everything starts with a ticket. Engineers log into devices manually and IP addresses may still be tracked in outdated spreadsheets.
Typical behaviours
Heavy reliance on individual experts
High anxiety around change windows
Limited documentation
Client experience
Application teams often wait weeks for basic changes such as VLAN updates or connectivity adjustments.
Metrics / KPIs
Lead time for change: 10+ days
Change success rate: <85%
Audit preparation: weeks of manual evidence gathering
Level 2: Task-Based Automation (The Scripting Trap)
What it looks like
A few engineers begin automating repetitive tasks with Python or Ansible.
Typical behaviors
Automation exists but is informal
Scripts live on individual laptops
No shared repositories or standards
Client experience
Some requests are faster, but outcomes depend heavily on who handles the task.
Metrics / KPIs
Automation coverage: <20% of tasks
MTTR improving for known issues but inconsistent overall
Level 3: Integrated Workflows (The Turning Point)
What it looks like
Automation evolves into structured workflows. Tasks are no longer isolated scripts but part of repeatable processes.
For example, a disaster recovery test might involve automated failover, verification, and rollback across multiple systems.
Typical behaviors
Introduction of a source of truth (for example NetBox or IPAM)
Standardized automation workflows
Version-controlled configuration management
Client experience
Requests are handled consistently regardless of which engineer is on shift.
Metrics / KPIs
Workflow completion rate: percentage of changes handled by automation pipelines
Configuration drift detection and alerting
Level 4: Network as a Platform
What it looks like
The network becomes a platform with CI/CD pipelines and automated testing. Configuration changes are validated in a virtual environment before production deployment.
Typical behaviors
Guardrails replace manual approvals
Engineers focus on platform development rather than ticket execution
Client experience
Application teams can provision network resources through APIs or portals without waiting for manual intervention.
Metrics / KPIs
Lead time for change: <1 hour
Deployment frequency: multiple times per day
Continuous compliance and automated validation
Level 5: Adaptive / Intent-Based Networking
What it looks like
The network understands and enforces intent. Instead of configuring individual elements, engineers specify outcomes and the system adjusts automatically.
Telemetry continuously monitors conditions and triggers self-healing workflows when problems occur.
Typical behaviors
Closed-loop automation
AI-assisted observability
Strategic focus on optimization rather than manual operations
Client experience
Infrastructure becomes largely invisible—the network simply works.
Metrics / KPIs
Mean time to detect (MTTD): near zero
Self-healing success rate: percentage of incidents resolved automatically
How to Run a Maturity Assessment
Rather than simply assigning a score, the assessment should be a structured cross-functional exercise.
A common approach is to run a workshop involving engineering, operations, security, and business stakeholders.
Typical steps include:
Gather stakeholders – include skeptics, application owners, and compliance teams.
Identify operational pain points – focus on where processes break down.
Define desired business outcomes – reliability, speed, resilience, or cost efficiency.
Align on a maturity model – map current capabilities to maturity levels.
Map a real workflow – for example, a disaster recovery test or branch rollout—and examine how it operates at different maturity stages.
The goal of the assessment is not to produce a scorecard. It is to create a shared understanding of where the organization stands today.
Conclusion
A NetDevOps maturity assessment is not about grading the network team or proving technical sophistication. Its real value is alignment.
When engineering, operations, security, and business stakeholders share the same view of the network’s current capabilities, transformation becomes far more practical. Instead of debating tools, teams can focus on outcomes.
This clarity becomes the foundation for meaningful change.
In the next article in this series, we will build on this assessment and explore how to translate maturity insights into a practical NetDevOps roadmap, prioritising initiatives that deliver measurable business value rather than automation for its own sake.