2.15.1  Enterprise Architecture (EA) Overview

2.15.1.1  (02-09-2009)
Introduction to the EA

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

2.15.1.1.1  (02-09-2009)
Scope

  1. The EA is composed of Enterprise As-Built Architecture, Enterprise Transition Architecture and Target Architecture.

2.15.1.1.2  (02-09-2009)
Purpose of the EA

  1. An EA 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.

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

    • Defines a plan for getting from the current state to the desired future state in a Transition Strategy and Release Architecture

  3. Given the large and complex nature of the IRS enterprise, if each project were left to independently interpret the enterprise vision and strategy, there is a high probability that deployed solutions would be non-integrated, inconsistent, and have overlapping or conflicting functionality. These problems would likely lead to excessive cost for development and maintenance, business expectations not being met, inconsistency in delivered business results, longer time to market for changes, inconsistent user interfaces, user and employee frustration, inability to exploit new ways of doing business (such as e-business), violations of security and privacy requirements, and stovepipe solutions that are rigid and unresponsive to change. The purpose of the EA is to help prevent these kinds of problems.

2.15.1.1.3  (02-09-2009)
The Objectives of the EA

  1. The objectives of the EA are:

    • Manage change within the IRS as it modernizes

    • Provide source of document of where business is going and how we will do business in the future

    • Identify business processes and their interactions

    • Provide a foundation for defining the scopes of modernization projects

    • Establish principle of requirements, design and transition for project development

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

    • Identify security and privacy needs for project development

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

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

    • Establish a sound information technology (IT) investment strategy satisfy legislative and other oversight requirements such as OMB Circular A–130.

2.15.1.2  (02-09-2009)
Major components and sub-components of the EA

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

    • As-Built Architecture

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

2.15.1.2.1  (02-09-2009)
AS-Built Architecture

  1. The As-Built Architecture (ABA) represents the IRS' Current Production Environment (CPE) with more than 570 systems identified and more than 200 verified with their owners. 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. See interrelationships between technological and business domains. Get information necessary to make informed decisions about improving or modernizing IRS' IT.

  2. The As-Built Architecture (ABA) is the single definitive representation of the IRS operational environment using the Six Domains of Change. Business-oriented domains are Business Process, Organization, and Location. Technological domains are Application, Technology, and Data. Therefore, 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.

2.15.1.2.2  (02-09-2009)
Enterprise Transition Architecture

  1. The Enterprise Transition Architecture is a part of the Enterprise Architecture, which also contains the As-Built-Architecture (ABA) and the Target Architecture.

  2. The Enterprise Transition Plan (ETP) is a primary product of the Enterprise Transition Architecture and encompasses strategies for transitioning the IRS Enterprise from its current state to its desired future state specified by the Modernized Vision and Strategy (MV&S), Service Oriented Architecture (SOA) Roadmap, Data Strategy, and Infrastructure Roadmap Initiative (IRI), etc. It begins with a description of the Current Production Environment, proceeds through a Near-Term Overview, continues on to Strategic Long-Term Planning.

  3. Governed by the Treasury IT Modernization Blueprint, Treasury Strategic Plan, IRS Strategic Plans, other components of the IRS Enterprise Architecture, OMB EA Assessment Framework, President’s Management Agenda (PMA), and IRS MV&SExecutive Steering Committees. The ETP provides the IRS with critical information for use in making investment decisions and business decisions relative to major and non-major projects.

  4. The ETP consists of the following three components:

    • a. The Enterprise Transition Strategy

    • b. The Release Architecture

    • c. The Enterprise-Wide Sequencing Plan

2.15.1.2.2.1  (02-09-2009)
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.

2.15.1.2.2.2  (02-09-2009)
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 Modernization Vision & Strategy (MV&S) effort and the Enterprise Transition Strategy (ETS). The RA reflects the best IT planning information available at the time of publishing including approved MV&S artifacts, the ETS, the Enterprise-Wide Sequencing Plan, data in the Project Engineering Analysis and Reporting System (PEARS) of the System Architecture and Engineering Division, and the Target and As-Built Architectures.

  2. The RA is organized around IRS IT Projects and their Releases and the IRS MV&S planning domains. The links in the RA show the associations between Projects/Releases and IRS organizations, business goals and objectives, supported business processes, the Target Architecture's requirements, etc. 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.

  3. The RA is produced as a web site allowing the user to study and navigate the complex interrelationships among RA data. The most recently approved version of the RA is maintained on the IRS intranet at http://ra.web.irs.gov.

2.15.1.2.2.3  (02-09-2009)
Enterprise-wide Sequencing Plan

  1. The Enterprise-Wide Sequencing Plan (EWSP) graphically provides an organization-wide view of programs and projects on a timeline with their relationships and impacts across the agency. This gives leadership the visibility to use the EA for organization-wide planning.

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

  3. This enables high-level impact assessment of investment decisions and programmatic changes on the overall plans for moving toward the target EA. Impacts of budget cuts or changes to program priorities that result in cancelled or delayed projects can be quickly assessed using the plan. The effects of those changes on other projects and programs can be identified and dealt with as needed.

2.15.1.2.3  (02-09-2009)
Enterprise Target Architecture

  1. The IRS Target Architecture defines the desired future state of the IRS Enterprise. The Target Architecture comprises the Business Architecture, the Systems Architecture, Application Architecture, Data Architecture, Security Architecture and the Technical Architecture.

2.15.1.2.3.1  (02-09-2009)
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

    • Defines a plan for getting from the current state to the desired future state in a Transition Architecture included in the Enterprise Transition Plan with the Enterprise Transition Strategy and the Release Architecture

2.15.1.2.3.1.1  (02-09-2009)
IRS Modernization Vision and Strategy (MV&S)

  1. IRS’ Modernization Vision & Strategy (MV&S) supports the fulfillment of the IRS mission and strategic goals by establishing a five-year plan that drives information technology (IT) investment decisions based on priorities around modernizing front-line tax administration and supporting technical infrastructure. MV&S leverages existing systems, as defined in the As-Built Architecture, and new development to build IT capabilities, optimize capacity, manage program costs, and deliver business value on an incremental and frequent basis.

  2. As such, it provides the foundation for the IRS Enterprise Architecture. It does so by defining the business vision of the IRS and how the IRS will conduct its business in the future to fulfill its mission, and by providing context for the architectural direction that is reflected in the architecture of the Target EA. This business vision and strategy is then documented within the EA’s Enterprise Transition Plan.

  3. 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 work products describe detailed results-oriented architecture and a transition strategy for each segment area. 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

2.15.1.2.3.1.2  (02-09-2009)
MV&S Domain Overview

  1. The MV&S framework is built on this 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: The Submission Processing Business Domain includes the filing of both paper and electronic tax returns and the initial capture and accounting for tax revenues.

    • Manage Taxpayer Accounts: The Manage Taxpayer Accounts Business Domain includes the data, systems, and processes used to manage taxpayer accounts.

    • Customer Service: The Customer Service Business Domain provides tax law and compliance assistance, taxpayer education, and taxpayer account, refund, and notice inquiries. Customer service assistance is provided through three primary means: Centralized Contact Centers (for phone, written and electronic inquiries), Self-Service applications (via the phone and Web), and Field Assistance (for walk-in assistance).

    • Reporting Compliance: The Reporting Compliance (Examination) Business Domain consists of a set of 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: Filing and Payment Compliance Business Domain includes collecting delinquent tax obligations and securing delinquent tax returns.

    • Criminal Investigation: Criminal Investigation Business Domain is uniquely responsible for the enforcing criminal statutes of the Internal Revenue Code and related statutes.

    • Internal Management: Internal Management Business Domain makes up IRS’ back office and manages IRS human capital and financial accounting. Internal Management also includes support services, such as real estate, education, and communications.

    • Chief Counsel: The Chief Counsel Domain 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 are supported by services that must be available to support the effective and secure execution of the core mission business functions. These 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: Common Business Services Domain includes capabilities that are applicable across business domains and systems, such as case management, workflow management, and document and image management.

    • Infrastructure: The Infrastructure Domain is defined as the 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: The Information Technology (IT) Security and Privacy (S&P) Domain is responsible for integrating 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), into a single program area to increase taxpayer and employee confidence in the way IRS secures its systems and handles sensitive information.

    • Data Strategy: The Data Strategy Domain will develop 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: The mission of the Applications Development (AD) Domain is to deliver integrated software solutions that address the objectives and priorities of the IRS. This translates into specific focus areas – delivering applications for the IRS IT Modernization Vision and Strategy (MV&S), delivering the filing season, and maintaining legacy technology systems.

    • Enterprise Services: The Enterprise Services domain 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.

    • End User Equipment & Services: The End User Equipment & Services Domain mission is to be the first choice for delivering premier IT products and services to the IRS in an ever-changing environment. EUES provides a single point of contact for customers to request MITS products and services; support and guidance for the full range of planning, directing, managing and executing activities related to the desktop environment; inventory management of ADP and non-ADP equipment; support for workstation software integration, testing, and distribution; support for password management applications and data security; support for the Volunteer Income Tax (VITA) Program to ensure filing season readiness; and support for the Integrated Document Solution Enterprise (IDSE).

    • Enterprise Network: The Enterprise Network Domain includes local and wide area network and data transmission services. The strategy for this domain will position the IRS for the 21st century by embracing IT managed services and by tightly coupling its IT operations with business processes.

    • Enterprise Operations: The vision of the Enterprise Operations Domain is to provide efficient, cost effect, secure and highly reliable computing (server and mainframe) services for all IRS business entities and taxpayers.

2.15.1.2.3.1.3  (02-09-2009)
IRS Strategic Goals and Business Process Alignment

  1. Many of the core IRS business processes support the strategic goals as described in the 2005-2009 Strategic Plan. In the current EA 3.1, connect to the link http://irsprime.web.irs.gov/irsea/index_framework.html, the Table1 presents a matrix that associates each of the target IRS business process groups with the Goals and Objectives within the Strategic Plan. The matrix is provided to assist in the development of business cases or E300s to provide a stronger justification of proposed improvements to IRS business processes by demonstrating a clearer line of sight to IRS business results.

2.15.1.2.3.2  (02-09-2009)
EA Roadmap

  1. The IRS EA provides two major Architecture Roadmap Initiatives.

  2. The IRS Enterprise Architecture Roadmap describes the intended use, scope, and depth of the IRS Enterprise Architecture (EA), and presents the strategy for evolving the Enterprise Architecture. The EA Roadmap also provides a vehicle for managing the Enterprise Architecture Program – the collection of activities, services, and processes necessary to achieve the Enterprise Architecture strategy. Finally, and perhaps most importantly, the EA Roadmap provides a vehicle by which the IRS can agree on a common intent towards the Enterprise Architecture and how it is to be used. The Enterprise Architecture Roadmap is a dynamic resource and will be updated as progress is achieved and/or priorities are changed.

  3. The IRS SOA Roadmap covers the aspects necessary to evolve and sustain the Service-Oriented Architecture in the IRS. The IRS SOA Roadmap is an integrated program plan that identifies which teams are working on which SOA projects/initiatives, and the key dependencies among these projects. The SOA Roadmap is used to track the activities of the different teams that contribute to the SOA build-out.

  4. The IRS SOA Roadmap is used to articulate the capabilities of the IRS SOA initiative, expressed as a capability maturity model; identify a specific approach to reach the next level of maturity; and provide a conceptual project plan to be used as a basis for developing a detailed project plan and allocating responsibility to accomplish each of the activities.

2.15.1.2.3.3  (02-09-2009)
EA Principles

  1. The IRS EA presents and describes the IRS Enterprise Architecture Principles. Enterprise Architecture Principles are an integral part of the IRS Enterprise Architecture and provide the basis for defining architectural strategies and making implementation choices. The Principles contained in the EA are statements of preferred architecture 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.

2.15.1.2.3.4  (02-09-2009)
EA Requirements

  1. Enterprise Architecture Requirements are required by federal law, IRS enterprise architecture principals and IRS Modernization Vision and Strategy. The Enterprise Architecture Requirements include:

    • Programmatic requirements

    • Security requirements

    • Privacy requirements

    • Performance requirements

    • System management requirements

    • Functional requirements

    • Traceability of data and functional requirements to business processes

2.15.1.2.3.4.1  (02-09-2009)
Programmatic Requirements

  1. The IRS EA presents programmatic requirements for the IRS Business Systems Modernization Program. In all cases, these programmatic requirements have been established on the basis of higher authority (for example, the U.S. Congress) and exist independently of the IRS EA. Therefore, they are merely referenced herein, rather than stated explicitly. 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. The IRS EA describes the following three varieties of programmatic requirements:

    • Programmatic requirements based on Federal laws and regulations applicable to all agencies

    • Programmatic requirements based on Federal laws and regulations applicable to the IRS

    • Programmatic requirements based on Federal laws and regulations applicable to security and privacy

    The following information is provided for each programmatic requirement

    • Requirement identification (ID) consists of the prefix PRGR and a four-digit integer

    • Title of programmatic requirement

    • Internet URL (universal resource locator), which is either a direct link to the full text of the programmatic requirement, a link to a Web page that contains the full text, or a link to a Web page that contains a link to the full text.

    • Description. Wherever possible, the description is a quotation from introductory material within the text of the programmatic requirement. For those programmatic requirements that do not contain concise descriptions of themselves, a description from another source is provided. In such cases, the URL of that source is provided.

    • Applicability. Applicability is the primary relationship between the programmatic requirement and the IRS EA. However, given the broad scope of many of the programmatic requirements, these statements should not be interpreted as precluding other relationships between the programmatic requirements and the IRS EA or other relationships between the programmatic requirements and the IRS.

2.15.1.2.3.4.2  (02-09-2009)
Security Requirements

  1. The primary purpose of the Security Requirements model is to specify security requirements for the IRS Enterprise Target Architecture (ETA). In addition to that model, two supporting models are also included here–in all, three models:

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

2.15.1.2.3.4.3  (02-09-2009)
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 here:

    • Traceability of Privacy and Technical Security Requirements to Business Process Security and Privacy Considerations: Traces the requirements of the Privacy Requirements model to what are called the 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

2.15.1.2.3.4.4  (02-09-2009)
Performance Requirements

  1. The IRS EA describes high-level system performance requirements. Five categories of performance requirements are specified:

    • Enterprise Workload Requirements

    • Enterprise Response Time Requirements

    • Enterprise Reliability, Maintainability, and Availability Requirements

    • Enterprise Quality of Service Requirements

    • Device Capacity Guidelines

    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.

  2. Each performance requirement has a unique identifier in the form PR nnnn in EA, where PR stands for performance requirement, and nnnn is a unique four-digit numeric string. In order to preserve uniqueness and avoid ambiguity, a requirement’s identifier is not reused when the requirement is deleted.

2.15.1.2.3.4.5  (02-09-2009)
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 MIS devices, systems, applications, processes, and system platforms (Tiers I, II, III) 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. Described below are arrays of management capabilities that must be provided in order to achieve a "best-practice" ESM solution for the IRS:

    • Enterprise Systems Management core functions shall touch almost all operational boundaries in the Enterprise.

    • Operating systems and applications alike require regular application of maintenance patches.

    • Financial analysts require an accurate understanding of existing hardware and software assets in use throughout the agency.

    • Contract management personnel require the ability to track the level of service level agreements (SLAs) by their respective service providers.

    • MIS operations must ensure the constant availability of mission-critical services and applications.

    • IRS customers and employees both need to be assured that the problems they encounter are addressed and resolved as expeditiously as possible.

    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.

2.15.1.2.3.4.6  (02-09-2009)
Functional requirements

  1. The IRS 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

2.15.1.2.3.5  (02-09-2009)
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 derived from the MV&S

    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: Business architects are key users of the Business Architecture. They use the Business Architecture to inform and 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 designs

    • A set of comprehensive sources of guidance is available to business architects. These sources include the Enterprise Lifecycle (ELC) Methodology, the ConOps Guidance Toolkit, and the supplementary materials available on the IRS EA website.

    In particular, the ConOps Guidance Toolkit enables the business architects to guide the ConOps (or V&S) project teams in planning and conducting necessary activities in a structured and efficient manner and in developing and refining required business architecture models and information. The ConOps Guidance Toolkit and the ELC Methodology provide guidance for creating and refining all necessary models.

  3. Project Managers: Project Managers of business and technology projects are also key users of the Business Architecture. They use the Business Architecture to inform and 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

    Project managers also have the ELC and ConOps Guidance Toolkit as key resources for planning and managing their work.

  4. Business and IT Planners: Business and IT Planners of business and technology change projects are also key users of the Business Architecture (and of the Enterprise Transition Strategy, which is also an element of the EA). They use the Business Architecture to inform and 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: Process designers of business and technology change projects are also key users of the Business Architecture. They use the Business Architecture to inform and 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: Financial Analysts who are supporting business and technology change projects are also key users of the Business Architecture. They use the Business Architecture to 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)

2.15.1.2.3.5.1  (02-09-2009)
Business Services

  1. A Business Service is a complete business transaction or interaction that the IRS conducts with a customer, partner, or stakeholder. A Business Service is an actual service that the IRS provides (or wants to provide in the future) that delivers something of recognizable value to one or more stakeholders. It can be a Tax Service (for example, answering a tax law question, processing a tax return, answering an account inquiry, issuing and/or validating a Taxpayer Identification Number [TIN], delivery of a Transcript or even a set of Transcripts for a group of TINs in batch mode, or providing a Letter of Determination), or a service that provides a Tax Product (for example, the provision of a tax form or tax publication, that can be delivered in either paper or electronic form). 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.

2.15.1.2.3.5.2  (02-09-2009)
Business Processes

  1. The IRS EA Describes the Enterprise-level, future-state business processes that will support the modernized 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)

2.15.1.2.3.5.3  (02-09-2009)
Cross Business Process Scenarios

  1. The IRS EA provides business scenarios that demonstrate how selected business processes contained in the IRS 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 IRS business functions under a variety of business conditions

    • To demonstrate cross-business process integration

2.15.1.2.3.5.4  (02-09-2009)
Custodial Financial Controls

  1. The IRS has, in addition to the traditional administrative accounting applicable to all government agencies, the added custodial requirement to manage the receipt and disbursement, and related assets and liabilities, of taxpayer accounts. Creating and applying financial controls to these activities is not just good accounting practice. 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 (which also contains an extensive list of pertinent laws and regulations), 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 added responsibility for safeguarding the taxpayer’s money makes custodial financial controls an important topic in the EA. The IRS has the custodial responsibility to manage the receipt and disbursement, and related assets and liabilities, of taxpayer accounts. Control of these financial events is critical and required.

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

2.15.1.2.3.5.5  (02-09-2009)
IRS Enterprise Context Diagram

  1. The IRS Enterprise context diagram profiles the business environment in which the IRS operates. In doing so, 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. Hierarchically structured entities are abstractions of organizations or people, which are defined by the roles they play (or will play) within the IRS.

  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 IRS Enterprise Context Diagram describes a conceptual view of the external entities with which the IRS interacts. The figure includes channel partner interactions. Interfaces between third parties and taxpayers are included in the domain of the context diagram. Internal IRS organizations are not displayed on the context diagram. The current and future states of internal process flows and organization design are described in other model views.

  4. The external entities are organized hierarchically with top-level entities broken down into second-level and sometimes third-level entities. Each entity has an EE-xx identifier. This hierarchical organization parallels the Enterprise Conceptual Data Model’s definitions of taxpayer and third party. The IRS EA (in Context Diagram Entity and Interface Definitions) presents the complete hierarchical organization and provides detailed definitions of the entities and interfaces. Only the most significant, higher level external entities are presented in the IRS Enterprise Context Diagram. 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

2.15.1.2.3.5.6  (02-09-2009)
Business Process / Functional and Data Requirement Matrix

  1. The IRS 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 by Domain and its data and functional requirements as specified in the Conceptual Data Model and Functional Requirements by Domain sections. These linkages are illustrated in a table in EA corresponding section. The table is divided into four columns, sorted by the first column:

    • Number: The number of the business process as identified in the business process definitions (NOTE: the entire table is sorted by this column)

    • Title: The title of the business process as identified in the business process definitions

    • EA 3.1 Functional Requirements Supporting the Process: The title of the corresponding functional requirements derived from the business process definitions

    • Supporting EA 3.1 Data Classes: The data classes that support the derived requirements

2.15.1.2.3.5.7  (02-09-2009)
Functional Requirements

  1. The IRS 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 functional requirement. 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.

    Here does not include security, privacy, performance, and system management functional requirements, which are described elsewhere.

2.15.1.2.3.5.8  (02-09-2009)
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

    Each thread is described as a sequence of actions. Most of these actions are automated by particular software applications within IRS systems. However, some actions may be manual. The processing steps are depicted in one or more figures. Solid arrows depict the logical flow from step to step. Systems involved in the sequence of steps are shaded. Dotted arrows indicate the exchange of data with specific IRS data stores, which are likewise shaded. As appropriate, additional symbols are added to the figures to indicate human participants and particular types of information (for example, a letter symbol for any paper tax form, correspondence, or notice). A table accompanies each figure and provides a detailed description of the actions in each step in the EA. These steps are numbered to correspond to the associated figure. The IRS system (in capital letters) and application (underlined) that perform each step are first identified, followed by the detailed actions within that step.

2.15.1.2.3.6  (02-09-2009)
Organization and Location

  1. The Organization Model View consists of the following:

    • Organization Descriptions identifies and describes the organizational entities that comprise the modernized 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. These ConOps scenarios describe how these organizations will operate in the future to achieve their mission and strategic goals.

    • Business Concepts of Operations refers to the framework IRS 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. Many organization business ConOps summaries are included within the Organization Descriptions document, while Select Business ConOps Scenarios and Business Concepts of Operations Details in their entirety are available for reference.

    • Role Definitions identify, classify and explain the roles that support the core business of the IRS. IRS business processes are associated with the specific Roles that perform them in Process / Role Matrices that accompany each business process area description, located elsewhere in the EA.

    The Location Model View consists of the following:

    • Location Type Definitions identify and classify all of the distinct types of locations where the IRS does business (directly or indirectly) or where critical functions are performed in support of IRS business or technical operations. IRS business processes are associated with the specific Location Types at which they are performed in Process / Location Type Matrices that accompany each business process area description, located in the Business Processes section of the EA.

2.15.1.2.3.6.1  (02-09-2009)
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 modernized 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 IRS EA provides summaries of organization-level business concepts of operations (ConOps) that have been completed, processed, and approved for inclusion in the EA. These ConOps describe how various IRS organizations will operate in the future to achieve their mission and strategic goals. The modernized organizations as described have been envisioned as a result of the ConOps efforts and are established in order to support the modernized mission and goals. ConOps scenarios show examples of how the modernized organizations will perform selected key functions. The full business ConOps and representative business ConOps scenarios from which these summaries are drawn are also available in the IRS EA.

2.15.1.2.3.6.2  (02-09-2009)
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.

2.15.1.2.3.6.3  (02-09-2009)
Location Type Definitions

  1. The Location Type Definitions identify and classify all of the distinct types of locations where IRS does 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.


More Internal Revenue Manual