Section 1. Enterprise Architecture (EA) Overview

(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

(1) Section 2.15.1.2.1 updates to AS-Built Architecture with approved changes by requesting party for this section.

(2) Includes updates to Internal Controls

(3) Update to show current acting CIO

Kaschit Pandya Acting Chief Information Officer

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

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.

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.

Policy Owner: Chief Information Officer

Program Owner: Enterprise Architecture

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

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.

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.

Enterprise Architecture defines the Authority, 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 as outlined within this IRM

Tony R. Smith, Director. Enterprise Services, Enterprise Architecture

Enterprise Architecture is the process of translating the business and strategy into effective enterprise change by creating communicating, and improving the key requirements, principles, and models that describe the future state of the enterprise and enable its evolution

Enterprise Architecture Office sets enterprise technology direction by translating business priorities into an effective enterprise technical framework, setting architecture guidance, and establishing technology standards

Definition

EA

Enterprise Architecture

ABA

As Built Architecture

ETA

Enterprise Transition Architecture

FEA

Federal Enterprise Architecture

OMB

Office of Management and Budget

ETB

Enterprise Technology Blueprint

ELCPMO

Enterprise Life Process Management

STM

Standards and Technology Management

TRM

Technical Reference Model

IRM 2.22.1, Business Planning and Risk Management (BPRM), Unified Work Request (UWR) Process

IRM 2.125.1 Change Management Policy.

IRM 2.17.1, Infrastructure Currency, Infrastructure Currency Policy for Software

IRM 10.8.1, Information Technology (IT) Security, Policy and Guidance

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.

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 is the authoritative repository of all of IRS' Current Production Environment (CPE) with business applications, external systems, and external trading partners. It also includes interfaces, key attributes, business processes, system owner contact information, i Privacy and Civil Liberties Assessments information, and Cybersecurity data. 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.

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.

To ensure the IRS maintains accurate information within the ABA and in compliance with related federal regulations, all application owners and authorizing officials within Business Operating Divisions, Functional Operating Divisions, and Information Technology must:

Provide at least two Points of Contact (POCs) who will be responsible for coordinating the consistent update of application information in the ABA. When applications are owned by multiple organizations, each owning different set of attributes, then each organization should provide two points of contacts.

Update existing and/or new applications information within 30 days of any changes, including but not limited to changes to the nature, usage, or features of the application; system ownership changes; interface changes; privacy or security changes; or platform changes (cloud hosting, operating system, programming language, major frameworks, etc.).

Ensure the author’s manager of record approves any updated information within 30 days.

Annually certify that the application information within the ABA is accurate and current.

Annually EA will report upon applications with outdated data, address updates with application owners and Business System Planners (BSPs) and escalate within each operating division as necessary. Failure to maintain current and accurate ABA information may result in reduction or termination of application support, approvals, and/or funding.

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.

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

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.

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

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

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.

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

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.

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.

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.

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.

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.

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.

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.

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

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.

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 Blueprint

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.

Updating the Technology Blueprint

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.

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.

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.

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.

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

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.

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.

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

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.

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.

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.

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.

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

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.

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.

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.

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.

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

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.

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

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.

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.

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

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.

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.

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

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.

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.

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

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.

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.

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.

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.

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.

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.

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.

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.

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

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.

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.

The Systems Architecture is presented in two logical sections:

System Requirements items

System Design items

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

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

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.

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

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.

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.

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.

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.

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

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.

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

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.

Enterprise Services (ES), Enterprise Architecture (EA), Standards and Technology Management (STM) is responsible for all Information Technology (IT) Commercial Off-the-Shelf (COTS) and Government Off-the-Shelf (GOTS) including computer hardware, software, and appliances for the IRS. STM manages approval of IT products, identifies Manage Services Provider (MSP) contracts and registers them into Enterprise Standard Profile (ESP) repositories. STM also provides leadership and guidance for emerging technologies with the management of approval of proof-of-concepts and demos. STM is essential to the successful alignment of standard technologies to the Enterprise Target Architecture as outlined in IRM 2.15. Only approved products listed in the ESP repositories, in accordance with IRM 2.17 of the Infrastructure Currency Policy for Software, may be deployed in the IRS. The STM intake process will be governed through the ES Front Door and Work Request Management System (WRMS). The intake process and approvals will be managed by STM in collaboration with IT Delivery partners and the IT Change Control Board (ITCCB). The goal of the approval process is to ensure alignment with the strategic roadmap, ensuring products are supported by the IRS and to minimize overlapping functionality. The ESP repositories provide detailed information about the products and their usability status. This IRM applies to all IRS employees wishing to request new computer software, hardware and/or appliances for necessary business usage within the IRS IT infrastructure. Intake for all requests must adhere to all the following steps.

Submit a new software request through the ES Front Door.

1. Follow the guidance on the New Software Request Navigator.

2. Complete the New Software Request Checklist.

3. Finalize Enterprise Architecture Enterprise Standards Profile Change Request (EA ESP CR).

4. Secure approval for the product from the Information Technology Change Control Board (ITCCB).

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

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.

There are three primary uses supported by the ETB.

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.

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.

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.

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.

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.

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

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.

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

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.

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

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

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

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

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

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.

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.

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

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.

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.

More Internal Revenue Manual

Share

Facebook

Twitter

Linkedin

Print