We hear that a lot now in our space. Automation not only reduces opex, but it also speeds up the delivery of new services. Get rid of manual requests between people and departments and companies, and replace them with machine to machine interfaces. Months to minutes to deliver a multi-operator connectivity service. It sounds so easy but it's hard, very hard. On at least three fronts.
The first front is organizational. Organizations are built not only of people, but structure and processes that run through the structure between people. Changing the flow of those processes for the purposes of automation by having them bypass those existing structures and people is not an easy task for management. Especially when they don't want to damage revenues from existing products and services, and when they have to do their best to keep and re-skill their employees rather than a series of mutually traumatic firing and hiring events.
The second front is commercial. Collaborating with competitors doesn't come easily to anyone. To get services automated means agreeing with your competition on what information you are going to share at the speed of software calls. That means possible, if accidental, exposure of potentially sensitive commercial information. Management is going to think very carefully before risking having their IT departments 'run riot' with new software directly connected to their competition.
The third front is technological. It takes time to work out what is the minimum effort required to implement meaningful automation, especially when it requires involvement of technology and commercial partners. For example, implementing an API that is acceptable to both a service provider buyer of wholesale services, and its partner selling those wholesale services is often far from a trivial task.
Developing standards is essential for implementing software-driven automation between different organizations and even between parts of an organization. But we can see that it only helps with that third technology front - and even there, standards are just part of the story.
Service providers are implementing digital transformation in order to stay ahead of their competition and to keep up with their customers and new customer applications. We can call it 'MEF 3.0' for short. MEF needs to help on all three fronts - organizational, commercial and technological - of this digital transformation of service providers.
The MEF 3.0 Service Fulfilment & Activation (F&A) implementation project is the first example of a new approach being driven by pioneering MEF members.
Dr. Ahmad Khalil at Tata Communications, Daniele Mancuso & Gabriele Laghi at TI Sparkle, and Sarit Tager at ECI Telecom are driving this project. They have interconnected three production networks to form a live connectivity service from Hong Kong to New Jersey via Frankfurt which is orchestrated according to MEF LSO principles. Well, they didn't do it all by themselves of course. They got help from colleagues in their respective companies. And this is the key.
Daniele from TI Sparkle highlighted this explicitly in his MEF17 workshop panel. This MEF 3.0 F&A project is a valuable vehicle for TI Sparkle, for example, to engage different parts of the organization in its drive to implement LSO-SDN-NFV based services. Rather than rely on a the product team to internally educate, through whiteboarding alone, the different departments on what they need to expect as new MEF 3.0 services get rolled out, they can actually get them involved in a practical fashion in a safe prototyping environment of a MEF 3.0 service, while engaging with friendly partner service providers on the interoperation and automation aspects. Many in the MEF will know Alessandro Talotta, CEO of TI Sparkle and MEF Board Member. His commitment to this transformation in TI Sparkle is exemplified by his encouragement of the very central participation in this project.
Ahmad at Tata Communications has had a similar experience. He, together with his Tata colleague Jeff Schwartz - also a longtime Carrier Ethernet services champion in MEF - was able to introduce us to Peter Juffernholz, AVP Virtualized Network Services at their company during his visit to MEF17 which allowed us to brief Peter more effectively about all the relevant MEF work going on in his space. This is just one example of Ahmad and Jeff using the MEF 3.0 F&A project to evangelize MEF 3.0 topics within their company, and get different departments to internalize the potential significance of MEF projects for Tata. It was also noted during the MEF17 workshop panel that getting the original interconnection of ENNIs was relatively very easy due to the MEF's standardization work (e.g. MEF 26.x) whereas the bureaucratic process part of coordination with the wholesale partner Operator required a lot of internal effort. This was a valuable lesson for everyone in the project.
Sarit at ECI Telecom sees a very different aspect of the project. Internal coordination in her company is not factor. Being software driven, the company is already largely in devops mode. (Service providers are not there yet but they will need to be eventually in order to truly take advantage of MEF 3.0) However, being able to sandbox solutions in a non-commercial context for the service provider participants in the project means that her company can communicate and understand the service providers' (both existing customers and potential customers) position in the transformation process to MEF 3.0. This plays out in questions of LSO implementation, use of LSO APIs (e.g. LSO Presto NRP and the LSO Sonata Ordering) and many other facets of introducing LSO orchestration.
So Ahmad, Daniele, Gabriele, and Sarit are sandboxing "months to minutes" in a MEF-facilitated project that spans the globe from Hong Kong to New Jersey, and in the cases of the service provider participants, bringing that measurable and meaningful KPI closer to reality in their respective companies.
The time is right now for other service providers to enter this project. Today, the project simulates a use case of automation using only one transit provider for the requests over LSO Sonata - in this case TI Sparkle. By having more service providers participate and simulate the transit provider options, we can harden LSO Sonata serviceability requirements, for the benefit of the whole industry. It's also a great internal learning exercise....
Let us know if you are interested in checking this out further. You only need to be a service provider member of MEF. If you aren't already a MEF member, then this is a good reason to join (and it's very easy)! If you're not a service provider, we might find it challenging to turn you into one but we can at least look for ways to have you participate (again, only if you are a MEF member...)