Automating service deployment can cause a dilemma if not done properly. Deploying services manually has the benefit of unlimited flexibility. Smart engineers can principally configure services to meet any customer requirement. However, that way of working is infeasible. Service deployment projects take too long time and introduce too many errors. Furthermore, the operational cost is too high since you need a larger staff to cope with the demand.

Accordingly, many service providers and enterprises automate service delivery.  Ironically, this type of automation is often counterproductive. Service providers tell us this leads to a culture of “it works, don’t touch”.  We refer to this as the “catch-22 of service orchestration”.

In a typical example, a part of the catalog is automated with a “hard-coded” solution which required a long and costly software project. The solution then fulfills the goals of fast and error-free configuration, but it does not offer the flexibility to adopt the portfolio to new customer and market needs. It takes yet another long and costly software project to achieve this. Therefore, there is a risk the organization falls back to manual configurations.

How can we use service deployment and orchestration to avoid this situation?

There are several things to consider to remain flexible and still automate:

• Inhouse DevOps teams: Do not outsource everything to an external partner. You need the skills internally to implement changes.
• DevOps culture: Your product owners, and operations and development teams need to work together in an efficient manner. See a presentation on the topic here: https://www.slideshare.net/stefanvallin/devops-for-network-engineers
• An automation/orchestration platform that supports both design-time and run-time features. At design-time, the design team must be able to design, implement and test new or changed services within days or weeks. Operations can then easily automate the deployment. It is a litmus test when you select the platform, how quickly can you implement a simple service yourself. Is it hard-coded? Aim for model-driven platforms that render themselves from data-models like YANG or TOSCA. Evaluate seriously with your own development teams.