Cloud Transformation at Scale
How do we enable cloud transformation within the enterprise?
From strategy to execution – Listen to how H&M mobilized their cloud transformation to enable speed and innovation.
How modern ways of working and DevOps created a customer obsessed value driven new focus and organization powered by people, data and tech.
Chapters
Full transcript
The complete talk, organized by section.
Jakob Knutsson
Hi, my name is Jakob Knutsson. I'm from H&M Group and work as a Product Area Lead Engineer for Platform Engineering. I'm here to talk about our cloud transformation and how we do that at scale.
H&M started in 1947 in a small Swedish town called Västerås, and in 1998, we started our first online shop. At the moment, we're 177,000 employees, 4,000 within IT, and around 800 of those are developers. Right now, we're building a product organization. One thing that I need to highlight is that 73% of employees in positions of responsibility are women, and that's really cool.
Retail is rapidly changing. We see a lot of changed customer behaviors, a lot of changed customer expectations, and of course, the competitive landscape changes all of the time. You all know that software eats the world. It eats the traditional business, it eats the value chain, and of course, we need to adapt.
In forming our digital business, we came up with a number of tech principles. We want to be customer-centric, close to the customer, and build a digital experience that our customers want and love. We want to be open, so start moving away from legacy integrations and use APIs and be really open and connected. And agile, being able to release on demand to really live up to those customer expectations. And intelligent, data-enabled. We have a lot of information flowing through our applications and platforms, and we want to leverage that data to really take data-driven decisions. And global. We're a global company. We have customers all over the world. To build a digital experience that they love, we need to be as close to the customer as possible.
Why cloud, then, you might ask? Well, we see cloud as a real true enabler. Cloud will give us a faster pace. It will build us a better global scale, and of course, more value for money if we build right and then focus on those value-added services. The cloud providers' R&D departments are far greater than we could build in-house, so leverage those services that really make an impact to build better products.
Traditionally, we've been really slow. We've been siloed. We have been working to keep the lights on, and it has been successful, but it has made us really slow. Now we want to change that. We want to focus on our key differentiators, what really makes us different. So we came up with our cloud strategy: H&M Group should run entirely in the cloud, supported by an organization that could build effective and secure cloud solutions using DevOps practices.
Our approach: how did we get started in this? There were initiatives within the cloud all around the company, but we needed to take some central governance and kickstart that central initiative. I'm going to talk about how we got started with Agile and DevOps practices and knowledge sharing and really having everything as code.
As I mentioned earlier, we started small. There were proof of concepts locally within different divisions, and we took the learnings from that and formed a central team. The first thing that project or team did was to establish a line organization that could take over when the project was finished. So we established a center for enablement called Cloud Office, to really become that tech enabler.
The focus or mission that we have is to enable and monitor the H&M cloud strategy, drive and support our cloud adoption, and focus a lot on engineering efficiency in the developer experience. One thing that we can do to improve the experience and efficiency of our engineers is to develop self-service capabilities that really enable the development of product teams to maximize the value output and to hit the ground running.
This was the starting point. We formed a center for enablement. We had one team focusing on the cloud adoption, helping out with advisory, really being out there in the organization and getting the teams up to speed. They could support with reference architectures, mapping current architectures to a good cloud architecture, and so forth. The Platform DevOps team stand on two legs. One: developing the platform with the governance and guardrails and some central services. We have a hub-and-spoke architecture. We're in a hybrid state at the moment. So taking care of those platform capabilities. The other leg that they stand on is to focus on that developer experience, so automating flows and building the Lego blocks that you can drag and drop into your pipeline. So every team doesn't need to reinvent the wheel for things like ordering DNS, certificates, authentication on your application, and those things that really make us faster. Then we have a Cloud Operations team that helps with developing the platform capabilities and also runs our central services.
Coming up with evolving our platform, taking aim at the North Star: where do we want to be? We have some design principles. We want to be cloud-native, so leverage cloud-native capabilities over third-party software. We want to be application-centric, to really cater for autonomy within our product teams, and resources belonging to an application should live as close to that application as possible. Subscription or infrastructure democratization is so important. Every resource that you spin up in the cloud as a product team, you take care of that. We're putting the infrastructure in the hands of our product teams when they need it, on demand, so that they can build the products that really make a difference.
We need, of course, to be archetype-neutral. We have a lot of legacy systems, and our cloud platform needs to cater for that as well. And we run our platform as code. Every change that we do to the platform is checked into a repo. It's deployed via pipelines, so we get that traceability and reusability and can really set an example within the organization on the everything-as-code agenda.
We do some policy-driven governance, and we see that with central governance and decentralized provisioning, we're really hitting the best spot within our cloud estate. We focus on 100% self-service and automation, and we provide reusable assets to get our teams going. As I was mentioning, those things that every team needs, but you don't want to reinvent the wheel every time. Getting things that you can drag and drop, like Lego bricks, into your pipeline to get your certificates and enable your authentication and work with your application.
To really spread the information, we're a large organization. We started out with setting up a lot of events and forums and hack days and knowledge sharing and inspirational sessions, and really started that evangelization both within cloud and DevOps and started to build a community. It's really important in the beginning to be super approachable and inviting and let all the people from the organization join you.
A key success factor for us has been having a central developer portal where you can have the documentation and guidelines and publish your repos with reference architecture, reference implementations. We call that TechSpot. TechSpot is not only a portal. It's a community. It's a Q&A. It's the documentation, the guidelines, the how-tos, the golden patterns. There's also the event part of it, the meetups, and actually it's building our whole engineering community.
As I was mentioning, we have a past, and now we're building our product organization. We're actually merging IT and business development to work together in multi-competent product teams. So we say we don't have any IT department anymore. We just have business tech. The base, of course, is our foundation of the H&M values, and then with the building blocks of DevOps and Agile, decoupled modern architecture, and the cloud.
We have super exciting times ahead of us. Business Tech will focus on the customer and business value and tech to really build a digital experience that our customers will love.
If you look at our product teams, they will have end-to-end responsibility of their product or application. They will be multi-competent and, of course, fully autonomous. So important, tying back to that first ideal of locality and simplicity, and of course, working with DevOps practices. What we want to achieve with this is, of course, be passionate about customer and business value and excite and empower our people that are building those products and shorten the time from idea to market.
We're not here to serve the business anymore. We're here to solve the problems that our customers face in ways that serve the business.
If we look at where we're coming from to where we're going: traditionally, we had roles that defined the specific responsibility, and now we want the product teams to share the responsibility, to have that shared responsibility of the product and the future and the roadmap of the product. We're coming from a handover and approval-based way of working, and now we want to focus on having that constant flow of value and reduce our manual activities. We want to build a culture of automation and actually paying off that technical debt, and of course the organizational and complexity debt as well. Development was measured on feature delivery, and operations measured on reliability. Now we want the product teams to take full responsibility and be measured on the value output that they provide.
We want to be able to move away from those long release cycles, to have that friction-free, continuous delivery of business value. It's a competitive advantage to be able to release on demand. Of course, we shouldn't be afraid of failure. We should use failure to learn and then try to pivot.
If we're trying to sum this up, having a clear strategy, of course, helps a lot, and you need to have that top management support. Maybe you can transform a couple of projects, but without that top management support, it's really hard. Going back from where we started, we were the pioneers, and it took us two years, and then we built the product organization that really captures all the values that we were after.
Don't worry too much on operating models. Just get the team going and establish the team, start executing, and just get going. I think we're not a bank, so we allow maximum freedom to our product teams with just enough governance.
I encourage you to use small batch thinking, MVP, and then scale. Super important to incorporate those key functions. Keep the security close, the networking, the identity and access management, because all of those things change when you move to cloud. Have that close partnership with your cloud provider and support team. Of course, super important to test, fail, learn, and constantly revisit your solution, because cloud is a constant evolvement, changes every time.
Scaling for our product organization: I've been talking about our central enablement for cloud, but now we're also building enablement teams for API and integrations, for DevOps and test, and security and risk, because it's going to be hard. We're a large organization. It's going to be hard to have that expert competence within all of the teams. We're over 200 product teams. So we're building enablements that work on hands-on advisory, being out there with a team, coding with them, having assets, guidelines, documentation in place to get the teams going.
H&M, we're all in on Business Tech, and the organization that you build must support the vision. Establishing our center for enablement and working with agile ways of working and DevOps practices has been really successful in our cloud journey and in our organizational journey and the way that we actually provide value. As an example, now we can provision a developer environment within under 10 minutes, and this could have taken weeks in our on-premises state.
We're setting up all our platforms to be easy to use and self-service. We're starting to build a community for our engineers, and having that developer portal, the one turning point where you know you can find the information at need. It's also community-driven, so you as an engineer at H&M can contribute with your knowledge, and provide onboarding support in the beginning to get the teams up and running, and never stop improving. Super important.
With that, we see a future with an infinite ambition, and we will continuously work to surprise and delight our customers by releasing the power of people, data, and tech to accelerate our business. It's really been an honor to be here at the DevOps Enterprise Summit and be invited by Gene.
I want to finish off with some words from the H&M founder, Erling Persson: "The secret to our success? There is no secret. The industry is so dynamic that it's absolutely necessary to constantly renew yourself and have a flexible mindset." I think this is super relevant even today, and with the times we are in now with the COVID and corona situation, many of us working from home, it's super important to renew yourself and have a flexible mindset.
With that said, I want to say thank you. My name is Jakob Knutsson. I work as a Product Area Lead Engineer at the H&M Group, and it's been a pleasure to be here at the DevOps Enterprise Summit. I will watch as many sessions as I can and try to learn and absorb as much as possible. Thank you.