DevX Skillbuilding for IBM DeveloperWorks
DevX Skillbuilding for IBM DeveloperWorks
DevX Skillbuilding for IBM DeveloperWorks
Get regular email alerts when we publish new features!
DevX Update for IBM developerWorks

More Newsletters
 Print Print
How Do Compliance Issues Affect You as a Developer?
If regulatory compliance is threatening to cloud your sunny development world, take heart! There are tools available to help you keep your apps in compliance and up to date with requirements—and keep the board of directors, your boss, and industry regulators off of your back. 

You signed on as a developer, right? You like to code? Good deal. You like to hear about cool new technologies like AoP Crosscuts or Ruby on Rails, Ajax and Java, OK? A certain amount of jargon helps to separate the best from the rest, for sure.

These days you're hearing rumblings from boring manager Rob about SarbOx, Basel II, HIPAA, FISMA, 21 CFR Part 11, etc. This is most likely bad news for you. You're not an accountant or a lawyer, and you didn't sign up to be one. You don't want to wear an IQ restrictor (necktie) nor do you want to lull people to sleep with your mastery of revenue recognition (or "revrec" as the hip kids say). What's all this rumbling about? Compliance!

Don't fall asleep on me yet.

What's compliance? Well in this case, we are talking about regulatory compliance and a ton of requirements that come with it. Most people see compliance as a necessary evil, maybe like a trip to the dentist. It certainly isn't what most developers signed on to worry about from the get go.

Compliance is, in most cases, a "cross cutting" concern which raises issues such as auditability, transparency (monitoring), privacy, security and process integrity. As such, there may be ways of managing these issues without coding and recoding your applications and services one by one. As regulations change, so do the corporate policies that satisfy these regulations. And as corporate policies change, the applications that implement these policies must change as well. Regulations are a source of new requirements and workload. For example, as the rules governing your company's revenue recognition and data security change, these changes become requirements. All these things have to be coded, tested, and delivered.

Resources
  • SOX Compliance Using IBM Rational ClearCase and ClearQuest
  • IBM Rational ClearQuest
  • IBM Rational Portfolio Manager
  • Compliance weenies talk a lot about business controls. The idea here is to implement policies and procedures and controls (tests) of these procedures to make sure the company is doing the right thing. Business controls span everything from HR (does the company Board of Directors have a conflict of interest?) to Facilities Management (is the front door locked?) to IT (are user access privileges deleted within 24 hours of leaving the company?).

    Business controls extend to the software development team, too. As an example, your development organization could determine that:

    1. All development projects must be approved by a Change Control board prior to project inception.
    2. Only approved Build Managers can build software releases.
    3. All releases must be approved by a Deployment Manager prior to deployment; the "control" of these procedures may take the form of sign-offs, access controls (only the Build Manager can access the pre-release environment, for example), or e-mail notifications.

    What happens when good controls go bad? In one case, a bank regulator from the FDIC discovered that a transaction in one city produced different results from the same transaction done in another city. This was a problem created by the bank not having good control over their software assets after a period of bank mergers. After regulators failed the company for an audit, the company was unable to conduct business as usual, including open new branches and ATM machines, until they proved they had change control in place. In this case, the bank found that implementing IBM Rational ClearCase—a software change management tool that supports distributed environments—gave them the bulletproof change management they needed to persuade regulators that good controls were in place.

    Another Example
    A subsidiary insurance company on the West Coast failed an audit—developers were forced to create an entirely paper-based process—a paper trail that consumed 25 percent of developer productivity. Sounds like a lot of fun doesn't it? No more writing code, start filling out forms! The parent company's internal auditors were prepping for Sarbanes Oxley compliance and forced this paper-based system. The CIO thought he had good control, but was unable to show documentation of the procedures that were in place—audit trails and approval cycles. In this case, the manual process was supplanted by an IBM tool called Rational ClearQuest. ClearQuest was used to automate this documentation process and was a welcome relief from filling out paper forms. This tools works together with IBM Rational Portfolio Manager, which helps track and manage IT projects, thus aiding in the regulatory process without creating extra work for developers.

    When organizations fail an audit, they need to come up with a plan to eventually pass. Typically, the auditor will go over the findings and come up with a remediation plan. Demonstrating progress against that plan is a must. In heavily regulated industries, such as medical device manufacturing, life science, and pharmaceuticals, regulators from the FDA are a part of daily life and the auditors are a part of the regular work environment.

    What are regulators and internal auditors (the guys who look like agents from "The Matrix") looking for when they scrutinize the reams of documentation you throw at them? In a nutshell, they are making sure that have good control over your software development process: that you say what you do, that you do what you say, and that you can prove it. Part of those controls will be documenting that you are managing regulatory requirements in a consistent and auditable way. For example, if your organization has HIPAA policies to ensure data privacy, or Sarbanes Oxley policies that specify revenue recognition rules, they want to see that these policies are translated into a set of requirements that are implemented across your applications.

    Why does this stuff exist? Well, businesses exist to serve—principally shareholders, but hopefully customers, employees, and their communities also! Thanks to people like Ken "Kenny Boy" Lay of Enron, whose deceitful business practices robbed millions of pensioners, employees, and public investors of their hard earned dollars, governments are increasingly focused on protecting people from acts of malfeasance. Of course it's not always so cut-and-dried. Agencies like the United States Food and Drug Administration (FDA) work tirelessly with pharmaceutical companies and health care providers to ensure that human lives are safeguarded in the flood of medical devices and new medicines being brought to market. Finally, regulations like the Health Insurance Portability and Accountability Act (HIPAA) of 1996 have provisions for the privacy and security of information systems. SARBOX of 2002 is all about enforcing accountability—at the executive level—of the accuracy and completeness of financial statements. The ripple effect is felt across the supply chain and every level of business is under an additional level of scrutiny. Anything that can land the pointy haired boss (from Dilbert) in jail will get a lot of attention in the company.

    Requirements Management
    The medical device division of a leading pharmaceutical company needed to manage about 20k requirements associated with a medical device used for analyzing blood to diagnose various conditions. They had to track the requirements against risk management, hazards, and software verification results (FDA). IBM Rational RequisitePro was used to trace the requirements to the verification results and the risk assessment of that requirement. When the FDA has a question about the testing and validation of the device, they can point to the database with the chain of traceability.

    So to sum it up, regulatory compliance is here to stay. In the big picture it will change the way developers do their work, and you can do yourself a big favor by finding out how these requirements can be automated by the best tools available in the market. The consequences of ignoring this issue could be as severe as a shutdown of your business, prison terms for your executives, or worse yet—an incident where your company or organization harms its customers or the surrounding community. Compliance is serious business, but it doesn't have to be a headache. Do yourself a favor and get ahead of this trend.


    Page 1 of 1
    Miko Matsumura, vice president of marketing of Infravio Software, an SOA Web Services management company headquartered in Cupertino. He is chair of the OASIS SOA Adoption Blueprints Technical Committee. He spent a few years as Sun's Java evangelist.
    Submit article to:
    Featured Resources from IBM