MAINFRAME > Case Studies > Banking/Finance

Commerce Bank Employs an Enterprisewide Solution to Track Application Changes


Craig Danielson — Photography by Austin Walsh Studio

Limited Impact

Although it had a change-management package in place prior to deploying the ISPW solution, Commerce Bank decided to investigate other options. Ultimately, the decision to go with ISPW was a fairly simple one. Its all-in-one solution ran on what the company considers the highly reliable framework of the mainframe and is not a piecemeal solution cobbled together out of many different change-management systems running on different platforms.

“If we had gone that route, which we had briefly considered, we would have had to learn all of the ins and outs of each of these systems, which would have increased the complexity required for supporting, training and using the systems.” Danielson recalls. “And on top of that, we’d also have to deal with multiple vendors should something go wrong. We just didn’t feel that was the right way to go with this.”

This was especially true given the critical nature of change management within the IT environment. So in 2007, Commerce Bank purchased ISPW software and pushed it into production after testing it and working with ISPW to ensure the system worked as desired.

Now, the bank has a single change-management solution running on the System z* platform that, in conjunction with its change-management systems, policies and processes, serves all of its needs. For example, when a developer is making a change to one of Commerce Bank’s applications—and after it’s been approved by the department heads during their morning meeting— ISPW can release the code to production based on a date and time entered by the developer. As more alterations are made, ISPW recognizes those changes, indicates they represent the latest version of the code and includes any additional pertinent information, such as who made the most recent changes.

In some cases, a script pushes the code to the appropriate production server, deploys it and then validates that the code changes were properly placed and the system is functioning as it should. Change implementations take place within an agreed-upon service-level agreement (SLA) window to minimize user impact. An SLA might stipulate, for instance, that changes must occur after 5 p.m. when no internal users are on the system, or in the case of customer-facing applications that run 24-7, when there’s likely to be limited impact.

Most of this is managed with ISPW. Authorized users can upload and modify the code and then determine the date and time the code should go into production. ISPW then automatically releases that code on the specified date and time into the production environment, after which the validation process takes place. In all cases, testing and validation of code changes occur prior to deployment.

Commerce Bank uses various internal systems, processes and tools for tracking all changes, and it manages them by keeping the business and its customers at the forefront of its decision-making processes. Over the Fourth of July, for example, the company didn’t deploy any changes that would have affected its ATM systems. “We want people to have access to their money even if our branch locations are closed, so we’re very aware of those dates and conscientious when it comes to our customers’ needs,” Danielson adds.

This also applies to hardware deployments. Because access to the company’s data center is highly restricted, the change process is used to track who was in that area and for what reason. If someone is laying cabling, that person must be authorized to do so at a specified date and time.

In addition to managing change and release dates, as well as data center access, ISPW also acts as an auditing mechanism, tracking every time code is checked out or new versions are created. This allows auditors to quickly and precisely determine which changes have been made to which systems, when and by whom. It also helps ensure the bank complies with applicable regulations, especially those pertaining to back-end systems.

 

Beyond Banking

Change is inevitable, but it’s also manageable. For organizations like Commerce Bank, this is a boon. Instead of hoping that code changes are properly vetted before being put into production, ISPW ensures they have been—and then properly validates them afterward.

Although the banking industry is under additional pressure to track changes and retain an audit trail of everything that happens in its data center, Danielson notes that every organization deals with finances in some way. That’s why he encourages all of them to look into change-management solutions such as ISPW.

“Audits are common everywhere, so it’s incumbent upon every company to keep track of what’s happening where and who’s involved in what. It’s not just in the banking industry. And not only that, but I would think every organization needs a way to manage its infrastructure in order to maximize application availability,” Danielson says. “Otherwise, your technicians may be managing more problems than new features and functionality.”

Jim Utsler, IBM Systems Magazine senior writer, has been covering the technology field for more than a decade. Jim can be reached at jjutsler@provide.net.


comments powered by Disqus

Advertisement

Advertisement

2018 Solutions Edition

A Comprehensive Online Buyer's Guide to Solutions, Services and Education.

A Sound Investment

Citigroup tames its backup environment with dedicated mainframes

MAINFRAME > CASE STUDIES > BANKING/FINANCE

Bankwest Modernizes Its Mainframe Integration Environment

IBM Systems Magazine Subscribe Box Read Now Link Subscribe Now Link iPad App Google Play Store
Mainframe News Sign Up Today! Past News Letters