Transforming telecommunications service execution

A recent estimate suggests 60% of global software spend (approximately $50Bn) is on software maintenance. Thirty percent of this is associated with software comprehension dealing with the inherent complexity of software. Other factors include insufficient governance of the software development process and a lack of comprehensive documentation of the final software product. Often the only comprehensive documentation of software, essential to plan new versions and undertake maintenance, is the software source code itself. The latest developments in the software industry are aimed at improving software governance and the automation of documentation creation. One such technology is Software Product Line (SPL). SPL is an innovative software governance and reuse approach. It introduces a robust technique which enables the planning and creation of reusable software units at the start of the software development. It is distinguished from most other software development methodologies by the comprehensive scope of reuse - not just source code but all the types of software assets involved in the development lifecycle, such as user requirements, architectures and test plans. SPL is defined by two development processes, 1) domain engineering and 2) application engineering. Domain engineering creates a reusable software platform whereas application engineering derives different versions of the product from this platform. The reusable software platform consists of different software assets such as requirements models, architectural models, software components, test plans, and test designs. A group of software assets defining a specific capability or functionality are grouped as a feature. Each new software product created by SPL is defined by a unique combination of features. The relationship between features are captured in a feature model which defines the product line. The feature model and the reusable software assets are fed to the application engineering process. Here, different features are selected to determine which software assets will be included and configured in a new product. The output of this process is a collection of configured software assets, typically a new (version of) product or software, ready to be deployed. Many organisations are using SPL to achieve extraordinary gains in productivity, time-to-market, and product quality. A good application area of the use of SPL in the telecommunications industry is in Network Function Virtualisation (NFV). NFV aims to address cost reduction and flexibility in network operations - network functions are implemented as software running over a virtualised infrastructure and provisioned on a service-by-service basis. NFV can benefit from SPL by adopting a systematic method for customising network services to accommodate diverse requirements. Not only does this enable the proper planning of NFV platform software artefacts, but it also enables a robust customisation of the chain of service functions that can adapt rapidly to situations, such as fluctuations in the network execution environment, and service failures. The challenges of SPL methodology include managing the variability information; lack of suitable tools to fully support the methodology; legacy systems where knowledge of the architecture and software components is not available. To address this, BT and Etisalat commissioned research by EBTIC (an ICT research and innovation centre established by Etisalat, BT, and Khalifa University and supported by the United Arab Emirates ICT fund) into the development of the EBTIC-SPL tool. The tool is currently being trialled and has demonstrated the potential for improved software comprehension and governance. As software increasingly underpins the services that telcos deliver, the importance of understanding and applying the best software engineering practices is critically important to service quality, speed of new service delivery and service flexibility. SPL is one of the most important approaches that telcos should be considering.