Bridging the gap between traditional IT infrastructure, Platform Engineering and Innovation | Bruno Almeida

Good afternoon everyone, and thank you for the crowd warm-up after lunch. We are off to a great start with that. So, hi, my name is Bruno, as mentioned. I'm the Vice President of IT Operations at Fortum. I'm responsible for areas such as platform engineering, - cybersecurity, service management and end-user services, - among a few other things. So the baseline of the structure of IT. I'm talking about different topics today, including platform engineering. But let me start by addressing Fortum. I think we're in Finland, I think pretty much all of you are, - or the majority of you are familiar with Fortum. Fortum is one of the largest clean energy producers of Europe. We have different headquarters in Finland. We have different assets, especially across the Nordics, - hydro, nuclear, solar, wind, heating and cooling. A lot of the things in today's world to actually drive the change. Now, when you think about this and translating to IT, - what does it mean for us to look at - this strategy and how the company is going forward? We established three different priorities in the past year. Customer centricity, - looking not just from the external customer point of view, - but also internal customer-centricity, looking at topics such as the developer - experience, the service management experience, - the employee digital experience. Then the cost efficiency as a cornerstone to drive the change, - and then the security and reliability as non-negotiables. And this is important to set also the stage for the context - for you to understand where I'm coming from - and perhaps why we are going through this change and transformation. I will start with something that even though you know Fortum very likely, - you don't know that Fortum does a lot of software development. Software development that you might see with the brand of Fortum - or any other brand that we might have in the context of having our - own innovation and venturing with our own startup ecosystem. Some of the brands that you might see is, - of course, Fortum Charge and Drive, Oma Fortum, - but Hive and Spring are also products and services that we develop. Now... We started the journey of course five years ago to build in-house software - engineering capabilities and I think we are well advanced now at that point. I will tell you one story that was a defining story for my journey at Fortum. And actually, it starts with a colleague called Mika. If you know Fortum and Mika, there's many Mikas, - I will not tell the last name for purposes. But I think maybe he will give you a little bit of insights, - if you know him, what comes behind this. Mika had an idea, where he had a dream. In Finland, it was, "Bruno, I have a challenge". But Mika had a dream and his dream was that he wanted to empower anyone - at Fortum to experiment with innovation, - digital ideas in six weeks. That's his premise. That was his flag. And it's a very powerful flag. Quick hands up, who works in an enterprise? It's after lunch, so you can also use this as an opportunity to stretch. Okay. Startups. No startups. Oh, startups. All right. Okay. So a lot of, I guess, - small, medium-sized companies for the others who want to stretch as well. Yes. Good. So doing innovation is hard in any company, - but in an enterprise can be a bit of a nightmare. This is a story of Mika and me. At the same time, - this was a few years back, I got tasked by our CIO at the time to look at how - can we drive both innovation, but looking at our technology ecosystem - and how can we enable this. IT is quite a vast area. So we have quite a lot of pieces on this puzzle. When we started to look at this, and we started to run this exercise that Mika - had of allowing anyone to experiment with an idea in six weeks. We started to look at what we needed. It's not enough that you have front-end developers, - back-end developers, data engineers, - data scientists, agile coach, you have everything. Yet you started to hit barriers. Barriers that were not necessarily so visible from just a business case idea. It was to navigate the internal organization to understand, - well, I need to request a cloud environment. I need to get access to this tool. And well, I only need this for six weeks, really. And that, funny enough, generated a lot of interesting discussion. What we started to do was to start combining this map and start - to look at how we navigate across our own organization. It was not a pleasant journey - to Mika or to me, but we found interesting things. And what we realized is that there's a huge war happening in the world. Which is any enterprise, any company, but especially enterprises, - they have the IT versus IT war. Who works in software development or digital development? Another opportunity to stretch. Who works in other parts of IT, - such as cybersecurity or core IT, - core IT infrastructures, service management? Opportunity to stretch as well. Okay, less. You know what I'm talking about, the innovation and digital - development versus the core IT and the core IT processes. I'm talking about the CIO versus the CTO. I'm talking about how can we enable great speed of innovation - at the same time ensuring that nothing breaks that is dramatic and critical. I'm talking about building a digital application, - a mobile application versus maintaining a reliable ERP system. That's a clash that happens in any company, - but special enterprises, they suffer from that because often the processes - are either geared up for one or the other. And then what happens is that most enterprises split these two worlds. You have the developers and digital development on one side, - one business unit or one line organization, - and then you have the traditional IT in a different one. It is a clash. Both are right, both are wrong. Maybe there's no ground in the middle. They focused so much on looking at the differences, - they don't find the commonality. That's what we started to realize when I started to look at this, - and especially helping Mika and the team navigating how to navigate across - the company. And we started - to look at simple cases or simple processes, - which, for instance, getting a new team or a new project access to, - let's say, to our GitHub or to having a new cloud environment for the team to - start developing. And we started to map what were the dependencies - and how that process looked like. One of the things that we realized is that there are a lot of parts - that were very manual. There was a lot of interdependencies - across teams, both enabling teams or product-driven teams. There was this interdependence in its mapping. One of the interesting bits was that most of these areas that we found that - were kind of enablers, they all translate to the core IT area. Because in the core IT area, you are very ticket-driven. You don't have that much automation in most companies. You need to make a request. Some team needs to review, - approve it, maybe even have an external partner that implements it. There's a lot of these handovers. Now, all of this, - we realized that a big part of this is what I will call - a larger platform engineering capability. In the sense that all of this is related to infrastructure, - is related to cybersecurity, is related to on-premises, - to clouds, to developer tooling. Network and connectivity. All of this foundation work. Now, the question arises, what is a platform? You tried to answer it a little. I have some different thoughts on that. The best definition that I found was this one. If you have been looking into platform engineering, - you might have bumped into this, which is from Eben Bottcher. And he mentioned, A quote that I love, - "a digital platform is a foundation of self-service APIs, - tools, services, knowledge, and supports, - which are arranged as a compelling internal product". Compelling internal product got me thinking. Do we have an internal compelling product when it comes to platform engineering? Do we as a company have something that a person like Mika - on our rapid development hub could go and select - what he needs for the business case in a compelling way? And what is compelling? What is compelling to a system admin - versus to an architect versus to a product owner is not the same thing. Because once, for instance, - favouring having the reliability and a very well-defined process, - no matter what it takes, and the others are looking for speed and agility. We gather a virtual team, at the time, comprises of different platform - engineering capabilities, so the foundations of IT. We started to look into how can we not just map the process, - but arrange an internal compelling product. And we had one use case which was requesting - or when the team was requesting a cloud environment. We built it in Azure or Amazon, doesn't matter in this particular case. The case was that every time that they were requesting, - they had six weeks to develop a prototype in this setup. But it was taking them roughly average five days to get - a new account. And that was a bit of a problem. Then we started thinking, what will be an internal compelling product? Well, if I take a credit card, - any of you take a credit card and you go and sign up for Azure or Amazon, - it takes you roughly 30 minutes to get a new environment. So if I, with the credit card, can get something in 30 minutes, - why does Mika in a company of our size need to wait five days? And it got me thinking. When we started to map that process, we started to look at these - dependencies. There are things that we could automate and we automated. There were things that needed a bit of a manual review and process, - and that is okay as well. In the end, when we started to streamline, - we ended up going from ticket-driven - to self-service from five days to 15 minutes. There are some people from the team in the crowd, - so they might say it's actually five minutes. But I'm being generous. I'm giving them 15 on this case, - but it is actually around five minutes. That starts with thinking what is compelling - and that's the customer centricity that we miss a lot - when we think about this core it and infrastructure - in any company of any size because we are often not looking at who is using it. We are creating processes for us and not really looking at - who is going to request things and what is their point of view. Of course, that was one of the, let's say, first cases - that we started to look, and then I started to look a bit more - broadly on core IT versus digital development. Understanding that there are different personas requesting those services - with different expectations, different needs, but also that - the processes were tailored to our company a lot towards service managers - that are looking at core IT applications. In their case, completely okay to wait five minutes for an environment. They don't have the rush, so to speak. Meaning that there are other things that they can cascade. Digital development was a bit of a problem. They need speed and agility, - even though we have hundreds of developers in the house. When we start looking at DevOps... I'm not sure if you saw my slides, but you mentioned this. DevOps, a lot of it exists within our teams. So our software engineering teams, they don't have a DevOps team. They might have a DevOps engineer to coach the team. But in essence, the whole team works in a DevOps manner. I think most cases today, - I mean, we are 2024 turning 2025, so this is not news. When we started to look more broadly, we started to look at, - in some cases, when we have multiple teams - that work towards the same goal, business goal, - in some cases, it made sense to form a domain-level platform team - that accelerates those different development teams. That is what we start calling platform engineering - in the broad sense or loose term of the sense. Now, if you jump a bit forward, a lot of companies, - ours was not an exclusion, had this platform DevSecOps or developer - experience team. We had this back then. They were focusing on, for instance, it was the team's responsibility to - look at things like Atlassian tools, GitHub. They're not sponsoring me for saying this, - but just to give you a perspective of different tools. The normal DevOps tools that you find in a company, - those were the tools that this team was doing at the same time. And we could call that, to some extent, platform engineering. When we think and look more broadly, we also had - in the core IT infrastructure, a managed services provider, so an MSP. You could also argue that in their mind or in their thoughts, - that was also platform engineering. You have a team supported by - an external or multiple external partners looking into - how do you get the cloud environment and that standardization? How do you support those running ERP systems - and HR systems and God knows what? All of those things, both of them could be classified as platform engineering. So wouldn't the natural step be to think holistically? On one side, you have managed service providers and core IT platform - engineering teams looking at the standardization, - looking at running things in a secure manner and running things - with a high availability. On the other side, - you need the agility and the automation. Why not combine the best of both worlds? And that's what we did. That led to very interesting discussions and very different learnings. I think one was that we started to continue thinking more broadly. Who is a service manager, by the way? Do we have service management professionals here? Okay, one. All right. This will be boring to you, but maybe not so boring to us. I know nothing about service management, or know very little. To my team, I know nothing. But the point is that I started to look - and I started to ask the team, how do you see this picture, - this compilation of this delivery model where you need to kind of look - holistically, not just from a platform, - but if you look from a normal ITIL framework, - I mean, how do you see those steps from the end user. The end user might be a developer, a service manager, - an employee or a consultant working for us. How do you see how they access things? So we started to look at that. And we realized that in this, - I mean, this is our own version of the model, - this is a normal service management model, by the way. But what we realized is that in most of the service management models, - it ends with application management. That's the baseline. Where is platform engineering? So we felt the need - that platform engineering needs to be there to support all of that. You will argue from a service management perspective is an application itself. But we felt the need to differentiate this - because there's no application that will run in our cloud or on our premise - environment or even a SaaS that does not obey to, - for instance, to the basics of platform engineering. You will not run a SaaS in our company without having a connection to AD - and the employees can log in with their employee credentials, right? That's the platform engineering capability. We started to feel the need that even in all the cases, - SaaS, on-prem or cloud, - you feel that you need to have a standardization in processes and tools. Now, what we end up, and this is a journey that we are still going, - I mean, proving, I would say, good learnings and opportunities, - but it has also been one of the three key things - that we have been discovering together. I say together because it's a compilation of functions actually. It's both cybersecurity, it's infrastructure, - it's network, it's service management. It's a digital experience and end-user services. So there are so many different IT domains coming to this. That was one of the first realizations we had - that you cannot do platform engineering without looking at the personas. Who are your customers, how do you make that internal compelling product? When you identify those personas, we identified three as mentioned. Developers, service managers and employees - When you define those personas, you need to look at how you are operating as IT - and how you make it user-centric? How do you make it interesting for them? How do you make it compelling for them - because they will be the ones to use it, and the alternative might be that - they just take a credit card and do something. We need to make it compelling for them. The other part was this service delivery model. That is a bit of a journey, but looking at what are you actually offering? What is your service offering when you look at platform engineering? So making that catalogue, making that visible in - an elevator type of pitch. If someone asks, what's your platform engineering doing? You should be able to tell them in five minutes or less. So understanding what they have to provide in the company. And then once you define that, - what are the delivery methods that they choose? Do they want to, will we deliver this internally, externally, - is it a hybrid co-development? So understanding all of those nuances - and how that interacts with the different layers above is incredibly important. And then the third point was the the focus on having a good workflow, - understanding the process. Often engineers jump to tools. They jump to development without looking at the picture ahead. Where does this fit? Why am I doing this? So focusing on the process, that impact is incredibly important. And once you identify the process and start mapping - those dependencies, then you have the opportunities to automate. Automating shouldn't be an end goal by itself. Automation should be a means to an end. A lot of things don't need to be automated. Some things should, but if it's something that you do once a year, - why would you automate it? If it takes you more time to automate it rather than - actually delivering it. So finding that balance. And of course, when you look at this totality, - you could say that it takes quite a long time to get there. Yes, but you need to start little by little. I think that the most important thing is that you start doing it - and that done is better than perfect. So start launching early. That was also one of the key outcomes for us. Thank you so much. [outro music]