Back

Testing and debugging are time consuming processes, and in the case of a slow-moving development organisation, such as the Pre-DevOps Compuware, these tasks further delayed their delivery and affected their ability to produce products that are in tune with the current market trends. By inserting automation in their testing, debugging, deployment, and monitoring methods, they were able to increase their productivity and delivery twice as much and decrease the amount of code that goes into production with undetected or unresolved flaws. It made them more competitive and more agile, as they continuously improve the quality of their work as they go through their DevOps transformation.

By using interactive tools, they have increased the communication level within within the organisation and across all sites, which positively impacted the way that they design their software as well. Using tools that allowed them to gain insight of their current and potential customers’ needs made it entirely possible for teams across all sites to get together to develop an idea and turn it into something that can help their customers run their business better and faster, too. It has given them the impetus to move to the next stage, which is to ensure the continuity of flow from Dev to Ops.

Another important step in making work visible was the Phoenix Project, where O’Malley made it a point that the back-end teams knew how a software company works and how they create value for their customers. The non-IT teams needed to see and understand where the tech and dev teams stand, so that they can align their processes and work towards becoming an organisation that is agile and moving in the same direction at all times. O’Malley believed this was an important key to success, and he’s right.

The Second Way of DevOps: Constant Flow of Feedback from Left to Right

Feedback is very important in product development, along with version control and documentation. Code editing, review, validation, and debugging were done using a tool that interacts with their mainframe tools. This allowed the tech teams to see what was going on and stay on top of things at all times. One of the main things about becoming agile is changing the way feedback and monitoring methods are done. They have used Topaz to facilitate this activity, which has the capability to automatically launch a debugging session whenever it is meant to do so or whenever it is triggered by a reported incident. This works for both mainframe and non-mainframe applications. Triggering alerts and ensuring the alert is routed to the right team is crucial in resolving issues without business interruption.

They implemented the use of Zephyr and Hiperstation Strobe for continuously monitoring their performance and the viability of their code changes. Strobe is integrated into JIRA which allows devs to get immediate information about bugs and issues, and allow them to keep a continuous integration as they go along. Having access to tools that allowed Dev and Ops to communicate freely made it easier for their Dev teams to remedy issues and increased Ops’ confidence in the Dev team.

The Third Way of DevOps: Lifelong Learning and Improvement

Lastly, O’Malley made sure that they had a proper documentation system in place. This is to ensure that version control is done without misses and that it is religiously done so. These pieces of information are useful in analysing past projects, finding out what needs improvement, what was done right, and what can further be improved. O’Malley understood that as a software company themselves, they needed to ensure that their entire organisation is agile; by automating the tools that every team within the organisation needs and by delivering information whenever it is needed and exactly where it is needed, it helped them move towards becoming a fully DevOps enabled.

Four years since they started,  they’ve managed to reduce the mainframe servers on location down to two, and have moved the rest to cloud. They have managed to find a way to continuously ensure the success of the COBOL mainframe business and bring it into a more agile environment, and not letting it slowly fade as it remains in its relic state. By bringing tools that enabled non-mainframe folks to manage and work on mainframe apps with the same confidence as they have when working in their areas of expertise, it ensured the survival of a once monolithic system as Compuware has successfully mainstreamed the mighty old mainframe.

Translate »