Living with Compliance

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.

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:

• Level 1 Identify and check-in all third-party libraries to the central SCM tool.
• Level 2 Give the SCM team the ability to compile the application's binary objects (.exe, .war, .jar, .dll) using the SCM enterprise build tool on a build machine with a resulting footprint report showing where the source code was found that was used in the build.
• Level 3 Load all application source code into the SCM repository and recompile the application to create a preproduction level build.

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.