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.
Improvements
Are Needed to Ensure Timely Delivery of Key Activities
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 |
|
|
|
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.
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
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/ |
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 |
|
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 |
|
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 |
|
Integrated Production Model Design (Dependency) |
Various areas of the design cannot be
finalized until the Integrated Production Model design is finalized. |
5/31 |
|
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
|
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 integration—data 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 |
|
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.