Host Intro (Gene Kim)

I'm super excited that we have another fantastic experience report from an organization that provides critical infrastructure. This is a category that includes things like power generation, and because of how important these services are to society, this is again a highly regulated industry.

Up next are Olivier, a longtime member of this community who presented for the first time in 2016, along with his colleague Claude Ampigny from AWS, and Clément Sabater. They will provide a behind-the-scenes view of the digitalization program of one such large industrial organization, and how they adopted innovative strategies such as the you-build-it-you-run-it model, Team Topologies for organizations, and many of Amazon's famous operational mechanisms.

With that, here is Olivier, Claude, and Clément.

Olivier Jacques

Yes, thank you, Gene, for the intro. Hi everyone from everywhere, I guess in Europe, but also I have seen around the world. We are really thrilled to be able to share with you what we're doing.

What you see in this intro picture is the actual bookshelf that we're sharing with everyone at our company, with some books like The Unicorn Project, which has been translated in French. It is no secret for us, but also no secret for you, that this library has had a massive impact on it.

Still, when we're applying what we learn in those books to the industry I am going to talk about, we are up for surprises. You probably have had surprises too. This matters because the industry we are going to talk about today is literally about keeping the lights on.

In this talk, Clément and Claude and myself are going to share our environment, our context, the danger zones that we found ourselves in, and how we got back sometimes into the winning zones. We will also share a scientific hypothesis from us and a call for book writers out there.

I'm from Professional Services at AWS, joined by Claude from Professional Services at AWS, and Clément from this industry provider. We are live from Lyon in France. Let's get started right away.

The industry is in the energy domain. It is also known as the utilities category. As you know, this industry has been going through a tectonic shift toward much greener energy and changing the energy mix.

If we look at what this means, this is a graph that we have from France and the evolution that we have observed. This is coming from a study from the French government. What you see on the left side is what we have observed so far regarding energy consumption, and things have not changed too much since the early 2000s. We have a mix of renewable energy, yes, but also lots of petroleum products and electricity production in many forms.

What you see, though, is that the projection is drastically changing the energy mix. Going forward, by 2050 we are going to end up with a slight reduction in consumption, but also a very different energy mix, which is going to be more renewable energy and electricity production with different forms.

To accompany that change that is drastically changing the profile of energy production, we also must change our IT, and Clément is going to share about the context of doing this.

Clément Sabater

Thanks, Olivier.

As Olivier said, we work in the energy domain, and the energy domain is closer to civil engineering than IT. What we are trying to do is convince every day experienced civil engineers that we can build a bridge as they always did, but we prefer to build it and deliver the bridge as we build. It is very, very hard work.

The same engineers built a very powerful legacy, and we have to acknowledge it elsewhere. But now we have to say thank you to it. It has been developed with a traditional model. We have hubs. We have contracts with solid requirements. We have start and end dates. Obviously all run is outsourced.

We have little custom development, but the core IT is made of off-the-shelf software. We customized but did not build them. As you see, it is quite different from what you can read in the IT Revolution library. We are coming from a different world, but where we are going, we have to adapt to the most modern organization and technologies if we want to be successful.

On the left is where we are now, on the right where we are going. We follow three principles. First, we conceive with our end user. Second, we learn how to build applications with high-performance quality. Third, we use everything that the cloud provides.

Next, Claude will lead us on our journey.

Claude Ampigny

Thank you very much, Clément. In fact, the challenge of the program that we're facing is that in a year we have to reach a target cadence of at least one new product deployed in production every month. This is a lot, especially when you know that the first six months were to share the ambitious goal and get approval for the budget.

The next six months, where we are currently, are to be ready and really sharp on the activities that we want to conduct and the experimentation that we want to convey, because we need to demonstrate some success, but we also need to learn some lessons and basically address the modernization pillar.

In order to address this challenge, we need to do a complete path shift. We decided to approach this program with three mental models in mind. The first is you build it, you run it. It is basically the Amazon model, where you operate what you build.

The second one is DevOps. Every team and all the practices on the program have the DevOps culture in mind and need to implement DevOps culture. The last but not least is Team Topologies, where we want to wire every team with a Team Topologies approach.

I'm going to show you where we started with the first product. Our first project was a really visible and impactful product. That was our first experimentation. For this product, we decided to implement Team Topologies with one product, but with three substreams and one platform team. The platform team collaborated with the cloud foundation team to build some shared services that were used by the substreams.

That was a relative success. It worked well, but the collaboration pattern was limiting our ability to scale. So we changed this and implemented a cross-platform team that builds consumable abstractions for the substreams. By doing that, we also implemented an enabling team that helps to adopt this abstraction. Again, we had good results with that, but we identified a few blind spots that Olivier will share with you.

Olivier Jacques

Yes, so talking about blind spots: things that we thought we knew, but that we encountered and were really kind of surprises, but actually were very important in our journey.

Remember, if you look at the three pillars of our transformation, the three tenets, we first want to optimize for our end users. Our plan was sane, and this brings me to our first blind spot: the need to align and then keep on doing this with many stakeholders with different priorities.

We found ourselves really in the danger zone when we were progressing but not really able to provide good clarity. Clarity is super important so that all of the stakeholders and all of the participants know what to do and can be very optimal and powerful in terms of implementing.

To get back to the winning zone, we used an Amazon mechanism called working backwards and the PR/FAQ. PR stands for press release. This working-backwards mechanism is quite known. You can find information on the internet. This is everything that we need to move forward on a project. This can be a brand-new service, a new feature, or even a new initiative. Actually, every time you need to ask for money and funding, that is what you need to go through.

With that, we start with the customer in mind and we ask ourselves first questions. Out of this working backwards, we write a PR/FAQ. PR is the press release. Essentially, this is what you could find in a newspaper. It can be an internal journal, but think of yourself as being published in a newspaper, and what the newspaper or journalist is going to say about this new feature or new capability that you want to start. It is a glimpse and a projection of us in the future.

Then the second section in this document is the FAQ. It is a set of all the questions that we think the stakeholders may want an answer for. It is a very difficult document to write. It takes a lot of time, many iterations. I counted 67 iterations for our PR/FAQ for the platform team. But this provides clarity and alignment, and the one thing it provided for us is who our customers are for the platform team.

Next thing is that, as Clément was saying, we need to build. There is a lot of stuff that we need to build, and for that we need builders. We need developers, software developers, architects, site reliability engineers. This is where we hit our second blind spot.

We found ourselves in the danger zone because something that we did not see coming is that developers had not been identified as a persona in the company that we were evolving. As such, the tools were inadequate for what they had to do. The developer experience, which was one of the big topics in the talk before, is also a huge challenge because building for cloud-native applications needs a different set of tools than building for on-premises.

To get back to the winning zone, we created cloud developer environments. Those are essentially development environments that are defined as code running in containers. Those containers can run locally in the developer PC or Mac and can be moved to work in the context of an AWS account and virtual private cloud environment connected to the rest of the infrastructure.

The third tenet is about modernizing with everything that we can take advantage from cloud-native development. We are talking about going mostly serverless wherever possible. We are also building applications that are going to last for 20 or 30 years, which means that we want to optimize for development, yes, but we also want to optimize for operations.

This is where we also found ourselves in the danger zone. We started to create applications and show the different phases that we're going through. Our first pilot applications were really custom-built and perfect, and really just-enough infrastructure. Because they were custom, this also created quite a bit of friction because each application had to go through an architecture review, a security review, and this can become very lengthy. It is a challenge each and every time.

To get back to the winning zone, we have put in place golden paths. In French, we call them cadres de référence, which cover a good set of our needs: essentially 80% of what we can expect from the applications we are going to build. We are talking about architecture templates, infrastructure as code, standardized quality gates, and also everything that can improve both our velocity and our security posture.

Golden paths are great, but one thing that we really pay attention to is that we want to create a very thin platform so that we do not do a lot of duplication. Claude, we went through all of this now. What's next?

Claude Ampigny

Thank you very much, Olivier. Now, Olivier presented some blind spots and challenges that we encountered, but keeping in mind our challenge to be able to deploy at least one new product per month, we have identified additional blind spots and roadblocks that we must solve to meet our expected velocity.

The first roadblock is developer experience, but for cloud-native. Many of our developers are coming from a Java background, and they are used to developing less distributed systems and having everything testable on their laptop. We need to really change that and be able to provide to them a streamlined experience on the cloud and with cloud-native technology.

The second roadblock is skill shortage. We identified that we have on the program to attract and retain at least 350 talents in the next one year and a half. That is a challenge, especially knowing that we are not located in Paris. But even if we were located in Paris, that is a challenge to attract top talent with very high cloud-native experience.

The last but not least challenge is that we are not changing the entire company. We are changing just a large bit of it and a very important piece of it, but not everything. That means that we will need to be able to operate as a nice isolated product operating model, but we need to connect to the legacy operating model. That is a challenge on the long term.

Basically, we are engineers and we love solving and documenting problems. To ease the future resolution and future occurrence of this problem, we tried to crisp our problem in one equation: modernization velocity. For us, modernization velocity is a factor of architecture complexity times skills and operating model to the power of builder experience.

This is a scientific way of showing the problem. This is helping us right now. We took the decision with Clément and the rest of the program to reduce a bit the architectural complexity so we can have more skills and find more skills. We are moving from a full serverless architecture, cloud-native serverless architecture, to a container-based architecture that can be serverless as well, but where we can probably find more skills on the market and more developers that are familiar with it.

That is our equation and who we are. We are Clément, Olivier, and myself, Claude. We think that we are going to have more insight this summer to share and to tell you where we are in our journey in terms of what we think is missing.

We have identified three different books that are missing. The first book: we think that we need to have more documents and more books built by the community about how to attract and retain cloud-native developers. It is not only how you attract; it is that this is a huge challenge to have this persona. We are at the age of AI. We are at the age of complex distributed systems. We need to know what those people need to be able to join our company and stay in our company.

The second point is developer experience. We need to have more details and more work on how we can build and shape a larger and better builder experience so people do not feel like they suffer in their work and feel empowered by the tools that we provide to them. When we deep dive in this, there is not a lot in this matter.

The last but not least is about the operating system. Not every company is doing a complete shift. Things need to work. Some companies need to work in isolation. We need more details on this as well: how we can work in isolation, but still have some connection and bridge the gaps.

To conclude, we have put together a reading list for you so you can scan the code and check everything that we have written that helped us on the program. I would like to thank everyone for your time. Thank you to my co-presenters, and over to Gene for the rest of the speech. Thank you very much.

Host Outro (Gene Kim)

Thank you so much, Olivier, Claude, and Clément.