Skip to main content

skip to main content

developerWorks  >  Rational | Architecture  >

Managing compliance with RUP: A starter plug-in

developerWorks
Document options

Document options requiring JavaScript are not displayed


Rate this page

Help us improve this content


Level: Introductory

Lynn M. Mueller, Senior Consultant, IBM
Thierry Paradan, Development Methodology and Standards, IBM, Intel, Microsoft,HP

15 Nov 2006

from The Rational Edge: Read this general overview of compliance as it pertains to software development and delivery requirements, and learn about the IBM Rational Compliance Management strategy for helping businesses meet those needs.

Disclaimer: The reader is responsible for ensuring his own compliance with legal requirements. It is the reader's sole responsibility to obtain advice of competent legal counsel as to the identification and interpretation of any relevant laws and regulatory requirements that may affect the reader's business and any actions the reader may have to take to comply with such laws. IBM does not provide legal advice or represent or warrant that its services or products will ensure that the reader is in compliance with any law.

illustrationCompliance is a part of our daily lives, whether it is obvious or not. Nearly all businesses are directly or indirectly influenced by standards and regulations. For example, in the United States, all businesses must comply with Occupational Safety & Health Administration (OSHA) regulations.

In the age of Sarbanes-Oxley, BASEL II, and other regulatory mandates governing US and international business, the reasons for implementing a compliance management strategy are increasingly clear. In the first place, compliance with applicable regulations, standards and policies cannot be ignored, because these are requirements for doing business. Failure to comply, as revealed by third-party audits, will subject your business to severe penalties. Therefore, your company's ability to pass audits ultimately confirms its adherence to compliance requirements. To pass audits, not only do you need evidence of compliance, but this evidence must be easy to access and understand. We refer to this as "auditability."

To create and maintain auditable evidence of compliance, you need to implement appropriate process controls. It is therefore the duty of organizations to investigate the regulations, standards, and policies governing their business and to manage their efforts to achieve compliance effectively.

To this end, the IBM Rational Compliance Management strategy can help an organization to achieve the following:

  • Mandating both business and technology controls over the software lifecycle
  • Promoting the least intrusive controls as the best ones to use
  • Laying the foundations for IT governance through its controls
  • Providing an opportunity for business advantage

This paper presents a general overview of compliance as it pertains to software development and delivery requirements, and it specifically describes the IBM Rational Compliance Management strategy for helping businesses meet those needs. This strategy is delivered to organizations via the Rational Unifed Process®, or RUP®, and a plug-in (RUP for Compliance Management) specifically designed for the RUP environment to support compliance management.

What is compliance all about?

Generally speaking, compliance requires a thorough understanding of regulations and policies, as well as an understanding of what it means to meet performance and procedural compliance mandates.

Regulations, standards, and policies

Frequently, doing business requires following any number of regulations. See Figure 1 for examples of regulations and standards. Regulations often share the following fundamental characteristics:

  1. Mandatory: Regulatory authorities may require qualification and/or adherence to specific standards, and may dictate explicit penalties for non-compliance.
  2. Non-directive: While regulators typically define what needs to be done, they do not always detail the how.
  3. Continuously changing: Regulations and their embodiment in corporate policies can change frequently and at inconvenient times.
  4. Increasing IT impact: While few apply directly to IT, regulations increasingly affect IT systems.
  5. Non-certifiable: Agencies generally do not approve, recommend, or validate particular solutions.
  6. Related to harm: Regulatory agencies recommend an approach based on performing a thorough assessment of the risks involved in the business and demonstrating that the these risks are being addressed adequately.

These characteristics remind us that the domain of compliance is complex and must be constantly managed. To help with this effort, process standards seek to embody the fundamental philosophy of current good systems practices and quality-by-design as integral parts of business operations. The integration of this philosophy is essentially what compliance auditors and inspectors are seeking during an audit or an inspection, respectively.

Figure 1

Figure 1: Example of regulations and standards

To address regulations and manage compliance, executives are often responsible for defining policies that are subsequently implemented as business controls in their IT applications and processes. In doing so, they seek out standards, such as the Capability Maturity Model Integrated (CMMI) or ISO 900x, both of which provide process frameworks for the organization. By adhering to such frameworks, businesses can implement the kind of processes, change control, and measurement mechanisms that will institute the type of control that legislations and regulations (such as those pertaining to FDA, SOX, and HIPAA) are mandating. In practice, large organizations implement a mix of these frameworks, drawing from IT Infrastructure Library (ITIL) and Control Objectives for Information and related Technology (COBIT), for example.

What does it mean to be compliant?

At a high level, compliance requirements are divided into two categories:

  • Performance requirements demonstrate the ability to deliver functionality or perform tasks that support a specific policy. For example, specific audit log data, or financial report content and format mandated by a relevant policy.
  • Procedural requirements demonstrate adherence to documented operational process -- i.e. "employers will be responsible for appropriately validating the identity of employees."

Companies rely on their own legal counsel and risk officers to interpret regulations and codify their interpretation into company policy, which results in the definition of controls over the way the organization does business.

How is compliance established?

Essentially, establishing compliance in a business involves implementing the means to be compliant, then working to obtain certification of actual compliance. Let's consider these in more detail.

Auditors, audits, and auditability

Auditors are responsible for assessing compliance. They are generally compliance framework neutral, which means that they will not be biased for or against a particular standard, as long as the selection rationale is documented and justified. For an organization to establish that it meets required performance and procedural requirements for compliance, it must provide evidence of their implementation to the auditor. In the end, compliance is largely decided by an organization's ability to pass audits of its processes.

Auditors typically seek the same types of information:

  • Documented processes for creation of business artifacts
  • Adherence to the defined process by artifact creators
  • Effective process automation
  • Process linkages to automated processes supported by tool mentors
  • Linkage between artifacts that align with the business process steps
  • Artifact traceability to points of accountability in the delivery chain
  • Transparency of reporting
  • Accountability in the chain of delivery
  • Non-repudiation of any artifact throughout the system

Due to the complexity of the compliance domain, an organization is unlikely to undergo successful audits if the required evidence is not readily available or cannot be warranted to be genuine. If a process meets these criteria, it qualifies as being "auditable." Auditability does not imply that an organization is deemed compliant, but it will make audits easier to manage and any gaps easier to characterize and subsequently address. At the opposite end of the spectrum, nothing is more frustrating than a situation where the organization actually meets regulatory requirements but could not convince the auditor and is thus not certified.

Organizational compliance

While auditability is crucial to achieving compliance with most regulations, standards, and policies, auditability alone is not sufficient; as each one may include unique requirements that a particular organization may or may not fulfill. Organizational compliance denotes the process of obtaining certification of compliance with a specific standard, regulation, or policy (e.g. ISO 9001-2000, SOX).

Compliance management: A journey

Organizations that have made a commitment to compliance typically find benefits in the process, but half-hearted commitments or over-zealous application of compliance rules can do more harm than good.

Benefits

One early benefit is that organizations gain clarity and empowerment in the process. The practices and controls instituted to manage compliance will help clarify roles and responsibilities and can help staff understand how to best add value to projects. They can also serve as a means to improve staff efficiency and start to transform the way an organization performs.

In addition, the need to maintain up-to-date records and use appropriate tools provides management with greater insight into project status and performance, and empowers management teams to increase their control over its project and processes. Automating the compliance management process increases the transparency for all.

While it is widely accepted that an effective process is important today, old habits die hard. Many businesses start small enough that a structured business process is viewed as more of a hindrance than a benefit. When these businesses experience success and thus grow quickly, acute problems with process and quality (i.e., usually a lack of these) often materialize. At this point, it is often hard to reconsider process models and gain support among key personnel to change what until recently worked well. Externally imposed compliance requirements may be a great opportunity to push a young organization over the edge by causing it to initiate the reengineering and incremental improvement of its processes.

Some anti-patterns

But there are definitely some approaches to compliance that businesses should try to avoid.

One thing to avoid is purchasing a turnkey compliance management solution. Because achieving and managing compliance can be a complex and costly journey, the temptation is to look for ready-made solutions. These seldom work in the long run. The compliance journey must start with codifying existing processes and putting in place necessary mechanisms to grow and improve them to progressively meet the requirements of standards, regulations and policies.

Compliance is often seen as complex, costly, and as not contributing significantly to the bottom line -- just one more thing to do. It is therefore tempting to "fake it" -- that is, to enact special projects to push the organization into compliance around the time of audits, whether internal or external. While this may work in the short term, it is not sustainable for the following reasons:

  • This strategy is costly, as every audit preparation will have to start from square one.
  • The organization will not derive significant benefits from being compliant only in appearance.
  • The organization will not be able to establish a consistent track record over time.
  • This strategy will have a negative impact on the corporate culture, because members of the organization will regularly be asked to devote substantial amounts of time following rules and practices they do not understand and accept.

Finally, you should also avoid implementing excessive controls simply in the name of compliance. As compliance management usually involves adding control to existing processes, any success with these efforts (for example, passing audits) may be interpreted as a green light to control any and every aspect of IT. Unfortunately, such a strategy will quickly reach a point of diminishing returns. As you manage compliance, you must not lose sight of its impact on your organization. Consider these undesirable outcomes:

  • Adding more control may have an increasing impact on the flexibility and implementation costs of the process.
  • As the staff finds itself spending an increasing amount of time tending to compliance related matters (at least in the short term before they become business-as-usual), employee productivity and morale may be substantially affected. Effective compliance management must constantly keep in mind its impact on IT.

Fundamentals of compliance management

Effective compliance management involves sound governance of compliance initiatives, along with basic process controls established for the IT organization.

Compliance governance

Organizations often find themselves in a situation where they must manage compliance to more than one standard, regulation, or policy. It is neither practical nor cost-efficient to custom-define controls on a project-by-project basis. Instead, organizations must institute a governance framework that will address the problem globally, at the enterprise level. An example of a possible compliance governance framework is illustrated in Figure 2 below.

Figure 2

Figure 2: Governance of compliance initiatives.

A compliance governance framework provides a means for:

  • Analyzing standards and regulations and deriving a comprehensive coherent set of policies to address them (depicted in red in Figure 2).
  • Formulating compliance requirements that must be met to implement these policies (depicted in blue in Figure 2).
  • Organizing compliance requirements into projects and prioritizing them (depicted in blue in Figure 2).
  • Approving and scheduling compliance enhancement projects (depicted in yellow in Figure 2). These projects fall into three main categories (depicted in gold in Figure 2):
    • Projects to develop IT process controls resulting in enhanced IT processes. These controls apply directly to the IT organization in order to improve the rigor of the software development process itself -- for example, by requiring that adequate project traceability, reporting, and approval procedures are in place throughout the software lifecycle.
    • Projects to develop Application Controls: These controls are built into the corporate IT systems themselves and they become software requirements that can have regulatory or standards-based significance. For example, a common control that applies to the Human Resources (HR) organization is to "Limit access to classified employee data." This control is automated by making it a common software requirement for all HR systems.
    • IT Process Control Automation Projects: These projects are at the junction between developing IT Process Controls and Application Controls. They consist of using (usually commercial) tools to automate workflows and manage the products of IT processes. What these project strive to accomplish is "tool-directed behavior" wherein enforcement of part of the process is built into the tools themselves.

Fundamental IT process controls

The controls we introduce here are key to achieving auditability of IT processes and are thus fundamental to the compliance domain. They are:

  • Formally specified and documented process. Among the many tasks that auditors can choose from, the first one is often to acquaint themselves with your software development process. Therefore, a prudent inventory of compliance assets should include documentation of existing processes.
  • Work product control. This control is a workflow that documents and verifies that selected work products specified by the process are produced according to the process. This workflow describes the review revision and finally the approval of a work product.
  • Record control. Records are write-once, read-only documents that provide formal evidence of what was accomplished. Record control specifies what records must be produced, how they are produced, and who has the authority to create them.
  • Traceability. Work products are not developed independently or in a vacuum: They exhibit dependencies and relationships. The purpose of traceability is to ensure consistency between related work products.
  • Separation of compliance management related information. This is done by defining compliance-oriented work products. This facilitates audits and focuses control on compliance oriented information
  • Role-based separation of duties. This is a fundamental tenet of highly controlled environments. Its foundation is that development, review, approval, and use of artifacts cannot be carried out by the same individuals, as otherwise the impartiality of the process can be called into question.
  • Formally gated process (defining control points). As projects and products become increasingly complex, plans alone are not enough to ascertain that overall project goals have been fulfilled. To assess this, a control point can be defined to manage the following activities:
    • Verification that milestone criteria are met
    • Assessment of the decisions and changes made to reach the milestone
    • Audit of the metrics associated to the milestone (risk, quality, content, etc.)
    • Overall review of the milestone content by its recipients (separation of duties)
    • Approval of the control point implemented through e-signatures.

Applying compliance management principles to RUP

The entire scope of compliance management is a long-range goal and exceeds the scope of individual projects. To support software development projects, the IBM Rational organization's first initiative was to develop a Rational Method Composer (RMC) plug-in to enhance the auditability of the RUP process framework -- RUP for Compliance Management Plug-in. This plug-in supports implementation of the process controls we described in the previous section. This will extend the applicability of RUP from high trust situations to environments where security and control must be enhanced considerably. Figure 3 below provides some high level criteria to consider when creating a process framework for your organization.

Figure 3

Figure 3: Creating the right level of process for your organization

The plug-in supports compliance management IT process controls as described in the remainder of this section.

A formal process

RUP now specified using Unified Method Architecture (UMA) is an industry flagship and standard for a comprehensive, formally specified software development process. Its integration with other Rational tools (such as IBM Rational Portfolio Manager) makes it possible to export relevant aspects to other process management tools, thus supporting process automation and tool-directed behavior.

Compliance management work products

The work products listed below have been introduced in this plug-in. While most of them could be defined as sections of existing RUP artifacts, they are kept separate to support auditable process control.

  • Corporate Policy reflects an organization's interpretation of the regulations. It is not developed within the process but is a necessary input for the development of compliance requirements
  • Compliance Enhancement Vision addendum identifies core compliance requirements and motivates the IT compliance management controls targeted by the project and summarizes the approach for validating that the process meets these control objectives.
  • Process Validation Plan defines a set of tests that can be used to validate that an automated software development process fulfills control objectives. An example is to validate that tool-directed behavior correctly automates the process.
  • Control Point Specification provides a definition of the controls and approvals of major work products and handover points.
  • Change Workflow Specification provides the detail of the change workflow that the project will follow.
  • Distribution Policy defines the policy for distributing deliverables to QA or to Deployment. It describes the exit criteria and procedures to be satisfied for a release to be authorized.
  • Project Archive provides a baseline of all the project artifacts both for audit purposes and for future use.

Compliance management roles

Compliance management expands and refines RUP roles, in part because of the new work products introduced, but also to address separation of duties in compliance sensitive areas.

  • Policy Analyst. Captures compliance requirements after cataloging and interpreting regulations, standards, and policies to identify internal policies that allow the business to be compliant.
  • Process Engineer. Responsible for documenting and defining an IT governance process, in accordance with applicable process standards, frameworks and regulations.
  • Technical Lead. Responsible for approving code changes and finalizing change requests. This role guides and oversees development of application software components.
  • Deployment Manager. Responsible for delivering and assessing the software release into the production environment. This role exists in classic RUP, but the expansion of its responsibilities requires and the separation of duties principle motivates the addition of the complementary role of Release Manager.
  • Release Manager. Responsible for collating the released work products from multiple projects, to produce a release that can be delivered into the production environment. The Release Manager owns the release management process.

Work product control

This plug-in addresses work product control in two ways. First, it provides a guideline on work product control that helps institute work product control. Second, it applies work product control by identifying a minimum set of work products that must be approved. Our enhancements to RUP include the following approvals:

  • Process Validation Approval formalizes that the project is "audit ready."
  • Deliver Change Approval controls the integration of a set of changes.
  • Baseline Approval controls the baseline used for on-going development tasks or for release into QA or Production.
  • Change Request Approval provides a record of the acceptance of a change request into the development process.
  • Test Results Approval indicates that the project has successfully tested the compliance requirements.
  • Distribution Approval provides control over the delivery of a set of build objects into the QA and Production environments.

Record control

This plug-in supports record control by:

  • Providing a guideline on record control.
  • Defining a new controlled artifact which summarizes record control.
  • Officially identifying approvals, test results, and project archive as records.

Traceability

In the most complex cases traceability can encompass the bulk of the work products produced by the process. In this plug-in we have kept it to the minimum acceptable level of maintaining traceability between change requests (including requirements) and associated tests and making change requests, tests, and test logs controlled work products.

Tool-directed behavior

The sophistication of the processes required to address today's regulations, standards, and policies often makes manual implementation prohibitively expensive and, more importantly, highly burdensome to the staff. Using sophisticated tools to automate parts of the process is called "tool-directed behavior," or (TDB) which is a key ingredient in making compliance a reality. IBM offers a comprehensive tool suite that enables tool directed behavior.

  • IBM Rational Method Composer (RMC) is capable of allowing customers to either tailor the Rational Unified Process to suit their needs and/or to capture their own best practices as part of establishing a team process.
  • IBM Rational RequisitePro® (ReqPro) supports requirements and change management with the appropriate levels of traceability and control.
  • IBM Rational ClearQuest® provides the ability to deliver an auditable change by supporting management and control of software assets through automated workflow management, audit trails, electronic signatures, and reporting.
  • IBM Rational ClearCase® enables delivery of auditable changes by supporting management and control of software assets through version control, audit trails and traceability, user authentication, baselines, and reporting.
  • IBM Tivoli Configuration Manager® (TCM) bridges the gap between software builds and deployments.
  • IBM Rational Portfolio Manager® (RPM) helps organizations control projects and optimize resources through more timely and accurate information, while also providing portfolio management views for middle and executive management.

Formally gated process (control points)

Defining points of control is very much situation-dependent. They typically are defined as part of implementing a workflow. The purpose of implementing a workflow is usually to ensure that those who participate in its execution conform to the various steps to produce output of consistent quality. As an additional mechanism to ensure accountability of product quality approval and gating procedures can be installed in the workflow throughout. These gating procedures typically require an inspection step, whereupon the reviewer is required to indicate his satisfaction or dissatisfaction with the produced output. These control points are key events in the development workflow, where an action of approval has to be taken to allow the process to continue. Careful consideration must be given to several items simultaneously when building an automated workflow solution. These considerations must include the establishment of those roles that participate in the workflow, the decision rights each role will be granted, and the points in the workflow where sufficient data is available with which to make a determination of the output quality.

We recommend considering making all major milestones control points. In the plug-in, we have focused on creating control points around the management of builds and creation of releases where controls are most likely to prevent costly errors. For example, the control points introduced in this plug-in may help prevent costly field problems such as the catastrophic crash of the first Ariane-5 rocket, whose failure was traced to the installation of an incorrect release of the thrust control software.

Benefits of enhancing RUP for auditability

The Business-Driven Development for Compliance Modular Service Offering, and the RUP for Compliance Management plug-in (which is based as part of the content within the service offering) formalize some compliance best practices and present them as self-contained IT process controls. The RUP for Compliance Management plug-in offers the following benefits:

  • A solid foundation for using RUP in compliance management by extending its applicability from high trust to highly controlled environments. The controls introduced are formally specified in RMC and include:
    • Compliance Management specific work products
    • Compliance management roles implementing Separation of Duties
    • A formally Gated Process (Control Points)
    • Work-Product Control
    • Record Control
    • Process automation through Tool Directed Behavior
  • Strong support for the IBM Rational compliance management approach summarized as:
    • "Say what you do"
      Establish a compliant development process
      • Business controls and workflow
      • Technical controls and workflow
      • Approvals, authorizations, quality gates, separation of duties
    • "Do what you say"
      Automate enforcement of your compliant process
      • Process guidance, automated workflow, tool-directed behavior
    • "Be able to prove it"
      Automate the generation of audit documentation
      • Audit report, audit trails for the software development organization
    • "Leverage compliance for business advantage"
      • Analyze project metrics and process metrics
      • Iteratively improve
  • Strike a good balance between formality and practicality. While not all the controls introduced may be required in some projects and extending them may be needed in others, experience demonstrates that it is not practical for organizations to fundamentally rethink core processes on a project-by project basis because of the cost and confusion this is likely to create. Only in rare cases does the implementation of the process warrant making significant adjustments, principally if more control is required.

Next steps

The IBM Rational organization's short to medium term goals are to:

  1. Productize the existing beta version of the RUP for Compliance Management Plug-in.
  2. Provide an overarching compliance governance framework where an organization can effectively manage compliance at the enterprise level.
  3. Develop coherent collections of process controls to address compliance to specific standards and regulations (organizational compliance)

References

Public Compliance launch page (public) on ibm.com: http://www-306.ibm.com/software/info/developer/solutions/compliance/index.jsp

Compliance Zone (public) on developerWorks; articles, webcasts: http://www-128.ibm.com/developerworks/rational/library/compliance.html

Download the RUP for Compliance Management Plug-in V1.0 Beta from developerWorks. (You must have Rational Method Composer installed to use this plug-in.)

Compliance Resource Library on ibm.com (public): http://www-306.ibm.com/software/info/developer/solutions/compliance/resources/index.html

Business Driven Development for Compliance Redbook: http://w3.itso.ibm.com/abstracts/sg247244.html



About the authors

Lynn M. Mueller is a senior consultant and project manager on the IBM Software Group Rational Services team, where she focuses on solutions in compliance and governance across industry sectors. She is an IBM Senior Certified IT Specialist in business analysis, and she has held several senior management roles for IT consulting firms in her fourteen years prior to joining IBM (formerly PwC Consulting ten years ago).


author photo

Dr. Thierry Paradan is a software methodologist for the IBM Rational Unified Process team. He has extensive experience in software development technologies and techniques, as well as a consulting and training background in advanced software engineering methods. Currently, his main professional interest is the domain of compliance management with special focus on striking a good balance between the current methodological trend towards simplicity and agility, and the ever increasing demands of standards and regulations.




Rate this page


Please take a moment to complete this form to help us better serve you.



YesNoDon't know
 


 


12345
Not
useful
Extremely
useful
 


Back to top