Processes and Services

Automation is not adopted  - either by the organisation or by individuals. Configuration is done manually using element management interfaces (CLIs or GUIs). Integrity is completely dependent on engineers.

Automation efforts are scattered and isolated. Single repetitive time-consuming tasks such as updates are automated by devising individual automation scripts that are then run when needed. These approaches are not coordinated in any way.

Task-specific automation is now transforming into process-level automation on the level of specific use cases (projects) that are being implemented.

The direct element configuration is abandoned; well-defined processes that are run and overseen by an orchestration engine are now in place. Integrity is guaranteed using input validation and a "single source of truth" approach. Implemented processes are able to guarantee stable configuration and correct information no matter whether  the process has been completed successfully or the process has failed (graceful exit).

Continuous improvement is implemented using the process feedback information. The initial steps towards the implementation of closed control loops are being implemented. Prediction information is used to make automated adjustments.

High-level business intentions are the only input to the system that then automatically triggers processes to implement the desired effects. Decision engines analyse the provided analytical prescriptions and initiate automated self-configuration/adjustment processes.

Formal/informal service configuration procedures are available outlining service-specific actions that need to be taken to manage a service. Service description in the service portfolio is available only in text format. Services are not described in a standardised manner.

Technical service specifications are available which describe the technological aspects of the services. Data modelling languages are being investigated in sporadic attempts to create a formal service specification definition. Service design practices such as “customer journeys” are being explored.

Chosen pilot services are being defined using service design practices. Data models are being built around these services and their service parameters are being defined (e.g. using YANG or XML).

Service design is embedded in the day-to-day activities. Parameterised service specifications exist for all services in the service catalogue and they are available in a machine-readable format ready to be consumed by different functional blocks. Specification activities follow a common approach. Resource Facing Services (RFS) and Customer Facing Services (CFS) are recognised as necessary.

Service specifications are defined as a combination of highly granular puzzle pieces that represent different parts of a resource-facing or customer-facing service. New services can be designed using readily available puzzle pieces.

Users become an active participant in service design. They are able to build their own custom services using  available service puzzle pieces in a flexible manner. The service design process is fully automated and streamlined to optimise the  customer experience.

All necessary service lifecycle management actions (device configuration, inventory record keeping, ticket updates, billing, etc.) are done manually.

Members of the operations team start to automate specific tasks that are part of the service lifecycle management processes in order to save time or increase reliability.

The service lifecycle management processes for certain services may be fully automated. The processes may be different for discrete services. There still may be manual steps in the process that require human confirmation - regarding configuration or other sensitive changes - because operational staff do not  trust the automated process.

All services are now managed in a fully automated fashion using well-established common processes. A self-service portal for end-users may be in place providing key information related to service instances.

Service lifecycle management processes are able to adapt to the current network state. For example, if a problem is encountered during the implementation of the main process workflow the system tries alternative ways to complete the process successfully before giving up and reporting a failure.

A fully-fledged self-service management is available where users only need to express their high-level intentions; everything else is inferred by the system. The orchestration processes are implemented using intelligent branching based on gathered information and analytic inputs.

There may be a lot of different monitoring tools and they work in silos. Tool configuration and alarm definitions are done manually.

Monitoring is housed within multiple, independent systems. There are dedicated monitoring tools that cover a number of technologies. There is some automation involved when it comes to preparing regular reports.

Service end-to-end visibility is available for certain use cases. Monitoring tools are being consolidated. Start/end of monitoring of chosen services is done automatically. Reporting for these services is also automated.

Every service/resource is automatically registered and classified on an overarching monitoring platform. The infrastructure - network, compute and storage - is seen as one unified view. Reporting is fully automated.

This is a stage of proactive service-level monitoring. In addition to real-time context-aware monitoring information, alarms are now predictive and provide information about potential future alarms based on AI modules. Instant detailed reporting is automatically made available.

The monitoring system requires no human intervention. The monitoring platform constantly learns from multi-user and multi-domain datasets. Anomalies are detected long before they become problems. User-customised reporting is automatically generated.

Troubleshooting is done in a very limited context. There may be too many unnecessary changes - and thus critical alarms may be hidden or overlooked due to alarm storms. Correlation of information from separate systems is extremely difficult.

Teams need to consult multiple tools and datasets to troubleshoot issues. Root-cause identification is very difficult since correlation is still performed manually. Automation is found mostly in the ticket management procedures.

Dashboards are used to provide a combined view of service information. Some alarms are recognised as related to the same service and are combined together automatically.

Troubleshooting is done using a single data pool. There is some small degree of machine learning implemented in the troubleshooting workflows - but no predictions yet. Root-cause analysis is automated.

Machine learning is used to extract essential insights from large pools of operational data. Predictions are made regarding potential issues and mitigative steps are  taken to avoid degradation. Root cause analysis and remediation are automated.

The system analyses data and repairs issues on its own. Failover is fully automated. Issues are resolved without any user input. Data and rules for self-healing algorithms are in use.

Isolated security logging in functional silos. There is no formal incident response process. The organisation is unaware of threats - internal, external and advanced persistent threats (APT).

No formal incident response process; no processes to manage security compliance violations. Some security activities are automated using simple scripts. Unaware of APTs and most threats.

There is minimal compliance mandated for monitoring and response. A process to manage security compliance violations is in place. Automation is used to set up the initial security configurations. The organisation is still unaware of most threats. There is no formal incident response process.

Reactive and manual threat intelligence lifecycle. Basic monitoring and high-risk alarms processes are automated. Basic incident response process is established. Good visibility of threats. Automation is now extended to reactive adapting of security configurations based on threat alerts.

Formal and mature monitoring and response processes with standard playbooks for most common threats. Targeted automation of investigation and mitigation workflow. Effective processes in place for monitoring of alarms. Proactive threat hunting. Leveraging automation to improve the efficiency and speed of threat investigation and incident response processes.

Established, documented and mature response processes with standard playbooks for advanced threats (e.g. APTs). Extensive automation of investigation and mitigation workflow. Fully autonomous automation - from qualification to mitigation - for common threats. Automated threat qualification, investigation, and response processes wherever possible. Recognising and quickly responding to all classes of threats early in the Cyber Kill Chain.