2.15.1  Enterprise Architecture (EA) Overview (Cont. 1)

2.15.1.2 
Major components and sub-components of the EA

2.15.1.2.3 
Enterprise Target Architecture

2.15.1.2.3.6 
Organization and Location

2.15.1.2.3.6.4  (02-09-2009)
Business Concepts and Operations

  1. IRS Organizations use the business ConOps as a strategic framework in order to express their future state vision. An organization’s ConOps is typically a key driver of changes to any of the six domains of change – organization, location, business process, data, applications and/or technology. The intent of the ConOps framework is to:

    • Conceptualize a holistic future state of an organization based on organizational and technological changes

    • Focus on the future state defined as five years out and beyond

    • Outline the key areas of change between the current and future states

    • Provide high level strategic goals from which actionable goals can be derived

    • Identify the capabilities necessary for achieving the future state

    • Provide a high-level assessment of the impact of the future state changes to the organization

    • Outline potential areas of process change

    • Depict examples of how the organization will operate in the future state A typical business ConOps contains many components. Some of the key components include vision, mission, strategic objectives goals and scenarios.

    • An organization’s vision and mission guide it towards the future state while supporting the IRS enterprise.

    • Strategic Objectives provide key focus areas that describe the differences between the current and future environments.

    • Scenarios are examples that illustrate the way the organization will operate in the future and reflect the main differences between the current and future states. They begin to show some of the key functions and processes that an organization will employ.

2.15.1.2.3.7  (02-09-2009)
Data

  1. The IRS EA defines both an Enterprise Conceptual Data Model (ECDM) and an Enterprise Logical Data Model (ELDM). Each is described in more detail in the following subsection but both pertain to organizing the data needed for the administration of the business of the IRS. The IRS EA also provides an Information Dictionary -- which incorporates a Glossary of IRS Business Terminology, a comprehensive Glossary for the EA, and a list of acronyms used throughout the EA.

2.15.1.2.3.7.1  (02-09-2009)
Information Dictionary

  1. The IRS EA Information Dictionary is divided into three parts:

    • The Glossary of IRS Business Terminology is limited to specialized definitions of IRS business terminology, and supports key areas of the IRS Enterprise Architecture directly traceable to the Business Processes specified in Volume 3.

    • The Glossary defines all other terminology used in the Enterprise Architecture.

    • The Acronyms List defines acronyms used in the EA.

    These two glossaries are intended to be mutually exclusive. If a term does appear in both, the definition in the Glossary of IRS Business Terminology has precedence. The complete and detailed dictionaries can be found at the EDMO website (http://mits.web.irs.gov/ES/SI/EDMO/default.htm.)

2.15.1.2.3.7.2  (02-09-2009)
Conceptual and Logical Data Model

  1. The Enterprise Conceptual Data Model (ECDM) is a high level view of non-transient data needed for the administration of the business of the IRS. The ECDM model within the IRS EA shows the classes of objects about which the IRS chooses to store data. Modeling of the details of each data class is not part of this model, but will be done in the logical data modeling. For the IRS, this conceptual model states that the IRS receives tax returns from taxpayers, but without defining the precise and complete list of what information should be stored about a taxpayer or a return. Such detail is the content of a logical model. The IRS EA presents the model as a series of data class diagrams, drawn using the Unified Modeling Language (UML) notation. Data models of more than a few data classes are organized as a hierarchy of subject areas, each more narrowly defined than the subject area containing it, until they are small enough to allow comprehension of the entire subject area in a diagram or two. The entire ECDM consists of 248 data classes shown in 34 diagrams. The ECDM is organized into three top-level subject areas, each of which also divides into three subject areas. (It is a coincidence that each unit is trisected.) The three top-level areas are:

    • Transaction Data. The data the IRS receives and works with in its day-to-day processing of individual transactions.

    • Analysis Data. The business data, summarized and reorganized for reporting and broad views of types and trends.

    • Knowledge Management (KM) Data. Documents and data about how the IRS does business.

    A logical data model takes the conceptual model down a level of detail to the concerns of technical staff rather than the business users. A logical data model is a complete account of the data required by an organization or business area. Complete means not only that there are data classes for each person, place, thing, event, and concept about which the business wishes to store data, but also that the classes have attributes for each fact the business wishes to store. The model is fully attributed and denotes the structure of the data. Tradeoffs for practicality and the limitations of technology are considered in the physical modeling. At this time, the ELDM consists of over 325 data classes, over 1,000 attributes, and over 400 relationships, shown in 64 diagrams. As an example, to further break down the Transactional area of the ECDM, the ELDM would show this high level detail:

    • Taxation Management Data. Consisting of parties and taxpayers; returns, applications and forms; remittances; taxpayer accounts; cases and case resolutions; and tax fraud activity.

    • Customer Management Data. Consisting of third parties and customers; third party businesses; customer communications; tax education and guidance; and external criminal investigation.

    • Internal Management Data. Consisting of human resources; workload and workflow management; performance management and improvement; asset management; financial management; and information tech management.

    The complete ECDM and ELDM can be found at the EDMO website (http://mits.web.irs.gov/ES/SI/EDMO/default.htm.)

2.15.1.2.3.7.3  (02-09-2009)
Data Architecture

  1. The data architecture component of the EA addresses the key principles that affect the way that projects create and use data. Data architecture in the EA covers the following areas:

    • Data storage and management

    • Data modeling, categorization and relevant subject areas

    • Data access standards and strategies

    • Authoritative data definitions and guidelines

    • Data resources and technologies, including metadata and XML

    • Data stewardship

    The complete and detailed description of the data architecture for each area can be found at the EDMO website (http://mits.web.irs.gov/ES/SI/EDMO/default.htm.)

2.15.1.2.3.8  (02-09-2009)
Application and Technology

  1. The Application and Technology in EA covers the following areas:

    • Conceptual Technology Architecture

    • System Architecture

    • Technical Architecture

    • Application Architecture

    • Security Architecture

    • System Management Architecture

    • IRS Logical System Architecture

    • Technical Guidance and Design Pattern

    • Service Repository

    • Service Oriented Architecture

2.15.1.2.3.8.1  (02-09-2009)
Conceptual Technology Architecture

  1. The technology architecture of the EA represents the hardware, system software, and network components needed to support the implementation of business system applications and application data. The technology architecture model view of the ELC represents the physical platforms and technical infrastructure that supports the operation and use of applications and data in the IRS.

  2. The goal of the technology architecture is to define common technology model principles that affect all projects, and to encourage and enforce commonality and re-use across conceptual, logical and physical model views of supporting technology.

  3. In general, the IRS EA presents a multi-layer technology architecture. This supports a services approach that complies with the layered approach specified in the TRM. Much of the detailed architecture guidance around the technology architecture is provided in the IRS TRM manual. The TRM describes the technologies that will be assembled into a system to support the IRS Enterprise applications processing requirements.

2.15.1.2.3.8.2  (02-09-2009)
System Architecture

  1. The Systems Architecture is presented in two logical sections:

    • System Requirements items

    • System Design items

  2. The System Requirements items detail the needs identified during a comprehensive systems analysis. It comprises the following seven topics:

    • Programmatic requirements

    • Data requirements

    • Functional requirements

    • Traceability of data and functional requirements to business processes

    • Performance requirements

    • Security and requirements

    • System management requirements

    • Technical Requirements

  3. The System Design items provides a high-level description of the design of the systems needed to satisfy the functional, performance, security and privacy, and system management requirements detailed in the System Requirements . It comprises the following three topics:

    • IRS Logical System Architecture </ li>

    • Processing Threads

    • System Interfaces

2.15.1.2.3.8.3  (02-09-2009)
System Interfaces

  1. The IRS EA specifies the external and internal system interfaces. However due to the high-level nature of the EA, this discussion is limited to identification of the information exchanged on each system interface. Within this context, Communications Services discusses the network infrastructure elements and the technology needed to support the System Interfaces, and Enterprise Services discusses specific services supporting the System Interfaces.

2.15.1.2.3.8.4  (02-09-2009)
Technical Architecture

  1. The IRS EA provides a detail description of the IRS TRM layers and interfaces, incorporating graphical detail depicting the IRS Enterprise Target Systems architecture. This description is intended to guide IRS projects in achieving and demonstrating their compliance with the Enterprise Architecture. The description is divided into following set of document segments, which are defined according to the IRS TRM Layers and Interfaces

    • Physical Infrastructure

    • Communication Services

    • Platform and Platform Services

    • Enterprise Services

    • Applications

    • Enterprise Security Services

    • Enterprise Systems Management

    • Technical Requirements

2.15.1.2.3.8.5  (02-09-2009)
Application Architecture

  1. The IRS EA provides an overview of the Technical Architecture from the perspective of the three technical views in the Enterprise Lifecycle (ELC) methodology. It provides high-level perspectives of the application architecture, the data architecture, and the conceptual technology architecture views. While the business architecture covers concepts related to business process, organization, and location, the technical architecture covers concepts and strategies related to data, applications, and technology. The ELC Domains of Change view of the EA is really a summarization of all the technical components of the EA as they guide the development of systems. Business drivers defined in the business architecture lead to the elaboration of functional and technical requirements. These are then used to develop a set of abstract systems, which in turn define a set of conceptual target-state applications that manage enterprise data on enterprise-approved technology platforms. The common architecture decisions for technology, application, and data model views (that is, the Technical Architecture) are documented in the Application Architecture (Official Use Only), Data Architecture, and Conceptual Technology Architecture models provided by the EA. The goals of defining these common decisions are to:

    • Ensure that projects deliver functionality that can be integrated and maintained in the IRS environment

    • Ensure that projects that develop application services can make certain of these services available to other IRS business systems in order to promote re-use of application functionality and to eliminate duplication of effort and redundant data

    • Ensure that projects take advantage of common infrastructure services in order to get maximum return on investment from a shared infrastructure environment, reduce redundant infrastructure, and enhance the use of common security, privacy, services management, and services delivery policies

2.15.1.2.3.8.6  (02-09-2009)
Security Architecture

  1. The Security Architecture models (work products) contained within the EA describe major security aspects of IRS logical business systems of the IRS Enterprise Target Architecture (ETA). There are two such models:

    • Allocation of Security Mechanisms to System Components: allocates the security mechanisms specified in the Security Requirements model to system components identified in the IRS Logical Business Systems / Allocation of Functional and Data Requirements to Systems model. (Each mechanism corresponds to one or more security requirements specified in the Security Requirements model.)

    • Security Processing Thread: shows the exercise of identification and authentication, access control, and audit mechanisms—both in the infrastructure and in an application—in a representative scenario

    While the first model shows the form of the systems security architecture, the second model shows something of its behavior. (For a list of other models of the security architecture view, see the Security Requirements Section.

    • Security Risk Assessment:: estimates the relative degree of security risk associated with major target system components

2.15.1.2.3.8.7  (02-09-2009)
Security Risk Assessment

  1. The EA provides a security risk assessment model that supports the Enterprise target systems security architecture. Specifically, this risk assessment estimates the relative degree of security risk associated with major system components. Two risk estimates are given: (1) for the component unprotected by any security mechanisms and (2) for the component protected by the security mechanisms described in the Allocation of Security Mechanisms to System Components model of the Security Architecture.

2.15.1.2.3.8.8  (02-09-2009)
System Management Architecture

  1. The IRS EA discusses Enterprise System Management (ESM) as the basis for designing and deploying a complete systems management capability at the IRS. This discussion supplies guidance regarding:

    • ESM core function details

    • Mechanisms deployed to provide ESM core functions

    • The allocation of ESM mechanisms to system components

    The need for systems management is not limited to any specific platform, system, or application types, but rather, extends to all platforms, systems, and applications that are deployed at the IRS. The inclusion of all systems components in the management solution is vital to ensure a consistent, cost-effective, and highly available operating environment. It is understood that no single tool will likely be capable of performing all ESM functions for all platforms and components. A complete solution is likely to be composed of a collection of well-integrated products that each provides a subset of the ESM mechanisms. It also is likely that the tools that are deployed may vary from one platform type to another. However, regardless of the breadth of management products that are selected for deployment at the IRS, all must conform to a common set of operational policies and procedures, and all must be very closely integrated. These operational policies and procedures must be well defined and, in most cases, captured in the IRS Systems Standards Profile (SSP). ESM mechanisms will be used to execute and enforce most of these policies and procedures.

2.15.1.2.3.8.9  (02-09-2009)
IRS Logical Systems Architecture

  1. In the IRS EA, logical systems are defined across the Enterprise. As appropriate, Enterprise Functional Requirements and Data Requirements are allocated to these systems. The EA defines and describes allocation of functional and data requirements to systems. In addition, the EA provides:

    • Tables of Functions – Systems Allocations

    • Tables of Data Classes – Databases Allocations

    • Tables of Service Entities – Systems Allocations

    • ECBSs/ECTSs Mapped to Technical Services and Traceability to Other EA Elements

    • Business Services in the Service Repository Mapped to Domains and Projects/Source

2.15.1.2.3.8.10  (02-09-2009)
Technical Guidance and Design Patterns

  1. The EA Guidance document provides guidance and practical reference for developers who are developing applications in compliance with the IRS Enterprise Architecture (EA). EA Guidance documents include Enterprise Data Standards and Guidelines (EDSG), Service-Oriented Architecture (SOA) Guidance, .NET Guidance, and Design patterns.

2.15.1.2.3.8.11  (02-09-2009)
Service Repository

  1. The IRS Online Service Repository captures the list of services and their descriptions contained in the IRS EA. It also provides information on service definition.

2.15.1.2.3.8.12  (02-09-2009)
Service Oriented Architecture

  1. The IRS EA provides access to a collection of resources that describe service-oriented architecture (SOA) within the EA and support IRS projects in achieving and demonstrating their compliance with the EA.

2.15.1.2.3.9  (02-09-2009)
Enterprise Standards Profile

  1. The Enterprise Standards Profile (ESP) lists standards and approved products applicable to the IRS target architecture as described in the EA, including both elements developed in the Modernization program and elements developed in other IRS development activities whose products will be incorporated into the target architecture.

  2. The ESP focuses on the applicability of standards and approved products spanning a four-year period (FY2007-FY2010). The ESP will be revised periodically to update the products and standards and extend the planning horizon up to three years. The ESP presents current information about standards and approved products, available at: http://irsprime.web.irs.gov/IRSEA/ESP/.

  3. The Online ESP consists of a web-based front-end and the database itself, which contains the data. The front-end interface allows the user to have instant access to current approved standards and products. Furthermore, it provides print and search capabilities in aiding the user in his or her research. The Online ESP website includes Help pages to assist the user in navigating and using the website and providing useful relevant information.

2.15.1.3  (02-09-2009)
Where to find the EA

  1. The IRS EA is accessible to IRS employees on the IRS Intranet at http://irsprime.web.irs.gov/IRSEA/index_framework.html

2.15.1.4  (02-09-2009)
Using the EA

  1. The IRS Enterprise Architecture is available through a two-layer framework of buttons. The first of these layers provides access to the three major components of the Enterprise Architecture:

    • The As-Built Architecture

    • The Enterprise Transition Architecture

    • The Enterprise Target Architecture

    The EA Target EA Framework provides pre-established Views or Perspectives across multiple EA functions (such as a Common Business Services View) as the means to access small content segments based on specific EA topics represented and linked to each button in the EA Framework. Many – but not all – of the buttons on the Target EA framework open context pages. A context page provides a brief introduction to the specified concept, as well as links to documents relating to the button subject. Each context page also provides links to higher levels, including the EA Framework page itself.

2.15.1.4.1  (02-09-2009)
Using the EA Roadmap

  1. The IRS Enterprise Architecture Roadmap describes the intended use, scope, and depth of the IRS EA, and presents the strategy for its evolution. The Roadmap also provides a vehicle for managing the Enterprise Architecture Program - the collection of activities, services, and processes necessary to achieve the Enterprise Architecture strategy. Finally, and perhaps most importantly, the Roadmap provides a vehicle for the IRS to agree on a common intent towards the Enterprise Architecture and how it is to be used. The Enterprise Architecture Roadmap is dynamic in nature and will be updated as progress is achieved and/or priorities are changed.

2.15.1.4.2  (02-09-2009)
Using the As-Built Architecture

  1. IRS Enterprise Architecture Division's As-Built Architecture (ABA) Web Site presents an enterprise view of the IRS' current Information Technology and Business environments, interactively displaying each of the Six Domains of Change (Business Processes, Organization, Location, Data, Application and Technology) and relationships between them.

  2. The ABA is a well-organized Web site. It does not exist, nor could it exist, as a traditional document. Navigation through the ABA is self-explanatory. The user can easily find any desired information by simply following the links.

  3. The ABA is primarily of interest to individuals who need to understand the current state of the IRS Enterprise. This includes everyone directly concerned with the details of the transition to the Target Architecture. The IRS ABA website includes a Navigation Tips page, which provides instruction on using the site.

2.15.1.4.3  (02-09-2009)
Using the Target Architecture

  1. The IRS Enterprise Architecture (of which the Target Architecture is one component) is available through a Web-based two-layer framework of buttons. The first of these layers provides access to the three major components of the Enterprise Architecture:

    • The As-Built Architecture

    • The Enterprise Transition Architecture

    • The Enterprise Target Architecture

    The Target EA Framework provides pre-established Views or Perspectives across multiple EA functions (such as a Common Business Services View) as the means to access small (less than 100 pages) content segments based on specific EA topics represented and linked to each button in the EA Framework.

  2. Many – but not all – of the buttons on the Target EA framework open context pages. A context page provides a brief introduction to the specified concept, as well as links to documents relating to the button subject. Each context page also provides links to higher levels, including the EA Framework page itself.

2.15.1.4.3.1  (02-09-2009)
Project Charter Guidance

  1. The IRS EA provides access to resources related to the Project Chartering process, including guidance for completing the EA Alignment portion of the Charter, a sample of a completed EA Alignment table, a collection of IRS Project Charter documents, and a link to the Enterprise Life Cycle Process Management Office (ELCPMO) Project Charter Data Item Description document. Specifically, the guidance explains how to complete a project charter and in particular the EA alignment table. It focuses on alignment of the charter to the IRS EA, thereby translating the purpose and scope of the Project in terms of its alignment to and support of the enterprise modernization program.

2.15.1.4.3.2  (02-09-2009)
EA Change Requests

  1. The IRS EA provides the blueprint for modernizing the IRS. It informs, guides, and constrains all IRS IT Projects in how to optimize the interdependencies and interrelationships among business operating divisions and the underlying IT that supports operations. Without enforcement of the EA, the IRS risks buying software and building systems that are duplicative, incompatible, and unnecessarily costly to maintain and integrate. The EA is essential to the successful evolution of IRS IT systems and the Agency’s necessary accommodation of periodic business changes, and its development of modernized systems. The EA contains unique inter-related components, including descriptions of:

    • Business directions

    • Business drivers and processes

    • Information flows

    • Organization structures

    • Location infrastructures

    • Systems requirements

    • Security and privacy

    • Data design and administration

    • Systems design

    • Technical reference model

    • Transition strategies

    The Change Request (CR) process is the means of enforcing the EA and ensuring that all IRS IT Projects adhere to the standards and guidelines set forth in the EA when implementing changes to any of the above mentioned components within their systems. It is the process by which proposed changes to Projects that might impact the EA are initiated, validated, justified, incorporated, and controlled.

  2. The Change Management Organization (CMO) is responsible for administering PRIME’s configuration and change-management processes. The CMO tracks and reports on individual CRs, and maintains all baselines. A CR is initiated and processed as follows:

    • 1. Upon determining that a change is needed to any of its components, a Project submits a completed Change Request form (available from the CMO) to the CMO. If the CR requests approval of a standard or a software product, the Approved Standards form or the Approved Products form must be submitted, along with the CR.

    • 2. The CMO asks relevant Projects and organization (such as SEO, SPO, ISS, EDMO, and ITD) to complete an Impact Assessment (IA) form, describing any impact the proposed change would have on the organization.

    • 3. Projects and organizations send IAs to the CMO.

    • 4. When all the IA forms have been received by CMO, they are sent to the EA organization.

    • 5. The EA organization analyzes the impact of the proposed change on the EA and prepares a summary of that analysis – together with a recommendation as to whether the change should be allowed – to the CMO.

    • 6. The CMO presents the proposed change to the Configuration Control Board (CCB).

    • 7. The CCB reviews the CR and the EA organization’s recommendation and approves or disapproves the CR.

    • 7a. If the CR is approved, the Project can proceed to implement the requested change to its system. In addition, if the CR requested approval of a standard or a software product, then the identified standard or software product will be added to the online ESP.

    • 7.b. If the CR is not approved, the Project may resubmit, after making all necessary changes.

2.15.1.4.3.3  (02-09-2009)
EA Waiver Guidance

  1. The EA Waiver Process is a set of procedures to be followed by the IRS IT projects, IRS MITS, and SEO to obtain waiver from EA certification or compliance at any approval milestone during the IRS Enterprise Life Cycle. IRS IT projects must ensure that the waived requirements(s) or architecture components(s) is in compliance in a subsequent release before moving into the next milestone or implementation, thus ensuring eventual full project compliance with the EA. Such a waiver necessarily contains a transition plan to achieving full EA compliance. The waiver, if approved, permits IRS IT Projects to reach EA compliance at any milestone, especially for Milestone 3 approval, despite the identification of inadequacies in complying with all EA requirements. Reasons for a waiver might include:

    • Project requirements(s) or architecture component (s) is/are absolutely required to the IRS IT Projects for moving forward to the next milestone

    • Selected IRS IT projects require commercial COTS products that are not identified by the EA

    • Proposed configuration of the IT environment has been modified

    The waiver process for large-scale projects comprises five steps (detailed below) and involves actions by Project Directors, the SEO Director, the IRS Director of EA, and various personnel involved with the appropriate CCBs. Analogous waiver processes are followed for small-scale projects.

    • 1. Identify waiver elements - The project identifies the waiver being requested, that is, the specific elements of the EA to which compliance is to be waived. The project documents the justification for the requested waiver, including the risks to be mitigated and associated impacts to requirements, systems, interfaces, business processes, cost, or schedule.

    • 2. Create, Complete, and Submit the Waiver Request: The project completes the Waiver Request Form, supplying all requested information, especially a detailed justification and a plan for the next compliance on waiver elements. The Project Director submits the Waiver request to the Director of the EAO.

    • 3. Process and Evaluate the Waiver Request: At the request of the EAO, the SEO Director evaluates the waiver request and coordinates recommended technical direction with the IRS Director of EA. The IRS Director of EA reviews the waiver and associated documentation, approves or rejects the waiver request.

    • 4. Issue Technical Directions on Waiver Elements: The EAO Director issues any necessary technical direction to affected projects.

    • 5. Submit Changes to CCB: The project prepares any necessary impact assessment, contractual change actions, or change requests and submits the changes to the appropriate CCB. In the event that the waiver is not approved at step 3, the Project must make any necessary changes to the waiver request and resubmit, beginning at step 2.

    This waiver process can be applied at any stages of the IRS ELC.

2.15.1.4.3.4  (02-09-2009)
Business Work Products

  1. The Business Work Products define all business-related aspects of the target state of the IRS Enterprise, including business processes, organization, and location. The Business Work Products also define the overall direction for IRS Business Systems Modernization.

  2. The following list includes all of the work products from the Business Architecture and also includes the Programmatic Requirements.

    • Programmatic Requirements

    • Enterprise Business Direction Model

    • Enterprise Business Concept of Operations

    • Operational Requirements

    • Organization Direction Model

    • Role Definitions

    • Location Type Definitions

    • Business Process Model

    • Enterprise Context Diagram

    • Process Thread Performance Model (integrated within Business Process Model)

    • Customer/Needs Process Matrix

    • Process/Organization Matrices (integrated within Business Process Model)

    • Process/Role Matrix (integrated within Business Process Model)

    • Process/Location Type Matrix (integrated within Business Process Model)

    • Cross-Business Process Scenarios

2.15.1.4.3.5  (02-09-2009)
Functional Work Products

  1. The Functional Work Products define what the IRS Enterprise must do. As such, these Work Products are the core of the IRS EA. The following list includes all the Functional Work Products:

    • Programmatic Requirements

    • Business Process Definitions

    • Functional Requirements

    • Traceability of Data and Functional Requirements to Business Processes

    • Allocation of Functional and Data Requirements to Systems

    • Functions to Systems Allocations

    • Processing Threads

2.15.1.4.3.6  (02-09-2009)
Data Work Products

  1. The Data Work Products define what data must be processed and stored by the IRS Enterprise, how it is structured and interrelated, and how it will be stored as listed in the following list:

    • Business Process Definitions

    • Data Requirements

    • Traceability of Data and Functional Requirements to Business Processes

    • Allocation of Functional and Data Requirements to Systems

    • External Systems Interfaces

    • Internal Systems Interfaces

    • Data Classes to Databases Allocations

    • Data Architecture

2.15.1.4.3.7  (02-09-2009)
Performance Work Products

  1. The Performance Work Products define how well the IRS Enterprise must perform as listed:

    • Process Thread Performance Model (integrated within Business Process Model)

    • Performance Requirements

    • Performance Requirements Supporting Data

    • Performance Model

2.15.1.4.3.8  (02-09-2009)
Technology Work Products

  1. The Technology Work Products define the technical infrastructure needed to support the Functional, Data, and Performance Work Products. The following list includes all the Technology Work Products.

    • System Management Requirements

    • Allocation of Functional and Data Requirements to Systems

    • Functions to Systems Allocations

    • Data Classes to Databases Allocations

    • Processing Threads

    • Technical Architecture

    • Technical Reference Model (TRM)

    • Physical Infrastructure

    • Communications Services

    • Platforms and Platform Services

    • Enterprise Services

    • Applications

    • Systems Security Architecture

    • Enterprise Systems Management

    • Performance Model

    • Disaster Recovery

2.15.1.4.3.9  (02-09-2009)
Security and Privacy Work Products

  1. The Security and Privacy Work Products are a subset of the Systems Architecture work products. Taken as a whole, these Work Products define the measures necessary to protect sensitive IRS assets, including taxpayer information. the following list includes all the Security and Privacy Work Products:

    • Federal Laws and Regulations Applicable to Security and Privacy (part of the Programmatic Requirements Work Product)

    • Security Considerations of Target Architecture Business Processes

    • Privacy Considerations of Target Architecture Business Processes

    • Data Requirements (Sensitivity Classification of Data Classes)

    • Security Categories of ETA Business Processes

    • Sensitivity Classification of ECDM Data Classes (part of the Data Requirements work product)

    • Security Requirements

    • Privacy Requirements

    • Traceability of Privacy and Technical Security Requirements to Business Process Security & Privacy Considerations

    • Crosswalk of NIST SP 800-53 and ETA Security Requirements

    • Allocation of Security Mechanisms to System Components (part of the Security Architecture work product)

    • Security Processing Thread (part of the Security Architecture work product)

    • Security Risk Assessment

2.15.1.4.4  (02-09-2009)
Using the Enterprise Standards Profile

  1. The Enterprise Standards Profile is applicable to the entire IRS Enterprise, both in terms of technical area and in terms of time.

  2. The Enterprise Standards Profile presents Technical Systems Standards and Systems Engineering Standards. The seven categories of Technical Systems Standards are directly related to the seven layers of the TRM.

  3. The Systems Engineering Standards apply to the engineering and development of the IRS modernized architecture, rather than to the delivered architecture itself.

  4. The Enterprise Standards Profile is primarily of interest to readers involved with design, development, and product selection.

2.15.1.4.5  (02-09-2009)
Using the Transition Architecture

  1. The Enterprise Transition Architecture comprises three documents:

    • Enterprise Transition Strategy

    • Release Architecture

    • Enterprise-Wide Sequencing Plan

2.15.1.4.5.1  (02-09-2009)
Using The Enterprise Transition Strategy

  1. The Enterprise Transition Strategy is the strategy for transitioning the IRS Enterprise from its current state to its desired future state. It begins with a description of the Current Production Environment, proceeds through a Near-Term Overview and continues on to a Strategic Overview, and concludes with Long-Term Planning extending to the final transition to the target architecture.

  2. The ETS is the initial framework for:

    • Definition of modernization projects

    • Sequencing of modernization projects in a way that supports the business priorities defined by the IRS during the Vision and Strategy ELC processes

    • Development of Business Systems Modernization spending plans

    • Assignment of Enterprise Architecture (EA) business systems to modernization projects

    • Assignment of system interfaces to modernization projects

2.15.1.4.5.2  (02-09-2009)
Using the Release Architecture

  1. Each release architecture is an incremental step along the transition path defined by the ETS. Each release architecture specifies the state of the IRS Enterprise as of the completion of the system deployments planned for a fiscal year.

  2. The current Release Architecture document includes a fully detailed release architecture for the fiscal year 2006 and less detailed release architectures for fiscal years 2007 and 2008.

2.15.1.4.5.3  (02-09-2009)
Using the Enterprise-Wide Sequencing Plan

  1. The Enterprise-wide Sequencing Plan is planning tool that giving leadership the visibility to use the EA for organization-wide planning. In the Enterprise-wide Sequencing Plan, it describes how the existing and proposed investments align to the IRS vision and strategy. It also provides an organization-wide view of programs and projects across the agency, The plan identifies the schedule for enterprise-wide management of multiple, concurrent, and interdependent development efforts. The plan further demonstrates incremental stages necessary to achieve target state business objectives, program efficiencies, and technology advances. This enables high-level impact assessment of investment decisions and programmatic changes on the overall plans for moving toward the target EA. Impacts of budget cuts or changes to program priorities that result in cancelled or delayed projects can be quickly assessed using the plan.


More Internal Revenue Manual