2.15.1 Enterprise Architecture (EA) Overview

Manual Transmittal

June 15, 2020

Purpose

(1) This transmits revised IRM 2.15.1, Enterprise Architecture (EA), Enterprise Architecture (EA) Overview. The purposes of this IRM are to:

  • Define the EA and depict the key components of EA

  • Define how the EA fits within the concept of operations for the business

  • Define how the EA should be used

  • Define where to find EA on the website

Material Changes

(1) All of the existing content, last updated in 2009, has been revised and replaced.

(2) Includes Internal Controls

Effect on Other Documents

IRM 2.15.1, dated February 10, 2009, is superseded.

Audience

This EA has the following main audiences: (1). Decision Makers - Commissioners and governance bodies. (2). Business Owners - Business Operating Units, Agency Wide Shared Services, Security and IT Operations. (3). Builders/Architects - EA Program, IRS developers, and contractor developers.

Effective Date

(06-15-2020)

Nancy Seiger
Acting CIO, Information Technology

Program Scope and Objectives

  1. This section includes the scope, purpose, and objectives of Enterprise Architecture.

  2. Purpose: An enterprise architecture is a strategic information asset base which defines the mission, the information and technologies necessary to perform the mission and the transitional processes for implementing new technologies in response to the changing needs of the mission.

  3. Audience: (1). Decision Makers - Commissioners and governance bodies. (2). Business Owners - Business Operating Units, Agency Wide Shared Services, Security and IT Operations. (3). Builders/Architects - EA Program, IRS developers, and contractor developers.

  4. Policy Owner: Chief Information Officer

  5. Program Owner: Enterprise Architecture

  6. Primary Stakeholders: IRS information technology management, analysts, and support contractors.

  7. Program Goals: The objectives of the EA include:

    • Managing change within the IRS as it modernizes

    • Providing source of document of where business is going and how we will conduct business in the future

    • Identifying business processes and their interactions

    • Providing a foundation for defining the scopes of modernization projects

    • Establishing requirements, design and transition for project development

    • Developing guiding principles, constraints, and assumptions for project development

    • Identifying security and privacy needs for project development

    • Establishing system standards and conventions, and define how tools will be used by projects

    • Developing sequence plan for transforming Current Production Environment(CPE) into future environment

    • Establishing a sound information technology investment strategy satisfy legislative and other oversight requirements.

Major components and sub-components of the EA

  1. The EA is composed of the following three major components and many sub-components within each major component:

    • As-Built Architecture including all information technology applications.

    • Enterprise Transition Architecture and its sub-components including Enterprise Transition Strategy, Release Architecture and Enterprise-wide Sequencing Plan

    • Enterprise Target Architecture and its sub-components including EA Strategy and Function, EA Roadmap, EA Principles, EA Requirements, Business Architecture, Organization and Location, Data Architecture, Application and Technology which covers System Architecture, System Interfaces, Technical Architecture, Application Architecture, Security Architecture, System Management Architecture, Technical Guidance and Design Patterns, Service Repository and Service Oriented Architecture, and Enterprise Standards Profile.

AS-Built Architecture

  1. The U.S. Federal Enterprise Architecture (FEA) is an initiative of the U.S. Office of Management and Budget (OMB), Office of E-Government and IT, that aims to realize the value of enterprise architecture within the U.S. Federal Government from an investment perspective. Enterprise Architecture, of which the As-Built-Architecture (ABA) is one component, is mandated by a series of federal laws to maintain and report annually to OMB on their respective ABAs. The ABA represents the IRS' Current Production Environment (CPE) with business applications, external systems, and external trading partners. It also includes interfaces, key attributes, and information related to Privacy and Civil Liberties Assessments. The ABA allows Business Analysts and Information Technology (IT) professionals to view the CPE from both technical and business perspectives using IRS’ Enterprise Life Cycle’s (ELC) Six Domains of Change, to see interrelationships between technological and business domains, and get information necessary to make informed decisions.

  2. The ABA provides the relationships between elements within each domain, for example, applications are linked to the technology platforms that host the application; technology platforms are linked to the physical and logical locations where they reside.

  3. All IRS organizations that own or manage IT applications in the CPE are required to provide updates to the EA organization so that the ABA remains updated and is as complete as possible in order to answer external data calls for application-related information.

Enterprise Transition Strategy

  1. The Enterprise Transition Strategy (ETS) describes the overall IRS vision and strategy, and how existing and proposed investments align to it. The ETS summarizes the current state of the current production environment, documents challenges and goals for the IRS by business, technical or service domain, includes the defined portfolio of programs and projects for achieving the transition. The ETS also describes how these programs and projects fulfill business goals and objectives of the IRS and US Treasury and highlights the impacts of transition on the current production environment and system retirements result from modernization efforts.

Enterprise Transition Strategy
  1. The Enterprise Transition Strategy (ETS) describes the overall IRS vision and strategy, and how existing and proposed investments align to it.

  2. It summarizes the current state of the current production environment, documents challenges and goals for the IRS by business, technical or service domain, includes the defined portfolio of programs and projects for achieving the transition.

  3. It illustrates how these programs and projects fulfill business goals and objectives for IRS domains, the IRS and Treasury.

  4. It illustrates the impacts of transition on the current production environment and highlights system retirements expected to result from modernization efforts.

  5. The ETS also provides an organization-wide view of programs and projects across the agency, giving leadership the visibility to use the EA for organization-wide planning.

Release Architecture
  1. The IRS Release Architecture (RA) is an IRS near-term IT plan encompassing all major and selected (strategic) non-Major IT projects planned for delivery within a sliding timeframe that includes the next three fiscal years. The RA provides an integrated view of the IRS-wide consolidated IT project portfolio and its effect on the Enterprise Architecture and IT environment. It draws its base data from the Enterprise Transition Strategy (ETS).

  2. The RA manages the complex relationship between projects and releases with planning domains. The RA allows the user to identify the impact of each planned project release on the current IT production environment (CPE) in terms of newly built business applications, data stores, data interfaces, and infrastructure systems as well as project releases that will modify or permit the retirement of existing systems. The RA also documents dependencies between different projects and their releases. This information is critical for integrated portfolio planning and project sequencing.

Enterprise-wide Sequencing Plan
  1. The Enterprise-Wide Sequencing Plan (EWSP) provides an evolving view of programs and projects and graphically depicts their relationships and impacts across the enterprise. The EWSP 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.

Enterprise Target Architecture

  1. The IRS Target Architecture defines the desired future state of the IRS Enterprise. The target architecture supports the fulfillment of the IRS mission and strategic goals by establishing a three to five-year outlook that drives information technology investment decisions based on priorities around modernizing front-line tax administration and supporting technical infrastructure. The Target Architecture comprises the Business Architecture, the Systems Architecture, Application Architecture, Data Architecture, Security Architecture and the Technical Architecture.

EA Strategy and Function
  1. The IRS EA captures the current state of the IRS Enterprise in an As-Built Architecture, defines the desired future state of the IRS Enterprise in a Target Architecture, and defines a plan for getting from the current state to the desired future state in an Enterprise Transition Plan.

Vision and Strategy
  1. The IRS mission and strategic goals are implemented through a five-year plan that drives information technology investment decisions based on priorities around modernizing front-line tax administration and supporting technical infrastructure. EA leverages existing systems, as defined in the As-Built Architecture, and new development to build capabilities, optimize capacity, manage program costs, and deliver business value on an incremental and frequent basis. This business vision and strategy is then documented within the EA’s Enterprise Transition Plan.

  2. To achieve this objective, segment architecture is used to identify the enterprise segments and to link enterprise-level planning with the development and implementation of solution architecture. Segment architecture is fully reconciled with the agency enterprise architecture. Business investments and resources are also fully aligned with the approved segment architecture. Segment architecture is developed to support a clear and concise value proposition linked to the agency mission, as well as to its strategic goals and objectives.

Domain Overview
  1. The vision and strategy framework is built on the functional segmentation of the IRS, representing the core mission business functions that directly relate to front-line tax administration. These segments, or business domains, reflect a purely functional rather than organizational view of the business, and ensure that business priorities remain the focus of IRS IT investments.

  2. The IRS Business Domains include:

    • Submission Processing: provides the filing of both paper and electronic tax returns and the initial capture and accounting for tax revenues.

    • Manage Taxpayer Accounts: provides the data, systems, and processes used to manage taxpayer accounts.

    • Customer Service: provides tax law and compliance assistance, taxpayer education, and taxpayer account, refund, and notice inquiries.

    • Reporting Compliance: directs activities designed to strengthen compliance by identifying taxpayers non-compliant with reporting requirements that impact their tax liability or exempt status.

    • Filing and Payment Compliance: includes collecting delinquent tax obligations and securing delinquent tax returns.

    • Criminal Investigation: enforces criminal statutes of the Internal Revenue Code and related statutes.

    • Internal Management: manages IRS human capital and financial accounting.

    • Chief Counsel: provides legal guidance and interpretative advice to the IRS, Treasury and to taxpayers on all matters pertaining to the interpretation, administration and enforcement of the Internal Revenue code.

    The business domains support the effective and secure execution of the core mission business functions. These critical services are addressed by the service domains, and include cross-cutting data, infrastructure and security services as well as common business functions that can be leveraged to support business domains.

  3. The IRS Service Domains include:

    • Common Business Services: includes capabilities that are applicable across business domains and systems, such as case management, workflow management, and document and image management.

    • Infrastructure: provides computing and communication systems/networks/platforms supporting IRS people and applications. It encompasses three tiers of the distributed computing architecture and includes data and voice networks, call centers and video communication and other physical components of IRS' IT environment.

    • Security & Privacy: manages the integration of the multiple legislative, regulatory, and departmental requirements specified by federal law, such as the Privacy Act, Presidential Directives, and the E-Government Act, including the Federal Information Security Management Act (FISMA).

    • Data Strategy: develops a coherent approach that will reduce data redundancy and the large operating costs caused by multiple, replicated or similar data stores.

    Finally, Technical Domains were recently introduced into the MV&S Framework. The focus of the Technical Services Domain is the delivery of base products and services (shared resources that can be used on demand by many different applications) that affect the development, operations, and maintenance costs of systems; the time necessary to develop and deploy new or revised capabilities; the flexibility and capability to resource-development efforts; and the effective operational performance of these systems and their ability to provide the desired business results.

  4. The Technical Services Domains include:

    • Application Development: delivers integrated software solutions that address the objectives and priorities of the IRS. This translates into specific focus areas – delivering applications for the IRS, delivering the filing season, and maintaining legacy technology systems.

    • Enterprise Services: sets critical enterprise standards to promote compatibility and common practices across the IRS, applies engineering expertise directly to projects and programs, establishes frameworks for IT demand management and prioritization, and establishes governance and control methodologies for the IT portfolio.

    • User and Network Services: delivers premier IT products and services to the IRS, provides a single point of contact for requesting MITS products and services; supports the desktop environment as well as inventory management, workstation software integration, data security.

    • Enterprise Operations: provides efficient, cost effective, secure, and highly reliable computing services for all IRS business entities and taxpayers.

    • Cybersecurity: ensures compliance with federal statutory, legislative, and regulatory requirements governing confidentiality, integrity, and availability of IRS electronic systems, services, and data in accordance with FISMA.

    • Strategy and Planning: provides business planning and risk management, financial management, investment and portfolio controland oversight, and strategic supplier management.

IRS Strategic Goals and Business Process Alignment
  1. The core IRS business processes support the strategic goals as described in the Strategic Plan. The matrix is provided to assist in business case development and provide stronger justifications of proposed improvements to IRS business processes by demonstrating a clearer line of sight to IRS business results.

Enterprise Technology Roadmap
  1. Enterprise Technology Blueprint

  2. The IRS Enterprise Technology Blueprint (ETB) articulates the envisioned long-range technology environment and describes how technology will be leveraged and deployed in support of the strategic IRS business direction. It uses EA methods and visualizations to depict the complex interrelationships between the envisioned business capabilities, data, applications and systems, technologies and infrastructure. The vision, themes, and enterprise technology direction in the TR is used by the IT investment planning team to evaluate the alignment of IT investment proposals with the broader enterprise business and technology decisions. The TR content fosters a common understanding of the IRS’s future technical direction among the project stakeholders and aligns the specific business needs to the enterprise programs, IT initiatives, and technology strategies.

  3. Updating the Technology Blueprint

  4. The IRS Technology blueprint is a living document that is continuously reviewed and updated as appropriate. EA continuously assesses the IRS landscape and plans and proactively identifies and validates needed changes. In addition, the blueprint is available online for all IRS employees and contractors with access to the intranet, and anyone may contact the EA team with proposed changes, which the EA team evaluates, prioritizes and incorporates as appropriate. Further, the Technology Blueprint is regularly socialized through briefings, and these sessions provide a forum for stakeholders to provide feedback.

EA Principles
  1. Integral business and technical governing principles serve as the primary component of the IRS Enterprise Architecture. They provide the basis for defining architectural strategies and implementing complex IT options. The principles contained in the EA are statements describing the preferred architectural direction for the IRS. They provide the basis for the realization of the IRS’ future vision by helping business owners and program developers ensure that proposed systems and other initiatives are approved, resourced, and integrated into the IRS enterprise.

EA Requirements
  1. Enterprise Architecture Requirements are required by federal law, IRS enterprise architecture principals, and vision and strategy mandates. The Enterprise Architecture Requirements initiative include programmatic, security, and privacy requirements. In addition, EA manages performance, functional, and system management requirements and provides traceability of data and functional requirements to business processes.

Programmatic Requirements
  1. The IRS EA presents programmatic requirements for the IRS Business Systems Modernization Program. These programmatic requirements have been mandated by higher authorities and exist independently of EA. Given the broad scope of many of the referenced requirements, some provisions of some of these requirements may not be fully applicable to the IRS business systems modernization program. EA describes programmatic requirements as those based on security and privacy; the IRS; and all agencies.

Security Requirements
  1. The Security Requirements model specifies security requirements for the IRS Enterprise Target Architecture (ETA). In addition to that model, EA specifies security requirements for traceability of Privacy and Technical Security Requirements to Business Process Security and Privacy Considerations and the crosswalk of NIST SP 800-53 and ETA Security Requirements.

    • Security Requirements: Specifies security requirements–particularly, technical (that is, information technology [IT]) security requirements–for the Target Architecture

    • Traceability of Privacy and Technical Security Requirements to Business Process Security and Privacy Considerations: Traces the security requirements of the previous model to what are called the security considerations of target business processes

    • Crosswalk of NIST SP 800-53 and ETA Security Requirements: A crosswalk of the Target Architecture technical security requirements and the controls specified in NIST SP 800-53, Recommended Security Controls for Federal Information Systems, Revision 1

    Other Models of the Target Architecture Security View

  2. The security architecture view of the Target Architecture consists of other models besides the three named just above. Other models of the security view include:

    • Security Considerations of Target Business Processes: Specifies very high-level security requirements for target business processes.

    • Security Categories of ETA Business Processes: Identifies FIPS 199 security categories for target business processes. (The categories also address privacy)

    • Sensitivity Classification of ECDM Data Classes: Identifies the sensitivity classification of each of the data classes of the Enterprise Conceptual Data Model (ECDM). (Sensitivity classification indicates whether a data class is sensitive or non-sensitive and, if sensitive, its sensitivity type [for example, Taxpayer, Employee Personal, Law Enforcement].) This model also indicates the FIPS 199 security category of Taxpayer data and Personally Identifiable Information (PII).

    • Allocation of Security Mechanisms to System Components: Allocates the security mechanisms specified in the Security Requirements model to target logical business systems.

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

  3.  

Privacy Requirements
  1. Privacy Requirements Models: The primary purpose of the Privacy Requirements model is to specify privacy requirements for the IRS Enterprise Target Architecture (ETA). In addition to that model, a supporting model is also included highlighting the traceability of Privacy and Technical Security Requirements to Business Process Security and Privacy Considerations: tracing privacy requirements models to privacy considerations of target business processes.

  2. Other Models of the Target Architecture Privacy View: The privacy architecture view of the Target Architecture consists of other models besides the two named just above. Other models of the privacy view include:

    • Privacy Considerations of Target Architecture Business Processes: Specifies very-high-level privacy requirements for target business processes

    • Security Categories of ETA Architecture Business Processes: Identifies FIPS 199 security categories for target business processes

Performance Requirements
  1. The IRS EA describes high-level system performance requirements. Five categories of performance requirements are specified, including Enterprise Workload, Enterprise Response Time, Enterprise Reliability, Maintainability, and Availability Requirements. These performance requirements are primarily based on the performance goals specified in the Process Thread Performance Matrix (provided in the EA’s Performance Architecture section). However in many cases, the performance goals specified by these matrices are incomplete. Therefore, they have been supplemented by information from sources such as the tax statistics area of http://www.irs.gov. Future versions of the Business Architecture are expected to provide more complete specification of performance goals. This will lead to expansion and refinement of the performance requirements specified herein, and may result in replacement of some of the requirements based on supplemental sources.

System Management Requirements
  1. The Enterprise Systems Management (ESM) Requirements exist primarily because systems and networks are not currently self-healing. In order to move the IRS towards the goal of self-healing, self-managed systems, applications, and networks, all devices, systems, applications, processes, and system platforms must participate in the overall systems management strategy. All ESM functions must be closely integrated with each other, provide for extensibility, scalability, and secure operation, and afford extensive multi-platform management capability.

  2. Arrays of management capabilities must be provided in order to achieve a "best-practice" ESM solution for the IRS. The ESM solution deployed at the IRS must be flexible enough to adapt to a wide variety of operational models. Producing an Enterprise-wide solution provides for a high degree of flexibility with regard to implementing evolutionary changes to the operational model with the least amount of disruption to service levels.

Functional requirements
  1. The EA describes the Enterprise-level, future-state functional requirements that will support the modernized IRS. The Business Process Model includes:

    • Automated and/or manual functions that develop the business processes described in Business Processes.

    • Functions that are organized primarily by the business areas described in Business Processes. While the Business Process hierarchy has placeholders for content that may be added later; placeholders are not used in the current functional requirements.

    • Functions that are depicted in activity diagrams using the Unified Modeling Language (UML) notation.

    • Relationships between the functions and the data, depicted as objects in UML notation.

    • Descriptions of each function.

Business Architecture
  1. The IRS Business Architecture defines the business aspects of the target state of the IRS Enterprise. The Business Architecture comprises the following content areas:

    • Business Direction

    • Organization and Location

    • Business Services and Processes, including a description of an initial set of Business Services

    The IRS EA presents a high-level view of how the Business Architecture can be used to support key roles in the planning, development, and managing the evolution of the IRS to meet its strategic goals and objectives.

  2. Business Architects: support the following activities:

    • Business process reengineering activities, and for planning Business Process Redesign Projects to ensure that project designs align with the business vision and supporting high level process designs and business services.

    • Coordinating and optimizing key business operations and services across the organization.

    • Consolidating or standardizing similar processes and services – as appropriate.

    • Introducing automation to improve upon manual activities and processes.

    • Chartering new strategic initiatives or projects.

    • Conducting compliance certifications – by ensuring project deliverables and designs align with the vision and high level designs contained in the Business Architecture.

    • Selecting applications software to support business process and service design.s

    • Employing a set of comprehensive sources of guidance including the Enterprise Lifecycle (ELC) Methodology, the ConOps Guidance Toolkit, and the supplementary materials available on the IRS EA website.

  3. Project Managers: support the following activities:

    • Ensuring that key stakeholders (organizations and roles affected by project scope) are involved on the project team.

    • Ensuring that their project scope is unique and well understood by the project team, key stakeholders and sponsors.

    • Ensuring that their work is integrated with other projects and within the operating units.

    • Ensuring that their business results are consistent with the business services offered, business process visions, and supporting high level process designs.

    • Ensuring that their teams communicate with a common language to understand the business and its supporting technology.

  4. Business and IT Planners: support the following planning activities:

    • Assessing all proposed business and technology solutions in the context and framework of the Business Architecture to avoid overlaps and duplication of proposed projects.

    • Taking advantage of new enabling technologies, techniques, and/or new software solutions.

    • Determining the impact of proposed changes in business to business services, business processes, roles, organizations and supporting systems and infrastructure.

    • Coordinating and optimizing key business operations and services across the organization.

    • Consolidating or standardizing similar processes and services – as appropriate.

    • Achieving balance and alignment within the IT project portfolio.

    • Prioritizing various projects and related investments.

    • Recognizing the dependencies and establishing key attributes of projects early in the life cycle, while the cost of changes or fixing problems is relatively small.

  5. Designers: support the following design activities:

    • Ensuring that their project scope is unique and well understood by the project team, key stakeholder and sponsors.

    • Ensuring that their work is integrated with other projects and within the operating units.

    • Ensuring that their business results are consistent with the mission and vision of the Agency.

    • Assessing all proposed business and application solutions in the context of the business services offered, business process visions, and high level designs to ensure alignment.

  6. Financial Analysts: support business-case development for the following purposes:

    • To demonstrate alignment of proposed projects (E300 proposed funding request) to the IRS business processes and the Treasury BRM.

    • To demonstrate alignment and support of the FEA Performance Reference Model.

    • To demonstrate alignment of major IT investments with the FEA Service Component Reference Model (SRM).

Business Services
  1. A Business Service is a complete business transaction or interaction that the IRS conducts with a customer, partner, or stakeholder. It can be a tax service or a service that provides a tax product. Like other business enterprises, the IRS offers an array of services, similar to a menu or catalog of services that identifies the various products and services that one can obtain from that business enterprise.

Business Processes
  1. The EA describes the future-state business processes that will support the IRS. The Business Process Model includes:

    • Process hierarchies in the form of decomposition diagrams that show structure.

    • Process flow diagrams that illustrate functions within major processes (shows interrelationships between subprocesses).

    • Process definitions that provide a robust description of processes and sub-processes, including key activities, data inputs and outputs, and security and privacy considerations.

    • Matrices showing the relationship of processes to the organizations where the work is done, the roles that perform the work, and the location types where the work is accomplished.

    • A list of custodial financial controls required by the process (when applicable).

Cross Business Process Scenarios
  1. The EA provides business scenarios that demonstrate how selected business processes contained in the EA support key business events. These scenarios were developed in response to requests from the business community to meet two objectives:

    • To demonstrate that the business processes outlined in the EA provide adequate coverage for the business functions under a variety of business conditions.

    • To demonstrate cross-business process integration.

Custodial Financial Controls
  1. The IRS has added custodial requirements to manage the receipt and disbursement, and related assets and liabilities, of taxpayer accounts. The Joint Financial Management Improvement Program (JFMIP) identifies controls as part of its mandatory requirements for federal financial management systems. In its framework for Federal Financial Management Systems, the JFMIP states that “Effective financial management depends upon appropriate control of business transactions, in accordance with internal control standards, and recording business event information in a manner that satisfies multiple users and uses. The JFMIP states that Effective financial management depends upon appropriate control of business transactions, in accordance with internal control standards, and recording business event information in a manner that satisfies multiple users and uses.

  2. The IRS EA defines several key concepts, in order to provide a better understanding of how and where custodial financial controls fit into the EA. These key concepts are:

    • Financial event

    • Financial control

    • Financial management control

IRS Enterprise Context Diagram
  1. The enterprise context diagram profiles the business environment in which the IRS operates. It describes the external entities with which the IRS interacts. These entities are organized hierarchically with summary-level entities sometimes broken down into second- and even third- level entities.

  2. In general, the IRS’ Enterprise context diagram does not describe interactions among the multiple roles of organizations unless those interactions are applicable to IRS business. For example, a business is a taxpayer when it pays its income tax, and a business is an employer when that business withholds taxes from its employees and submits tax-related W-2 information to the IRS. The IRS Enterprise context diagram describes interactions between business taxpayers and the IRS and between employers and the IRS; it does not describe interactions between taxpayers and employers.

  3. The external entities are organized hierarchically with top-level entities broken down into second-level and sometimes third-level entities. This hierarchical organization parallels the Enterprise Conceptual Data Model’s definitions of taxpayer and third party. The higher level external entities are listed below:

    • EE-1.0 – Taxpayers

    • EE-1.1 – Individual Taxpayers

    • EE-1.2 – Organizational Taxpayers (not shown on context diagram)

    • EE-1.2.1 – Businesses

    • EE-1.2.2 – Employee Plans

    • EE-1.2.3 – Exempt Organizations

    • EE-1.2.4 – Government Entities

    • EE-2.0 – Third Parties (not shown on context diagram)

    • EE-2.1 – Employers

    • EE-2.2 – Financial Institutions

    • EE-2.3 – Tax Education Partners

    • EE-2.4 – Other Third Parties (not shown on context diagram)

    • EE-2.4.1 – Other Taxpayer/IRS Intermediaries

    • EE-2.4.2 – Other Partners

    • EE-2.5 – Government Third Parties

    • EE-2.6 – Private Collection Agenciess

Business Process / Functional and Data Requirement Matrix
  1. The EA describes linkages between every Tax Administration Services, Support Delivery of Services and Internal Management of IRS Resources business process as defined in the End-to-End Business Process Views.

Functional Requirements
  1. The EA describes the enterprise-level, future-state functional requirements that will support the IRS. The Business Process Model includes:

    • Automated and/or manual functions that develop the business processes described in Business Processes

    • Functions that are organized primarily by the business areas described in functional requirement.

    • Functions that are depicted in activity diagrams using the Unified Modeling Language (UML) notation.

    • Relationships between the functions and the data, depicted as objects in UML notation.

    • Descriptions of each function.

Processing Threads
  1. The IRS EA describes processing threads that are used to demonstrate how system software applications are involved in executing high-level business processes. The processing threads consider aspects of processing tax returns and payments, initiating compliance actions, and providing customer support and taxpayer education. Third party support also is addressed. A security processing thread presented in Security Processing Thread emphasizes the involvement of infrastructure components as an employee logs on to an IRS workstation and begins working on a filing and payment compliance case. The following processing threads are discussed in the corresponding section in EA:

    • Balance-due tax return with subsequent installment agreement and default.

    • Information returns (bulk file) – one for an account missing a tax return.

    • Reporting compliance (remote assistance) requiring an exam.

    • Filing and payment compliance for an LMSB tax return.

    • Third party online request for a taxpayer transcript.

    • Tax law inquiry with call back and service request.

    • Exempt organization (IRC Section 6104) public disclosure of 527

    • Taxpayer receives individual assistance with unpaid balance for previous year’s taxes

Organization and Location
  1. The Organization Model View consists of the following:

    • Organization Descriptions identifies and describes the organizational entities that comprise the IRS. This section also contains summaries of organization-level concepts of operations (ConOps) that have been completed, processed, and approved for inclusion in the EA.

    • Business Concepts of Operations refers to the framework organizations use to plan out and reach their target state in all domains of change, including organization and location, as well as business process, data, applications and technology.

    • Role Definitions identify, classify and explain the roles that support the core business of the IRS. IRS business processes are associated with the specific process / role matrices that accompany each business process area description.

    The Location Model View consists of Location Type Definitions which identify and classify all of the distinct types of locations where the IRS conducts business (directly or indirectly) or where critical functions are performed. IRS business processes are associated with the specific Location Types at which they are performed in process / location type matrices.

Organization Descriptions
  1. IRS Organization Descriptions, which are part of the IRS EA Organization Model View, identify and describe the organizational entities that comprise the IRS. The scope encompasses the entire IRS Enterprise, including advisory functions, such as Chief Counsel and the National Taxpayer Advocate, as well as all Operational Support components. The EA provides summaries of organization-level business concepts of operations (ConOps) that have been completed, processed, and approved for inclusion in the EA.

Role Definitions
  1. The purpose of the Role Definitions section is to identify and classify roles that support the core business of the IRS; it is not intended to be an exhaustive list of roles. While functional roles are identified, organizational roles are not identified, because these change over time. All identified roles contain role descriptions that define each role.

Location Type Definitions
  1. The Location Type Definitions identify and classify all of the distinct types of locations where IRS conducts business (directly or indirectly) or where critical functions are performed in support of IRS business or technical operations. These definitions establish the enterprise-wide terms, nomenclature, and hierarchical structuring of locations, so that consistent names and meanings are used across the enterprise. The focus is on functional and physical locations that are durable over time. The Location Types definitions do not try to define organizational locations, which tend to change over time. IRS business processes are associated with the specific IRS Location Types at which they are performed in Process / Location Type.

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.

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.

Information Dictionary
  1. The IRS EA Information Dictionary is located within the Glossary of IRS Business Terminology. It is divided into the Glossary defining all terminology and 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.

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. 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 ECDM is organized into three top-level subject areas, each of which also divides into three subject areas. 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 conducts 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.

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.

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

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. 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.

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

    • Processing Threads

    • System Interfaces

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.

Technical Architecture
  1. The IRS EA provides a detail description of the IRS 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 layers and interfaces:

    • Physical Infrastructure

    • Communication Services

    • Platform and Platform Services

    • Enterprise Services

    • Applications

    • Enterprise Security Services

    • Enterprise Systems Management

    • Technical Requirements

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.

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
  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.

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.

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

    • Business Services mapped to Domains and Projects/Sources

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.

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

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.

Standards and Technology Management
  1. Standards and Technology Management (STM) is responsible for all COTs-based information technology insertions within the IRS. STM identifies, approves, and manages the technology products, service contracts (including cloud), and standards that define the business initiatives affecting IT. STM also provides leadership and guidance for emerging technologies with the approval of Proof-of-Concepts and Demos. STM is essential to the successful alignment of individual products, standards, and technologies to the Target Enterprise Architecture. The key standards component is the Enterprise Standards Profile (ESP) database. Only products listed in the ESP, a technical product repository, may be deployed (e.g. Current) in the IRS and when the products are Sunset through the product lifecycle management process. The web-based Change Request management application is accessed by IT partners to modify the ESP. The ESP focuses on the functionality of standards and approved products. The ESP presents status about standards and approved products. The goal of the approval process is to align to the strategic direction, ensure products are supported (e.g. removal of unsupported products), and to minimize overlapping functionality.

Where to find the EA

  1. The IRS EA is accessible to IRS employees on the IRS Intranet.

Using the EA

  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.

Using the Enterprise Technology Roadmap

  1. There are three primary uses supported by the ETB.

  2. Foster Collaboration and Coordination: The ETB promotes dialog and collaborative planning across the enterprise. It provides IRS business and IT stakeholders a common long-range view of IRS operations from a business and IT perspective and depicts the alignment between business and IT concepts. It identifies emerging technology trends and their potential applicability to different IRS business functions, enabling different stakeholders to identify potential technology opportunities in support of business needs.

  3. Align Strategic and Architectural Planning: The ETB provides inputs to and receives outputs from other levels of enterprise planning. The ETB reflects the vision, goals, and direction identified in higher level planning processes such as the IRS Strategic Plan, IRS Integrated Modernization Business Plan, IT Vision, business unit operational planning, and other sources. From these sources, the ETB synthesizes an architectural vision that in turn serves as a touchpoint to guide more detailed program/project architectural planning, IT strategy initiatives, and other planning activities.

  4. Align Strategic and Architectural Planning: The ETB provides inputs to and receives outputs from other levels of enterprise planning. The ETB reflects the vision, goals, and direction identified in higher level planning processes such as the IRS Strategic Plan, IRS Integrated Modernization Business Plan, IT Vision, business unit operational planning, and other sources. From these sources, the ETB synthesizes an architectural vision that in turn serves as a touchpoint to guide more detailed program/project architectural planning, IT strategy initiatives, and other planning activities.

  5. Inform IT Investment Prioritization and Decision Making: The ETB provides a framework for identifying and evaluating potential investments and ensuring their alignment with a common enterprise vision.

Updating the Enterprise Technology Blueprint

  1. The Enterprise Technology Blueprint is a living document that is continuously reviewed and updated as appropriate. EA continuously assess the IRS landscape and proactively identifies and validates needed changes. In addition, the ETB is available online for all IRS employees and contractors with access to the intranet, and anyone may contact the EA team with proposed changes, which EA evaluates, prioritizes, and incorporates as appropriate. Further, the ETB is regularly socialized through briefings, and these sessions provide a forum for stakeholders to provide feedback.

Using the Target Architecture

  1. The Target Architecture is available through a Web-based two-layer framework providing access to the major components of the Enterprise Architecture:

    • The As-Built Architecture

    • The Enterprise Target Architecture

    The Target EA Framework provides pre-established views or perspectives across multiple EA functions as the means to access small content segments based on specific EA topics.

Project Charter Guidance
  1. The Project Chartering process includes guidance for completing the alignment portion of the Charter, a sample of a completed EA Alignment table, a collection of 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 alignment table.

EA Change Requests and 508 Compliance
  1. The Standards and Technology Standards (STM) organization is responsible for administering the configuration and change-management processes. The Change Request (CR) process ensures that all projects adhere to the standards and guidelines set forth in the EA. The ESP complies with high-level section 508 requirements. Enterprise Architecture directs all users of its products to develop, procure, maintain, or use Information and Communication Technology (ICT) ensure that these technologies provide access to information and data for people with disabilities. Unless excepted, these standards apply to all Information systems and products including Development, Procurement, Maintenance, and Official Communication. These standards contain technical criteria specific to the usage of technologies. Additional legislative requirements include Federal Acquisition Requirements (FAR) regulations. Section 508 compliance is a driver for the design of interfaces for all IRS systems. These 508 standards, requirements, and regulations include the provisions for building 508-specific technical requirements, functional performance criteria, and both system and user interfaces into the design.

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

    • Federal Laws and Regulations Applicable to Security, Section 508, and Privacy

    • Security Considerations of Target Architecture Business Processes

    • Data Requirements

    • Section 508 Considerations of Target Architecture Business Processes

    • Security Categories of ETA Business Processes

    • Sensitivity Classification of ECDM Data Classes

    • Security Requirements

    • Privacy Requirements

    • Section 508 Requirements

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

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

    • Allocation of Security Mechanisms to Systems Components

    • Security Processing Thread

    • Security Risk Assessment

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

  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

Functional Work Products
  1. The Functional Work Products define and mandate 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

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:

    • 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

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

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

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.

Using the Enterprise Standards Profile

  1. The Enterprise Standards Profile is applicable to the entire IRS Enterprise. The Enterprise Standards Profile is primarily of interest to readers involved with design, development, and product selection. The product lifecycle status dates provide guidance for technology insertion, product deployment, and version updates as well as identifying when products are no longer supported and must be removed. Vendor product lifecycles change and the ESP alignment captures the information at approval but may be updated when needed or detected to synchronize with industry changes.

Using the Transition Architecture

  1. The Enterprise Transition Architecture comprises three documents: the Transition Strategy, the Release Architecture, and the Enterprise-Wide Sequencing Plan.

Using the Release Architecture
  1. Each release architecture specifies the state of the enterprise after the system deployments planned for a fiscal year. Release Architecture is an incremental step along the transition path.

Using the Enterprise-Wide Sequencing Plan
  1. The Enterprise-wide Sequencing Plan describes how the existing and proposed investments align to the IRS vision and strategy. 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. Impacts of budget cuts or changes to program priorities that result in cancelled or delayed projects can be quickly assessed using the plan.