TREASURY INSPECTOR GENERAL FOR TAX ADMINISTRATION

 

The Customer Account Data Engine 2 Database Implementation Project Made Progress in Design Activities, but Improvements Are Needed

 

 

 

September 20, 2011

 

Reference Number:  2011-20-110

 

 

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-622-6500

Email Address   |  TIGTACommunications@tigta.treas.gov

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

 

 

HIGHLIGHTS

 

THE CUSTOMER ACCOUNT DATA ENGINE 2 DATABASE IMPLEMENTATION PROJECT MADE PROGRESS IN DESIGN ACTIVITIES, BUT IMPROVEMENTS ARE NEEDED

 

Highlights

Final Report issued on September 20, 2011  

Highlights of Reference Number:  2011-20-110 to the Internal Revenue Service Chief Technology Officer.

IMPACT ON TAXPAYERS

The mission of the Customer Account Data Engine 2 (CADE 2) Program is to provide state-of-the-art individual taxpayer account processing and technologies to improve service to taxpayers and enhance Internal Revenue Service (IRS) tax administration.  Once completed, the new modernization environment should allow the IRS to more effectively and efficiently update taxpayer accounts, support account settlement and maintenance, and process refunds on a daily basis, all of which will contribute to improved taxpayer services.

WHY TIGTA DID THE AUDIT

The overall objective was to review the preliminary and detailed designs of the CADE 2 database to ensure that the design is secure and satisfies the stated requirements, and that project management practices adhere to Enterprise Life Cycle standards and processes for the related design milestones.

WHAT TIGTA FOUND

The CADE 2 Database Implementation Project team made progress to complete design activities and address security and privacy controls.  For example, the Database Implementation Project team closed issues identified from the CADE 2 database Extract, Transform, and Load prototypes and addressed requirements and business rules.  In addition, an improved Project team and Cybersecurity organization partnership addressed Database Implementation security and privacy controls and made critical decisions relating to security of the database.  Despite overall progress, improvements are needed to ensure key activities for the Design Specification Report, audit plan, and database trial initializations are timely, and the Interface Control Documents and Work Breakdown Structure comply with Enterprise Life Cycle criteria.

WHAT TIGTA RECOMMENDED

TIGTA recommended that the Chief Technology Officer ensure key activities and deliverables (including security) are completed timely and, if not, an assessment is made to determine the impact or risk of not completing the required activity; the Enterprise Life Cycle guidance is kept current and includes all artifacts needed for projects following the Iterative Path; and several other system development process improvements are implemented to ensure the CADE 2 system functions as designed when deployed into IRS operations.

In its response to the report, the IRS agreed with four of TIGTA’s recommendations and has taken or plans to take appropriate corrective actions.  The IRS disagreed with TIGTA’s recommendation to ensure the Internal Revenue Manual (IRM) guidance for the Enterprise Life Cycle is current and addresses the artifacts needed for the Iterative Path.  The IRS stated the IRM is updated annually and reflects the required artifacts.  Further, the IRS indicated that when projects proceed through milestone reviews without the artifacts identified in the IRM, they do so under a tailored plan, a practice also outlined in the IRM. 

TIGTA found that the IRS’s project tailoring plan contained the artifacts from the IRM and was not subsequently updated to include an updated artifact based on the Iterative Path approach.  As a result, TIGTA maintains that the IRM needs to be updated to make the guidance more effective in managing projects following the Iterative Path.  Until the IRM guidance can be revised during the next annual update cycle, the IRS should consider sending out additional guidance based on lessons learned.

 

September 20, 2011

 

 

MEMORANDUM FOR CHIEF TECHNOLOGY OFFICER

 

FROM:                   (for)  Michael R. Phillips /s/ Michael E. McKenney

                                         Deputy Inspector General for Audit

 

SUBJECT:                    Final Audit Report – The Customer Account Data Engine 2 Database Implementation Project Made Progress in Design Activities, but Improvements Are Needed (Audit # 201120002)

 

This report presents the results of our review of the Customer Account Data Engine 2 Database Implementation.  Our overall objective was to review the preliminary and detailed designs[1] of the Customer Account Data Engine 2 database and ensure that the database is designed in a secure manner, the design satisfies the stated requirements, and project management practices adhere to Enterprise Life Cycle standards and processes for the related design milestones.  This review is included in our Fiscal Year 2011 Annual Audit Plan and addresses the major management challenge of Modernization. 

Management’s complete response to the draft report is included as Appendix IX.

Copies of this report are also being sent to the Internal Revenue Service managers affected by the report recommendations.  Please contact me at (202) 622-6510 if you have questions or Alan Duncan, Assistant Inspector General for Audit (Security and Information Technology Services), at (202) 622-5894.

 

 

Table of Contents

 

Background

Results of Review

The Database Implementation Project Made Progress to Complete Design Activities and Address Security and Privacy Controls

Improvements Are Needed to Ensure Timely Delivery of Key Activities

Recommendations 1 and 2:

Interface Control Documents and the Integrated Master Schedule Do Not Comply With All Enterprise Life Cycle Criteria

Recommendation 3:

Recommendations 4 and 5:

Appendices

Appendix I – Detailed Objective, Scope, and Methodology

Appendix II – Major Contributors to This Report

Appendix III – Report Distribution List

Appendix IV – Enterprise Life Cycle Overview

Appendix V – Customer Account Data Engine 2 Integrated Design Reviews

Appendix VI – Customer Account Data Engine 2 Transition Strategy

Appendix VII – Database Implementation Design Issues in Pending Status

Appendix VIII – Glossary of Terms

Appendix IX – Management’s Response to the Draft Report

 

 

Abbreviations

 

CADE

Customer Account Data Engine

DSR

Design Specification Report

ELC

Enterprise Life Cycle

ETL

Extract, Transform, and Load

IMF

Individual Master File

IMS

Integrated Master Schedule

IRM

IRS

TIGTA

WBS

Internal Revenue Manual

Internal Revenue Service

Treasury Inspector General for Tax Administration

Work Breakdown Structure

 

 

 

 

Background

 

The Customer Account Data Engine 2 Program is the highest priority information technology modernization project in the IRS.

In August 2008, the Internal Revenue Service (IRS) Commissioner established the Modernized Taxpayer Account Program Integration Office to manage the transition of current individual income tax processing, which consists of multiple computer systems for processing tax returns, payments, and other transactions that affect individual taxpayer accounts, into a more consolidated system.  Working in conjunction with IRS business owners, the Program Integration Office decided to integrate elements from both the existing Individual Master File (IMF)[2] and current Customer Account Data Engine (CADE) processes into a new CADE 2 Program.  The proposed plan incrementally transfers taxpayer accounts from the current IMF and CADE processing systems to a new CADE 2 relational database.

The CADE 2 Program is the top information technology modernization project in the IRS.  The CADE 2 Transition Strategy[3] involves three phases:  Transition States 1 and 2 and a Target State.

To accomplish Transition State 1 goals, the CADE 2 Database Implementation Project was established to move the IRS away from operating in two tax processing environments and to maintain a single system of records for all individual taxpayer accounts.  The primary deliverable of the CADE 2 Database Implementation Project is a relational database that will house individual taxpayer account data, currently processed by the IMF and current CADE systems.  Some of the Database Implementation Project objectives are to:

This review is one of a series of audits providing assessments of the CADE 2 Program as part of our Security and Information Technology Audit Strategy for Fiscal Years 2010 and 2011.  For instance, the Treasury Inspector General for Tax Administration (TIGTA) issued its report on the results of the CADE 2 prototype activities on November 24, 2010.[4]  The objective of each prototype was to demonstrate confidence in the CADE 2 Program approach by verifying system viability and performance and by defining components that would serve as the foundation for development activities.  Specifically, the CADE 2 Database Implementation Project was dependent on the CADE 2 database Extract, Transform, and Load (ETL) prototypes that were established to test hypotheses around the tools and architecture of selected Database Implementation Project components.  The results of the prototypes would facilitate the CADE 2 Database Implementation Project design and develop the CADE 2 database in Transition State 1.  In addition to the prototype review, the TIGTA has recently completed audits covering the CADE 2 Program Management Office and Daily Processing.[5]

This review was performed at the Modernization and Information Technology Services organization facility in New Carrollton, Maryland, during the period January through May 2011.  We conducted this performance audit in accordance with generally accepted government auditing standards.  Those standards require that we plan and perform the audit to obtain sufficient, appropriate evidence to provide a reasonable basis for our findings and conclusions based on our audit objective.  We believe that the evidence obtained provides a reasonable basis for our findings and conclusions based on our audit objective.  Detailed information on our audit objective, scope, and methodology is presented in Appendix I.  Major contributors to the report are listed in Appendix II.

 

 

Results of Review

 

The Database Implementation Project Made Progress to Complete Design Activities and Address Security and Privacy Controls

The CADE 2 Database Implementation Project team made progress toward implementing a new database that will house all individual taxpayer accounts and provide the ability for IRS employees to view the updated account information online.  In addition, security and privacy controls will be implemented as necessary to protect taxpayer information. 

The Database Implementation Project team accomplished key activities to complete the preliminary and detailed designs[6] of the CADE 2 database and to ensure the design considered security and privacy controls.  For instance, the Database Implementation Project team took actions to close open issues from the CADE 2 database ETL prototype projects.  A dedicated team was formed to address business requirements and business rules issues.  Also, an improved Project team and Cybersecurity organization partnership addressed Database Implementation security and privacy controls.

The Database Implementation Project team closed issues identified from the prototypes

One of the primary objectives of the Database Implementation Project is to resolve outstanding issues from the CADE 2 database ETL prototypes.  The Database Implementation Project team conducted analyses and tests that resulted in simplifying complex transformation rules and improved database performance.  Simplifying transformation rules improves transformation performance, which is the measurement of the time it takes to transform the data in preparation for loading into the CADE 2 database.

In order for the CADE 2 Program to meet business requirements, the CADE 2 system daily updates must be completed in 6 hours.  The CADE 2 Database Implementation ETL Performance prototype indicated that it will take 12.81 hours during weekly peak days and 8.94 hours during typical days.  The Database Implementation Project team further closed the performance gap between the allocated 6-hour processing window and the prototype projections by a combination of optimizing the hardware, system, and product configurations and revision of the application code. 

A dedicated team was formed to address business system requirements and business rules

Gathering and developing business system requirements and business rules are the responsibility of the Program Management Office up to Milestone 2 and are critical as they serve as the foundation for the system’s preliminary and detailed design.  At Milestone 3, the business system requirements were provided to the Database Implementation Project team to further decompose (i.e., break down into component parts) for the preliminary and detailed designs.  Business rules are developed from requirements.  However, the general state of the requirements was not sufficient to begin this work.  Therefore, a dedicated team was formed to address the business system requirements and business rules.  The Database Implementation Project team developed the CADE 2 Database Implementation Analyst Handbook and a framework tool for collecting business rules.  The CADE 2 Database Implementation Analyst Handbook in conjunction with the Requirements Management Plan and the Requirements and Demand Management Requirements Handbook provides guidelines, principles, best practices, and techniques for business rules development for the Milestone 4a detailed design.

In addition, the Database Implementation Project team completed deep dives and a series of integrated design reviews[7] between September 2010 and April 2011 to assess whether design plans were consistent with requirements.  A collaborative team identified a total of 88 design issues.  These efforts, along with the business system requirements and business rules process improvements, contributed to closing 84 of the 88 open issues.  The remaining four design issues[8] were still open as of April 18, 2011, the detailed design milestone exit date.  One issue was closed in early May 2011, and the three remaining design issues were expected to be closed by the end of May 2011. 

An improved Project team and Cybersecurity organization partnership addressed Database Implementation security and privacy controls

In November 2010 the TIGTA reported that, as the work progressed, the prototype teams gave more consideration to security provisions and a foundation was laid for providing more opportunities for the Cybersecurity organization’s involvement in CADE 2 design activities.[9]  Our review of CADE 2 Database Implementation Project preliminary and detailed design activities showed that the Cybersecurity organization was heavily engaged and proactive in its assigned role of managing all aspects of CADE 2 security.  From the onset, a technical leader from the Cybersecurity organization and Privacy office was assigned to the Database Implementation Project team to coordinate and ensure alignment and compliance with enterprise standards in the areas of security and privacy.  This included participating in the development of the security and privacy requirements.

When the CADE 2 Program Management Office expressed concern that encrypting data from the IMF to the CADE 2 database would slow performance, the Cybersecurity organization completed a risk assessment and, based on compensating controls, agreed with a risk-based decision not to require Enterprise File Transfer Utility encryption.

The Cybersecurity organization created a threat model to understand the attackable surface, entry points, trust boundaries, Sensitive but Unclassified data stores, entities, processes, and data paths of the system.  Also, they developed a Live Data Risk Mitigation Strategy that provides a standardized process for:  1) developing CADE 2 Live Data Guidance, 2) working with the Privacy office, and 3) tracking all live data requests through its life cycle, as oversight.  This strategy addresses concerns reported in the above-referenced TIGTA report that contractors were allowed to work with live taxpayer data without adequate request documentation.

Security and privacy deliverables, which included the security and privacy section of the CADE 2 Database Implementation Design Specification Report (DSR), Security Risk Assessments, and Privacy Impact Assessments, were adequate and completed timely, as required.  For instance, our review of the CADE 2 Database Privacy Impact Assessment showed that taxpayer privacy protection was adequately considered in the design.  Also, our review of the Security Risk Assessments showed areas of potential security risks[10] are being resolved or mitigated and are adequately monitored by the Cybersecurity organization.

Even though some security and privacy aspects of the Database Implementation system had not been specified at the completion of the physical design,[11] we are confident they will be considered prior to testing because of the improved collaborative partnership among the Project team and Cybersecurity organization.  Also, the operation and effectiveness of security controls will be evaluated in a future audit of the CADE 2 system. 

Improvements Are Needed to Ensure Timely Delivery of Key Activities

Despite overall progress, improvements are needed to ensure timely delivery of key activities, such as the CADE 2 Database Implementation DSR, the IRS CADE 2 Database Implementation Audit Plan, and database trial initializations.  The CADE 2 Database Implementation Project is following the Enterprise Life Cycle (ELC) Iterative Path.  See Figure 1 for a depiction of the Iterative Path approach to information technology project development.  In the Iterative Path development life cycle, projects start with initial planning and end with deployment, with repeated cycles of requirement discovery, development, and testing in between, compared to the traditional Waterfall Path that is distinguished by sequential development of a solution with planned reviews and formal approvals required before continuation of work.[12]  The ELC allows for tailoring.  Tailoring is customization of the ELC and its various features for use by an individual project.  The objective is to arrive at an approach that is based on standard methods that have been modified (as necessary) to take into account the specific needs and unique conditions of the project.  The intent of tailoring is not to fit a project into the constrictions of the ELC, but to adapt the ELC so that it is practical and effective given the realities of the project.   

The Database Implementation Tailoring Plan defines the Project’s plan to satisfy the requirements following the ELC and includes the deliverables and work products necessary to support the iterative approach to information technology project development. 

Figure 1:  Iterative Path Approach to Information Technology
Project Development

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

As required by the ELC framework, key design activities, such as the DSR and audit plan, were not completed as scheduled.

The Database Implementation Design Specification Report was not completed as planned

The CADE 2 Database Implementation DSR documents the application design, data design, technical infrastructure, and traceability to the requirements.  It also describes the design based on a defined scope and the business system requirements that are described in the CADE 2 Project Charter, the CADE 2 Database Implementation Business System Report, and the CADE 2 Program Roadmap.

The Database Implementation Project Tailoring Plan showed that the DSR will be finalized in Milestone 4a and did not provide for an update in Milestone 4b.  However, the DSR was not finalized prior to exiting Milestone 4a because of the dependency on pending design issues,[13] such as transformation rules, Integrated Production Model design, and Process Automation and Monitoring design.

The Project team used the ELC tables and did not realize it did not include DSR updates in Milestone 4b.  The ELC tables list the Milestone phase artifacts (i.e., the tangible result or output of an activity or task performed by a project during the life cycle).  There are several updates planned for the DSR during Milestone 4b.  The ELC provides that project teams should be aware that other artifacts (not included in the ELC tables) may be required and/or necessary for their particular project.  The ELC tables should not be considered all-inclusive.  Also, although artifacts may be initiated in one phase, they are subsequently reviewed and may be updated throughout later phases of the ELC.  Since the Project is following the Iterative Path, we would expect the DSR to be updated during Milestone 4b for necessary design changes as a result of testing.

The IRS maintains that the ELC Iterative Path was adopted and implemented earlier this year with a clear understanding that it would need to be tailored in the near term to accommodate project needs and to leverage more effectively the experience of key stakeholders with pre-existing development approaches (e.g., Waterfall).  As such, lessons learned from the project teams using the new iterative path would be relied on and captured to enable revision of the path (and associated artifacts) to establish a viable and effective iterative development approach. 

In addition, the Chief Architect provided the perspective that the iterative development of the DSR was a major step forward for the IRS ELC.  The path the Database Implementation Project chose enabled a wide audience from business, engineering, development, and test to get a good look at the design, and then focus on the critical areas of the design and resolution of design issues.  A traditional Waterfall would have limited the review time and locked the design with some poor design choices.  The TIGTA agrees and believes as the IRS matures in its implementation of the Iterative Path development life cycle, the ELC and its execution will be more aligned.

In addition, the CADE 2 Transition State 1 Transformation Rules were incomplete.  Transformation Rules are one of several items used by the ETL Program to transform individual taxpayer accounts from IMF flat-file formats and current CADE relational database formats (for the one-time initialization) to the formats and structures defined for the CADE 2 database.  Our review of this documentation found missing file layout identification information.  Project management indicated that this document would be completed by May 31, 2011, during Milestone 4b.

The Database Implementation Project Audit Plan was not completed timely

As discussed earlier, security deliverables were generally completed timely, except in this case.  The IRS CADE 2 Database Implementation Audit Plan was not finalized as required prior to exiting Milestone 4a on April 18, 2011.  The audit plan describes how audit trail requirements will be met for the CADE 2 Database Implementation.  Audit trails are key to achieving several security-related goals, including supporting individual accountability, detecting application intrusions and other forms of abuse, and allowing analysis and reconstruction of the sequences of events for effective security incident response.  In addition, the development of a comprehensive audit plan supports the IRS’s goal to resolve its Computer Security Material Weakness on audit trails and related TIGTA and Government Accountability Office findings.

We identified information gaps in the following areas of the IRS CADE 2 Database Implementation Audit Plan:  Daily Processing/Database Implementation Balance and Control, Error Handing, and Enterprise Informatica Platform.  The Cybersecurity Information Technology Security Requirements Overview guidelines state the final IRS CADE 2 Database Implementation Audit Plan should be submitted as part of the security package for the Milestone 4a exit.  Because many configuration details in the areas provided above were not yet available, the audit plan was not finalized and submitted prior to the CADE 2 Milestone 4a exit.  Timelines of security deliverables are critical to ensure validation, testing, and overall risk assessment can be performed in a timely manner.

Database trial initializations were not completed as scheduled

The purpose of the CADE 2 database trial initializations is to assess and address performance and data quality issues prior to production implementation.  Initialization of the CADE 2 database will be performed in phases.  During the first phase, database trial initializations were originally planned to begin in March 2011 and April 2011.  The duration of the database trial initialization was planned for 6 months, with the formal database initialization beginning October 2011.  Meanwhile, there would be a number of iterative database trial initializations increasing in volume and complexity until September 2011. 

However, the database trial initializations were delayed, and a new schedule to complete this activity was not finalized prior to the completion of our fieldwork in May 2011.  Personnel from the Modernization and Information Technology Services Application Development office cited the following reasons for the delay:  delays in getting the testing environment ready, delays in awarding the Informatica contract, and late resolution of the Enterprise File Transfer Utility issue.

Not performing the database trial initializations as originally planned may impact the quality of testing efforts.  For instance, there will be only a limited amount of time for further performance tuning and identifying data anomalies.  Also, there may be less time to address data quality business rules and take corrective actions prior to production deployment. 

We are concerned with the number of key activities that were not completed as scheduled and were instead postponed to Milestone 4b.  With an already aggressive schedule, these delays could put the CADE 2 Transition State 1 scheduled dates for coding, testing, and certification at jeopardy and the “go-live” date of January 2012 for Database Implementation could be at risk.

Recommendations

The Chief Technology Officer should:

Recommendation 1:  Ensure key activities and deliverables (including security deliverables) for the Database Implementation Project are completed timely and, if not, ensure an assessment is made to determine the impact or risk of not completing the required activity. 

Management’s Response:  The IRS agreed with this recommendation.  The IRS will ensure key milestone activities and deliverables (including security deliverables) for the Database Implementation Project are completed timely and, if not, ensure an assessment is made to determine the impact or risk of not completing the required activity.  If it is determined that there are impacts that put the project at risk, they will be documented and mitigated through the risk process currently in place.

Recommendation 2:  Ensure the Internal Revenue Manual (IRM) 2.16.1, Enterprise Life Cycle Guidance, is kept current and includes all artifacts that are needed for projects following the Iterative Path.

Management’s Response:  The IRS disagreed with this recommendation.  IRS management stated that the Enterprise Life Cycle Guidance in IRM 2.16.1 is already current, and is kept current through an annual update process.  The IRM already reflects the artifacts required for projects following the Iterative Path.  When projects proceed through milestone reviews without the artifacts identified in the IRM for their respective development path, they do so under a tailored plan consistent with the practice also outlined in the IRM guidance.  A deviation from standard development path, or tailored plan, can be allowed through normal risk-based decision processes (e.g., either executive or governance decisions) with supporting documentation.

Office of Audit Comment:  The TIGTA found that the IRS’s project tailoring plan contained the artifacts from the IRM and was not subsequently updated to include an updated artifact based on the Iterative Path approach.  As a result, the TIGTA maintains that the IRM needs to be updated to make the guidance more effective in managing projects following the Iterative Path.  Until the IRM guidance can be revised during the next annual update cycle, the IRS should consider sending out additional guidance based on lessons learned.

Interface Control Documents and the Integrated Master Schedule Do Not Comply With All Enterprise Life Cycle Criteria

The ELC is the approach used by the IRS to manage and implement business change through information systems initiatives.  The ELC provides the direction, processes, tools, and assets necessary to accomplish business change in a consistent and repeatable manner.  An objective of the ELC is to help ensure project and program success by reducing risk and ensuring compliance with applicable internal and external standards and mandates.

Interface Control Documents did not always meet established standards

The Interface Control Document is an agreement among multiple organizations that must collaborate to produce a solution regarding design of the interface.  The CADE 2 Database Implementation Project team completed three Interface Control Documents for Milestone 4a:

·         Daily Processing and Database Implementation.

·         Database Implementation and Integrated Production Model. 

·         Database Implementation and Integrated Data Retrieval System.

Although all of the Database Implementation Interface Control Documents contained the proper approvals, the documents did not always meet ELC standards.  For example, key document elements were either missing or did not provide the necessary details describing the interface processes, and specific interface controls for error handling performed by the interfaces were not provided.  The Database Implementation Project manager stated that error checking will be performed on each side of the two interfaced systems.  The interface-related errors should be included in the Database Implementation Interface Control Document, but the engineering team decided they would include this information only in the DSRs.  Also, there was no information on interface issues.  Project management stated that all of the design issues were kept in a separate document on the Project SharePoint site and issues were addressed during two Customer Technical Reviews.

Although the Interface Control Documents included capacity and performance requirements, there was no mention of service-level, operational-level, or any other type of agreement as required by the ELC.  The purpose of these types of agreements is to ensure that coordination efforts are well understood and there are no missing gaps.  Project management stated that they coordinated with the ELC Program Management Office in preparing the Database Implementation Interface Control Documents.  The Service Level Agreement is required for a system to communicate with an external (non-IRS) system.  It is not required for an IRS system to communicate with another IRS system.  Usually, the Memorandum of Understanding or Uniform Work Request is used within the IRS.  The process owner of the Interface Control Documents advised they never complete the Service Level Agreement in the Interface Control Document for internal systems.  Also, for CADE 2, they are creating a Master Service Level Agreement for the Enterprise Informatica Platform, which would cover the Database Implementation Project.  This is inconsistent with the ELC and IRS procedures that provide for the use of operational agreements for an IRS system communicating with another IRS system. 

Further, references in the Interface Control Documents were not current.  Older versions of design documents were provided in the References section of the document and referenced throughout the document when a more current version existed.  For example, when we reviewed the Interface Control Documents for specific details on interface controls for error handling, the documents referenced an older version of the Daily Processing DSR.  Project management stated that this occurred because the Database Implementation Project had focused a lot on the content and forgot to update the References section. 

When the Interface Control Documents have missing or insufficient information, an end-to-end view of the interface process cannot be obtained and there is no assurance that systems have been adequately designed to ensure interface implementation testing.

Management Action:  In June 2011, the Database Implementation Project team improved the Interface Control Documents by including previously omitted items and up-to-date references. 

Work Breakdown Structure is not complete

The CADE 2 Database Implementation Project team did not adhere to all ELC criteria with regard to defining and maintaining the Integrated Master Schedule (IMS).  The IMS contains a Work Breakdown Structure (WBS).  The WBS is a project management tool used to define and group a project’s individual work elements (or tasks) in a way that helps organize and define the total work scope of the project.  In conjunction with the Database Implementation Project team’s decision to follow the ELC Iterative Path, they used a methodology called “rolling wave,” which is a project management technique that involves progressive elaboration to add detail to the WBS on an ongoing basis.  At the beginning of the project, near term deliverables are decomposed into individual components and defined at the greatest level of detail.

The Project team indicated that they did not have sufficient knowledge at project inception to accurately define and develop the WBS.  IRS guidelines recognize the inherent challenges with building a project WBS that incorporates the entire lifecycle of the project, noting that a project WBS represents the scope of the project from beginning to end, to the best of the team’s ability at the time of creation.  IRS guidelines further state that the detailed decomposition of WBS elements is often not known during the initial creation of the project WBS.  It is acceptable to leave these generic WBS elements in the project WBS without further decomposition.  It is important to reflect them in the WBS from the beginning to provide visibility to the entire scope of the project.  

The Database Implementation Project Tailoring Plan contains deliverables identified through Milestone 5 (project completion) that are not reflected in the initial WBS or subsequent iterations through Milestone 4a.  To comply with the Modernization and Information Technology Services organization’s Work Breakdown Structure Template Tailoring Procedure, the initial WBS should have reflected all of the deliverables identified in the WBS Tailoring Plan through Milestone 5.  We previously reported this same condition in our review of the CADE 2 Program Management Office[14] and recommended that the Chief Technology Officer ensure the IMS includes all key activities associated with the development and deployment of the CADE 2 System, including the Database Implementation Project.

Development of a comprehensive WBS is a critical factor for project success.  Equally as important is performing regular status updates as well as schedule analysis.  IRS guidelines recommend these activities be conducted weekly and require they be done no less than twice a month.  While the Database Implementation Project monitored the critical path on a weekly basis, the naming conventions of the deliverables/activities in the weekly Critical Path Summary report were not consistent with the naming conventions in the IMS.  This may be attributed to the fact that the IMS is in a different format from the Critical Path Summary report.  Discrepancies in naming conventions make it difficult to reconcile the activities on the Critical Path Summary report.  Delays in completing activities on the critical path can impede the January 2012 scheduled deployment date.

Management Action:  In July 2011, The IRS updated the Database Implementation section of the IMS for Milestone 4b to mitigate the differences in naming conventions.  Specifically, the IRS added a column on the Critical Path/Key Task Summary called “IMS Unique Identifier, i.e., UID” to further clarify and cross-reference the tasks contained in the Critical Path Summary in relation to the IMS. 

Recommendations

The Chief Technology Officer should:

Recommendation 3:  Ensure future versions of the Database Implementation Project’s Interface Control Documents meet ELC standards by including accurate and adequate information on document references, interface controls, error handling, and issues.

Management’s Response:  The IRS agreed with this recommendation.  The Database Implementation Project’s Interface Control Documents use templates that meet ELC standards.  Improvements have been made to Interface Control Documents for Milestone 4a to include previously omitted items and up-to-date references.

Recommendation 4:  Ensure that the Interface Control Document guidance on Service Level Agreements is consistent with processes being followed by the project.

Management’s Response:  The IRS agreed with this recommendation.  The Associate Chief Information Officer, Enterprise Services, will review and clarify the Service Level Agreements section of the Interface Control Document guidance.

Recommendation 5:  Ensure that appropriate and consistent naming conventions are used in future IMS and related documents to ensure activities can be traced between these documents.

Management’s Response:  The IRS agreed with this recommendation.  To mitigate this in future milestones, starting in Milestone 4b, the IRS has included a column on the Critical Path/Key Task Summary called “IMS UID,” which will clarify and cross-reference the tasks contained in the IMS.

 

Appendix I

 

Detailed Objective, Scope, and Methodology

 

The overall objective of this audit was to review the preliminary and detailed designs[15] of the CADE 2 database[16] and ensure that the database is designed in a secure manner, the design satisfies the stated requirements, and project management practices adhere to ELC standards and processes for the related design milestones.  There were tests that we could not perform because the activity was moved to Milestone 4b, which was outside the scope of this review.  To accomplish our objective, we:

I.                   Reviewed the ETL controls for ensuring the accuracy and completeness of the CADE 2 database.

A.    Interviewed project staff to obtain an understanding of plans for creating and updating the CADE 2 database and controls for ensuring data accuracy and completeness.

1.      Discussed any gaps or missing requirement areas (i.e., contingency planning, incident response, disaster recovery, etc.) and their impact.

2.      If not indicated in the documents reviewed in I.B. below, determined how business rules and the tax code will be maintained.

B.     Identified and reviewed key design documents.

C.     Using information obtained in I.A. and I.B. and other supporting documentation, assessed whether design plans are consistent with the stated requirements.

D.    Determined if identified database ETL issues were resolved, including issues identified from prototyping efforts.

1.      Reviewed ETL prototype status reports, the CADE 2 database ETL prototype and the CADE 2 Database Performance Test Prototype Final Report, version 1, dated October 2010, to identify outstanding issues.

2.      Obtained documentation on the resolution of outstanding issues, including Engineering Alternative Analysis Reports (i.e., the CADE 2 ETL Performance Alternative Analysis Report, dated September 2010).

E.     Determined if the Database Implementation Project will meet projected time periods for initializing the database trial initializations.

F.      Determined to what extent the Project has addressed the dependency upon the development of business rule sets/rules for addressing the IMF data transformation and data quality issues and anomalies.

II.                Determined if systems and interfaces affected by Database Implementation have been adequately addressed to minimize system impact.

A.    Interviewed Project staff to obtain an understanding of the work performed to adequately address Database Implementation-affected systems and interfaces and related Project dependencies.

1.      Identified supporting integration analysis, design, and testing documentation.

2.      Identified any issues from reliance on existing legacy design documentation for the affected systems (e.g., Programming Requirements Package, Functional Specification Package, Core Record Layout, etc.).

B.     Determined if Interface Control Documents exist for all Database Implementation interface systems (Daily Processing, the Integrated Data Retrieval System, and the Integrated Production Model) and are adequately designed to ensure interface implementation testing.

C.     Evaluated interface processing controls (including inputs/outputs) to ensure that system interfaces are secure.

D.    Determined if the IMS dependencies on other subordinate schedules and Project dependencies on Delivery Partners are properly managed.

III.             Determined if the appropriate security and privacy controls had been considered and timely included in the CADE 2 Database Implementation design.

A.    Interviewed Program and Project management staff to determine if Project staff and Cybersecurity office personnel were involved in the development of security and privacy controls.

B.     Reviewed security and privacy documentation at the Program and Project levels to identify the controls applicable to Database Implementation.  Documents reviewed at the Program level included:  Security Framework, Security Strategy, and Privacy Strategy.  Documents reviewed at the Project level included the Business System Report, DSR, Privacy Impact Assessment, and System Security Plan.

C.     Using information obtained in III.A., III.B., and the WBS, determined if security deliverables were completed timely and, if not, assessed the effect.

D.    Reviewed the security categorization criteria prescribed by Federal Information Processing Standards Publication 199[17] and National Institute of Standards and Technology Special Publication 800-60[18] and determined if the security categorizations the IRS assigned to the CADE 2 Database Implementation are documented and supported.

E.     Reviewed the Database Implementation System Security Plan for Milestones 3 and 4a.

F.      Reviewed the Privacy Impact Assessment to ensure that privacy protection is considered in the design.

IV.             Determined if Project management practices adhere to ELC standards and processes for the related design milestones.

A.    Determined if a Project Charter exists that clearly defines the scope, vision, system objectives, and potential impact on organizational culture and existing processes.

B.     Determined if a Project plan was created to manage system design project efforts and is properly updated.

1.      Reviewed the Database Implementation Project Management Plan to ensure it has been properly updated.

2.      Reviewed the WBS and identified if Project time periods were defined and achieved, critical phases were present, and management approvals were present.

C.     Determined if Project risks were assessed and appropriately mitigated.

D.    Determined if there are well-defined system requirements by reviewing requirements management documentation obtained from the CADE 2 Program Management Office team and Project-level system requirements documentation.  Also, we determined if requirements were analyzed for compliance with Federal Government regulations, internal control policies, and security procedures and if requirement approval is formally documented by all key stakeholders and by governance or steering committees.  

E.     Determined if requirement changes are controlled by evaluating if changes to system requirements are verified.

F.      Determined what metrics are used for assessing Project quality assurance by reviewing the CADE 2 Program Performance and Quality Management Plan and related documentation.

G.    Evaluated contingency planning efforts to ensure all Project contingencies are properly addressed.

Internal controls methodology

Internal controls relate to management’s plans, methods, and procedures used to meet their mission, goals, and objectives.  Internal controls include the processes and procedures for planning, organizing, directing, and controlling program operations.  They include the systems for measuring, reporting, and monitoring program performance.  We determined the following internal controls were relevant to our audit objective:  the ELC and related IRS guidelines and the processes followed in the development of information technology projects.  We evaluated these controls by conducting interviews and meetings with management and staff, attending CADE 2 meetings of the Program and Project teams, and reviewing Project documentation such as the Project Charter, various Project plans, and other documents which provided evidence of whether ELC systems development processes were followed.

 

Appendix II

 

Major Contributors to This Report

 

Alan R. Duncan, Assistant Inspector General for Audit (Security and Information Technology Services)

Diana M. Tengesdal, Acting Director

Kimberly R. Parmley, Audit Manager

K. Kevin Liu, Acting Audit Manager

Esther M. Wilson, Lead Auditor

Jena R. Whitley, Senior Auditor

David F. Allen, Program Analyst

Michael T. Mohrman, Information Technology Specialist

 

Appendix III

 

Report Distribution List

 

Commissioner  C

Office of the Commissioner – Attn:  Chief of Staff  C

Deputy Commissioner for Operations Support  OS

Deputy Commissioner for Services and Enforcement  SE

Chief, Agency-Wide Shared Services  OS:A

Commissioner, Wage and Investment Division  SE:W

Deputy Chief Information Officer for Strategy/Modernization  OS:CTO

Associate Chief Information Officer, Modernization Program Management Office  OS:CTO:MP

Chief Counsel  CC

National Taxpayer Advocate  TA

Director, Office of Legislative Affairs  CL:LA
Director, Office of Program Evaluation and Risk Analysis  RAS:O

Director, Risk Management Division  OS:CTO:SP:RM

Office of Internal Control  OS:CFO:CPIC:IC

Audit Liaisons:

Commissioner, Wage and Investment Division  SE:W:S:PEI

Director, Risk Management Division  OS:CTO:SP:RM

 

Appendix IV

 

Enterprise Life Cycle Overview

 

The ELC is the IRS’s standard approach to business change and information systems initiatives.  It is a collection of Program and Project management best practices designed to manage business change in a successful and repeatable manner.  The ELC addresses large and small projects developed internally and by contractors.

The ELC includes such requirements as:

In addition, the ELC improves the IRS’s ability to manage changes to the enterprise, estimate the cost of changes, and engineer, develop, and maintain systems effectively.  Figure 1 provides an overview of the phases and milestones within the ELC.  A phase is a broad segment of work encompassing activities of similar scope, nature, and detail and providing a natural breakpoint in the life cycle.  Each phase begins with a kickoff meeting and ends with an executive management decision point (milestone) at which IRS executives make “go/no-go” decisions for continuation of a project.  Project funding decisions are often associated with milestones.

Figure 1:  Enterprise Life Cycle Phases and Milestones

Phase

General Nature of Work

Milestone

Vision and Strategy/
Enterprise Architecture Phase

High-level direction setting.  This is the only phase for enterprise planning projects.

0

Project Initiation Phase

Startup of development projects.

1

Domain Architecture Phase

Specification of the operating concept, requirements, and structure of the solution. 

2

Preliminary Design Phase

Preliminary design (logical design) of solution components.

3

Detailed Design Phase

Detailed design (physical design) of solution components.

4A

System Development Phase

Coding, integration, testing, and certification of solutions.

4B

System Deployment Phase

Expanding availability of the solution to all target users.  This is usually the last phase for development projects.

5

Operations and Maintenance Phase

Ongoing management of operational systems.

System Retirement

Source:  The Enterprise Life Cycle Guide.

 

 

Appendix V

 

Customer Account Data Engine 2
Integrated Design Reviews

 

Integrated Review

Outcomes

Deep Dive Logical Design Review (3 Part)

September 28, 2010 October 3, 2010

The Deep Dive Logical Design Review validates that proposed project solutions are sound and adhere to the CADE 2 Program design principles and the CADE 2 Program Roadmap and Architectural Components.

Integrated Logical Design Review

November 2010

The Integrated Logical Design Review validates that the project-level designs support the solution’s logical implementation as defined in the Program Roadmap and that the projects collectively will deliver an integrated and cohesive solution.

End-to-End Logical Design Review

December 2010

The End-to-End Logical Design Review gains leadership and oversight confidence that the solution will be successful and captures any
Milestone 3 Logical Design issues and action items.

CADE 2 Database Implementation End-to-End Physical Design Review

February 2011

The CADE 2 Database Implementation End-to-End Physical Design Review provides an understanding of the Database Implementation DSR and Interface Control Documents key components and gains knowledge of what is included in each section of the documents for the stakeholder review.

CADE 2 Transition State 1 Physical Design Review

April 2011

The CADE 2 Transition State 1 Physical Design Review gains confidence that the Transition State 1 solution will be successful, captures any Milestone 4a Physical Design issues and action items, and ensures common understanding of next steps in Milestone 4b.

Source:  The IRS CADE 2 Integrated Design Review Documentation.

 

Appendix VI

 

Customer Account Data Engine 2 Transition Strategy

 

Figure 1:  Description of CADE 2 Transition Strategy Achievements and Goals[19]

State

Business Achievement

Architectural Achievement

Related Program Goal

TS 1

·   Reduced risk and cost of operating two environments for individual taxpayer account processing.

·   Timelier response to taxpayers with refunds, notices, and information.

·   Reduction of manual processes related to weekly processing of individual taxpayer accounts.

·   Target database deployed and proven to accept all current-state account conditions.

·   Target database provides source for online viewing.

·   Target database used to feed critical downstream functions, establishing target-state architectural pattern for bulk data distribution.

·    Move to relational database processing that provides a solid data foundation for the future and away from sequential, flat-file processing.

·    Demonstrate substantive progress toward achieving long-term viability.

o Complete migration of data from current CADE and IMF into a single, complete relational database.

o Create opportunities for new enforcement and service business processes that rely on a more complete, reliable database.

TS 2

·   Financial material weaknesses associated with individual taxpayer account processing addressed.

·   Target application framework developed and deployed.

·   Target technology framework developed and deployed.

·    Address financial material weaknesses, demonstrate compliance with Federal Financial Management System Requirements, and maintain a clean audit opinion.

·    Improve security and privacy posture by addressing critical weaknesses with the core tax account processing application.

Target

·   To improve business processes that rely on timely and accurate individual taxpayer account information.

·   Target applications completed.

·   Transitional components retired.

·    Continue the focus on moving away from 1960’s technology (i.e., aging infrastructure and applications).

Source:  The IRS CADE 2 Academy, Program, Strategies, Architecture and Transition, January 2011.  Note:  TS = Transition State.

 

 

Figure 2:  Flow Chart of the CADE 2 Transition Strategy

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

 

Appendix VII

 

Database Implementation
Design Issues in Pending Status

 

Title

Description

Target Date

Mapping Transformation Rules to Informatica Implementation Details

Document in the Database Implementation Design Specification Report that describes how Informatica mappings apply the transformation rules, as well as how complexity, performance, and reusability are addressed.

Provides a description of the transactional boundaries for both a logical unit of work (e.g., accounts and modules) and the operational units of work (e.g., commit intervals).

5/31
on target

Residual Current CADE Data (Dependency)

The current design has not been completed for physical design of the retention and printing of Government Accountability Office transcripts in the current CADE database.

5/31
on target

Integrated Production Model Design (Dependency)

Various areas of the design cannot be finalized until the Integrated Production Model design is finalized.

5/31
on target

Process Automation and Monitoring Design

Finalize documentation of physical design for the Process Automation and Monitoring.

Closed on 5/6

Source:  The IRS CADE 2 Milestone 4a Design Pending Issues, dated May 11, 2011.

 

Appendix VIII

 

Glossary of Terms

 

Term

Definition

Balance and Control

Refers to the overall mechanism for accumulating and checking counts and amounts to ensure overall processing integrity.

Business Rule

A statement that defines or constrains some aspect of the business (see Business Rule Set).

Business Rule Set

A group of business rules related to a common topic or business decision.

Business System Report

A document containing the end-state vision and solution concept, the architecture, and the requirements analysis that form the basis for subsequent solution design, development, integration, testing, and deployment of the system.  This document is comprised of three principal sections:  Business Systems Concept, Business System Architecture, and Business System Requirements.

Corporate Files On‑Line

A system that provides online transactional access to IMF and Business Master File data, Information Return Program data, and various other related data collections.  These files are accessed via IRS-developed Customer Information Control System command codes.

Current Processing Environment

The IRS’s existing entire information technology environment including business applications, data stores, data interfaces and processing flows, infrastructure, and information technology services, as well as involved organizations, locations, processes, policies, and people.

Customer Account Data Engine

A major component of the IRS modernization program.  The system consists of current and planned databases and related applications that work with the IRS Master File system (see Master File below).

Customer Account Data Engine 2 Program Roadmap

Defines the Program’s approach for delivering the Customer Account Data Engine 2 (CADE 2) solution and describes the path from the current state to the target state through the identification and definition of Program Transition States.  

Customer Technical Review

One of the features in the Solution Layer of the ELC Framework.  A Customer Technical Review is a review performed by IRS stakeholders on an artifact or a small group of closely related artifacts produced by a project with the purpose of facilitating approval of the artifact by ensuring early stakeholder feedback as well as early identification and resolution of issues and actions.

Daily Processing Project (CADE 2)

Planned to modify affected tax processing systems and applications to accomplish daily processing of individual taxpayer accounts.

Database

An application that manages data and allows fast storage and retrieval of that data.

Design Specification Report

Documents the application design, data design, technical infrastructure, and traceability to the requirements.  It also describes the design based on a defined scope and the business system requirements that are described in the CADE 2 Project Charter, the CADE 2 Database Implementation Business System Report, and the CADE 2 Program Roadmap.

Enterprise Architecture

A unifying overall design or structure for an enterprise that includes business and organizational aspects of the enterprise as well as technology aspects.  Enterprise Architecture divides the enterprise into its component parts and relationships and provides the principles, constraints, and standards to help align business area development efforts in a common direction.  An Enterprise Architecture ensures that subordinate architectures and business system components developed within particular business areas and multiple projects fit together into a consistent, integrated whole. 

Enterprise File Transfer Utility

Provides point-to-point file transfers and store-and-forward transfers within the IRS firewalls between systems in the Modernized environment, between Current Production Environment systems, and between Modernized and Current Production Environment systems.

Enterprise Life Cycle

A structured business systems development method that requires the preparation of specific work products during different phases of the development process.  

Error Handling System

System that collaborates the handling of production errors.

Extract, Transform, and Load (ETL)

The processes that enable the data from multiple sources to be moved, cleansed, and loaded into another database, a data mart, or a data warehouse for analysis or on another operational system to support a business process.

Individual Master File

The IRS database that maintains transactions or records of individual tax accounts.

Informatica

A comprehensive, open, unified, and economical data integration platform that supports all five steps in the data integration life cycle.  It sustains all roles involved in data integrationdata stewards, data analysts, architects, administrators, and developers.

Infrastructure

The fundamental structure of a system or organization.  The basic, fundamental architecture of any system (electronic, mechanical, social, political) determines how it functions and how flexible it is to meet future requirements.

Initialization

Initial population of the CADE 2 database primarily from IMF data.

Integrated Data Retrieval System

The IRS computer system capable of retrieving or updating stored information; it works in conjunction with a taxpayer’s account records.

Integrated Production Model

Intended to be a data store to meet IRS needs for data analytics and long-term reporting and as a source for other types of analytic data that supplement the transactional core data store.

Interface Control Document

An ELC artifact documenting an agreement between two (or more) parties used to define and gain consensus on an interface between systems, subsystems, or system components developed by different groups.

Logical Design

The second of two-stage components of the Preliminary Design Phase in the System Life Cycle Layer of the ELC Framework.  Completes the logical design from all perspectives, including logical design of applications.

Master File

The IRS database that stores various types of taxpayer account information.  This database includes individual, business, and employee plans and exempt organizations data.

Milestone

Scheduled time period for providing a “go/no-go” decision point in a program or project and can be associated with funding approval to proceed.

Milestone Exit

Checkpoint formalizing the conclusion of a Milestone.

National Institute of Standards and Technology

A nonregulatory Federal agency, within the Department of Commerce, responsible for developing standards and guidelines, including minimum requirements, for providing adequate information security for all Federal Government agency operations and assets.

Phase

Broad segment of work encompassing activities of similar scope, nature, and detail and providing a natural breakpoint in the life cycle.

Preliminary Design Phase

One of the phases in the System Life Cycle Layer of the ELC Framework.

Privacy Impact Assessment

An analysis of how information is handled to:  1) ensure handling conforms to applicable legal, regulatory, and policy requirements regarding privacy; 2) determine the risks and effects of collecting, maintaining, and disseminating information in identifiable form in an electronic information system; and 3) examine and evaluate protections and alternative processes for handling information to mitigate potential privacy risks.

Program

A set of projects and other activities undertaken to improve the IRS. 

Project

A group of tasks to accomplish a specific objective with a beginning and ending date that is planned, monitored, and measured; follows a life cycle process; and results in deliverables or end products.

Prototype or Prototyping

Prototyping is the process of quickly putting together a working model (a prototype) in order to test various aspects of a design, illustrate ideas or features, and gather early user feedback.  Prototyping is often treated as an integral part of the system design process.

Relational Database

A collection of data items organized as a set of formally described tables from which data can be accessed or reassembled in many different ways without having to reorganize the database tables.  

Requirement

A formalization of a need and statement of a capability or condition that a system must have or meet to satisfy a contract, standard, or specification.

Risk

Identification of a condition that can pose a barrier to the progress or delivery of the project if left unmitigated.

Risk-Based Decision

A decision made by individuals responsible for ensuring security by utilizing a wide variety of information, analyses, assessments, and processes.  The type of information taken into account when making a risk‑based decision may change based on life cycle phase, and a decision is made taking the entire posture of the system into account.  Some examples of information taken into account are formal and informal risk assessments, risk analysis assessments, recommended risk mitigation strategies, and business impact.

SharePoint

A web-based repository that the IRS uses to store and control organizational products and documentation.

Solution Concept

Describes a complete solution for realizing the future state vision that includes all domains of change.

Stakeholders

An individual or organization that is materially affected by the outcome of the system.  Key stakeholders represent both business and technical functions that fully participate in the architecture development effort to ensure that directional guidance is both accurate and sufficient.  These stakeholders are empowered to make project and architectural decisions.  Examples of project stakeholders include the customer, the user group, the project manager, the development team, and the testers.

System

A set of interconnected hardware and programs that the IRS uses to perform certain business functions.

System Concept

Provides a conceptual view of the chosen data, application, and infrastructure (technology) architectures for realizing the
future-state vision.

Transformation Rules

Used by the ETL Program to transform individual taxpayer accounts from IMF flat-file formats and current CADE relational database formats (for the one-time initialization) to the formats and structures defined for the CADE 2 database.

Transition State 1

Specific to CADE 2.  An intermediary state for the CADE 2 system, delivering a set of functionality as defined by the Roadmap and other supporting documents.

 

Appendix IX

 

Management’s Response to the Draft Report

 

DEPARTMENT OF THE TREASURY

INTERNAL REVENUE SERVICE

WASHINGTON, D.C. 20224

 

 

CHIEF TECHNOLOGY OFFICER

 

SEPTEMBER 13, 2011

 

MEMORANDUM FOR DEPUTY INSPECTOR GENERAL FOR AUDIT

 

FROM:                             Terence V. Milholland /s/ Terence V. Milholland

     Chief Technology Officer

 

SUBJECT:                       The Customer Account Data Engine 2 Database Implementation Project Made Progress in Design Activities, but Improvements Are Needed

     (201120002) (e-trak 2011-24436)

 

Thank you for the opportunity to review your draft audit report and to discuss earlier draft report observations with the audit team.

 

I was pleased to read your comments and observations acknowledging our progress on the CADE 2 Database preliminary and detailed design, and, in particular, your team's recognition of the progress made to close performance gaps to meet business requirements for Database daily updates. I also appreciate recognition on how the partnership between the CADE 2 team and the Cyber Security organization has benefited the development of the overall Database Implementation project.

 

As noted in the attached corrective action plan, we have already addressed your recommendation on traceability between the IMS and related documents through the use of naming conventions and unique identification numbers (UID) for cross-referencing.

 

We are committed to continuously improving our information technology systems and processes. We value your continued support and the assistance and guidance your team provides. If you have any questions, please contact me at (202) 622-6800 or Karen Mayr at (202) 283·0015.

 

Attachment

RECOMMENDATION #1:  The Chief Technology Officer should ensure key activities and deliverables (including security deliverables) for the Database Implementation Project are completed timely and, if not, ensure an assessment is made to determine the impact or risk of not completing the required activity.

 

CORRECTIVE ACTION #1:  The IRS agrees with this recommendation. We will ensure key milestone activities and deliverables (including security deliverables) for the Database Implementation Project are completed timely and, if not, ensure an assessment is made to determine the impact or risk of not completing the required activity. If it is determined that there are impacts that put the project at risk, they will be documented and mitigated through our risk process currently in place.

 

IMPLEMENTATION DATE:  January 3, 2012

 

RESPONSIBLE OFFICIAL:  Associate Chief Information Officer, Modernization/CADE 2 PMO

 

CORRECTIVE ACTION MONITORING PLAN:  We enter accepted Corrective Actions into the Joint Audit Management Enterprise System (JAMES). These Corrective Actions are monitored on a monthly basis until completion.

 

RECOMMENDATION #2:  The Chief Technology Officer should ensure the Internal Revenue Manual 2.16.1, Enterprise Life Cycle Guidance, is kept current and includes all artifacts that are needed for projects following the Iterative Path.

 

RESPONSE TO RECOMMENDATION #2:  The IRS disagrees with this recommendation. The Enterprise Life Cycle Guidance in IRM 2.16.1 is already current, and is kept current through an annual update process. The IRM already reflects the artifacts required for projects following the Iterative Path. When projects proceed through milestone reviews without the artifacts identified in the IRM for their respective development path, they do so under a tailored plan consistent with the practice also outlined in the IRM guidance. A deviation from standard development path, or tailored plan, can be allowed through normal risk-based decision processes (e.g., either executive or governance decisions) with supporting documentation.

 

IMPLEMENTATION DATE:  No Action Required

 

RECOMMENDATION #3:  The Chief Technology Officer should ensure future versions of the Database Implementation Project's Interface Control Documents meet ELC standards by including accurate and adequate information on document references, interface controls, error handling, and issues.

 

CORRECTIVE ACTION #3:  The IRS agrees with this recommendation. The Database Implementation Project's ICDs use templates that meet ELC standards. Improvements have been made to ICD documents for MS 4a to include previously omitted items and up-to-date references.

 

IMPLEMENTATION DATE:  Completed May 31, 2011.

 

RESPONSIBLE OFFICIAL:  Associate Chief Information Officer, Modernization/CADE 2 PMO

 

CORRECTIVE ACTION MONITORING PLAN:  We enter accepted Corrective Actions into the Joint Audit Management Enterprise System (JAMES). These Corrective Actions are monitored on a monthly basis until completion.

 

RECOMMENDATION #4  The Chief Technology Officer should ensure that the Interface Control Document guidance on Service Level Agreements is consistent with processes being followed by the project.

 

CORRECTIVE ACTION #4:  The IRS agrees with this recommendation. The ACIO Enterprise Services will review and clarify the Service Level Agreements section of the Interface Control Document guidance.

 

IMPLEMENTATION DATE:  January 3, 2012

 

RESPONSIBLE OFFICIAL:  Associate Chief Information Officer, Enterprise Services

 

CORRECTIVE ACTION MONITORING PLAN:  We enter accepted Corrective Actions into the Joint Audit Management Enterprise System (JAMES). These Corrective Actions are monitored on a monthly basis until completion.

 

RECOMMENDATION #5  The Chief Technology Officer should ensure that appropriate and consistent naming conventions are used in future IMS and related documents to ensure activities can be traced between these documents.

 

CORRECTIVE ACTION #5:  The IRS agrees with this recommendation. To mitigate this in future milestones, starting in MS4b, we have included a column on the Critical Path/Key Task Summary called "IMS UID," which will clarify and cross-reference the tasks contained in the IMS.

 

IMPLEMENTATION DATE:  Completed April 4, 2011

 

RESPONSIBLE OFFICIAL:  Associate Chief Information Officer, Modernization/CADE 2 PMO

 

CORRECTIVE ACTION MONITORING PLAN:  We enter accepted Corrective Actions into the Joint Audit Management Enterprise System (JAMES). These Corrective Actions are monitored on a monthly basis until completion



[1] Enterprise Life Cycle Milestone 3 is the preliminary (i.e., logical) design of all solution components and Milestone 4a is the detailed (i.e., physical) design of solution components.

[2] See Appendix VIII for a glossary of terms.

[3] See Appendix VI for the CADE 2 Transition Strategy.

[4] Prototype Process Improvements Will Benefit Efforts to Modernize Taxpayer Account Administration (Reference Number 2011-20-001, dated November 24, 2010).

[5] The Customer Account Data Engine 2 Program Management Office Implemented Systems Development Guidelines; However, Process Improvements are Needed to Address Inconsistencies (Audit # 201020025), draft report dated August 11, 2011; and The Customer Account Data Engine 2 Is Making Progress Towards Achieving Daily Processing, but Improvements Are Warranted to Ensure Full Functionality (Audit # 201120001), draft report dated August 9, 2011. 

[6] Enterprise Life Cycle Milestone 3 is the preliminary (i.e., logical) design of all solution components and Milestone 4a is the detailed (i.e., physical) design of solution components.

[7] See Appendix V for CADE 2 Integrated Design Reviews.

[8] See Appendix VII for Database Implementation Design Issues in pending status.

[9] Prototype Process Improvements Will Benefit Efforts to Modernize Taxpayer Account Administration (Reference Number 2011-20-001, dated November 24, 2010).

[10] Security risks are based on selected security controls from the Internal Revenue Manual as well as from Recommended Security Controls for Federal Information Systems and Organizations (National Institute of Standards and Technology Special Publication 800-53).

[11] Some decisions regarding the ultimate design of the technical infrastructure, boundary authority, and daily update application architecture components are required in order to define security controls at a sufficient level of detail.

[12] See Appendix IV for an overview of the ELC.

[13] See Appendix VII for the Database Implementation Design Issues in Pending Status.

[14] The Customer Account Data Engine 2 Program Management Office Implemented Systems Development Guidelines; However, Process Improvements Are Needed to Address Inconsistencies (Audit # 201020025), draft report dated August 11, 2011.

[15] Enterprise Life Cycle Milestone 3 is the preliminary (i.e., logical) design of all solution components and Milestone 4a is the detailed (i.e., physical) design of solution components.

[16] See Appendix VIII for a glossary of terms.

[17] Standards for Security Categorization of Federal Information and Information Systems, published February 2004.

[18] Guide for Mapping Types of Information and Information Systems to Security Categories, Volume 1, Revision 1, published August 2008.

[19] See Appendix VIII for a glossary of terms.