What type of initial workload should you focus on when adopting new technology? I’ll explain why you shouldn’t quickly rule out mission critical.

In a discussion with the CTO of a bank on getting the company’s first workload onto the IBM Cloud Pak® for Integration, he surprised me by saying that they always prefer mission critical workloads as the first workload for new technologies. His statement made me reconsider and seek input on my usual, industry-standard recommendation to avoid mission critical workloads as the first on a new technology. My conclusion, after probing deeper, is that companies shouldn’t hesitate to consider using mission critical workloads to pilot new technology as long as certain conditions are met and there are measurable advantages to be gained.

Approach new technology strategically

My recommendation for adopting new technology is to focus on getting an initial workload deployed to production on the technology to prove its effectiveness, start deriving value from the technology quickly, and build skills, confidence, and buy-in towards its adoption. Too often, I’ve seen companies adopt a new technology platform with a ‘build it and they will come’ approach, and, for a variety of reasons, the planned-for workload never comes. We (the IBM Garage team) have adapted our approach to develop innovative minimal viable products (MVPs) to apply to all types of new technology adoption. The key is choosing a thin slice of workload that can be deployed through production to start delivering value, while meeting non-functional requirements and building skills.

To put a new technology into production, you must be confident the technology can meet the workload’s functional and non-functional requirements (NFRs) — security, latency, reliability, monitoring, etc. — and that the teams who have developed the workload and those that will operate the technology have the skills and established processes in place to meet these requirements. My default in the past has been to recommend a workload that will deliver business value, but one that is not mission critical and has reasonably ‘easy’ NFRs to meet to mitigate risk.

However, with today’s technologies and practices, you can lower the impact of a new workload failing to meet NFRs to be negligible, therefore eliminating the main reason to not consider deploying mission critical workloads. Some key practices and technologies to apply are canary testing, dark launch (where you only route a small part of traffic through the new deployment), and reversibility (where you can back out from using the new technology).

With these capabilities, you can ensure the newly adopted technology can be switched off without disruption, if necessary, and can process the initial traffic. Then, you can gradually add more traffic and features. This requires keeping the older infrastructure in place to be able to process some of the traffic or as an active backup until you are confident in the new technology. Unfortunately, I’ve seen major issues when switchovers are done without a verified backup or backout option. Additionally, adoption of Site Reliability Engineering (SRE) practices — including automation for maintenance and recovery — further lowers operational risk.

The advantages of mission critical for the first workload

So, if we can mitigate risk, what else keeps people from starting with mission critical workloads? A commonly made mistake is to associate mission critical with the biggest, hairiest, and hardest-to-modernize workloads — and no one wants that as their ‘first’ anything.

At its core, mission critical means the workload’s capability is deeply impactful to the business, and that doesn’t mean it has to be big, hairy, or even too hard (more on that in the next section). The focus of adopting new technology should be delivering direct business value — whether that be speed to deploy new features, lower cost, improving processing, or expanding into new geographies. Therefore, there is greater benefit to be gained in applying new technology to mission critical workloads because they are part of highly impactful business functions.

Mission critical workloads, whether simple or complex, typically have requirements for consistent availability, reliability, and performance. They may also have more stringent security, latency, and auditing requirements than other workloads — which all sound like disadvantages when wanting to quickly receive value from the new technology, and they can be. However, there are also advantages — you can choose mission critical as an opportunity to test if the technology is ready to meet a subset of critical NFRs and also to push your teams to ensure they are ready to operate the technology. Sometimes, teams may want to start with a simple, non-critical workload to get the technology up and running quickly, with more gradual learning as they go. Which workload and associated NFRS to initially address is, ultimately, a balancing act based on your unique IT imperatives, skills, and the business case for the technology adoption.

Start off small and build in increments to larger adoption

Judicious selection of a mission critical workload means avoiding choosing the biggest or most complex workload. Instead, pick a simpler workload that still has impact and will require the technology and organization to meet a subset of your ultimate NFRs.

For example, the workload could be a single API that is part of a larger business process or is client facing — such checking on real-time stock availability. In this case, the NFRs would include low latency and high availability, but not compliance or handling of sensitive information. If the workload chosen was, for example, the entirety of the online shopping experience, many additional NFRs would be required and the time to deploy and receive value from the new technology would be significantly longer.

When approaching larger workloads, my recommendation is to modernize in slices; incrementally keep moving more of the workload onto the new technology, gradually adding more NFR capability from both technological deployment and from increasing skills and adapting processes. With a strategic and gradual approach, higher confidence and readiness to deploy more complex workloads will grow as the process continues.

Design a holistic adoption strategy to support growth and scale

Choosing the first workload should be part of an overall new technology adoption journey. The new technology needs to be architected to meet the NFRs of the ultimate set of target workloads. In addition to architecture, you need a roadmap to incrementally add more NFRs and more functional features. You need to ensure you have a plan to acquire what is needed to support your roadmap and target architecture — for example, a public cloud needs to currently or eventually have the compliance certifications required to support your regulated workloads.

Skill development is also a critical element of your roadmap. I highly recommend focusing on experiential learning as well as digital and classroom learning. With any new technology adoption, I recommend consulting experts to help you with building your architecture, roadmap, and skill development — ideally as part of your team to get your initial workload (whether it be mission critical or not) into production and to accelerate experiential learning.

You can learn more about my team’s approach to new technology adoption and innovation from our published IBM Garage Methodology. Also, the IBM Garage team and I would be happy to talk to you about new technology adoption— you can contact my team directly through the Email an Expert form on our site. For further insight into the topic, I recommend this blog by my colleague Kyle Brown about how to start ‘strangling’ existing monolith applications and move them to new technologies.

I also want to thank Kyle Brown and Stacy Joines, IBM Fellows in IBM Garage, for their great insights on this topic that contributed to this blog.