This also led into a discussion that revolved around the large number of standards organizations, open source groups, and similar forums. Some questioned whether there might be just one way and one organization. Diego Lopez from Telefonica pointed out that the industry does not need a monoculture.

From a management perspective, this means that a viable solution must also have the inherent ability to deliver promised benefits in the face of this accelerating technical volatility. Unfortunately, all the potential solutions presented at the conference—in addition to being monolithic in nature—appeared to be hard-wired to specific technologies and susceptible to the kind of problems faced by Affirmed.

So, from a senior management perspective, the automation solution requirements are:

• Not monolithic;
• Proves before major financial outlays that it can deliver promised benefits;
• Delivers those benefits in spite of accelerating technical change.

One way to meet these requirements is to have a solution based on an architecture that can be

• Distributed;
• Implemented in a small area where benefits can be confirmed;
• Scaled up slowly as continual monitoring shows benefits are achieved;
• Architected to provide on-ramps for new technology.

Supplier Ecosystem

The creation of alternatives to the monolithic high-cost solutions that don’t deliver promised benefits involves changes in the supplier ecosystem. Current CSP business practices make it very difficult for the small, innovative software companies.  Although the very large vendors speaking included Accenture, Amdocs, Ericsson, HPE, IBM, Intel, Nokia, and Netcracker, Dr. Alex Jinsung Choi from DT noted that the automated orchestration ecosystem landscape is very sparsely populated. Alex Vul from Intel noted that to make the needed changes, “a new business architecture” was needed. In other words, part of the changes needed must be new ways of doing business.

A side conversation focused on answering the question: should CSPs fund small development efforts that, if successful, have a path to larger deployment—thus creating an opportunity for a number of small innovative software companies to bring forward solutions? One of the CSP representatives said, “I cannot agree more. Without allowing these specialized niches, any ecosystem will end being another unproductive attempt to bring the ultimate standard (or open-source implementation, or test spec or…) with the same usual suspects around. We do need to incorporate a healthy amount of disruption capability.”

During the conference, there was also a lot of discussion about what the correct balance of open source, standards-based, and proprietary development was. All agreed that there was a place for all three. But there was no agreement on what those places might be. Also, there was no discussion about how the high costs associated with standards and open source participation tended to lock out small innovative software companies.

In an nutshell

The conference demonstrated that the basic automation requirements and technical terminology are now well understood. Unfortunately though, it appears that CSP senior management is not yet ready to do what is necessary to make automation happen.  To get CSP senior management to make the necessary commitment, three areas of comfort are needed:

• Compelling business case
• Technology that management is comfortable with
• Viable supplier ecosystem

To move automation out of the advanced technology arena into production, these senior management requirements must be addressed.

In an off-line conversation after the conference was over, Klaus Martiny said that a group met after the conference. “There are concrete steps for moving forward.  These steps will be announced in a couple of weeks.” If these steps are well-designed to achieve CSP senior management commitment to automation, then it may be realistic to expect progress. Otherwise, things are likely to stay the same.