In another Think Tank article i discussed ‘The industrialisation of the telecoms industry’. This is in contrast to today’s paradigm of the ‘medieval craft telco’, where every network is created as one-off bespoke activity, together with the supporting systems.
As promised, I am digging into one of the opportunity areas that I highlighted. The operational integration of systems is a key problem area. To explore this subject, I interviewed Richard Mishra, who is CEO and co-founder of Standard Interoperations Ltd (SIO). His company is actively developing new solutions to ‘collapse complexity’ in this space, and hence to industrialise network integration and operation.
Martin Geddes: What is operational integration?
Richard Mishra: In every telco, we must somehow assure the quality of the user experience being delivered over a data network. It is not enough to turn on the network and for it to work just for a day or a week or even a month, as you need to keep everything working continuously. At some timescale, everything is mission critical: both network elements and their business support systems. Today we see the systems as no longer ‘supporting’ and long-term, but integral to the service and immediate.
Every telco has a desired level of service to the user, and creates an end-to-end business process to support it. What is missing today are (implicit or explicit) contracts between all the systems to enable the service provider to operate as a highly-connected and responsive unit.
Operational integration is about ensuring and assuring that performance of complete systems when in operation. This activity includes a collection of common capabilities, such as customer experience management (CEM), service quality management (SQM) and fault and performance management. These are all connected by the service levels the provider promises to its customers.
MG: What is the problem with operational integration that needs to be solved?
RM: The world is transforming away from late 20th century approaches to building communications networks. We are still in a situation where a software system that costs a few hundred thousand dollars to buy can easily cost several million dollars to operationally integrate. This cost structure is backwards and unsustainable. Unless there is to be chaos, we need to move to new 21st century structures that tame the cost and complexity.
To resolve this issue, we need to simplify operational integration by reducing (or hiding) the variability between implementations. There is an ‘80:20 rule’ at work here. After several decades, we now have a solid understanding of what the core operational systems are, and a consensus on the demarcations. Major software systems like CRM and fault management align to particular duties or business divisions that are near-universal.
We are now defining and standardising these ‘bread and butter’ everyday operational integration tasks. Our goal is to collapse the complexity involved, and radically reduce the cost. The way we plan to do this is by the introduction of operational integration standards, abbreviated to ‘OIS’ (and rhymes with ‘noise’).
MG: How do operational integration standards work?
RM: With OIS, we identify the dozen or so core operations performed between each pair of systems, and specify the performance needs for those interactions. We focus purely on what is required operationally for the business, without trying to model everything that is technically possible. Critically, we are not doing it bottom-up. That would require analysing each of the hundreds of possible commands to send between OSS or BSS systems before we can make any progress and create value.
IT-literate readers may think: “Aha! This is service-oriented architecture!”. This is a category error: OIS models the operational coupling between the systems and their performance, not the advertised services of any one system. Whilst we may use SOA capabilities inside OIS-enabled management and monitoring systems, we are only concerned with the automation of the ‘operational integration’ (with emphasis on bothwords).
What we do in practise is to construct a canonical model for each standard job or process. The tool-set generates machine-readable ‘contracts’ that describe the operational relationships, and can be ingested by the operational management systems, which then execute to those specifications.
MG: Where does this effort currently stand?
RM: We have developed a domain specific language (DSL) for enterprise integration and gone through an initial ‘proof of platform’ for OIS tooling. Standardisation is unlikely to be successful unless it is supported by the right tools, which we will offer as SaaS.
Standard Interoperations’ business model is based on membership, which licenses the use of OIS for telecoms, and bundles-in the tool chain. In addition, we offer training and consultancy to support the sector in OIS adoption. The language and specifications themselves are under the copyright control of Standard Interoperations to ensure the ongoing integrity of the standard, but are freely available to all in the telecoms sector who are signed up to use OIS.
MG: Who will use OIS tools and standards?
The network equipment vendors are our first target, since they have an obvious problem. They themselves are an amalgam of many acquisitions, and can be responsible for the operation of networks through outsourcing deals. They are obliged to integrate a variety of equipment, such as LTE, both with their own systems as well as the huge variety of systems found in their customers. All of this integration is pure cost for them, and may hold up equipment sales. There is no reason LTE provisioning should take a massive new integration project, as if we’ve never done any of this before.
Beyond the network equipment vendors, our next targets are the service providers. They also have the full complexity problem of integration with many operational and business support systems. The regulators and standards bodies are potential partners in this endeavour.
MG: How do you see this playing out in the longer term?
RM: There is a bigger picture here, beyond automating and standardising of the creation of the basic operational contracts.
Today, there are endless systems alarms going off, but many are false positives. Operators have no way of joining the pieces of information together. They don’t know what data to gather, or over what timescales the issues are occurring. It is hard for network administrators to distinguish real issues from ordinary system performance variation. Engineering talent is therefore wasted on chasing tactical issues, rather than creating strategic business value. This situation is made much more demanding in the transition from 20th century telecoms services to modern media and applications services.
We can join together the network, service and customer layers into one management domain. Pick your service level goals, set the dials on the system to the designed cost and performance trade-off, and the systems will deliver that.
Beyond telecoms, OIS is applicable to any sector where enterprise systems need to be integrated in a consistent and repeatable way.
MG: How can this vision be achieved?
You need to consider every network element and business support system as being part of a single holistic service delivery platform. That platform has two phases to the challenge of operational integration:
- Design-time, where you want to know the capabilities and constraints of operational systems at your disposal (or will need to acquire). You don’t want to commit yourself to something you can’t deliver.
- Run-time, where metrics inform decisions that need to be made to keep the system meeting its business goals. What happens in telecoms networks is that all elements get worse over time. Things fail, and more variation is introduced with patches and fixes. Complexity increases.
As a CIO or CTO, you want a complete model of the totality of these systems and their ongoing performance.
We envision a world where design-time resource planning is fully integrated with a run-time continuous health monitoring, not just of the network and the end user service, but of the operations systems, because they are no longer just ‘supporting’. This needs to happen without hiring armies of specialist performance engineers, and thus has to be fully automated.
With OIS, you know not only what is supposed to happen, but you also have formal contracts that reflect that. Longitudinal metrics capture the adherence of systems to their performance contracts over time. The monitoring systems can then tell you whether there is any unplanned variation in performance.
For that to occur, we see a need for a richer language in which to specify all the operations with performance couplings, such as the time frame for each job to be done, and the resources consumed. Trade-offs of resources and performance should be made explicit and under the control of the business.
MG: How does this differ from the activities of existing industry bodies like TM Forum?
RM: Bodies like TM Forum are a great place to meet like-minded people with shared issues. They are good places for problems where you need to have everyone on board. Their limitation is that you cannot allow serious disagreements. That makes it hard for them to tackle the OIS issues, which break new ground. Bodies like TM Forum would be obliged to attempt to please everybody, which in practise would serve nobody.
In contrast, we have a prescriptive approach to our standards, without a drawn-out consensus-making process. We feel it is necessary to take a proactive lead, based on our long industry experience and deep domain knowledge.
MG: Are there any winners and losers from OIS?
There are many experts in the telecoms business who understand the core operational requirements, but today this expertise is not truly valued, collated, maintained and distributed. Instead, IT graduates are asked to invent solutions from a blank sheet from requirements that are usually out of date before the systems are delivered. As a result, we keep on re-inventing the wheel, and it’s not always a very round one. Once we stop doing that, we can afford innovate on the chassis. OIS builds a bridge between operational expertise and IT, and so helps to relieve this endemic skills shortage that hinders the whole industry.
In the medium and long term we see OIS helping enterprise system integration to shake off its reputation for under-delivery and project deadline and cost over-runs. We see this in frequent and shocking headlines, mainly from the public sector, who have an obligation to disclose how they spend public money. Anyone with the right experience will confirm the problem is universal. OIS is a critical step in the industrialisation of enterprise software.
In the short term, those businesses who rely on software being a hand-made craft will need to re-focus to apply their skills to higher-order, reusable technical and business problems. Ultimately, OIS is good for everyone in the telecoms value chain.
If you would like to learn more about Standard Interoperations Ltd (part of the people2persons brand) see www.people2persons.com, or contact Richard Mishra directly at richard@people2persons.com.
To keep up to date with the latest fresh thinking on telecommunication, please sign up for the Geddes newsletter
Read It Now
