TREASURY INSPECTOR GENERAL FOR TAX ADMINISTRATION

 

 

Instilling More Discipline to Business Rules Management Will Help the Modernization Program Succeed

 

 

 

December 2005

 

Reference Number:  2006-20-009

 

 

This report has cleared the Treasury Inspector General for Tax Administration disclosure review process and information determined to be restricted from public release has been redacted from this document.

 

 

Phone Number   |  202-927-7037

Email Address   |  Bonnie.Heald@tigta.treas.gov

Web Site           |  http://www.tigta.gov

 

December 14, 2005

 

 

MEMORANDUM FOR CHIEF INFORMATION OFFICER

                                        

FROM:                            Michael R. Phillips /s/ Michael R. Phillips

                                         Deputy Inspector General for Audit

 

SUBJECT:                    Final Audit Report – Instilling More Discipline to Business Rules Management Will Help the Modernization Program Succeed (Audit # 200520013)

 

This report presents the results of our review of business rules harvesting[1] and management as part of the Internal Revenue Service’s (IRS) Business Systems Modernization (BSM) program.  The overall objectives of this review were to assess the process for considering use of business rules engine[2] technology, determine whether business rules harvesting activities will be timely completed, and determine whether the adequacy of actions taken to address the BSM Challenge Issues related to the business rules management activities.  This review is part of the Treasury Inspector General for Tax Administration Fiscal Year 2005 Information Systems Programs audit plan for reviews of the IRS’ modernization efforts.

Synopsis

A business rules approach is a formal process to manage and automate an organization’s policies, procedures, and guidelines (or business rules) allowing business people to initiate changes to the business rules.  In the IRS, business rules are principally representations of tax laws, tax administration policies, and tax forms.  To define the business rules approach for its BSM program, the IRS created the Business Rules Management initiative in 2003.  The Business Rules Management initiative provides a foundation for the IRS to manage business rules enterprise-wide.

The Customer Account Data Engine (CADE) project is the foundation for managing taxpayer accounts in the IRS modernization plan.  The CADE consists of databases and related applications that will replace the existing Master Files, the IRS’ central and official repository of taxpayer information.  The CADE is considering using the business rules approach with a business rules engine.  A business rules engine is the software that executes business rules.  For the CADE, a business rules engine would process transactions related to a tax form and select and execute correct rules based on the tax year and tax form.

In late 2003, the IRS developed a process to address modernization program findings following several independent studies.  The IRS responded to these studies with action items, referred to as challenge issues.  One challenge issue involved the Business Rules Management process, and another focused on the Business Rules End-to-End Prototype Project.

Work resulting from the Business Rules Management challenge issue included testing a pilot business rules methodology, establishing evaluation criteria for proposals to acquire a business rules repository, and initiating the Submission and Settlement Harvesting Project (SSHP) in March 2005.  One goal of the SSHP is to identify business process redesign opportunities for the submission and settlement aspects of electronic tax return processing.

Our reviews of the SSHP identified the need to improve project management activities to help ensure the Project’s success.  We found the Business Rules Office needs to incorporate its current approach to business rules harvesting and management into the Modernization Vision and Strategy being developed by the Associate Chief Information Officer (CIO), BSM.  In addition, we determined recommendations from the independent technical review were not timely considered to ensure effective Project Management Plan development.  We also determined the SSHP Project Management Plan has not been completed and approved.

Further, the business rules repository acquisition is at risk of not being procured in time to meet the CADE Release 3 planning needs.  Although the Business Rules Office planned for operation by January 2006, the CADE project team requested the new repository be operational by October 1, 2005, to allow for use of the new tool during training for CADE Release 3 planning activities.  Additionally, the Business Rules Office needs to ensure the acquired repository will have the ability to manage business rules in a manner meeting the needs and requirements of the Configuration Management Office.

The other CADE challenge issue relates to the Business Rules End-to-End Prototype Project, which had goals to determine if and when to use business rules engine technology, programming languages, or a combination of the two in implementing business rules within IRS systems such as the CADE and validating the business rules harvesting methodology.  Work started on the Business Rules End-to-End Prototype in February 2005, and results were timely reported in August 2005.  The Project activities included business rules governance, metrics creation, business rules harvesting, project design, development, and testing.  The Business Rules End-to-End Prototype results determined a business rules engine is not a prerequisite for any CADE applications and showed a business rules engine should be considered only when specified criteria are met.  While the Business Rules End-to-End Prototype was performed timely, performance and cost issues need to be addressed to fully assess the IRS’ ability to successfully use a business rules engine.

Recommendations

We recommended the CIO direct the Business Rules Office to incorporate the results of the SSHP efforts to redesign business opportunities and identify associated technical capabilities into the Modernization Vision and Strategy being developed by the Associate CIO, BSM.  Actions also need to be taken to ensure independent validations of project work plans are performed; recommendations are addressed prior to beginning project execution; and the SSHP Project Management Plan is completed, approved, and updated.  Further, the CIO should ensure the Business Rules Office coordinates with the Configuration Management Office to clarify configuration management roles and processes for use of a business rules repository.  The CIO should ensure performance testing and a cost analysis are completed before making any decision to use business rules engine technology in the CADE project.

Response

IRS management agreed with the recommendations presented.  The SSHP Final Report will be provided to the Modernization Vision and Strategy leadership team for inclusion in the development of the modernization strategy report.  The Deputy Associate CIO, Business Integration and Process Management, plans to update the Project Management Plan Data Item Description with guidance on the appropriate use and management of independent validations of project work plans, and the SSHP Project Management Plan was completed and approved in October 2005.  The team developing the requirements for the business rules repository met with the Configuration Management Office and solicited its input; the Configuration Management Office confirmed its concurrence with the roles and processes that the Business Rules Management Office will use to manage the repository.  IRS management decided not to use a business rules engine in CADE Releases 2 and 3.  Modernization efforts going forward will continue to employ the Package Evaluation and Selection methodology if the IRS determines that a business rules engine software package offers an opportunity for a specific solution within modernization projects.  Management’s complete response to the draft report is included as Appendix VII.

Copies of this report are also being sent to the IRS managers affected by the report recommendations.  Please contact me at (202) 622-6510 if you have questions or Margaret E. Begg, Assistant Inspector General for Audit (Information Systems Program), at (202) 622-8510.

 

 

Table of Contents

 

Background

Results of Review

The Internal Revenue Service Is Beginning to Manage Business Rules in Support of the Modernization Program and the Customer Account Data Engine

The Business Rules Office Needs to Incorporate Its Current Approach Into the Modernization Vision and Strategy

Recommendation 1:

Recommendations From the Independent Technical Review Were Not Timely Considered to Ensure Effective Project Management Plan Development

Recommendation 2:

The Submission and Settlement Harvesting Project Management Plan Has Not Been Completed and Approved

Recommendation 3:

The Business Rules Repository May Not Be Procured Timely and Needs to Meet Requirements of All Customers

Recommendation 4:

Additional Actions Are Needed to Ensure the Successful Integration of Business Rules Engine Technology

Recommendation 5:

Appendices

Appendix I – Detailed Objectives, Scope, and Methodology

Appendix II – Major Contributors to This Report

Appendix III – Report Distribution List

Appendix IV – Criteria for the Selection of a Business Rules Engine

Appendix V – Enterprise Life Cycle Overview

Appendix VI – Overview of the Standards for Internal Control in the Federal Government

Appendix VII – Management’s Response to the Draft Report

 

 

Background

 

A business rules approach is a formal process to manage and automate an organization’s policies, procedures, and guidelines (or business rules) allowing business people to initiate changes to the rules.  In the Internal Revenue Service (IRS), business rules are principally representations of tax laws, tax administration policies, and tax forms.  To define the business rules approach for its Business Systems Modernization (BSM) program, the IRS created the Business Rules Management initiative in 2003.  The Business Rules Management initiative provides a foundation for the IRS to manage business rules enterprise-wide.

The Customer Account Data Engine (CADE) project is the foundation for managing taxpayer accounts in the IRS modernization plan.  The CADE consists of databases and related applications that will replace the IRS’ existing Master File processing systems.  The Master Files are the IRS’ central and official repository of taxpayer information.  The CADE is considering using the business rules approach with a business rules engine.  A business rules engine is the software that executes business rules.  For the CADE, a business rules engine would process transactions related to a tax form and select and execute correct rules based on the tax year and tax form.

The IRS initiated the CADE project in September 1999.  In August 2004, the IRS delivered CADE Release 1.1,[3] which successfully processed refund and even-balance Forms 1040EZ[4] for single taxpayers with no pending tax issues.  CADE Release 1.2 started processing tax returns in January 2005.

The CADE’s March 28, 2001, Baseline Business Case presented plans by the PRIME contractor[5]  to use a business rules engine for the CADE project.  The CADE Baseline Business Case targeted January 2002 as the delivery date for Release 1.  The development of the CADE project was revised in August 2003 to use a business rules approach with a business rules engine for CADE Release 2, which was scheduled to begin operation in July 2005.  Since August 2003, the IRS has scaled back the scope of CADE Release 2 by continuing to use the C++[6] programming language and deferring use of a business rules engine.

The IRS made this decision in part because of an independent technical assessment released by the Software Engineering Institute at the request of the IRS.[7]  In its October 2003 report, the Software Engineering Institute concluded the business rules engine selected for consideration by the PRIME contractor may not be compatible in translating IRS tax laws, tax administration policies, and tax forms.  In addition, the study indicated the need to harvest and document the business rules is independent of the choice of a specific business rule engine and is necessary for the success of modernization.  The report also pointed out the IRS was behind schedule in implementing its business rules approach.

This review is the fourth in a series of reviews related to the CADE project activities and was performed at the Business Systems Modernization Office (BSMO) facilities in New Carrollton, Maryland, during the period March through August 2005.  The audit was conducted in accordance with Government Auditing Standards.  Detailed information on our audit objectives, scope, and methodology is presented in Appendix I.  Major contributors to the report are listed in Appendix II.

 

Results of Review

 

The Internal Revenue Service Is Beginning to Manage Business Rules in Support of the Modernization Program and the Customer Account Data Engine

In late 2003, the IRS developed a process to address modernization program findings following several independent studies.  The IRS responded to these studies with action items, referred to as challenge issues.  One challenge issue involved the Business Rules Management process, and another focused on the Business Rules End-to-End Prototype Project.

Business Rules Management

Work resulting from the Business Rules Management Challenge issue included initiating the Submission and Settlement Harvesting Project (SSHP) in March 2005, testing a pilot business rules methodology, and establishing evaluation criteria for proposals to acquire a business rules repository.

The goals of the SSHP are to identify business process redesign opportunities for the submission and settlement aspects of electronic tax return processing, allocate high-level business rules sets to modernized systems such as the CADE, and identify architectural alternatives such as potential reuse of the current processing environment.  The SSHP execution activities began in March 2005, with completion targeted for November 2005.  During the period of our review, the SSHP team assembled a technical team, completed initial business workshops, developed business rules groups or sets for identifying individual taxpayers and settling their accounts, developed the basic design for the future submission and settlement process applications, and mapped current business processes to current business systems.  The SSHP team also developed a risk log to document the management of project risks and their resolution.  In April 2005, the SSHP team transferred its control and documentation of risks to the Issue Tracking and Risk Control System.

The goal of the business rules repository acquisition is to procure a business rules management environment (software tools) to support the harvesting,[8] storage, management, and allocation of business rules enterprise-wide.  The business rules repository acquisition team was originally scheduled to select a vendor by October 2005, with initial operation targeted for January 2006.  During the period of our review, the business rules repository acquisition team conducted a 30-day study to justify the acquisition of a repository and solicited interest from 6 companies.

The Business Rules End-to-End Prototype Project

Work resulting from the Business Rules End-to-End Prototype challenge issue included completing the Business Rules Engine Performance Study and addressing results of the CADE Engineering Analysis Study.  The Business Rules End-to-End Prototype team also completed a project work plan and awarded a Business Rules End-to-End Prototype contract.

The goals of the Business Rules End-to-End Prototype were to determine if and when to use business rules engine technology, programming languages, or a combination of the two to implement business rules within IRS systems such as the CADE and to validate the business rules harvesting methodology.  Work started on the Business Rules End-to-End Prototype in February 2005, and results were reported during August 2005.  During the period of our review, the IRS reported the Business Rules End-to-End Prototype team set up the development and test environments for the business rules engine and C++ programming language, presented an approved approach to measure project results, performed business rules testing, and timely delivered the final report.

Creation of the Business Rules Office

In addition to the above challenge issue and project team accomplishments, the IRS created the Business Rules Office within the BSMO Business Integration Office.  The Business Rules Office is responsible for managing and ensuring the success of the SSHP and the business rules repository acquisition.  Additionally, the establishment of the Business Rules Office included chartering the Business Rules Advisory Board, the purpose of which is to ensure the successful achievement of Business Rules Office project goals.  The Board includes executives from the BSMO’s Business Integration Office and Enterprise Architecture Office, the Wage and Investment Business Unit, the PRIME contractor, and the Science Applications International Corporation. 

As each release of the CADE processes additional taxpayer segments and becomes increasingly more complex, sound business rules management practices need to be in place to ensure success.  This is particularly true for upcoming CADE releases that take on more complex capabilities such as adding new tax forms, processing accounts with closed issues, and updating active accounts.

The Business Rules Office Needs to Incorporate Its Current Approach Into the Modernization Vision and Strategy

The BSM program’s goal is to redesign business practices with new technology.  This process builds on the organizational modernization effort that resulted in a new, customer-focused IRS that started in October 2000.  As the modernization effort progressed, modifications to the approach were made.  These modifications were necessary to meet revisions to project development plans and to incorporate new or different technology capabilities.

The CADE project, the foundation for managing taxpayer accounts in the IRS modernization plan, has undergone many modifications to meet its goals.  The approach to the CADE project’s development includes the following events and modifications:

  • March 2001 – The CADE Baseline Business Case stated, “A rules engine approach is better than the traditional programming approach because it reduces the time and effort to create and maintain the business logic.”
  • November 2001 – The IRS was unable to secure a business rules engine vendor, which resulted in a complete shift in execution philosophy when the PRIME contractor implemented business rules using C++ programming instead of using business rules engine programming in the CADE.
  • October 2003 – The Software Engineering Institute reported, “Modernization depends on [the] CADE, and [the] CADE depends on harvested business rules.”  The Software Engineering Institute went on to state that, while the business rules approach is conceptually sound, business rules engines have not been demonstrated in the CADE environment.
  • March 2004 To assist in addressing the Software Engineering Institute recommendations, the Business Rules Enterprise Management project began to define the business rules approach and provide a foundation for the IRS to manage its business rules from an enterprise-wide perspective.  This approach will allow the IRS business units and functional organizations to initiate changes to their information systems at the business rule level, keeping them in line with changes to their business policies and the Internal Revenue Code.
  • August 2004 – The Business Rules Engineering Management team addressed the Software Engineering Institute recommendations by conducting a pilot focused on process analysis, process redesign, and business rules harvesting.  The pilot established an interim business rules repository populated with data from the pilot.
  • December 2004The Business Rules Engineering Management team reported the IRS is considering using existing processing systems to support modernization projects such as the CADE.
  • February 2005 - The SSHP developed its goals and process redesign analysis to include the use of existing systems to support modernization projects.
  • August 2005 – The Business Rules End-to-End Prototype Project recommended only limited use of business rules engine technology within the CADE and use of C++ programming language for the majority of the continuing work.

Due to the various approaches to using the business rules concept and the various studies conducted since 2001, the CADE project approach to business rules has also changed over time.  The Business Rules Office project activities that are currently being completed will also change CADE development plans.

The Business Rules Office initially considered developing and harvesting business rules for the entire modernized environment.  In performing project activities, such as the SSHP, the Project team identified significant system and manual activity redundancies.  In analyzing the redundancies, the Business Rules Office recognized the opportunity to consider program development alternatives.  The Office intends to document the modifications resulting from these alternatives through business rules harvesting.  The business rules harvesting activity will need to tie the existing process documentation to the modernized system’s business rules.  The modernization program development alternatives include:

  • Combining existing current processing into the modernized environment.  An example may involve tying existing processing documentation for validating the identity of a taxpayer account into the CADE’s business rules.
  • Reengineering existing processes.  An example may involve incorporating various taxpayer account interest calculations into the modernized environment’s business rules.
  • Incorporating commercial off-the-shelf software.
  • Developing business rules for new project development.

The SSHP team is in the process of identifying and proposing reuse of aspects of the current processing environment and potential use of commercial off-the-shelf applications.  It is also anticipating the potential effect of using business rules engine technology in determining the scope of business rules to be developed.  Comprehensive plans to accept business rules from different sources (e.g., the IRS business operating divisions and functional organizations) during the course of project development have not been made.  Developing a process to include the input from the IRS operating divisions’ functional organizations will allow the Business Rules Office teams to successfully identify, harvest, and manage business rules.

As presented above, the evolving approaches to CADE development indicate a need to clearly articulate and document the IRS plans for using business rules and a business rules engine in future CADE development work so the IRS and external stakeholders (e.g., Congress) have a clear understanding of the IRS plans for the CADE and its use of business rules.  In addition, the BSMO’s and IRS business operating divisions’ roles and responsibilities for identifying, capturing, controlling, and documenting the business rules harvesting approach need to be clearly defined.

Recommendation

Recommendation 1:  The Chief Information Officer (CIO) should direct the Business Rules Office to incorporate its results of the SSHP efforts to redesign business opportunities and identify associated technical capabilities into the Modernization Vision and Strategy being developed by the Associate CIO, BSM.  The plans should define roles and responsibilities of the various IRS components and provide direction for using the appropriate business rules approach to fully realize the benefits of combining existing current processing environment, reengineering existing processes, incorporating commercial off-the-shelf software, and developing business rules for new project development.

Management’s Response:  The CIO agreed with this recommendation, stating the Director, Business Rules and Requirements Management, will provide the SSHP Final Report to the Modernization Vision and Strategy leadership team for inclusion in the development of the modernization strategy report.

Recommendations From the Independent Technical Review Were Not Timely Considered to Ensure Effective Project Management Plan Development

The Enterprise Life Cycle (ELC)[9] prescribes the use of a Project Management Plan to define the project, the scope of work to be performed, and the project activities and deliverables.  The Technical Contract Administration Guide[10] requires an independent technical review of the Project Management Plan to validate and integrate relevant recommendations into the Plan.  The SSHP team began performing project work on March 1, 2005; however, the IRS did not issue a work request soliciting an independent technical review to validate the SSHP Project Management Plan until March 29, 2005.  The independent technical review results were issued May 3, 2005, 2 months after the SSHP team began work.

SSHP management stated the work request for the contractor’s independent technical review was issued late because the technical approach for SSHP activities was not fully agreed to until March 29, 2005.  SSHP management further stated contractor support was used in developing the overall plan and methodology, and it was not unusual to request an outside review after some work had already started.

Without assurance that the activities and schedule are validated prior to executing the Project Management Plan, the SSHP is at a higher risk of not attaining its stated goals within the targeted dates established.  Validating the Project Management Plan after the start of the Project’s execution phase puts the SSHP at a higher risk of not timely allocating resources to capture sufficient business rule sets[11] to meet its Project goals.  One of these goals is to capture business rule sets to enable the CADE Release 3 planning activities, scheduled to begin in January 2006.

The independent technical review results presented 14 recommendations to improve the Project Management Plan.  As of June 14, 2005, only 4 of the 14 recommendations had been completed, and the status of the remaining 10 recommendations was unknown.  The recommendations stress immediate attention to increase the likelihood of the SSHP team effectively completing its work on schedule.  For example, 4 of the 10 open recommendations identify inadequate resource assignments within the SSHP Project Management Plan, with approximately 10 percent of the activities not having resources assigned.  The report also states it is critical for the technical SSHP team to know precisely what work is to be produced, by whom, and when.

Specifically related to inadequate resource assignments, the independent review recommended the SSHP team:

·         Define specific project roles.

·         Create a list of the available technical resources and list the roles each person is qualified to fulfill.

·         Ensure there is coverage for each activity.

·         Review the activity assignments with responsible individuals and obtain concurrence.

Recommendations were made to provide details about identifying and assigning project resources

IRS management followed up on the technical review recommendations and advised us on July 29, 2005, the remaining 10 recommendations were either resolved or no longer relevant to the SSHP Project Management Plan.  However, documentation to support resolution of these recommendations could not be provided.  The best practices of the Office of Management and Budget and the Government Accountability Office stress significant events need clear documentation that should be readily available for examination.  Appendix VI presents an overview of the Government Accountability Office Standards for Internal Control in the Federal Government.

Adequate and timely consideration of the technical review recommendations will help complete development of an effective Project Management Plan.  Without documentation to track management’s decisions about the disposition of the recommendations, Project Management Plan development may not include all agreed additions or adjustments to plan activities and resources.

Recommendation

Recommendation 2:  When independent validations of project work plans are to be performed, the CIO should ensure independent validations of project work plans are performed and recommendations are addressed prior to beginning project execution.  This practice would help ensure planned activities and target dates are reasonable and independent validation recommendations are adequately resolved and documented.

Management’s Response:  The CIO agreed with this recommendation, stating the Deputy Associate CIO, Business Integration and Process Management, will update the Project Management Plan Data Item Description to incorporate guidance and criteria on appropriate use and management of independent validations of project work plans.

The Submission and Settlement Harvesting Project Management Plan Has Not Been Completed and Approved

The SSHP Project Management Plan and its detailed work plan schedule have not yet been approved or timely updated.  The ELC requires Project Management Plans to be approved by stakeholders to provide accountability resulting in efficient, repeatable, and auditable deliverables.  It also serves to integrate the business, customers, and other stakeholders with the project team.  In addition, the Internal Revenue Manual requires tracking the actual results and performance to the Project Management Plan so management can take effective actions if the project’s performance deviates significantly from the Plan.

As mentioned above, the best practices of both the Office of Management and Budget and the Government Accountability Office stress significant events need clear documentation that should be readily available for examination.  Without clear documentation about activities and accomplishments, managers do not have a means to recognize deviations or voids in planned activities.  Adequate documentation allows managers to identify significant deviations and take appropriate actions to keep a program on track.

The Standards for Internal Control in the Federal Government cite documentation as a means to ensure actions are taken to control risks

The SSHP Project Management Plan was scheduled to be complete by January 6, 2005.  Segments of the Plan still need to be completed, such as the Project Acceptance Plan and the Communications Management Plan.  The Project Management Plan also is awaiting SSHP Project management team comments for consideration and inclusion in the Plan, and the document does not include designations or signatures of approving officials.

The SSHP work plan is part of the Project Management Plan and is designed to track the status of the Project’s detailed schedule.  The latest work plan made available to us was updated on July 21, 2005.  The SSHP Project manager advised us the update to this work plan did not reflect the current status of the Project’s progress due to resource constraints resulting from the unexpected departure of contract personnel assigned to the Project.  Additionally, the manager directed the Project team to focus on project development and deferred the documentation of project management requirements.

We were advised by BSMO executive management the SSHP was not subject to the ELC methodology; therefore, a completed and approved Project Management Plan was not required.  Because of the relatively short duration of the SSHP, management determined that following the ELC methodology was not appropriate.

However, our review of the SSHP documentation identified some project development work was following ELC guidance and indicated the work was part of the Project’s Milestone 2 activities, as required by the ELC.  In addition, the ELC methodology states the ELC must be followed by both the IRS and the PRIME contractor for developing/acquiring business solutions as part of Tier A modernization projects.[12]  Because the goals of the SSHP were to develop business solutions in support of the CADE project (a Tier A modernization project) by identifying business process redesign opportunities for the submission and settlement aspects of electronic tax return processing, allocating high-level business rules sets to modernized systems, and identifying architectural alternatives such as potential reuse of the current processing environment, one could interpret the ELC guidance as applying to the SSHP.

Regardless of whether the ELC methodology is appropriate for the SSHP, Project Management Plans are a basic management control used to document planned project activities, obtain executive management approval and concurrence, provide estimated completion dates, assign tasks to appropriate staff members, and track progress on completing the tasks.  Reliable project management information, as well as appropriate supporting documentation, provides evidence of activities that have been executed and ensures staff accountability in completing assigned tasks.  For instance, a current work plan allows management to identify and address activities falling behind schedule.

Recommendation

Recommendation 3:  The CIO should ensure the SSHP Project Management Plan is completed, approved, and updated according to established standards, including the ELC, the Internal Revenue Manual, and the best practices of the Office of Management and Budget and the Government Accountability Office.

Management’s Response:  The CIO agreed with this recommendation, stating that the SSHP Project Management Plan was completed and signed on October 11, 2005.

The Business Rules Repository May Not Be Procured Timely and Needs to Meet Requirements of All Customers

The business rules repository acquisition is at risk of not being procured in time to meet the CADE Release 3 planning needs.  The business rules repository, planned for operation by January 2006, will be used by modernization projects such as the CADE to harvest, store, access, and manage their project-level business rules.  Although the IRS currently uses several types of applications to act as a data or business rules repository, IRS management stated these applications do not provide the desired capabilities and controls.  The desired capabilities and controls include ready access to business rules and business rule sets and the ability to manage and properly catalog different versions of business rules.

At the June 9, 2005, meeting of the Business Rules Advisory Board, the CADE project team requested the new repository be operational by October 1, 2005, to allow for use of the new tool during training for CADE Release 3 planning activities scheduled for October through the end of December 2005.  However, the Business Rules Office stated it will not be possible to procure a new repository by October 1, 2005, 3 months earlier than the originally planned January 2006 implementation.  Because the new business rules repository acquisition is needed for training related to CADE Release 3 planning activities by October 1, 2005, its effectiveness is at risk because it may not be operational until January 2006.

To reduce the effects of not having the selected repository operational during CADE training, the Business Rules Office stated strategies are in place to allow CADE engineers to gain familiarity with the new repository tools during preliminary testing.  Also, the IRS will attempt to obtain a copy of the selected repository prior to completion of the acquisition contract.

Alternatives for managing business rules are being considered if a business rules repository is not acquired when needed

The IRS received limited response in July 2005 to its initial business rules repository procurement request from approved vendors.  Subsequently, in August 2005, the IRS opened the repository acquisition process to an unlimited vendor audience by requesting industry comments on a draft statement of work prior to soliciting formal proposals to acquire a repository.  The Business Rules Repository acquisition team plans to contract with a vendor by the end of December 2005 and to implement use of the repository in February or March 2006.

The Business Rules Office should coordinate its needs for the new business rules repository with the Configuration Management Office

The Internal Revenue Manual requires software development, improvement activities, or project commitments to be coordinated and negotiated across the organization.  The Business Rules Office stated it was coordinating with the Modernization and Information Technology Services organization Requirements Management Office and Configuration Management Office.

The Business Rules Repository acquisition project manager coordinated with the Requirements Management Office.  This coordination considered specifications of the IRS’ Enterprise Architecture.[13]  Considering the software tool compatibility with the Enterprise Architecture will allow acquisition of a business rules repository that can work with Requirements Management Office tools.

On June 15, 2005, we inquired about coordination of the acquisition of the business rules repository between the Business Rules Office and the Configuration Management Office.  The Business Rules Office had not made any contacts at that time and subsequently had one conversation with the Configuration Management Office in early July 2005.  The Business Rules Office informally shared its objectives with the Configuration Management Office after a weekly SSHP project management meeting.

Coordinating the business rules repository acquisition with the Configuration Management Office will help ensure conformity with configuration management processes.

Configuration management involves establishing proper controls over approved project documentation, hardware, and software.  It also assures changes are authorized, controlled, and tracked.  Generally, the BSM project teams work with configuration management offices staffed by the PRIME contractor and the Modernization and Information Technology Services organization Information Technology Services office.

Coordination with the Configuration Management Office will help to ensure the acquired repository will have the ability to manage business rules in a manner meeting the needs and requirements of the Configuration Management Office.

Recommendation

Recommendation 4:  The CIO should ensure the Business Rules Office coordinates with the Configuration Management Office to clarify configuration management roles and processes for use of a business rules repository.

Management’s Response:  The CIO agreed with this recommendation and stated the team developing the requirements for the repository met with the Configuration Management Office and solicited its input.  The Configuration Management Office confirmed its concurrence with the roles and processes that the Business Rules Management Office will use to manage the repository.

Additional Actions Are Needed to Ensure the Successful Integration of Business Rules Engine Technology

The main objectives of the Business Rules End-to-End Prototype were to determine whether a business rules engine technology should be used within the CADE and to validate the business rules harvesting methodology.  To accomplish this, the Business Rules End-to-End Prototype evaluated the benefits of using a business rules engine, the C++ programming language, or a combination of both to operate the CADE.  For this evaluation, the Business Rules End-to-End Prototype used approximately 163 Spousal Offset[14] business rules.  The Spousal Offset business rules were selected because IRS management believed they provided the complexity needed to ensure IRS business rules as a whole were adequately represented during the Business Rules End-to-End Prototype testing.

The PRIME contractor timely delivered the Business Rules End-to-End Prototype Project results to the IRS on August 12, 2005, and concluded a business rules engine is not a prerequisite for any CADE applications.  However, if a business rules engine were to be used, the Prototype suggested it would be best used to manage rules such as those for fraud detection.

The Prototype results showed a business rules engine should be considered only when the following six criteria are met:

·         Performance and capacity are not major considerations.

·         The rules are highly volatile and the business needs to change the rules often.

·         A large percentage of rules contain statements with facts (declarative statements).

·         The total number of rules within a specific process area is high.

·         Rule testing requirements are complex.

·         It is desirable to have business analysts to develop rules.

Additionally, the Business Rules End-to-End Prototype determined applying the full business rules management methodology for all business rules in the CADE program would significantly challenge IRS resource capacity, financial resources, and timelines.  For example, the Business Rules End-to-End Prototype measured 2.8 hours to harvest 1 of the estimated 25,000 business rules to be harvested from the current systems, indicating that in excess of 30 staff years would be needed to complete the harvesting process.  The Prototype results suggest using other approaches to capture and document existing business rules when the full business rules management analysis is not required to successfully implement CADE applications.  Presentations about the Business Rules End-to-End Prototype to IRS executives occurred between August 26, 2005, and September 19, 2005.

While the Business Rules End-to-End Prototype was conducted timely, performance and cost issues need to be addressed to fully assess the IRS’ ability to successfully use a business rules engine.  Appendix IV presents industry criteria for selection of a business rules engine.

The Business Rules End-to-End Prototype did not include performance testing for business rules technology

One aspect of performance testing is to determine the number of business rules that can be processed per second, which is measured in millions of instructions per second (MIPS).  Each MIPS costs approximately $6,000 per year.  Previous performance testing estimated a business rules engine used between 6,000 and 9,000 MIPS during peak volume, which is cost prohibitive.

If business rules engine technology is integrated into the CADE Release 3 or future releases, additional performance testing needs to be part of the overall evaluation process to ensure processing capacity (MIPS) can meet CADE requirements.  At a minimum, performance testing should include business rules requiring high computer processing speed and numerous accesses to the business rules engine.  Additionally, to make sure MIPS use is accurately measured, performance testing should be conducted in the same computer environment that will be used during live operations.  Underestimation of the MIPS required by the CADE will significantly affect the IRS’ ability to process tax returns.

The Business Rules End-to-End Prototype did not include a cost analysis for business rules engine technology

If business rules engine technology is integrated into the CADE Release 3 or future releases, a cost analysis of hardware, software, and maintenance requirements also needs to be a part of the overall evaluation process.  A cost analysis has not been performed during the Business Rules End-to-End Prototype.  IRS management recognizes a cost analysis will help to determine the funds needed for the purchase and ongoing maintenance of a business rules engine.

In June 2001, a cost analysis was not performed when the BSMO and the PRIME contractor were considering a business rules engine for use in the CADE Release 1.  In November 2001, the negotiations between the PRIME contractor and the business rules engine vendor broke down when the complete purchase price was determined to be too high.  This determination was not made in time to consider another business rules engine for use in CADE Release 1.

In October 2003, the Software Engineering Institute stated the failure to acquire a business rules engine to implement business rules stalled the CADE project.  The inability to secure a business rules engine vendor mandated a complete shift in execution philosophy when the PRIME contractor implemented the business rules in C++ programming language.  If a business rules engine is deemed appropriate, a cost analysis must be conducted so business rules engine technology needs can be put into the annual IRS budget cycle.

Recommendation

Recommendation 5:  To help ensure the efficient and effective development of the CADE project, the CIO should ensure performance testing and a cost analysis are completed before making any decision to use business rules engine technology in the CADE project.  If the use of business rules engine technology is anticipated for a CADE release, performance testing and a cost analysis should be built into the CADE release schedule.

Management’s Response:  The CIO agreed with the recommendation and stated IRS management decided not to use a business rules engine in CADE Releases 2 and 3.  Modernization efforts going forward will continue to employ the Package Evaluation and Selection methodology contained in the ELC if the IRS determines a business rules engine software package offers an opportunity for a specific solution within modernization projects.

 

Appendix I

 

Detailed Objectives, Scope, and Methodology

 

The overall objectives of this review were to assess the process for considering use of business rules engine[15] technology, determine whether business rules harvesting[16] activities will be timely completed, and determine whether the adequacy of actions taken to address the Business Systems Modernization (BSM) Challenge Issues related to the business rules management activities.  This is the first phase of a two-phase review to determine whether the Customer Account Data Engine (CADE) project management and development activities are effective in assuring future releases of the CADE include all planned functionality and are implemented within cost and schedule estimates.  This review is part of our Fiscal Year 2005 audit plan for reviews of the Internal Revenue Service’s BSM efforts.

To accomplish our objectives, we reviewed available documentation and interviewed Business Systems Modernization Office (BMSO) personnel, Submission and Settlement Harvesting Project (SSHP) managers and analysts, and Modernization Acquisition function analysts from the Agency-Wide Shared Services organization.  Specifically, we:

I.                   Determined whether the BSMO was taking appropriate actions to assess business rules engine technology for use in the CADE.  We made this determination by interviewing BSMO staff and obtaining documentation to determine:

A.    The criteria to select a business rules engine vendor for the Business Rules End-to-End Prototype.[17]

B.     The criteria to use business rules engine technology for the CADE.

C.     Whether the Business Rules End-to-End Prototype testing will provide adequate data and information to make a determination to implement a business rules engine, use C++[18] programming, or use a combination of both.

II.                Determined whether business rules harvesting activities will be timely completed in support of the CADE’s needs and project schedule.  We made this determination by:

A.    Interviewing BSMO, Wage and Investment Business Unit, and Modernization Acquisition function managers and analysts and obtaining documentation about:

1.      The Business Rules Enterprise Management project activities in providing support to the CADE project.

2.      The SSHP activities in providing support to the CADE project.

3.      The criteria and status of the business rules repository suite acquisition.

B.     Interviewing SSHP project staff about their efforts to coordinate the development of business rules harvesting with all necessary stakeholders.

III.             Determined whether the actions taken to address the BSM Challenge Issues have improved the management of the CADE project to successfully move forward.

 

Appendix II

 

Major Contributors to This Report

 

Margaret E. Begg, Assistant Inspector General for Audit (Information Systems Programs)

Gary Hinkle, Director

Edward A. Neuwirth, Audit Manager

Bruce Polidori, Senior Auditor

Louis V. Zullo, Senior Auditor

Steven Gibson, Auditor

Kim McManus, Auditor

 

Appendix III

 

Report Distribution List

 

Commissioner  C

Office of the Commissioner – Attn: Chief of Staff  C

Deputy Commissioner for Operations Support  OS

Associate Chief Information Officer, Business Systems Modernization  OS:CIO:B

Associate Chief Information Officer, Enterprise Services  OS:CIO:E

Director, Office of Procurement  OS:A:P

Director, Stakeholder Management Division  OS:CIO:SM

Deputy Associate Chief Information Officer, Business Integration  OS:CIO:B:BI

Deputy Associate Chief Information Officer, Program Management  OS:CIO:B:PM

Deputy Associate Chief Information Officer, Systems Integration  OS:CIO:B:SI

Chief Counsel  CC

National Taxpayer Advocate  TA

Director, Office of Legislative Affairs  CL:LA

Director, Office of Program Evaluation and Risk Analysis  RAS:O

Office of Management Controls  OS:CFO:AR:M

Audit Liaisons:

Associate Chief Information Officer, Business Systems Modernization  OS:CIO:B

Manager, Program Oversight Office  OS:CIO:SM:PO

 

Appendix IV

 

Criteria for the Selection of a Business Rules Engine

 

When selecting a business rules engine vendor, the focus should be on ease of integration, ease of development, and testing qualities

A business rules engine obtains results by interpreting business rules expressed as sentences in everyday language, such as “if/then” statements.  The business rules express exactly the rules that apply, not the sequence of actions needed to obtain a result like in classical and sequential programming language.

Forrester, an independent technology research company, lists the following attributes that should be considered when selecting a business rules engine:

·         Integration capabilities into development and production environments.

·         The quality of developer and business analyst tools.

·         The capability to simply express complex business rules.

·         A user-friendly interface for business users, including some capability to change rules during the actual execution of the program.

·         Performance, for example the number of rules processed per second.

·         Debugging, diagnosis, and quality explanation of results.

·         The ability to use data stored in databases through diverse interfaces such as Extensible Markup Language.

·         Repository storing rules and version management of rules.

 

Appendix V

 

Enterprise Life Cycle Overview

 

The Enterprise Life Cycle defines the processes, products, techniques, roles, responsibilities, policies, procedures, and standards associated with planning, executing, and managing business change.  It includes redesign of business processes; transformation of the organization; and development, integration, deployment, and maintenance of the related information technology applications and infrastructure.  Its immediate focus is the Internal Revenue Service (IRS) Business Systems Modernization (BSM) program.  Both the IRS and the PRIME contractor1 must follow the Enterprise Life Cycle in developing/acquiring business solutions for modernization projects.

The Enterprise Life Cycle framework is a flexible and adaptable structure within which one plans, executes, and integrates business change.  The Enterprise Life Cycle process layer was created principally from the Computer Sciences Corporation’s Catalyst® methodology.2  It is intended to improve the acquisition, use, and management of information technology within the IRS; facilitate management of large-scale business change; and enhance the methods of decision making and information sharing.  Other components and extensions were added as needed to meet the specific needs of the IRS BSM program. 

Enterprise Life Cycle Processes

A process is an ordered, interdependent set of activities established to accomplish a specific purpose.  Processes help to define what work needs to be performed.  The Enterprise Life Cycle methodology includes two major groups of processes:

Life-Cycle Processes, which are organized into phases and subphases and address all domains of business change.

Management Processes, which are organized into management areas and operate across the entire life cycle.

Enterprise Life-Cycle Processes

The chart was removed due to its size.  To see the chart, please go to the Adobe PDF version of the report on the TIGTA Public Web Page.

Life-Cycle Processes

The life-cycle processes of the Enterprise Life Cycle are divided into six phases, as described below:

·         Vision and Strategy - This phase establishes the overall direction and priorities for business change for the enterprise.  It also identifies and prioritizes the business or system areas for further analysis.

·         Architecture - This phase establishes the concept/vision, requirements, and design for a particular business area or target system.  It also defines the releases for the business area or system.

·         Development - This phase includes the analysis, design, acquisition, modification, construction, and testing of the components of a business solution.  This phase also includes routine planned maintenance of applications.

·         Integration - This phase includes the integration, testing, piloting, and acceptance of a release.  In this phase, the integration team brings together individual work packages of solution components developed or acquired separately during the Development phase. Application and technical infrastructure components are tested to determine if they interact properly.  If appropriate, the team conducts a pilot to ensure all elements of the business solution work together.

·         Deployment - This phase includes preparation of a release for deployment and actual deployment of the release to the deployment sites.  During this phase, the deployment team puts the solution release into operation at target sites.

·         Operations and Support - This phase addresses the ongoing operations and support of the system.  It begins after the business processes and system(s) have been installed and have begun performing business functions.  It encompasses all of the operations and support processes necessary to deliver the services associated with managing all or part of a computing environment.

The Operations and Support phase includes the scheduled activities, such as planned maintenance, systems backup, and production output, as well as the nonscheduled activities, such as problem resolution and service request delivery, including emergency unplanned maintenance of applications.  It also includes the support processes required to keep the system up and running at the contractually specified level.

Management Processes

Besides the life-cycle processes, the Enterprise Life Cycle also addresses the various management areas at the process level.  The management areas include:

·         IRS Governance and Investment Decision Management - This area is responsible for managing the overall direction of the IRS, determining where to invest, and managing the investments over time.

·         Program Management and Project Management - This area is responsible for organizing, planning, directing, and controlling the activities within the program and its subordinate projects to achieve the objectives of the program and deliver the expected business results.

·         Architectural Engineering/Development Coordination - This area is responsible for managing the technical aspects of coordination across projects and disciplines, such as managing interfaces, controlling architectural changes, ensuring architectural compliance, maintaining standards, and resolving issues.

·         Management Support Processes - This area includes common management processes, such as quality management and configuration management that operate across multiple levels of management.

Milestones

The Enterprise Life Cycle establishes a set of repeatable processes and a system of milestones, checkpoints, and reviews that reduce the risks of system development, accelerate the delivery of business solutions, and ensure alignment with the overall business strategy.  The Enterprise Life Cycle defines a series of milestones in the life-cycle processes.  Milestones provide for “go/no-go” decision points in the project and are sometimes associated with funding approval to proceed.  They occur at natural breaks in the process where there is new information regarding costs, benefits, and risks and where executive authority is necessary for next phase expenditures.

There are five milestones during the project life cycle: 

·         Milestone 1 - Business Vision and Case for Action.  In the activities leading up to Milestone 1, executive leadership identifies the direction and priorities for IRS business change.  These guide which business areas and system development projects are funded for further analysis.  The primary decision at Milestone 1 is to select BSM projects based on both the enterprise-level Vision and Strategy and the enterprise architecture.

·         Milestone 2 - Business Systems Concept and Preliminary Business Case.  The activities leading up to Milestone 2 establish the project concept, including requirements and design elements, as a solution for a specific business area or business system.  A preliminary business case is also produced.  The primary decision at Milestone 2 is to approve the solution/system concept and associated plans for a modernization initiative and to authorize funding for that solution.

·         Milestone 3. - Business Systems Design and Baseline Business Case.  In the activities leading up to Milestone 3, the major components of the business solution are analyzed and designed.  A baseline business case is also produced.  The primary decision at Milestone 3 is to accept the logical system design and associated plans and to authorize funding for development, test, and (if chosen) pilot of that solution

·         Milestone 4 - Business Systems Development and Enterprise Deployment Decision.  In the activities leading up to Milestone 4, the business solution is built.  The Milestone 4 activities are separated by two checkpoints.  Activities leading up to Milestone 4A involve further requirements definition, production of the system’s physical design, and determination of the applicability of fixed-price contracting to complete system development and deployment.  To achieve Milestone 4B, the system is integrated with other business systems and tested, piloted (usually), and prepared for deployment.  The primary decision at Milestone 4B is to authorize the release for enterprise-wide deployment and commit the necessary resources.

·         Milestone 5 - Business Systems Deployment and Postdeployment Evaluation.  In the activities leading up to Milestone 5, the business solution is fully deployed, including delivery of training on use and maintenance.  The primary decision at Milestone 5 is to authorize the release of performance-based compensation based on actual, measured performance of the business system.

 

Appendix VI

 

Overview of the Standards for Internal Control in the Federal Government[19]

 

The Federal Managers’ Financial Integrity Act of 1982[20] requires the Government Accountability Office to issue standards for internal control in the Federal Government.  Rapid advances in information technology have underscored the need for updated guidance on internal controls over modern computer systems.  At the same time, the management of human capital is increasingly recognized as an important part of internal control.

Internal Control Definition and Objective

Internal control is a major part of managing an organization.  It comprises the plans, methods, and procedures used to meet missions, goals, and objectives and, in doing so, support performance-based management.  Internal control also serves as the first line of defense in safeguarding assets and preventing and detecting errors and fraud.  In short, internal control, which is synonymous with management control, helps Federal Government program managers achieve desired results through effective stewardship of public resources.

Internal control should provide reasonable assurance that the objectives of the agency are being achieved in the following categories:

  • Effectiveness and efficiency of operations, including the use of the entity’s resources.
  • Reliability of financial reporting, including reports on budget execution, financial statements, and other reports for internal and external use.
  • Compliance with applicable laws and regulations.

The Five Standards for Internal Control

The five standards for internal control are:

·         Control Environment Management and employees should establish and maintain an environment throughout the organization that sets a positive and supportive attitude toward internal control and conscientious management.

A positive control environment is the foundation for all other standards.  It provides discipline and structure as well as the climate that influences the quality of internal control.  The following key factors affect the control environment:

-         The integrity and ethical values maintained and demonstrated by management and staff.

-         Management’s commitment to competence, including the attitude and philosophy toward information systems, accounting, personnel functions, monitoring, and audits and evaluation, can have a profound effect on internal control.

-         The agency’s organizational structure and management framework for planning, directing, and controlling operations to achieve agency objectives.

-         Good human capital policies, including establishing appropriate practices for hiring, training, evaluating, counseling, promoting, compensating, and disciplining personnel.

-         The agency’s relationship with Congress and oversight agencies such as the Office of Management and Budget, Inspectors General, and internal senior management councils can contribute to a good overall control environment.

·         Risk Assessment – Internal control should provide for an assessment of the risks the agency faces from both external and internal sources.

A precondition to risk assessment is the establishment of clear, consistent agency objectives.  Management needs to comprehensively identify risks and should consider all significant interactions between the entity and other parties as well as internal factors at both the entity-wide and activity levels.

Once risks have been identified, they should be analyzed for their possible effect.  Risk analysis generally includes estimating the risk’s significance, assessing the likelihood of its occurrence, and deciding how to manage the risk and what actions should be taken.  Because governmental, economic, industry, regulatory, and operating conditions continually change, mechanisms should be provided to identify and deal with any special risks prompted by such changes.

·         Control Activities – Internal control activities help ensure management’s directives are carried out.  The control activities should be effective and efficient in accomplishing the agency’s control objectives.

Control activities are the policies, procedures, techniques, and mechanisms that enforce management’s directives, such as the process of adhering to requirements for budget development and execution.  They help to ensure actions are taken to control risks.  Control activities are an integral part of an entity’s planning, implementing, reviewing, and accountability for stewardship of Federal Government resources and achieving effective results.  Examples of control activities include:

-         Reviews by management at the functional or activity level.

-         Controls over information processing.

-         Physical control over vulnerable assets.

-         Establishment and review of performance measures and indicators.

-         Segregation of duties.

-         Proper execution of transactions and events.

-         Access restrictions to and accountability for resources and records.

-         Appropriate documentation of transactions and internal control.

·         Information and Communication – Information should be recorded and communicated to management and others within the entity who need it and within a time period that enables them to carry out their internal control and other responsibilities.

For an entity to run and control its operations, it must have relevant, reliable, and timely communications relating to internal as well as external events.  Information is needed throughout the agency to achieve all of its objectives.

Program mangers need both operational and financial data to determine whether they are meeting their agencies’ strategic and annual performance plans and meeting their goals for accountability for effective and efficient use of resources.  For example, operational information is required for development of financial reports.  Financial information is needed for both external and internal uses.  It is required to develop financial statements for periodic external reporting and, on a day-to-day basis, to make operating decisions, monitor performance, and allocate resources.

Effective communications should occur in a broad sense with information flowing down, across, and up the organization.  In addition to internal communications, management should ensure there are adequate means of communicating with, and obtaining information from, external stakeholders that may have a significant impact on the agency achieving its goals.

·         Monitoring – Internal control monitoring should assess the quality of performance over time and ensure the findings of audits and other reviews are promptly resolved.

Internal control should generally be designed to assure ongoing monitoring occurs in the course of normal operations.  It is performed continually and is ingrained in the agency’s operations.  It includes regular management and supervisory activities, comparisons, reconciliations, and other actions people take in performing their duties.

Monitoring of internal control should include policies and procedures for ensuring the findings of audits and other reviews are promptly resolved.  Managers are to (1) promptly evaluate findings from audits and other reviews, including those showing deficiencies and recommendations reported by auditors and others who evaluate agencies’ operations; (2) determine proper actions in response to findings and recommendations from audits and reviews; and (3) complete, within established time periods, all actions that correct or otherwise resolve the matters brought to management’s attention.

 

Appendix VII

 

Management’s Response to the Draft Report

 

The response was removed due to its size.  To see the response, please go to the Adobe PDF version of the report on the TIGTA Public Web Page.


[1] A business rule is a statement that defines or constrains some aspect of the business.  Harvesting is a general term used to broadly describe the entire set of activities involved in gathering, formalizing, analyzing, and validating business rules for a particular scope.

[2] A business rules engine translates business rules, or processing criteria, into executable computer code which processes transactions related to a tax form and selects and executes correct rules based on the tax year and tax form.

[3] A release is a specific edition of software.

[4] Form 1040EZ is the Income Tax Return for Single and Joint Filers With No Dependents.  The initial release of the CADE does not process Forms 1040EZ for joint filers.

[5] The PRIME contractor is an alliance of leading technology companies brought together to assist with the IRS’ efforts to modernize its computer systems and related information technology.

[6] Programmers can write or code software programs using several different programming languages.  C++ is an object-oriented, high-level programming language developed by Bell Labs.

[7] Report of the Independent Technical Assessment on the Internal Revenue Service Business Systems Modernization Customer Account Data Engine, dated October 2003.

[8] Harvesting is the general term used to broadly describe the entire set of activities involved in gathering, formalizing, analyzing, and validating business rules for a particular scope.

[9] The ELC establishes a set of repeatable processes and a system of reviews, checkpoints, and milestones that reduce the risks of systems development and ensures alignment with the overall business strategy.  Appendix V presents an overview of the components of the ELC.

[10] The Technical Contract Administration Guide provides contract guidance to the IRS, including roles and responsibilities, and identifies required services and products by project milestone.

[11] A business rule set is a logical group of business rules around a business process, such as the business rules that verify Taxpayer Identification Numbers.

[12] Tier A modernization projects are large automation development activities that support basic tax functions and usually affect multiple IRS business organizations. 

[13] The architecture is the design of a computer system.  It sets the standard for all devices that connect to it and all the software that runs on it.  The modernized architecture guides the organization of the BSM effort.

[14] The Spousal Offset affects refunds for either spouse or ex-spouse when a prior year tax return has an outstanding balance.

[15] A business rule is a statement that defines or constrains some aspect of the business.  A business rules engine translates business rules, or processing criteria, into executable computer code which processes transactions related to a tax form and selects and executes correct rules based on the tax year and tax form.

[16] Harvesting is a general term used to broadly describe the entire set of activities involved in gathering, formalizing, analyzing, and validating business rules for a particular scope.

[17] The Business Rules End-to-End Prototype will assist in determining if a business rules engine is the correct strategy for the CADE.

[18] Programmers can write or code software programs using several different programming languages.  C++ is an object-oriented, high-level programming language developed by Bell Labs.

1 To facilitate success of its modernization efforts, the IRS hired the Computer Sciences Corporation as the PRIME contractor and integrator for the BSM program and created the Business Systems Modernization Office to guide and oversee the work of the PRIME contractor.

2 The IRS has acquired a perpetual license to Catalyst® as part of the PRIME contract, subject to certain restrictions. The license includes rights to all enhancements made to Catalyst® by the Computer Sciences Corporation during the contract period.

[19] Standards for Internal Control in the Federal Government (GAO/AIMD-00-21.3.1, dated November 1999).

[20] 31 U.S.C. §§ 1105, 1113, 3512 (2000).