| PenandCamera.com: Writing: IT Compliance Institute | About | Clips | Photography | Writing | Updates |
IT Compliance Institute, March 7, 2006:
Trends and Technologies
BNSF Railway On-track with Long-haul Compliance
While BNSF Railway needed to improve its application management processes to meet SOX regulations, it parlayed the effort into an application lifecycle management overhaul.
By Mathew Schwartz
Railroads are renowned for taking a long-term view of their assets. Industry realities demand it: they manage thousands of miles of track, lease countless locomotives and freight cars, and manage the human infrastructure needed to keep it all running.
That’s especially true at BNSF Railway, a subsidiary of Burlington Northern Santa Fe. BNSF operates a North American railroad network—one of the continent’s largest, spanning about 32,000 route miles in 28 states and two Canadian provinces.
So when BNSF needed to improve its software-development processes to comply with Sarbanes-Oxley (SOX), it didn’t look at the project as a regulatory one-off. Instead, BNSF used the project to standardize its release-management and application-deployment processes, further automate development, and help create a corporate dashboard to measure enterprisewide efficiency and effectiveness.
Managing Assets, Railroad-style
Before SOX, BNSF’s Technology Services Division already tracked developers’ time, since it’s a capital expense. “We capitalize, for new development, the detailed design, the coding, and the implementation phases,” notes Jeff McIntyre, assistant vice president in BNSF’s Technology Services division. The same is true of software maintenance and upgrades. “Software capitalization of the IT organization is the largest piece of our capital budget. It’s more than what we spend on our telecommunications infrastructure or our IT infrastructure.”
BNSF builds, maintains, and modernizes many of the software applications it relies on, since there are relatively few off-the-shelf applications for a market as limited as railroads. And as is typical in the industry, BNSF tries to maximize its resources. “We’re funny about our assets. If you buy a locomotive or box car, we use it for a long time, and we’re the same about our applications.”
Beyond capitalization, there’s another imperative for tracking projects: managing about 250 in-house developers, plus 250 contract developers and offshore contract developers, all working on 150 to 200 projects per year.
Making Software Development Comply with SOX
To improve the enterprisewide approach to managing software project development, in mid-2004 BNSF began overhauling its application development testing processes. “The QA [quality assurance] team didn’t test everything—just the critical changes going into our transportation system, which is our bread and butter,” explains McIntyre. “In the context of that, we still ran across variations in how projects were being managed.” Since QA is just a part of the entire software development lifecycle, however, BNSF also looked at all related processes. “You can’t just look at testing. You have to look at the whole lifecycle, because you have to think about testing all the way through the project.”
Almost simultaneously, the company’s auditors recommended their own—often similar—software development changes, though their familiarity with financial reporting systems gave them a SOX-oriented perspective. “Lots of our systems can have an impact,” notes McIntyre, and “there were breakdowns in the application development process that they think needed to be addressed.” Auditors gave the division 45 days to implement fixes, as well as other changes, such as adding sign-offs at various points in the application management lifecycle. The auditors planned to return in 90 days to assess their progress.
Improving the Application Management Lifecycle
The railroad began streamlining its application development management processes and implemented the changes in November 2004. With auditors returning early in 2005, the IT department also began tackling what McIntyre classifies as “felonies and misdemeanors.” “We had misdemeanors in the code repository world, since not all code was stored in one place,” he says. To solve that problem, “We were looking for a tool that would also provide us with an automated means of complying with the needs of internal and external audits.”
In short, BNSF wanted a code repository, so it formed a team to select an off-the-shelf product. They articulated the needed requirements and passed them onto a Gartner Group research analyst, who helped generate a shortlist that included IBM Rational Software, Serena Software, and their ultimate choice, MKS.
“The MKS tool was nice because it was a built-from-scratch solution, and it provides a very nice, consistent interface for application developers to work in,” says McIntyre. “A lot of the products in this space have been built by acquisition, so the various functions are not as seamless as what we saw in MKS. That’s one of the reasons our developers were excited about it.”
Code repository implementation began in May 2005. Though auditors set a September 1, 2005, deadline, the implementation team gave itself an aggressive August 1 deadline. “We had 30-some application teams and I can’t tell you how many applications,” he says. “We had to migrate all their code to this single repository, test it, and make sure it worked fine.”
Ultimately, BNSF met the deadline; MKS notes it’s one of the fastest implementations it’s ever seen. “We didn’t have any choice,” says McIntyre. “We had a team of our best and brightest working on it, and we had people in here Saturdays, Sundays, and watching things in the evenings, just to make sure we could really meet the deadline that we’d imposed on ourselves.”
That deadline, however, was only the first part of the project. “The code management piece was definitely done to meet a compliance requirement,” he says. “The second half is more of an effectiveness and efficiency play, trying to take some of the administrative requirements of SOX off of our developers, so they can focus on developing applications. Then we’re also going to have business users that are using MKS, and I think it’s going to be a much broader implementation.”
Beyond SOX: Improving Efficiency and Effectiveness
The code repository team had already identified all IT applications relevant to developers and SOX when it began to implement the next stage of the project. By the end of February 2006 it had expected to identify how those applications should work with the code repository, then implement said changes by the middle of 2006. Much of that work involves integrating the Primavera TeamPlay project management software BNSF uses, which doesn’t allow managers or customers to automatically sign off on work, with the MKS code repository, which does. Adding sign-offs should make everything from requirements gathering to implementation easier. “It’s going to, I hate to say automate the process, but it will be a huge gain in productivity for our developers,” notes McIntyre.
While the overall project has been partially compliance-driven, there has also been a business upside, he says. “Being able to automate the development lifecycle, as well as meet those compliance requirements, was kind of the frosting on the cake.”
After the sign-offs are in place, BNSF plans to continue improving business processes, using the MKS software, as part of its balanced-scorecard approach to measuring efficiency and effectiveness. “We do something, we measure the results, we tweak the process—it’s just a continuous process improvement thing. We’ve been doing it for five years now, that’s one of the reasons we launched a balanced scorecard,” he says. While the balanced-scorecard approach was initially just used departmentally, a corporate dashboard project is now underway that will draw from a BNSF-wide data warehouse for many business managers.
The impetus for using balanced scorecards came from the company’s business-savvy CIO, and the approach underlies all of BNSF’s compliance efforts. Notes McIntyre, “His motto was, ‘You can’t manage what you can’t measure.’”
Mathew Schwartz is a former contributing editor for the IT Compliance Institute. You can contact him about this and other articles at Mat@PenandCamera.com.
This article originally appeared in IT Compliance Insitute and is reprinted by permission of 1105 Media, Inc.