Digitalization at network operators - New Way of Working or how to get really agile

In our last article, "Digitization of grid operators - Modernization of the IT landscape in four steps", we showed how the technical conversion of obsolete application landscapes can be successful. However, the step-by-step, technical conversion alone is not enough. In the third part of our article series, we want to point out ways in which working methods should be adapted accordingly.

As soon as a major implementation project is on the agenda, the priority is always to find costs reductions and potentials as well as the solution itself. What rarely comes up is the question of "how" a project should be approached and implemented. Wasn't it often the "how" that led to problems, even with well-known large-scale projects? Likewise, everyone agreed on wanting to build an airport in Berlin - but the practical implementation still failed.

Energy suppliers and grid operators are also interested in bringing projects to a successful conclusion. The "how" has to change. Companies still have a traditional separation of concerns for business units with a traditional understanding of roles. This means that the builders of a solution - the project team - and the subsequent users - the operating team - must not be identical. There may be historically good reasons for this separation, including the fact that the teams are highly specialized in their respective tasks. On the other hand, the handover from project to operation often fails due to a lack of communication and coordination. This affects speed and quality and contradicts the new challenges: Customers always have new requirements, market events and regulatory influences need to be responded to more quickly. Moreover, in most projects the required technical skills are not so pronounced that a dedicated separation of functions is required. This is where you can start and close the gap between project and operation by skillfully restructuring the organization.

The "DevOps" concept is based precisely on this idea and is made up of the two terms development and operations. Both functions should be consciously held together. Applied to the project, this means that the employees are involved in the project and will later operate the newly created solution. Standing teams are built that take care of a solution or a product holistically from the definition of requirements to implementation and operation. There are less friction losses. An explicit handover and the associated knowledge transfer as well as problems with lack of communication and coordination are eliminated. The product team works completely agile and focuses exclusively on the right solution for the customer, up to a smooth operation.

In addition to organizational adjustments, technical developments also contribute to improvements. In many companies the focus is traditionally on the improvement of the product, the necessary tools get much less attention. A good example for this thesis is the deployment to production, which is well known source of problems in many applications. Errors found at the last minute, incorrect configurations, night shifts, broken databases and rollbacks are the classic side effects of new releases.

But there is also another way, as newer approaches from software development show: Automated toolchains (continuous delivery and continuous integration) significantly simplify and accelerate the productive implementation of new functions. Starting from the requirement to the finished product, virtually any automation is conceivable. Especially at the beginning of the project, it is not advisable to cover all parts. There are therefore several expansion stages during implementation:

Step 1: Tests

As soon as a developer checks new code into the central repository, a process starts automatically that analyzes, assembles, and checks the source code incl. its ability to run. Then a series of predefined tests are performed (unit tests). If these are successful, entire modules are assembled and tested together (integration tests). If even a single error occurs on the way, the programmer receives direct feedback, even if the error does not occur at all in the module he has just processed. Ideally following the TDD (Test Driven Design) philosophy, the approach minimizes the need for manual testing and significantly accelerates the development cycle.

Step 2: Packaging & Configuration

Finished developments usually include not only the actual source code, but also other files that are required for the software to run. To compile these automatically according to clear rules, to version them and to make them available in one place does not help to forget anything. Sounds trivial - but in practice a great relief. The same applies to the addition and adjustment of parameters for productive operation. Here, too, a clear process helps to avoid errors.

Step 3: Deployments

Regulated steps for the productive implementation in the system including the demolition criteria and necessary clean-up work help to carry out regular deployments and bring new releases to the customer. If the script determines in the course of the deployment that deviations have occurred, the old status is restored automatically. Unexpected side effects are minimized and the well-known late hour coordination calls to Go-/No-Go are a thing of the past.

What sounds good in theory can actually be lived in practice. Amazon, for example, has perfected the entire thing. The amazon.com site is built in such a way that several hundred changes are made every day. So if you click on the same product several minutes apart, you will most likely see a different version of the site - technical improvements have gone completely unnoticed by the user. This is agility in its purest form.

 But has Amazon made it so perfect from day one? Certainly not ... In addition to the use of new tools, cultural change is a compelling prerequisite, i.e. breaking down organizational silos and creating holistic processes from requirements capture to implementation and operation. It is not advisable to change the whole organization immediately. Instead, one should start on a small scale, find a nucleus, e.g. a manageable project, as a starting point for change.

In addition to all improvements to processes and tools, companies are naturally also faced with the question of the cost-effectiveness of the measures. Particularly in the case of major changes to the application landscape, the financial benefits are often not immediately apparent and many business cases are not exactly positive. Nevertheless, it is more relevant than ever to think about the above-mentioned topics. In our last article of this article series we come to the point, which mechanisms there are to finance the shown way.

Authors: Michael Ruckel (Senior Manager) and Soeren Greve (Senior IT Architect) are part of the energy practice area (EPA) of BCG Platinion and are experts for digitization in the energy market.