"I am a partner in a certified organic farm, and I've made an interesting discovery: Growing organically is easy compared to all the record keeping involved in getting certified as an organic grower. Sometimes it seems that we spend more time proving that we did what we said we'd do than actually doing it."
Does that sound familiar? If so, it's probably because you, too, are living with compliance.
Too Many Moving Parts
You can blame Enron (for all the good it'll do you), or 9/11, or the senior senator from Maryland, but these days an increasing percentage of software development time and resources are being dedicated to proving that you did what you said you'd do.
The buzzword for this kind of activity is "compliance," as in "software compliance management," but there are several different kinds of requirements that are being complied with.
There's the governmentally mandated kind of compliance. The Sarbanes-Oxley Act of 2002 (SOX) requires every publicly traded company in the United States to report on certain aspects of its IT and software systems, especially with regard to financial transactions and security. The intention behind the law is sensible: Even companies not under the SOX umbrella need to think about protecting customer data and guarding against security risks, and to do this you need to implement rules about access to files and a mechanism for monitoring or managing compliance with the rules. You need compliance management.
There are a number of other such regulations that impact software development and IT, and on top of these there are industry-specific regulations.
But there are other kinds of compliance requirements. When a project is a mix of open-source code, the company's own proprietary code, and some outsourced code, all the intellectual property hooks come along with the code. A business that fails to manage these intellectual property hooks through every stage of the product's lifecycle invites blown schedules, public embarrassment, and lawsuits.
Take Service-Oriented Architecture: SOA is by definition a component software model. As SOA governance expert Miko Matsumura puts it, "SOA has too many moving parts." Gartner Research predicts that the top cause of failures of SOA projects in 2006 will be the lack of a mechanism for managing those parts.
Take startups: A startup software company in 2006 is almost certain to follow this assembled-from-parts model, and if the company can't account to the VCs for the provenance of those parts, it is unlikely to get out of the startup phase.
Take embedded systems: As Doug Levin, President and CEO of Black Duck Software (www.blackducksoftware.com), points out, embedded software companies have been wrestling with the problem of managing components from various sources for a decade now.
You need compliance management to manage those IP hooks. Even a company that builds strictly from scratch needs this kind of compliance management today, to ensure that its software is as pure as promised.
These could all be called external forces, but there are also forces driving the implementation of compliance management that are strictly internal to the company.
A company can be thought of as making investment decisions when it prioritizes the projects it might pursue, based on the projects' defined objectives, costs, and timeframes. Compliance in this context means adhering to the project as defined. But in a software project it's not enough that everyone agree on the objectives of the project, they must also have an intimate understanding of the project's requirements, because a "small" change in the requirements can drastically change the costs and benefits of a project.
"These issues can make [this type of] compliance almost a joke," says Joe Marasco, President and CEO of Ravenflow (www.ravenflow.com), because the requirements so often get lost in translation or redefined on the fly to meet a deadline or a budget. Marasco sums up this compliance issue with the manager's lament, "That's not the system I thought we were building."
Ensuring that you're building the system you thought you were building amounts to "proving that you did what you said you'd do." Who'd have thought that this would prove to be one of the thorniest problems in software development?
