Columns

Covering your assets

• By Tony Baer
• May 1, 2004

For anyone following SCO's Linux litigation, headlines that SCO's lawsuit against DaimlerChrysler was originally targeted at Bank of America may have provided a bit of comic relief. How do we know about this possible lawsuit? According to press accounts, someone at SCO forgot to turn off the Microsoft Word change-tracking feature. While, for obvious reasons, SCO would have preferred keeping its tracks hidden, for most organizations audit trails are increasingly becoming part of the price of doing business. Pharmaceutical companies have long been required to maintain detailed audit trails for every step in the development, testing and manufacturing of drugs.

For banking institutions, emerging Basel II requirements covering risk management are driving the need to shed more light on how cash management, loan origination and investment activities are conducted. And for publicly held firms, Sarbanes-Oxley rules are requiring top executives to personally sign off on any financial data reported in SEC documents.

In the long run, all of these changes could heavily impact software development. As more businesses automate their processes using software, companies may have little choice but to build validation into the life cycle. If your CEO must sign off on sales figures coming out of your general ledger, the process might have to validate not only the data itself, but also the integrity of the systems that process it.

Much of this may seem like second nature to organizations that take certifications, such as the SEI Capability Maturity Model or ISO 9000, seriously. However, certification covers only the processes by which software is engineered; it does not imply anything about the quality or integrity of the software itself.

There are numerous processes and frameworks that could fill in some of the blanks on the integrity of software engineering. For instance, the Rational Unified Process (RUP) provides a framework of processes and metrics for tracking different activities throughout the software life cycle. You could track the rate at which requirements or project scope changes, and the rate of defects during development. However, while RUP or some similar process could improve CFO confidence regarding the integrity of the underlying software, that's not why you employ RUP.

Nonetheless, aspects of sound software engineering, such as change management, could make a huge difference. As a Butler Group white paper commissioned by Merant suggests, when the members of your development team are not in the same building or time zone, how else can you be sure that a change to a data mode won't impact the design assumptions for a Java component generated downstream that, in turn, processes some key numbers?

So far, we've focused on software development. But what happens after the application goes live? At that point, the health of your IT infrastructure could bring the best software, designed by the most mature organizations, to its knees.

That's where enterprise architecture, the discipline that answers the question of whether technology assets are aligned with the enterprise, comes in. The Zachman Framework, probably the best-known EA framework, offers a matrix for planning technology assets. For each planning activity, it probes what the asset is, how it will be implemented, whom it must serve, when it is needed and why. Now we can get a few more pieces of evidence to tell us whether we have the right assets in place to get the numbers right.

The final piece is how well the company is doing. In my February column, "BAM against the world," I spoke of the emergence of dashboards charting corporate performance. Although most scorecards focus on overt business indicators, such as sales or profitability, the idea could be turned inward on IT performance itself. Veering into territory traditionally covered by the Tivolis, BMCs or Hewlett-Packards of the world, IT governance tools from providers such as Mercury Interactive are placing mirrors on IT service. While focusing on parameters such as whether IT is meeting promised service-level agreements (SLAs), wouldn't it be nice if SLAs could also extend to validating the integrity of data processing itself?

As regulatory scrutiny grows, software engineering will increasingly find itself under the spotlight. While your team might not embark on various certification, software engineering or IT governance initiatives strictly because the government is bearing down on you, some of the resulting data and process improvements might help to keep your CFO out of jail.