Yin and Yang of Automation

The risk posture is key for the successful completion of automation projects. Another important issue to take into account is the Yin and Yang of automation.

Yin: Fast delivery...

Customers are expecting on-demand delivery of network and security services. For service providers this comes down to the time to cash: how fast can we provision the service and start billing the end customer. End-to-end automation is critical in order to enable on-demand delivery driven from a self-service customer portal. If done properly, the on-demand delivery of a service should take only a few minutes.

A second aspect related to speed is the time to market of new products and features: how fast can we release a new product or feature to all or a set of our customers? This also includes changes and updates to existing products and services. Automation is relevant for the time to market in 2 ways:

1. Automating the release pipeline of the product, service and features;
2. Building the lifecycle automation itself for each product or service, so that it can be delivered and managed without any manual involvement (i.e. to enable the first aspect: on-demand delivery).

Clearly, this second aspect takes much more time than just a few minutes. It requires quite some human effort to engineer the products, services and/or features as well as to develop the lifecycle automation code. Automation in this phase can reduce the duration of the development lifecycle only in a limited way (e.g. automated CI/CD pipeline).

... versus Yang: Reliability

Of course, when under pressure of competition to release faster, the typical approach is to cut in the engineering and development time. Under the guise of Minimum Viable Product (MVP), shortcuts are made on critical supporting components:

• the lifecycle automation code: the focus is on automated provisioning of the MVP only and other important lifecycle stages are skipped for later. Typically, we end up with partial automation that does not even cover the provisioning of the end-to-end (minimal) service.
• the automated release pipeline: more specifically, there is no continuous structured, automated testing of the MVP components individually and the integrated solution.

Shortcuts gain time in the short term, but at the expense of reliability and resilience. In the long run, it will cost a fortune.

In the short time (i.e. first release), you will gain some time. However, with the second release, you will have to re-do quite some things that have not been properly automated. And this effort will only increase.

In addition, an important reason to go for automation is to avoid human errors. By cutting corners, the automation is not properly tested and this puts the reliability at risk. So we end up with the opposite of what we want.

Finally, by automating only partially, the on-demand delivery of the end-to-end service (even if it is only the MVP) cannot be achieved. This has a major impact on the customer experience. But it will also heavily affect the operations effort.

Keep the balance

The main lesson for successful automation is that you have to keep the balance between the (at first sight) two opposites: fast delivery on the one hand and reliable automation with sufficient testing on the other hand. It is safer to initially invest more in lifecycle automation and the automated release pipeline, and to reap the benefits afterwards. Cutting corners will only push you deeper into the "trough of disillusionment".