I just finished reading the “The Unicorn Project: A Novel About Developers, Digital Disruption, and Thriving in the Age of Data” by Gene Kim. If you are not familiar with the book, the story follows Maxine and Kurt, employees of a car parts retailer and manufacturer named Parts Unlimited. After a production issue, Maxine is reassigned to the Phoenix Project, a massive transformative project that spans almost every platform in the company. When Maxine tries to do a build on the Phoenix Project and is unable to get it working, she is introduced to Kurt and the Rebellion. The Rebellion is a group of engineers within IT trying to transform the company and the way they do work. In working with the Rebellion, Maxine and Kurt lead a total transformation of Parts Unlimited by focusing on the “Five Ideals.”

• The First Ideal: Locality and Simplicity
• The Second Ideal: Focus, Flow, and Joy
• The Third Ideal: Improvement of Daily Work
• The Fourth Ideal: Psychological Safety
• The Fifth Ideal: Customer Focus

At first glance, you might think that the book would advocate removing older legacy platforms like the mainframe, but that is not at all the case. The book is about modernizing, improving the developer experience, and eliminating technical debt. All of these goals are possible and part of the modern mainframe.

First let’s tackle the idea of “modernizing the mainframe.” I do not like this term, since it implies that as a platform, the mainframe is not modern. I am here to say that is not the case. The mainframe is a modern and vibrant platform. With the release of IBM z16^®, as well as Db2^® v13, the platform is as modern as any cloud, web, or mobile platform. Enhanced capabilities around artificial intelligence and machine learning (AI/ML), quantum computing, and hybrid cloud are just a few of the advancements built into the latest release of the mainframe, bringing it in line with any modern platform today.

Instead, the discussion should really be focused on modernizing application development and architecture on the mainframe, and modernizing the development environment. This may seem like a subtle distinction, but it is a distinction nonetheless. Modernizing the application development space is absolutely necessary and in line with the message in “The Unicorn Project.” The most business-critical applications run on the mainframe, so updating and modernizing them is essential to becoming a high-performing organization.

Let’s look at modernizing application development through the lens of “The Unicorn Project” and the Five Ideals.

The First Ideal: Locality and Simplicity

Simply stated, this ideal relates to the degree to which a development team can make code changes in a single location without impacting various teams. Teams should be able to make simple changes in a single place and test them without affecting or involving other application teams.

I think of all the Five Ideals, this one could potentially be the most difficult to achieve for mainframe application teams. Over the years, many mainframe applications have become very interwoven with other applications, and it’s become increasingly difficult to make simple changes given their size and complexity. Refactoring and simplifying these applications will be challenging. Many of the subject matter experts who wrote these applications are either retired or close to retirement, so the expertise on these systems is dwindling.

The immediate task of refactoring and simplifying applications can seem very daunting, but the payoff for that work will set application teams up to reap the benefits of DevOps, and more importantly, make things simpler to maintain and change for the most critical applications in an organization. And by doing so, organizations will also modernize and simplify your most critical applications and make working on them easier and more fulfilling.

The Second Ideal: Focus, Flow, and Joy

This ideal is all about how daily work feels. To boil it down into a couple of words: developer experience. How does it feel to come into work each day and try to do your job? Is it a joy, are you working with top-of-the-line systems and processes that aid in getting work done, or is it a challenge each day? Does it take days or weeks waiting on processes or system to be available?

Focus, flow, and joy make your work a delight and help organizations attract and retain top talent. Like the first ideal, this one has fallen by the wayside for a lot of mainframe application development. As an example, many teams are still using green-screen technology and following older waterfall processes that make it more difficult to work. This need not be the case.

Mainframe developers can have the same focus, flow, and joy as their distributed counterparts. Modern integrated development environments (IDEs) like BMC AMI DevX Workbench for Eclipse or Visual Studio Code are available for doing day-to-day work. Mainframe source code management and deploy systems like BMC AMI DevX Code Pipeline are built with agility and the developer experience in mind. For those application teams  who can and want to make the transition to Git, ISPW fully integrates with Git systems. Achieving focus, flow, and joy will bring new life to existing developers and attract an entirely new generation onto the mainframe.

The Third Ideal: Improvement of Daily Work

While this ideal sounds a lot like things we touched on in the first and second ideal, this is a different concept. This ideal is about paying down technical debt that has built up over the years and re-architecting your applications to be more efficient. The first ideal is about decoupling applications so they’re easier and simpler to change. The second ideal is about making it easier for developers to do their work.

For the third ideal, technical debt needs to be treated as a priority and paid down and your architecture needs to be modernized so your development teams can flow and push out changes faster and easier. This can be a difficult proposition for mainframe teams. For years, technical debt on the mainframe has been ignored and allowed to build up, so it will take a lot of time and effort to dig back out of that hole, but it is well worth it. By improving your daily work on the mainframe, you make it approachable, easy, and smooth to deliver value. This is a necessary step for the advancement or development on the mainframe.

The Fourth Ideal: Psychological Safety

This is the idea that people should feel safe to speak up about issues, concerns, and problems. If teams do not feel they can bring up issues without fear of repercussions, then no problems or concerns will be discussed and issues will continue to arise and never get fixed. An open dialogue is one of the top indicators of team performance and is essential to building a high-performance team. Regardless of the platform, organizations need to create a culture of open communication at all levels to be able to confronts hard problem and resolve issues. This is true on the mainframe or any other platform.

The Fifth Ideal: Customer Focus

This ideal highlights the idea of “context and core,” as described by Geoffrey Moore. Core is what customers can and are willing to pay for—the center of your business. Context is the systems that customers do not care about—backend systems like marketing or HR. They are very important to the business and should be treated as such, but they are not essential to the customer or the customer experience.

Context should never kill core. Your focus should always be on the systems that face and are important to the customer. In almost all of the organizations we talk with, mainframe systems are core. They are the center of the business and essential to the customer experience. By focusing on mainframe applications and modernizing the development experience, organizations are keeping the fifth ideal.

The Five Ideals in “The Unicorn Project” are not exclusive to the four “ technology stock leaders—Meta, Amazon, Netflix, and Alphabet. They are for any organization, on any platform, with any application, that wants to make a change and become a high-performing organization. Mainframe is just another box in the datacenter and the applications on it are like any others that need to be modernized and reconstructed to stay relevant in today’s ever-changing market.

More and more mainframe organizations are either moving to Git or talking about moving to Git. Traditionally, the mainframe has existed as a separate platform, with its own set of tooling and processes, walled off from other platforms in the company like cloud, mobile, or web. As more mainframe teams are introduced to DevOps, though, these walls are starting to come down.

Many organizations use distributed tooling like Jenkins or GitHub Actions to orchestrate their continuous integration/continuous delivery (CI/CD) pipelines. Many also use tools like SonarQube to scan their source code and Veracode to enforce security. It is only natural that organizations would start to look to Git, the de facto standard for version control and source code management (SCM), to house their source. But this alone will not bring results—you need something to handle the remainder of the DevOps processes, such as build and deploy. To take your DevOps to the next level, you need to pair Git with a world-class build and deployment system like BMC AMI DevX Code Pipeline to supercharge your DevOps.

Why Git, why now?

The choice of Git is an easy one. It is the dominant SCM system in the industry and there are many reasons to adopt it.

• It was designed with the developer experience in mind. Whether you are using native Git or one of the popular remotes available like GitLab, GitHub or Bitbucket, Git was made to provide the best possible user experience and make day-to-day development easy. Git provides many built-in features to enhance the developer experience, like comparing, merging, and making it easy to approve changes.
• Git supports multiple languages and multiple methodologies for working. Just as it supports distributed languages like Java, C, Node or Python, it can support Cobol, JCL, Rexx, PL1, Assembler or any other source language necessary for mainframe applications.
• It offers branching support to enable parallel development amongst teams and individuals. Git allows a user to create an isolated environment for development or R&D and then merge that code back into the main branch or trunk.
• Git allows organizations to consolidate their software delivery lifecycle (SDLC) processes across the organization, regardless of platforms. The mainframe will no longer be a siloed platform if it uses the same tool and process as the rest of the organization.
• It enables easier on-boarding of new developers and empowers less-experienced engineers on the mainframe platform. College grads and younger engineers already have experience, having been trained on Git systems from day one. They come out of school already having a GitHub account or equivalent and have been using Git in their studies.
• Git Platforms are open and easy to integrate into almost any system. Due to its prolific use, almost any DevOps tools or environment already supports Git and Git systems support most platforms and tools.

How does Git work with ISPW?

So, now we understand Git but how does it work with BMC AMI DevX Code Pipeline to create a next-level DevOps system? You may be thinking, “Doesn’t ISPW handle source code itself?” Yes, ISPW does handle source code in addition to providing speed, agility, quality, and velocity in the way it handles that source. But, as detailed above, there are a lot of reasons an organization would want to bring Git into the picture to complement ISPW, allowing Git to do what it does best on top of ISPW’s world-class build and deploy capabilities on the mainframe.

To use Git on the mainframe is no different than using Git on any other platform or with any other codebase. A developer would branch code into a local environment and start making changes. As part of that process, they would call ISPW to handle building and executing any unit tests in their local environment. Once complete and satisfied with their changes, the developer would issue a pull request to merge the changes into the main branch. At that point, the changes would be reviewed and, if complete, merged back into the main branch. This is no different than a distributed developer working in Java.

This is not the only interaction ISPW would have with Git though. Now that changes are complete and merged into the main branch, they must be deployed. Thanks to ISPW’s open-borders approach, all the functions necessary to promote and deploy your change are exposed via API so now ISPW can be used to deploy your changes, as well. To make this even easier, a Jenkins plugin has been developed to handle this task which can easily be triggered from your Git system. If you do not have Jenkins, the same integrations have been built for other popular orchestration tools like GitHub Actions and Azure DevOps to name a few. Along with an API for anything, our expert services teams can help you create a deployment flow for your pipelines.

With your Mainframe plugged into the same process and CI/CD tooling you use for the rest of the platforms in your organization, you can then coordinate deployment across cross-functional teams so changes that go onto the mainframe can also be deployed at the same time as changes on cloud or any other distributed systems.

Does everyone HAVE to move to Git?

The answer is a simple, “no.” Like anything, this is not a one-size-fits-all solution. Git has many benefits and can be used in any scenario, but it might not fit every team or application. With BMC AMI DevX Code Pipeline, you can take a hybrid approach to development within the organization, allowing teams to decide if moving to Git is right for them. Let’s look at an example with 2 teams, team A and team B. Team A supports an application that is in maintenance mode, with no real new development, and they only deploy patches and updates 1-2 times per year. Team B supports a very active app that is deploying monthly, weekly, or maybe even daily. For team A, transitioning to Git does not make a lot of sense and they would get limited benefit out of it.  So, for team A, using the traditional mainframe development method would be fine.

Team B, however, wants to move to Git and would reap many benefits from the capabilities Git brings to the table. Typically, either team A or team B would have to conform to the other teams wishes—but not with ISPW. ISPW allows for a hybrid approach to development where one team can use Git and the other team can use ISPW for all of their development needs. This allows for flexibility within the organization and provides choice so that each team can make the best decision for themselves.

Where should I start?

After reading all of this you might be asking yourself, “Where do I get started? Do I just put some code on Git and start working?” You can but that might not be the best place to start. Like anything, a phased approach is preferred to reduce the risks inherent in a major transformation. With a proven track record of success, BMC has some steps to follow to help you migrate successfully to using Git and supercharge your mainframe DevOps.

• Step 1: Migrate off your legacy mainframe SCM system and onto BMC AMI DevX Code Pipeline. Whether you have another SCM solution or a home-grown tool, getting off that system and onto a modern tool built for agility, like ISPW, is a key first step to setting yourself up for success. If you already have ISPW then you are 1/3 of the way there already. If not, BMC professional services can help migration from your old system so you can immediately start reaping the benefits.
• Step 2: Automate all your processes and get your pipelines built out. Integrate your existing DevOps tooling with BMC AMI DevX Code Pipeline and start automating all you can. Get your teams used to automation and DevOps and start making your process as efficient as you can.
• Step 3: Assess all your teams and begin migrating them to Git as needed. You have already set up your pipelines and automated your processes, now it is time to assess your teams and move those that want to migrate onto your Git offering and plug into the pipelines defined for ISPW. Once again, BMC professional services has scripting that can help you move your source code, history, and meta data to Git.

Using Git and BMC AMI DevX Code Pipeline together enables organizations to manage mainframe workloads with the speed and efficiency that only DevOps can bring. Doing so ensures that code is maintained in a place that encourages parallel development and is immediately comprehensible, while also allowing seamless and accurate building, testing and deployment of code.

To explore these concepts in greater detail, download our eBook, Git for the Mainframe.