2.15.1 Enterprise Architecture (EA) Overview

Introduction to the EA

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

Scope

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

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.

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.

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.

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.

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

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

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

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

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

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

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

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.

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.

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

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

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.

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.

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.

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.

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

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.

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.

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

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.

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.

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

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)

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.

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)

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

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

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

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

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.

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.

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.

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.

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

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

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

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

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

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

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

    • Identify the capabilities necessary for achieving the future state

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

    • Outline potential areas of process change

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

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

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

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

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

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

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

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

    • The Acronyms List defines acronyms used in the EA.

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

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

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

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

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

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

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

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

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

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

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

    • Data storage and management

    • Data modeling, categorization and relevant subject areas

    • Data access standards and strategies

    • Authoritative data definitions and guidelines

    • Data resources and technologies, including metadata and XML

    • Data stewardship

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

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

    • Conceptual Technology Architecture

    • System Architecture

    • Technical Architecture

    • Application Architecture

    • Security Architecture

    • System Management Architecture

    • IRS Logical System Architecture

    • Technical Guidance and Design Pattern

    • Service Repository

    • Service Oriented Architecture

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

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

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

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

    • System Requirements items

    • System Design items

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

    • Programmatic requirements

    • Data requirements

    • Functional requirements

    • Traceability of data and functional requirements to business processes

    • Performance requirements

    • Security and requirements

    • System management requirements

    • Technical Requirements

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

    • IRS Logical System Architecture >/ li<

    • Processing Threads

    • System Interfaces

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

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

    • Physical Infrastructure

    • Communication Services

    • Platform and Platform Services

    • Enterprise Services

    • Applications

    • Enterprise Security Services

    • Enterprise Systems Management

    • Technical Requirements

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

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

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

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

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

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

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

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

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

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

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

    • ESM core function details

    • Mechanisms deployed to provide ESM core functions

    • The allocation of ESM mechanisms to system components

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

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

    • Tables of Functions – Systems Allocations

    • Tables of Data Classes – Databases Allocations

    • Tables of Service Entities – Systems Allocations

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

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

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

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

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

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

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

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

Where to find the EA

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

Using the EA

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

    • The As-Built Architecture

    • The Enterprise Transition Architecture

    • The Enterprise Target Architecture

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

Using the EA Roadmap

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

Using the As-Built Architecture

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

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

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

Using the Target Architecture

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

    • The As-Built Architecture

    • The Enterprise Transition Architecture

    • The Enterprise Target Architecture

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

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

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

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

    • Business directions

    • Business drivers and processes

    • Information flows

    • Organization structures

    • Location infrastructures

    • Systems requirements

    • Security and privacy

    • Data design and administration

    • Systems design

    • Technical reference model

    • Transition strategies

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    • Proposed configuration of the IT environment has been modified

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

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

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

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

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

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

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

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

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

    • Programmatic Requirements

    • Enterprise Business Direction Model

    • Enterprise Business Concept of Operations

    • Operational Requirements

    • Organization Direction Model

    • Role Definitions

    • Location Type Definitions

    • Business Process Model

    • Enterprise Context Diagram

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

    • Customer/Needs Process Matrix

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

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

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

    • Cross-Business Process Scenarios

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

    • Programmatic Requirements

    • Business Process Definitions

    • Functional Requirements

    • Traceability of Data and Functional Requirements to Business Processes

    • Allocation of Functional and Data Requirements to Systems

    • Functions to Systems Allocations

    • Processing Threads

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

    • Business Process Definitions

    • Data Requirements

    • Traceability of Data and Functional Requirements to Business Processes

    • Allocation of Functional and Data Requirements to Systems

    • External Systems Interfaces

    • Internal Systems Interfaces

    • Data Classes to Databases Allocations

    • Data Architecture

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

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

    • Performance Requirements

    • Performance Requirements Supporting Data

    • Performance Model

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

    • System Management Requirements

    • Allocation of Functional and Data Requirements to Systems

    • Functions to Systems Allocations

    • Data Classes to Databases Allocations

    • Processing Threads

    • Technical Architecture

    • Technical Reference Model (TRM)

    • Physical Infrastructure

    • Communications Services

    • Platforms and Platform Services

    • Enterprise Services

    • Applications

    • Systems Security Architecture

    • Enterprise Systems Management

    • Performance Model

    • Disaster Recovery

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

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

    • Security Considerations of Target Architecture Business Processes

    • Privacy Considerations of Target Architecture Business Processes

    • Data Requirements (Sensitivity Classification of Data Classes)

    • Security Categories of ETA Business Processes

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

    • Security Requirements

    • Privacy Requirements

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

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

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

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

    • Security Risk Assessment

Using the Enterprise Standards Profile

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

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

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

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

Using the Transition Architecture

  1. The Enterprise Transition Architecture comprises three documents:

    • Enterprise Transition Strategy

    • Release Architecture

    • Enterprise-Wide Sequencing Plan

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

  2. The ETS is the initial framework for:

    • Definition of modernization projects

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

    • Development of Business Systems Modernization spending plans

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

    • Assignment of system interfaces to modernization projects

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

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

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