Most professionals who’ve spent enough time in the IT industry have seen organizational silos in action. The classic silos are the ones created by Development and Operations organizations; silos we aim to break down through DevOps-style collaboration. But how many organizations pursuing digital transformation are continuing that siloed thinking when it comes to evaluating the application portfolio for cloud migration and modernization?
Application Development, Database Operations, Infrastructure, and the various lines of business have portions of the application portfolio for which they take responsibility. When organizations think about modernization, they need to deemphasize the silos and develop a comprehensive approach that evaluates the entire portfolio, and the teams that support those applications. Otherwise, they’re leaving money on the table in the form of missed opportunities for cost savings and application improvements that generate revenue and increase customer engagement.
A comprehensive approach takes into account the full range of workloads supported by the IT organization and starts making tough decisions about: which workloads can/should be modernized, which should be rehosted to take advantage of more efficient cloud platforms, and which should be left as is or even retired because they’re outlived their usefulness.
My team works with many organizations that treat Kubernetes/OpenShift container platform adoption as an infrastructure modernization project. We recommend using the current wave of Kubernetes adoption as an opportunity to broaden the discussion, build bridges between Ops and Dev, and develop an approach that evaluates all application migration pathways, including ones that may not necessarily result in containerization.
So how does an organization work through an application portfolio assessment efficiently and holistically?
One way to approach this project is through a three-step process that looks like the following:
- Filter the Portfolio/Teams
- Identify and Select Archetypes and Teams
- Analyze and Prioritize Individual Applications and Teams
Step 1. Filter the Portfolio/Teams
Start with a configuration management database or application index and assemble your candidate application population. Ideally, this index also has some information about the team responsible for operating, maintaining, and developing the applications. This might include the responsible group, project manager, primary technical team lead, and number of operators and developers.
At this point, it’s important to apply a filter to the application/team inventory, setting aside workload/team types that are not good initial candidates for onboarding to container platforms.
Kubernetes has to-date largely focused on orchestration inside Linux host clusters. Workloads that target other operating systems, especially mainframe and enterprise desktop, don’t make good candidates for initial onboarding activity today. This story may change to the extent that Microsoft containers and Windows hosts become more integrated into the Kubernetes ecosystem and its operational practices.
Because container platform workflows accelerate software development and deployment practices, the largest ROI opportunities are with workloads whose source code you maintain and control. These are the workloads for which accelerated deployment frequency can improve software quality and foster innovation and value creation. This should also include net-new development, including modernization efforts that involve rewriting legacy mainframe workloads as container-native applications. Infrequently re-deployed commercial off-the-shelf databases and other enterprise products may not be the right workloads to start with, especially if they weren’t designed to take advantage of distributed, elastic cloud environments.
Put all of these considerations together and you wind up with a preliminary filtering guide that looks something like the following:
Step 2. Identify and Select Archetypes and Teams
Step 1 should have resulted in a much smaller list of workloads and teams for consideration for onboarding to the container platform. The next step is to understand where to focus within the remaining set to capture the best ROI for modernization. That means considering application patterns, application value to the business, and team personality.
Every application portfolio has a mix of application types. These types are defined by application function (user interface layer, API layer, web services, batch processing, etc.), system dependencies, and technology choices, among other variables. Identify applications that seem to match particular patterns (e.g. Java web services) that tend to repeat themselves across the portfolio. The idea is to perform an onboarding and capture lessons learned in a way that can be reapplied among the remainder of applications of the same type. You want to address as much of the portfolio with that repeatable pattern of onboarding as possible.
Also in this stage, consider that each application generates differing levels of business value for the organization. Some applications may be infrequently used or outmoded completely. These are candidates for retirement. Some applications may have more visibility to the organization and/or support revenue generating function. Actively developed applications are more likely to benefit from rapid delivery processes aligned to container technology.
Beyond that, the onboarding process represents an opportunity to create a new platform of API-driven, reusable services opened to a wider stakeholder group. Try to select applications and workloads that contribute to this kind of transformed vision of service delivery and add productive value to the organization, with a measurable impact that can be highlighted to build enthusiasm for the program.
Finally, recognize that not all teams have equal enthusiasm to be early adopters of enterprise cloud technology. Consider teams that have demonstrated an ability to learn and embrace new technology, and, importantly, are willing to provide feedback to the platform team on how the platform and onboarding processes can be adjusted to create a pleasant platform user experience for other onboarded development teams in the future.
Step 3. Analyze and Prioritize Individual Applications/Teams
Now that you have your application portfolio and team analysis focused on a smaller, more manageable number of applications and teams, you’re ready to do a deep dive analysis on the prioritization of those workloads and rough level of complexity for migrating each.
The high level technical requirements for application suitability for container platforms are not particularly stringent. Here is a sample list of criteria for Red Hat OpenShift:
You may want to expand beyond these basic criteria to uncover hidden layers of complexity that could cause an onboarding project to get bogged down. Are there dependencies on external services that will need to be onboarded to the container platform as well or is egress routing sufficient? How well does the application support clustering for resiliency or performance? Does the application have a robust test suite to validate proper system behavior after onboarding to the new platform? Does it have a performance metrics baseline to compare against?
You would like to arrive at a decision on which initial teams will launch and spearhead your container adoption program, along with a queue of 10-15 additional teams and workloads for expanding the program in the next phase of application onboarding. Use initial app onboarding efforts as test cases, documenting what is working and what isn’t and capturing patterns of app onboarding techniques that can be re-applied across the portfolio.
Container adoption requires cross-functional collaboration between operations and application teams to develop a platform that works for everyone. The most important thing is getting started and getting feedback. With a portfolio assessment completed, you have enough planning in place to get application onboarding off on the right foot.