Olivier Jacques

Hello. And welcome. So what you see here on the slides — actually on the screen — is the actual bookshelf that we have at the office. And I think for many of you as well, this bookshelf has been extremely influential to things that we have been doing in the last 10 years or so. And actually, what you can see also is that there is a French version of the Unicorn Project, which I brought over there just to get it signed. So we're thinking I'm going to read a part of it in French. No, but…

So yes, very influential library. Extremely important for us, extremely important for you as well. But what we're going to talk about today is a transformation that we are leading with my customer EDF right now. And for an industry like ours — which we're going to learn more about — this bookshelf is interesting, but also can lead to surprises, right? So this is the intent, and this is what we're going to share today.

In this talk today, we are going to share the context of the industry — Clément's going to talk about that — the danger zones that we found ourselves into, how we try to get back to the winning zone. So experiments, maybe we'll try even to have a scientific hypothesis, a formula. I don't know if it's a formula for success, but that helps us to understand where we are and where we want to go. And, and also at the end, a call for the book writers out there.

So before I introduce myself, you can see that there is a third name. We are only two on stage. Claude could not be here today. This is Claude — my colleague, not Claude the large language model. He participated a lot in the material that is also featured there.

I'm Olivier, I'm from AWS Professional Services in France, partnering with my customers to help them taking more advantage of the cloud.

Clément Sabater

And I'm Clément, from EDF. I'm very thrilled to present EDF at this ETLS. At a glance — what we do. We served 40 million customers worldwide. We have one very special client: the planet. We are global leader in low-carbon electricity generation, and our bold ambition is to achieve carbon neutrality by 2050.

We are confident in achieving this goal, because we made a strategic decision five decades ago to invest in nuclear technology. Now we prepare for the new energy mix, and we are taking to the next level six new nuclear power plants. We will create about 150,000 jobs in France.

Now let's take a closer look at this graph — the energy consumption evolution in France. On the left, we see what happened since 2000: not much has changed, except for a slight decline in fossil fuel usage. But fast forward to the right side. You'll notice something remarkable: by 2050, our projection indicates that all energy consumption will significantly decrease. Why? By shift towards more sustainable means, because we think about public transportation, biking to work, on-production, and new urban planning with positive energy. Fossil usage is expected to plant to zero in 2050. And the renewable energy sources will experience massive growth.

I know maybe some of you might be skeptical about the French. You may think that's just typical French flair — all talk, no action. You could be right. But didn't we organize one of the most beautiful Olympics? Whatever — now we discuss, we have a concrete proof: the decline has begun, and it's time for us to take action.

So, crucial next step is to revamp our IT infrastructure from the ground up. We are not talking about incremental tweaks. We need radical transformation of our technology landscape.

But our context is the energy gentleman — and it doesn't help so much. As you know, energy is more related to civil engineers than IT. Our challenge is convincing experienced civil engineers to adopt a new approach — building bridge iteratively, the exam as we build — and it's tough work. These engineers have created a powerful legacy system. We must acknowledge and express gratitude for its service. However, it was built using traditional method: separate the dev and the ops. We have outsourced operations, and contracts — contracts with solid requirements. And — 699, if you were there to, for Elisabeth Hendrickson's talk Tuesday, you know what I mean about contracts.

We also had some custom developments, but our core IT runs on SAP software, which we customize, but we never build it from scratch. As you can see, it's far away from the evolution playbook. We are coming from a different world. But to structure it in the future, we must adopt more general organization and technologies.

This image will present our journey — where we are now on the left, and where we are headed on the right. Together, we are led by three core principles. First, using user-centric design — we conceive solutions with our end user in mind, ensuring their needs are at the heart of everything we build. Second, high-performance quality — we learn to develop applications that develop high performance, reliability, and security. And last, cloud innovation — we leverage all that the cloud has to offer, offering its power to drive agility, scalability, and innovation in our solutions.

Olivier Jacques

Yes, that's right. So this is the journey — actually very, very popular: think big, start small, scale fast. So we start small. Actually we first started by thinking big, right? And start small, and then scaling fast. The eventual goal is to really have a big industrial factory that is going to be high-performing. So the intent is to be able to release one new product every month in production.

So we started to do that by securing the budget first, assembling the program, getting alignment — and I'm going to talk about that very quickly. And then starting small by starting with few applications that we will put in the cloud, which is something that actually is very new for EDF.

When I say about starting small, just to give you a sense of where we are — those are the number of people participating in the program. We are in our "guest" — which is "août" in French, August — but in the middle. And the numbers here, we are not projections, but they are actual numbers as we are going through right now.

Now to modernize, we have been using very popular transformation pillars. The first one, which is extremely important for us, is "you build it, you run it." I even have it on my T-shirt. It seems like something simple to do, but it's actually very difficult to put in place. I mean, I'm coming from Amazon — I know how long this took Amazon to go from, you know, a monolithic application for amazon.com to a transformation full of APIs and two-pizza teams. But for us, coming from where we are, from what Clément shared, this is something that is very impactful. I'm going to share more about that.

Team Topologies also extremely important. This is the target team organization that we want to achieve at scale. So we also are to talk about that. And DevOps is kind of almost by design in the DNA now, but it's also a very important paradigm.

Clément Sabater

Yes, Olivier, books are good. Very good, yes. But what about real life?

Olivier Jacques

Yes. Well, and then real life hits, right? What you see is the team topology mapping — which is, by the way, defined in there is a map link in the bottom, teamtopologies.com/tim. But basically it's a mapping of one of the first biggest applications that we have put in place. And you can see there, we have three components, which are actually — it's not small components, not microservices, but quite big components — and shared components and relying on cloud foundation that are provided by the central IT organization.

This was successful to an extent, but really something that we tried to actually, you know, try out. But we quickly realized that we needed to change and scale, right? So what we have added is added our own platform, really much inspired by Gregor Hohpe's talks and work on the platform strategy. And what you can see here is that the platform is not only a collection of fruits — I don't know if you have the analogy, if you were in the talk — but separate tools and separate capabilities. But also we have added additional capabilities such as single sign-on, the way it is done at EDF — so something that a cloud provider like AWS cannot provide, but a capability that is absolutely required.

The other thing that we have added here are enablement teams. Very often — and across the week here — I heard a lot about platforms. I really heard about enablement teams, which I really think is the secret sauce. So, enablement teams are really teams that are going to help us to co-develop, co-work, and really implement whatever is described in the platform, the services in the platform, with the team. So instead of having them read the documentation, they actually get to work with the enablement teams to put that in place.

Clément Sabater

Maybe I have to remind you, it wasn't as easy as we were in the book.

Olivier Jacques

No, you're right. We actually encountered a number of blind spots and things that we didn't think about when I joined the program initially. And let me share a little bit of those blind spots with you.

As we said initially, we want to first optimize for the end users. The first thing that we wanted to do is make sure that we needed to be — I mean, not that we wanted to do, but we needed to be aligned, right? And cloud was new to EDF. So we had this big introductions, integrational moment where — "hey, this is the cloud."

Clément Sabater

Yeah, right? It's right. When we decided to use AWS, everyone become cloud expert. We had so many questions. We had to manual security, sovereignty — you know, in Europe, we are not so fans of the Cloud Act, American dependency, and reversibility. And those were convinced we could do with on-premise — same thing.

Olivier Jacques

Exactly. I mean, the intent was to say, okay, then what? We can do more by going to the cloud, right? So obviously you get lots of new services. So it's not only about virtual machines and storage. With AWS you have more than 200 services. You have the ability to take advantage of being able to scale down and pay at, you know, the level of the milliseconds. But also there is much more innovation that you can introduce, for example, to scan large document bases and take advantage of this body of work.

So, but talking about alignment — I think what really struck me initially is that we had many people, many — not opposing priorities, but different priorities depending on who you were talking to. And this real misalignment at the beginning started to create some issues and friction, right? So quickly we needed to find ways to get aligned.

So we introduced something that is very popular at Amazon, which is the PR/FAQ. And basically the press release-slash-FAQ is a document. And the intent there is that you are going to write a press release — it's a fake press release as if you were releasing the product or the service — and what you would like to read in the newspaper about your service. So it's like, hey, we are introducing this new service and we are going to be able to do that. And then the developers shares what is — why this is good for her, right?

And then there are questions as well. So a PR/FAQ starts with a working-backward exercise. The working-backward exercise actually answers five basic questions. They're not so basic. And what is really interesting is that they're absolutely and entirely focused about the customer. So first, who is the customer? And what do we know about that customer? What data points, what numbers do we have to share about that persona? And then what is the prevailing customer problem or the opportunity? Same thing, informed by data points. What is the solution that we think may actually fulfill the needs? And what would be the benefit for the customer? So something that looks like — I mean, it's just common sense, but this brings a lot of alignment. I would describe the solution and what is going to be the experience for that customer. And eventually as well, how do we test the solution with the customers, and how do we measure success?

All of this — series of workshops, series of discussions — the intent is to create this memo, like six pages or more or less, which has a narrative, a press release, fake press release, and descriptions, and also the FAQ and visuals. This is not an easy document to write, and the point is not the document itself, it's about the discussions that happen. It's about the interactions, and really understanding who is the customer and what we're trying to achieve to answer the customer's pain points.

Clément Sabater

Okay. Well, we know customer, blah, blah, blah, blah, blah. But customers were aligned, but still not happy. Why, right?

Olivier Jacques

So initially when we started, the first customers were the builders, right? We have a lot of software to work on and to build. And one of the big things that we worked on was the developer experience. Actually, it's not something that we're expecting — and maybe this is not the case in corporate industries here, but in our case, what we were facing is that the builders' PCs or workstations were more "slideware" pieces than actual developer workstations, right? So you could not install an SDK, a software development kit; you could not install an AWS CLI. Memory was restricted, and not talking about even storage. And don't talk about running a container on your machine.

So those slideware PCs served us well, but we needed to solve the issue. So what we've done is that we have adopted a technology called development containers — dev containers — which allows basically to package developer environments that can work on the developer's machine, and also with the same development environment described as code that can run also in the cloud and take advantage of more resources and more capacity. So dev containers or devfile — I mean, two technologies to basically do the same thing — extremely important for us.

Then the next thing that we have been working on is, you know, we need to modernize and we need to take advantage of the cloud and have more cloud-native type of approach, right? One thing that we struggled very quickly about is that as we were architecting the first applications, those applications were — I mean, their architecture was custom every time, which meant — because we have to go through architecture review boards and security review boards and the like, and I know there is a topic that maybe this is not a good idea — but because we have to do that, so far, this was creating a lot of latency and friction every time, right? And because we were custom every time, basically the innovation was not there. I mean, there was a lot of time in the first application that we started spent on inventing the architecture, making it work, getting the single sign-on working, et cetera.

So where we're moving right now, and what we really are actually well advanced now, is our set of patterns or architectures "on the shelf" that we can pick from and choose from, depending on where you are. And basically, what needs to go next is to open network streams with other applications that are not part of the core architecture or the core pattern. So those are our golden paths.

So looking at where we are and where we are going — what you see there is that if we look at the "start small" piece in the middle, lots of things that we're putting in place: between the platform teams, we have the PR/FAQs, we have OKRs that we defined for each and every team, and up in to the program.

We know that we have additional roadblocks that are going to happen. For example, the developer experience is still not a hundred percent awesome, and sometimes it actually feels better to develop on-premise than develop in the cloud. So there are works that are lots of ideas and things that we're putting in place.

Another one is skill shortage. It's probably something that everyone in the industry is feeling, but for our case, because we are located and co-located in few cities in France, having 350 developers or so in one city basically dries out all of the developers in the city. So, and we cannot really look for developers abroad because of the sensitivity of the project. So, we know that this is something that we are going to face. The countermeasure to that is to have much more standard and, I guess, very popular architectures, so that developers can use the most popular language, the most popular architecture, maybe using container, and not being very specialized in one way or the other.

And the operating model is going to be very important. So, because many of us — and especially EDF, lots of scientists there — we try to hypothesize. It's probably completely incorrect, but at least it gives us a mental model. Our modernization velocity — we believe that today our modernization velocity is a factor of: the architecture complexity (how difficult it is to grasp the architecture of the application of what we are now providing off the shelf), multiplied by the skills (how skilled the engineers are going to be), with the ops model (is it compatible with this velocity and this change that we are introducing?), and add the power of the builder experience.

This is something I grasp during the talks this week — is that there are lots of people that are talking about DevOps and team topologies, but many, many about developer experience. I mean, been many talks about developer experience. It's not only about the developer, it's also about the others, right? SRE experience, the OpsX operational experience, and the architecture experience as well.

So we are moving down this road. Now, the three of us — and Claude is not being there, but — we are putting countermeasures in place. And this is something that we are still struggling, and there are lots of more work that we want to achieve.

And I think because this is the IT Revolution, more or less, conference — kind of making a call for book writers and book authors out there. There are things that we are missing in the library, right? The first book that I think we are missing is: how do we develop and retain cloud-native engineers, right? The people who can actually understand this technology and take advantage of it.

I think another chapter that we could have in the book is: how do we make cloud-native totally transparent? And I know that this has been something that also was taught during this week. Another one is about this developer experience for cats — for cloud-adopting teams. But, same thing, right? When you are using native, you're using serverless, you're using managed services — how do you make sure that the developer experiences is seamless, and that you can work with all of the services?

And last but not least, the operating model, which is something that — I mean, we have to fit in a puzzle, which today is different and probably not compatible with where we are going. But where are the connection points? Where can we hook regarding, for example, on-call setup, which is kind of in the enterprise — it's totally codified and there is not much that we can do against it. Same for sourcing people, right? So how do we fit there, and how do we connect the transformational organization with the existing one and wire it?

Alright? So, thank you so much. We are leaving you with two QR codes. The one on the right side is the reading list that inspired us so much. So probably a lot of books that you're aware of. And because for us at Amazon, you know, feedback is a gift. If you can please make sure that you enter the feedback for the conference at the end or later in the day. Really appreciated. Alright, thank you. Thank you.