Red Hat doesn't just talk about transformation, we do transformation with our clients, hands-on.

I recently committed code into a code repository for a transformation project, working alongside our customer and the Red Hat APAC Open Innovation Labs team in a residency-style engagement. Let's talk about why Red Hat customers choose to work with us to transform vital parts of their business.

Organizations realize that transformation needs to be people-centric. It can’t be only top-down, theoretical, or unrelatable to outcomes. That only allows room for fear and change resistance to grow. 

It needs to come with globally proven practices, methodologies and processes. It needs to build on innovative open source, cloud-ready technology and bring people together on the journey of collaboration, information sharing—in a safe environment to learn and grow. 

That’s what the Red Hat approach is all about. And I’ll walk you through the details now.

Words are cheap. Show me your code.

Our industry is full of buzzwords. Once storage and photocopy machine vendors started talking about “digital transformation,” the industry was—yet again—in for a ride. And because of it, you know you have to specify precisely what you mean when you say “digital transformation.”

Unfortunately, I had to learn the hard way: I have delivered complex transformation projects in the automotive industry and the banking sector, and more system-specific enterprise resource planning (ERP) migrations and human resources (HR) and customer relationship management (CRM) system  modernizations. These projects were Waterfall and Gantt chart driven.  

In these experiences, I saw that  digital transformation often comes at a heavy price, especially for people who care, but see themselves drowning in a sea of “things that could go wrong” without fast and effective feedback loops and channels to make their insights heard to the decision makers far, far away (did someone say empowered teams?). 

With fast feedback loops, weekly demos and retrospectives, real-time documentation and reporting and—most importantly—co-creating and co-delivering real transformation daily with the customer, the Red Hat residency transformation approach is different, refreshing, empowering, people-centric.

But as Linus Torvalds and my friend Faisal Masood say, “Words are cheap. Show me your code.” and for all the “How” people (like me) out there, I’ll walk you through the actual approach next.

Let’s get started with a discovery session

Pre-engagement starts with a discovery session. This is a mixture of open culture practices that help break the ice, make attendees feel comfortable, enable open information sharing and open collaboration to create a shared understanding of the terminology, business and technology context, approach, and goals. Before the engagement kicks off, the delivery team is set up with VPN and system access for Jira, GitLab, OpenShift, etc.

Figure 1. As the residency kicks off participants are in for a ride. A Red Hatter once called it a 6-to-12-week pressure cooker, and that description is very close. 

People will be stretched as new concepts, new technologies, new practices, and new team members get introduced. 

These factors can lead to change resistance and fear. That’s why there’s a major focus on creating the right team culture, a safe space, psychological safety, and a safe learning environment through open information sharing and collaboration practices. Red Hat technology experts are working closely with the customers' business experts, which is why reciprocal learning happens every day.

During the Discovery Session, we picked components to focus on through voting.  One with medium complexity where we were able to address the vital questions of how to achieve scalability, availability through eventual consistency, routing and integrations to start the decomposition into microservices.

On the people and process change management side, we create a team identity—a sense of belonging, a social contract, logos, and run energizers while we introduce practices we use later on to create deliverables. Energizers are short team based fun exercises that take the mind off the current problem space.

For example, we split up all participants into smaller teams to demonstrate mobbing versus pairing to design the team logo. This allows people to experience first-hand when specific practices are useful and when they are not. Smaller team sizes also help ensure that everyone is actively involved in a safe space.

More delivery-focused activities in the first few days are running a session to agree on the “Definition of Ready” and “Definition of Done.” We also prioritize the goals so that we find the right balance between the desired people, process, and technology emphasis.

My favorites are the daily retrospectives and learning more about other cultures during the daily energizers with our regionally diverse team. There are so many people from different countries, cities, languages, or time zones involved—there’s always heaps to learn.

We then move fairly swiftly into more delivery-specific exercises with user story mapping and event storming. These exercises help us create a shared understanding between technology, product and business participants as well as define the bounded context to drive the microservices design. 

The Red Hat team delivers short education and training sessions throughout the day by running Event Storming on a Pizza Delivery example or a slide deck that explains core fundamentals of microservices design, patterns, eventual consistency, and when to use a monolithic versus microservices approach.

Additional complexity and picking up speed

At the end of week 1, application programming interface (API) design is ready and coding is already under way. 

Additional complexity arises when existing, and new codebases need to run in parallel and legacy data backends, and database schemas need to be extended or new data repositories created. In addition, technical details like distributed transactions, synchronous and asynchronous calls, class design, implementation technologies (e.g., Spring Boot versus Quarkus), test approaches, libraries to use need to be discussed and agreed upon and education gaps filled.  

Build pipelines and QA environments are created and the creation and deployment automated. All the while, business logic is shared and explained through conversations with business stakeholders, demos, reading existing code, entity-relationship diagrams, and querying the database.

Globally, many institutions have chosen this approach working closely with Red Hat. It’s a game-changer. It’s learning by doing, and investing money into creating outcomes instead of just writing a document about it.

The truth, however, is that you need the technical, design, and architecture expertise to make this successful. This is what Red Hat brings to the table whether in person or through a virtual residency style. The approach remains consistent with tightly-knit teams collaborating and sharing challenges and progress. The technology and practice expertise transfers from Red Hat to our customers, with the goal of setting up customers to continue as a self-sufficient team. If the transformation is enterprise-wide, we establish what we call Dojos, where different teams rotate in and out so that the same concepts, patterns, blueprints, and approaches can be reused.

By the end of week one

By the end of week one, people and teams have accomplished more than they thought they would. Our engagement leads like Donna Benjamin usually create videos to remind the team what was learned and covered:

  • Figure 2. Agile Agenda

  • Team building exercises and a social contract

  • Learning mobbing and pairing while designing the team logo

  • Word of the day in 10 different languages

  • User Story Mapping

  • Event Storming, Bounded Context, Microservices design and patterns

  • Team exercises to apply the new concepts right away

  • Project structure, code samples, git repositories, user stories in Jira, a groomed backlog

  • How to trade off performance, scalability, and consistency and why

  • ...and the first showcase

  • Retro

In week two of a residency

In week two, the pace continues at high speed (as in all other weeks really), which means that energizers and team fun exercises are very important. And that’s on top of driving implementation progress, of course. After walking the walls every day to recap what has been done in previous weeks and days, the microservice API designs are finalized, and coding is in full swing. 

The code outline is filled with business logic, and the routing between monolithic legacy code elements and the new microservices design is implemented.

Figure 3. Distributed transaction and eventual consistency designs are discussed and finalized before being put into code. The continuous integration/continuous delivery (CI/CD) pipelines are now stable across development, test, and production environments. During this week, the team does confidence votes on the sprint goal, run tests, document architecture, prepare and run another showcase, and create and assign action items out of the things that the retrospective identified as “to be improved” before our engagement lead creates another video of the week.

Week three and beyond

As application code, tests, and deployment pipelines are getting production-ready, the focus shifts towards production deployment. Because legacy code and new microservices components are running side-by-side, deploying a microservices-based routing component is necessary. This routing component routes requests and determines whether to call the new or legacy components. As more and more legacy components are replaced, the router gets updated and, hence, is a vital component at the heart of the transformation journey toward a microservices architecture.

Webhooks trigger new builds, test runs, and deployments from code into the test environments, and the latest supported Red Hat Universal Base Image is used to build off a secure, tested and supported container image to increase our customer’s software supply chain security posture.

Outcomes after six weeks

Having worked on transformation programs that are usually more than 18 months long, it’s quite astonishing what can be achieved in 12 weeks or less. Depending on the complexities and scope involved, the core microservices are usually completed after 6 to 12 weeks. On git-commit, container images are built, functionality and security tested, and deployed. Integration test scenarios demonstrate how requests are routed to the new microservices. Finally, performance and load tests are run to showcase how the Red Hat OpenShift Container Platform automatically scales individual pods based on load scenarios.

Figure 4. The weekly showcases and demo day is a great change management tool. It allows the delivery teams to take center stage in front of peers and executives to present what they have achieved during the recent sprints.

Most importantly, the customer’s team has learned how all the parts fit together, from coding to troubleshooting to running in production. And the transformation has occurred because the changes across the people, process, and technology dimensions have been implemented, taught, and understood. 

As a result, there’s no need to go back to doing things the old way. Once the module is production-ready, the team is moving on to the next module. In this case, the client has chosen first to establish the overall microservices design through Event Storming across all modules.

 The client team can then implement the next component by reusing patterns, practices, designs, and infrastructure components already created. As the client matures, the Red Hat team can exit and sprinkle the residency style transformation fairy dust onto another team or organization.

The power of transforming by doing

The Red Hat residency style transformation engagement is hands-on. There’s no slide or concept which remains a theory only. The goals are ambitious but reachable—the participants and organization can walk away having learned a lot. And that in itself is a goal for many transformation programs. 

The money on those engagements is spent on doing transformation, reducing fear, bringing people along, learning, and getting hands-on with new processes, practices, and technologies. Those wise transformation papers and articles can’t tell you if whatever is described will work in your organization. The Red Hat approach is different. 

I wish I had known this approach before starting any of my high-stress, over budget, over time, waterfall transformation programs. Once you see how open collaboration and open information flow positively affects your culture while people learn, take ownership and produce tangible results, you can’t go back.

Learn how Red Hat Open Innovation Labs uses an immersive residency to arm customers with the skills, tools, and processes to deliver better software, more quickly, to meet the demands of today’s market.


Open Practice Library series on the Red Hat Blog

virtual collaboration illustration

Learn more about our community-driven collection of exercises for making incremental progress along the product delivery cycle from the full Open Practice Library series: 


About the author

Andreas Spanner leads Red Hat’s Cloud Strategy & Digital Transformation efforts across Australia and New Zealand. Spanner has worked on a wide range of initiatives across different industries in Europe, North America and APAC including full-scale ERP migrations, HR, finance and accounting, manufacturing, supply chain logistics transformations and scalable core banking strategies to support regional business growth strategies. He has an engineering degree from the University of Ravensburg, Germany.

Read full bio