Franz Seiser

So if you really wanted to do something bigger that needed changes over multiple systems, you had to set up a pretty big exercise.

You need to start making teams talk to each other, which did not talk to each other that often.

So this was really cumbersome exercise.

because of complexity and need to align between the silos, because you have to from time to time do things where work is required in all the silos.

What you also then saw, of course, you have engineers being in charge and engineers always have a certain ambition to optimize their own silo.

So what you saw then is that, of course, each silo was done to its local optimum, but we all know the sum of local optimas is most likely not the global optima, right?

So all these things simply make you slow, make discussions pretty long and inefficient.

And moving forward, it slows you down.

And over time, of course, more and more things were invented.

So more silos were added.

So the overall complexity was growing and growing like crazy.

And as of today, we have more than 50 of these type of systems in our network up and running.

Typically in the silo, one software upgrade per year, roughly.

Some maybe a little bit quicker.

So the really, really, really good ones managed maybe two or three.

But the real big ones had one per year or maybe one per one and a half years.

So this was really slow speeds.

If we would still have that architecture, exactly.

We have fundamentally different demands regarding speed, keeping up security-wise with the environment, resilience of what is a customer today expecting from a really good network.

So we really had to think differently.