|
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?
June 01, 2006
URL:http://www.drdobbs.com/architecture-and-design/living-with-compliance/188700752
"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.
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?
So it's a problem—one of those dreaded "people problems." So how are companies addressing this problem? Looking at current software compliance-management solutions from a programmer's perspective, the phrase "heck of a job" comes to mind.
Companies have frequently ignored developer concerns or made them secondary. Very often what has been put forth as a solution looks like a whole new set of problems to the programmers who are just trying to get the job done.
There's certainly room for improvement in communication. In a survey by CFO-IT magazine last year, executives overwhelmingly agreed that government regulators didn't understand IT and IT personnel didn't understand government regulations, and that the situation was so bad that a reliable audit was simply not possible.
Developers have every reason to resent policies that complicate their jobs if the necessity for the policies has not been effectively communicated. Developers also have reason to resist burdensome policies when they can see that those policies are poorly conceived and inefficient. Jim Duggan of the Gartner Group recently pointed out that, while good automated tools do exist for at least parts of the compliance-management puzzle, "[t]o date, IT organizations have relied on manual integration and human handoffs." While that might be fine for small, one- or two-person projects, Duggan is talking about much bigger operations.
Looking at the glass as half full, I guess you could say that many companies now have enough experience with the problem that they should have gained valuable insights in how not to manage compliance.
So how do you manage compliance effectively? Catalyst Systems' Tracy Regan has some suggestions in "Compliance Scorecards" for companies on how to do compliance management without making the developers crazy.
A few other general points:
To see in detail how the right tools can help manage compliance without driving developers crazy, I checked in with Doug Levin and John Riley of Black Duck Software. Black Duck focuses on one kind of compliance management—managing software-licensing requirements.
Riley points to the fact that developers today commonly "gather various components, such as open-source code, software from outsourcers, and their own company's proprietary code, and glue them together to make finished applications." This assembly model of software development often shortens project schedules, cuts costs, and improves quality.
But it also creates a piece of software that is a complex mix of intellectual property. Ignoring or downplaying the legal risks inherent in the assembly model is neither a viable business strategy nor a good career move for an individual, Riley advises.
You can implement company policies for the use of intellectual property, but it would be foolish to assume that policies are always followed or effective. You still need to be able to analyze the code for the intellectual property obligations embedded in it. Despite all your training and policies, somebody could have downloaded a piece of code from the Internet and incorporated it into your code base. So how do you ensure that your code is a good software citizen?
"Some companies choose to piece together home-grown solutions," Levin says. "The usual set-up includes some combination of open-source tools (such as GREP, CheckSUM, and String Search engines), which they use in conjunction with Google, along with tools like Krugle, Koders, etc."
Black Duck was set up to provide the tools to deal with exactly this problem.
The key component of Black Duck's protexIP is a huge searchable online knowledge base of open-source licensing information. You can create and store queries to speed subsequent searches, check all sorts of file types and languages. The knowledge base contains over 200 million code prints, which is what they call the form in which they represent code for search and comparison.
The product comes in a pro version that is single-user and an enterprise version that builds validation into a collaborative model and includes tools for managing software licenses. It's not enough to know that a particular chunk of code that you are using is owned by so-and-so; you need to know what license applies and to be able to evaluate your use of the code for compliance with the terms of the license—or rather, your legal department needs to be able to do that. They give you that.
But tools only work in the right environment. As Levin points out, a company putting a tool like protexIP in place needs to create policies and rules and procedures for handling automated code review, assign responsibilities, and implement whatever organizational changes are necessitated by replacing manual/visual code review by an automated system. So it's still, at least in part, a people problem.
I'd kinda hoped it could all be automated.
Michael is DDJ's editor-at-large. He can be contacted at [email protected].
|
Compliance Scorecards
by Tracy Ragan
Tracy is CEO of Catalyst Systems. She can be contacted at www.openmake.com.
With new IT compliance requirements, the pressure is mounting for organizations to rollout centralized software-configuration management (SCM) solutions. Key to the success of these solutions is your ability to provide easy-to-understand status reports to all stakeholders. "Compliance scorecards," like that in Table 1, are one tool for reporting on the compliance level teams have reached.
Table 1 lists three application teams and three levels of compliance. The Customer Service team is 100-percent compliant, yet the Loan Processing team has not committed to a date to be at the highest level of compliance. This scorecard lets upper management see what teams are lagging behind in becoming 100-percent compliant. The scorecard also gives team leaders an opportunity to negotiate when they will become compliant.
Table 1: Typical compliance scorecard.
Creating scorecards can be done using spreadsheets or databases. The real trick is in defining the levels of compliance—the minimum needs. When defining the levels, make the early levels easy and later ones more comprehensive. This lets teams accept the process without interrupting their development workflow. The more teams accepting the enterprise-level SCM process, the quicker other teams will join in. While the levels of compliance must be created around the unique needs of your organization, there are basic levels to consider. And while Table 1 shows three levels of compliance, there's no rule regarding how many levels you should define. I suggest limiting it to no more than five levels.
Here are my favorite levels of compliance:
In Table 1, it isn't until Level 3 that developers began using the centralized SCM tool to manage their in-house developed code. This delay gives them time to migrate from their old tool to the new centralized process. Once they reach the highest level of compliance, their team version-control process is retired.
Reporting on the success of your enterprise SCM rollout using scorecards keeps the momentum moving. Providing levels of compliance that are clearly communicated and obtainable by development teams gets them to take the "baby steps" needed to move from team-based to enterprise-based systems. And lastly, be realistic. As long as there are new development efforts, there are new teams creating their own team-based version-management solution that you will need to confront, address, and move towards compliance. |
Terms of Service | Privacy Statement | Copyright © 2024 UBM Tech, All rights reserved.