/ Lifecycle Management /
Lifecycle Management ensures all logical and physical assets held within the organisation are correctly managed and maintained. Lifecycle Management includes ensuring:
- There is no unnecessary duplication of data or assets, but there is sufficient to meet current and forecast business needs;
- That all data and assets are compliant to business, technical, regulatory and vendor regulations, especially with regards to access and security;
- That data and assets do not become outdated;
- That there is no incorrect or inconsistent data or assets present in the organisation;
- That there is no surplus or unnecessary data or assets present.
In some ways, Lifecycle Management begins with the Capacity Management use case, where network plans for growth and contraction and where technology evolution is determined, and execution is initiated.
Tracking the usage of network resources to identify where capacity constraints may become an issue is a key enabler to planning and delivering network growth.
Real-time usage trends coupled with usage forecasts moderated by strategic objectives can ensure that costly investment is appropriately focused in a timely, just-in-time fashion.
Capacity Management where networks plan for growth and contraction and where technology evolution is determined, and execution is initiated
In some ways, Lifecycle Management begins with the Capacity Management use case, where network plans for growth and contraction and where technology evolution is determined, and execution is initiated.
Tracking the usage of network resources to identify where capacity constraints may become an issue is a key enabler to planning and delivering network growth.
Real-time usage trends coupled with usage forecasts moderated by strategic objectives can ensure that costly investment is appropriately focused in a timely, just-in-time fashion. This is not about measuring the real-time capacity metrics for the currently installed network resources, but about identifying when and where new capacity will be required, or existing capacity will be retired.
The decisions will reflect the strategic vision of the CSP, the technical evolution of its suppliers’ network equipment, as well as market demands. Once decisions have been taken, they are realised through the Physical Design & Assign and Logical Design & Assign use cases.
Logical design and assign activity results in any logical resources (numbers, VPNMs, circuits, etc) related to the requested services being created, modified, or deleted as necessary. This will involve interaction with possibly many different inventory systems. The logical resources are selected for use by the service according to the service-specific technology rules, reflecting the CSP-defined service architecture (and intended, for example, to ensure correct service operation as well as avoiding network element performance problems), and their availability in the inventory system is updated accordingly.
Different service types (e.g., SIP, IPVPN, Mobile, IPTV, etc.) will require different types and combinations of logical resources, and there will be business rules, technical standards and equipment vendor recommendations which will affect which resources may be allocated for a given service.
Physical design and assign includes the identification and specification of any physical resources required to complete the order. This may include:
- CPE such as modems, routers, set-top boxes, and mobiles.
- new physical connections (copper, coax, fibre) either from the CSP’s equipment to the customer location, or between CSP equipment
- new street-side distribution cabinets
- additional cards, racks or similar which are required to be installed in the CSP data centres.
- new network elements to be installed in the CSP’s data centres or telephone exchanges.
Some of the physical equipment may need to be shipped to the customer for new service order line items; for modify or cease order lines existing equipment already in the customer’s possession may need to be returned/retrieved for recycling or reuse initiatives.
Stock may be picked and shipped from the telco’s warehouse, or they may have outsourced this to the stock vendor or another third party. Whatever the implementation, the telco must ensure that the equipment is correctly received by the intended recipient, and where not must have in place appropriate procedures to resend it if necessary.
There may need to be an installation of physical equipment, maybe in corporate data centres which will be undertaken by an in-house team, or there may need to be an outside plant installed with associated civil engineering works, or this may be a customer-facing service that is required to install e.g., a modem in a customer location, or to provide setup and training services at a customer house.
Where an outside plant such as street-side cabinets or last mile connectivity is to be installed, this may require appropriate licences or permission from local authorities for digging up roads, or agreeing wayleaves with landowners.
Scheduling and agreeing installation dates with customers can be an extended process with many changes. While not particularly complex, this can be an extended process with many information exchanges and reschedules as availability changes.
Before the in-house or subcontracted field force installation activities can begin, there may need to be some validations or preparatory actions undertaken; additionally, actions, such as undertaking safety-related commissioning tests, may also be required as part of the installation activities.
After installation has been completed there may need to be some standard data and service configuration to be provisioned on the equipment. The relevant inventory systems will need to be updated to reflect the new availability and status of the equipment, and of any physical and logical sub-components of it.
Upon completion of the logical, physical and third-party component changes for a product, and depending upon the service complexity, to ensure everything is Ready for Service, a series of tests may be performed prior to handover to the customer to ensure that the service is working as intended.
These tests may form the basis of future tests also run for Customer Experience and Service Provisioning that can be executed when a customer reports a problem, as a customer self-service mechanism accessible via a website of mobile app, or as part of a routine service quality assessment by the CSP.
Errors or quality issues identified during this assessment may cause trouble tickets to be created, which in turn may result in automated or manual diagnostic and resolution activities.
Being able to recognise Faults and Events in delivered services is a key component of Service Assurance. Automation tools like CORTEX can automate more than 99% of the faults leaving a very small number of faults, as opposed to tickets, to resolve. Fault and events are usually reported by network elements directly into the trouble ticketing system.
Once reported to the trouble ticketing system, the faults or events must then be classified, prioritised, and correlated with other reported faults. After the traffic is distilled, root cause analysis of the fault is performed by gathering data/evidence and applying heuristics/logic.
A set of rectification actions will be identified based upon the root cause, and these are applied to rectify the fault and resolve the issue.
If the fault cannot be rectified, then it may be possible to minimise the impact of the fault by, for example, re-routing traffic; fault rectification can then occur at a later time.
As part of this activity, a trouble ticket may be raised or updated in the trouble ticketing system; updates to this ticket will document the activities undertaken during the fault resolution activities.
This can be used as an audit of activities performed during a subsequent review of the incident; as input or supporting information to customer SLA reporting; or to ease the handoff between people of the issue. This process can be substantially automated, and in some cases fully automated.
Tracking the performance of network elements and the services they are delivering can help ensure that customer satisfaction is maintained, but can also be used to identify opportunities for cost mitigation, as well as to provide early indications of possible faults. Similarly, it is possible to track the Resource Compliance, more than the condition of network elements, this should identify that they meet the cyber compliance and manufacturers’ compliance requirements.
A typical self-healing automation process would identify:
- Known configuration of an element and confirm its compliance,
- Known configuration of an element and confirm its failure with compliance.
- This can be fully automated and will self-heal. Similarly, the same automation can be used to determine:
- If there is no known configuration of an element, which would trigger work to establish said configuration, the to build automation routines and bring the elements under automated governance and,
- Which elements are not checked for configuration or compliance. This would lead to more substantial work with the CMDB/inventory systems to properly identify elements, then to establish said configuration, to build automation routines and so on.
In the current climate of TSA, NIS2 and similar legislative requirements, an automated LCM process is vital.
The Performance Management use case monitors current network resources for over or under-threshold KPIs, and also for long-term trends (either in real-time or on a scheduled or on-demand basis). When a monitored performance threshold is breached, an event can be generated, which will initiate the Fault or Event Management use cases.
Problem Management is a set of use cases aimed at preventing incidents or reducing their impact. Following the successful resolution of a fault, lessons learned are extracted and changes made to the network or service architecture (to avoid or limit the fault impact), or to the fault diagnosis and resolution activities (to limit its impact and to reduce mean time to resolution). Potentially, the KPIs and their associated thresholds monitored as part of the Performance Management use cases may also be modified as a result of these use cases.
Ensuring appropriate Access Management to systems and data is also critically important. Access must be controlled and maintained on an as-needed basis, and auditing that access on a regular basis is a key requirement not just for cybersecurity but also for Service Assurance.
Limiting the access to network-related systems and data by unauthorised, unqualified or malicious people limits their ability to change configurations that might adversely affect network operation or service quality.
Read more about Cyber Compliance.
Access rights to these systems must be reviewed as employees join and leave the company, but also as they move roles or have changes in responsibilities. Contractors and suppliers may also have a need for access which must be approved, audited and revoked as appropriate.
Regular validation of systems and data can help ensure that your network infrastructure is correctly and appropriately configured. This includes activities such as:
- Inventory reconciliation, where actual network configuration is compared against that held in network inventories. Discrepancies can be resolved by updating the inventory, by reconfiguring the network or by a combination of both, depending upon the exact nature of the delta.
- Routine maintenance, such as log archiving, disk space management, or regular restarts. This should be done in line with business, technical or vendor recommendations, and will help ensure the ongoing smooth operation of the various network elements.
- Validation of configuration against regulatory, business, technical or vendor policies. Where discrepancies exist between actual and expected configurations, actions must be taken to resolve them. Typically, this will involve updating the network elements to bring them in line with the requirements. Depending upon the type of change required, it may be possible to accomplish it in real-time as it is discovered, or a change request process may need to be initiated to make the change at a later time in line with the service SLAs or when convenient for the customer.