Compliance: What Architects Must Know
Summary: Compliance is a complicated domain that is built upon a simple concept: doing what you said you were going to do. (6 printed pages)
Regardless of the size of your company, the industry in which you operate, or your geographic location, chances are that compliance has become a hot topic not only for the corporate suits, but also for your IT organization. Simply put, the term compliance addresses external regulations, internal policies, standards, and governance to which an organization must adhere. For you, the software architect, compliance imposes certain IT controls on the environment in which you must work. Typically, these controls focus on the creation and retention of information, as well as the protection, integrity, and availability of it.
In recent years, there has been an avalanche of government-mandated regulations introduced that directly affect IT. Primarily the result of some high-profile corporate scandals involving the misuse of corporate funds or misrepresentation of financials through the manipulation of data, these regulations attempt to prevent similar problems from happening again. Both private and public companies face stiff penalties for noncompliance with specific financial and IT controls. Most of us watched as one after another CEO, CFO, or COO was prosecuted for various types of corporate misconduct. Sentences ranged from hefty fines to prison time. But not all of those who were implicated were so high up on the corporate ladder. Some IT personnel also were targets of investigation for the roles that they played.
Do I have your attention?
Knowing the potential consequences of being noncompliant, you are probably wondering how to ensure that you are compliant. But first, you have to understand just what that means in terms of your organization as a whole, and how you individually play a part. To be in compliance means that your organization satisfies the requirements of the various regulations that are imposed upon it.
That sounds easy enough, right? We should just look for the group of binders on a shelf somewhere that will tell us how to meet each regulatory requirement that applies to our company, client, or individual project. If only if it were that easy! If you were to read the actual government-mandated regulations, you would find that the lawmakers do not explain how exactly compliance is to be accomplished. The regulations just say what is to be accomplished. The end result is that each organization must determine for itself what policies, procedures, and controls to implement to ensure compliance.
Familiarizing yourself with the expansive domain of compliance means more than just understanding regulations. You will have to learn about internal policies, standards, certifications, and licensing compliance, as well as the broad topic of IT governance. As an enterprise architect and a solution architect, I have had real-world exposure to many of these topics and can share with you how they have affected my organization, my clients, and many of my individual software-development projects. While I cannot teach you everything that you must know, I can give you a few examples and references that can launch your own self-study and set some context for what you might encounter in your own career with regard to compliance.
A good place to start is an introduction to the rules and requirements that are imposed upon an organization by external bodies. A regulation is a mandate that is issued as a result of some government legislation. It contains performance and procedural requirements that must be met to avoid loss of accreditation, loss of access to markets, fines, or even incarceration.
While different industries face different regulations, there are a handful of key regulations that you are likely to encounter in your career. These regulations require that the software that you develop behave very specifically and consistently in the ways in which it grants access to users, stores certain types of data, and records access to a variety of system resources. As we take a look at those prominent regulations, we will consider the impact that they have on our work as architects.
The Sarbanes-Oxley Act of 2002 (also known as SOX) is a federal law that was passed in the wake of several corporate-accounting scandals. U.S. stock-market investors lost $35 billion as a result of illegal manipulation of corporate financials. The primary intent of SOX is to require internal controls that ensure the accuracy and transparency of financial reporting for public companies.
Shortly after the law was passed and compliance techniques were being defined as we went along, I was part of an initiative at the Phone Company to identify and implement specific IT development procedures and controls to support SOX compliance. With stacks of legal material and herds of consultants to guide us, we zeroed in on key areas of impact to development teams.
Of critical importance were the following:
- Identifying financial data and systems in scope of SOX regulation.
- Determining allowable access to affected data and systems.
- Creating audit trails.
- Documenting implementation standards.
We developed a set of standard use cases to be applied and refined to the development and maintenance of all systems and data under the SOX microscope. The bottom line was to ensure that financial data was not exposed to unauthorized users (that included ensuring that no IT personnel had carte-blanche access to alter data without an audit trail), and that it was captured, accessed, manipulated, and stored in compliance with the federal regulations.
An entire industry has emerged as a result of SOX. There are consulting organizations, automated software, frameworks, and any number of techniques to support an organization's SOX compliance. As an architect, you should be familiar with the implications that it has on your organization, as well as your individual projects. Make use of the resources that you have available to you to ensure that you support your organization's compliance efforts.
Another regulation that you might encounter is the Health Insurance Portability and Accountability Act (HIPAA). HIPAA was enacted by the U.S. Congress in 1996 to preserve health-insurance coverage for workers and their families when they changed or lost their jobs. A major impact of this legislation was a need to identify individuals uniquely and associate their health records with them.
As you can imagine, this information is highly sensitive, and, if not sufficiently protected, could affect an individual's ability to obtain new insurance or employment. In response to this very real concern, HIPAA includes security provisions to protect medical information. There are three categories of security safeguards that are imposed by this legislation: physical, administrative, and technical. Physical safeguards control physical access to protected data, while administrative safeguards include the policies and procedures that are in place to protect patient information. Finally, technical safeguards must be in place to control access to computer systems and to protect any patient data that is transmitted electronically over open networks from being intercepted by anyone other than the intended recipient.
HIPAA appeared on my radar screen for the first time when I was assigned to be the lead architect of a solution that enabled physicians to transmit prescriptions and other medical information via wireless devices. Aside from the technical challenges that we faced in developing a robust wireless architecture, we had to account also for the HIPAA technical-security compliance requirements. Similarly to SOX-compliant systems, auditability was critical. We also had to preserve the confidentially of patient data as it traveled over wireless networks. While we would have enacted these security measures regardless of any mandated regulation, we were careful to document the manner in which each requirement was met, so that the client had proper documentation for any audit process.
Other regulations with which you should have some familiarity are the USA PATRIOT Act, which affects banking applications; FDA Title 21, which is targeted at pharmaceutical- and medical-device manufacturers; and the Federal Information Security Management Act of 2002 (FISMA) which could affect any government or government-contracted projects that you might take on.
Also falling under the category of externally mandated rules and requirements is licensing compliance. Because software is intellectual property, it is automatically protected by federal copyright law, which results in myriad compliance issues that organizations must address.
One industry watchdog for licensing compliance is the Software and Information Industry Association (SIIA). Their anti-piracy division represents over 750 software-code and information-content companies in an active campaign to fight software and content piracy. To educate organizations in how to maintain licensing compliance, the SIIA provides some guidelines that architects should keep in mind, both from the enterprise and project perspectives.
First and foremost, your organization should have procedures for acquiring and registering software, so that no unlicensed software finds its way onto corporate hardware. Have you ever worked on a project with a shortage of licensed IDEs or other critical tools? It's tempting to go ahead and load that one licensed copy of the needed software on multiple machines, but doing so puts your company and your personal integrity at risk. Licensing is a unique area, in that every individual in a company with access to a corporate computer has personal responsibility for its compliance.
Periodic internal audits should be conducted on all workstations and servers to verify that all software is properly licensed. These audits can be conducted with inexpensive (or free) automated software, even in the smallest companies. A software-license library should be maintained that records and verifies each purchased license; it should also keep track of what user or workstation is in possession of the licensed software. Aside from proving compliance in case of an audit, this library will help your department's bottom line. When someone leaves the company or moves on to another project that does not require a particular piece of software, that license can be transferred to another user, instead of disappearing into a black hole.
Regulations are often the driving force behind the establishment of standards, certifications, and IT governance. Internal and external audits are performed to confirm a company's level of compliance with those regulations, standards, and its own governance practices. As an architect, sooner or later, you will find yourself in the position of having to conform to certain standards that are imposed by your organization or by a client. It's also likely that you will find yourself preparing for an audit that is related to regulatory compliance or your company's own internal IT-governance policies. Familiarizing yourself with these concepts will help you to know what to expect.
Standard and Certifications
A number of standards can be applied to software development and its management. Industry-recognized certifications that are based on these standards allow an organization to have its adherence to these standards audited and certified—demonstrating specific improvements in product and service quality, development costs, and time-to-market achieved.
In the category of software-process improvement models and standards, the Capability Maturity Model (CMM) of the Software Engineering Institute (SEI) figures prominently. The CMM is a method for evaluating and measuring the maturity of the software-development process of an organization on a scale of 1 to 5. Each maturity level is a defined achievement in process improvement that has stabilized a key part of an organization's processes. While there is no actual "certification" of the capability or maturity levels reached, organizations can receive a level rating through an SEI-authorized appraiser, who will determine whether they are performing CMM practices and to what level.
For quality standards, look to ISO/IEC 9001/9000-3. ISO 9000 is a set of standards for quality assurance that was developed by the International Standards Organization (ISO) and first published in 1987. ISO 9001 was designed to be a generic standard, applicable to any business; so, a new paper, ISO 9000-3, was developed to specialize those standards for the development, supply, and maintenance of software. For a system to be ISO-compliant, an organization's processes must meet specific standards, be documented, and be consistently practiced. Documentation is a critical element for ISO compliance. It helps an organization to understand, control, and improve its processes. ISO does not certify organizations. Instead, accreditation bodies exist to audit companies that apply for ISO 9001 compliance. After it is received, an ISO certification must be renewed at regular intervals.
There are many standards that are specific to certain domains of IT. For example, the Information Technology Information Library (ITIL) is a framework of best practices for IT service management. Good architects spend time researching the standards and frameworks that are most relevant to their area of specialization, and they learn how those practices can improve the quality of their work, as well as the overall performance of their organization.
Another topic of which you should be aware is IT governance. This term refers to both a body of knowledge and practices, as well as a corporate organizational structure. Gaining more attention in recent years as a result of compliance initiatives, IT governance mitigates IT risks. It also ensures that investments that are made by an organization in IT provide actual business value.
In the context of compliance with internal policy or regulation, IT governance is often implemented with the support of one or more frameworks, such as ITIL or Control Objectives for Information and related Technology (COBIT). ITIL addresses the IT delivery and support area, while COBIT supports financial auditing and controls. Governance frameworks are typically composed of a technical component and an organizational one. Organizationally, they must include the involvement of senior management and provide education across all of IT with regard to the policies and procedures that are in place to meet regulatory and standards requirements. The technical component must implement those policies and procedures through tools and other technical controls.
No discussion of compliance is complete without bringing up the topic of audits. An audit is basically a review and examination of an organization's compliance with regulations or policies, to detect any deficiencies and recommend necessary changes in controls or procedures. Conducted by external bodies as well as internal staff, audits are intended to make sure that an organization undergoes a continual process of review and improvement.
Broken down into its simplest elements, an audit consists of a few key things. Auditors want to know what you do to meet the requirements (describe your processes); they want to know where those things are documented (your documented processes); and they want you to prove that you actually did what your documentation says that you were going to do (present your documented records). After that information has been gathered, any areas of noncompliance are noted, and recommendations are made for improvement.
In the current atmosphere of ever-evolving regulatory requirements, IT organizations are increasingly affected by strict business controls throughout the software-development life cycle. As an architect, you must be aware of these controls and understand how to operate within your organization's compliance framework. Go a step further and use your practitioner experience to identify ways to assess and achieve compliance. Your skills are a natural match for compliance initiatives, because you know the flaws and holes in IT controls, and can identify the potential for system breaches. Demonstrating your dedication to supporting its compliance efforts will make you even more valuable to your company.
- Flexible architectures are necessary to keep pace with the ever-changing regulatory landscape. How can you address compliance at an architectural level? How can service-oriented architecture support compliance?
- At the application level, what types of controls must be incorporated in order to ensure that financial transactions and data are complete, accurate, and valid?
- How can compliance initiatives in your organization be more sustainable? How can you contribute to that sustainability?
- Green, Scott. Manager's Guide to the Sarbanes-Oxley Act: Improving Internal Controls to Prevent Fraud. New York, NY: Wiley, 2004.
- Grünendahl, Ralf T., and Peter H.L. Will. Beyond Compliance: 10 Practical Actions on Regulation, Risk and IT Management. Wiesbaden: Vieweg, 2006.
- Health Insurance Portability and Accountability Act of 1996
- International Standards Organization
- Paulk, Mark C. The Capability Maturity Model: Guidelines for Improving the Software Process. Reading, MA: Addison-Wesley, 1995.
- Sarbanes-Oxley Act of 2002 (SOX)
- USA PATRIOT Act
About the author
Denise Cook is a method architect and content author with IBM Rational, contributing to the definition of IBM's software-development methods, including the Rational Unified Process (RUP). Before joining the Rational team, Denise worked as a lead consulting architect for IBM and Andersen Consulting. She has 17 years of experience in the field of software engineering.
This article was published in Skyscrapr, an online resource provided by Microsoft. To learn more about architecture and the architectural perspective, please visit skyscrapr.net.