Attachment_2.pdf

PBGC EAD: Business Needs Analysis Standard Purpose The purpose of this standard is to define and communicate the process for developing and maintaining segment and other architectural analyses.

When aggregated, these architectural analyses form part of the foundation of the Pension Benefit Guaranty Corporation (PBGC) Enterprise Architecture (EA).

Scope This standard applies to all PBGC business needs that require or are expected to be addressed by an IT solution.

This standard is applicable to all PBGC organizations that use information technology to meet business needs.

Authority/ References OMB Circular A-130, “Management of Federal Information Resources”

Approving Body Technical Review Board (TRB)

Owner Enterprise Architecture Division (EAD)

Collaborator Enterprise Cybersecurity Division (ECD), IT Infrastructure Operations Department (ITIOD), Project Management Division (PMD), and

IT Portfolio Division (ITPD)

Implementer Enterprise Architecture Division (EAD), Information Technology & Business Modernization Department (ITBMD) Service Divisions, IT Program Owners

Standard Type Technical

Control Number IT1.1-T Business Needs Analysis, Technical, PBGC Business Needs Analysis Standard.

Standard A Business Needs Analysis (BNA) is a research and analysis effort that results in recommendations for a specific business area or issue. Recommendations may address issues in some or all of the following architectural categories:

Strategy and Performance Business Data and Information Applications Infrastructure Information Security

A business needs analysis addresses potential gaps, redundancies and opportunities that result in improved performance in these areas. A Business Needs Analysis is generally composed of a current state, target state and migration plan.

The BNA Standard establishes a common approach to architecture known as PBGC Common Architecture Methodology (PCAM). PCAM is a customized

November 2014 Page 1 of 2

Attachment 2 methodology that provides guidance for conducting business needs analyses to support prioritization, investment and planning decisions as well as establishes or confirms the alignment of these decisions to PBGC’s business plans and strategic goals.

Metrics For future use.

Owner Signature John Larsen Chief Enterprise Architect

11/06/2014

Approval Signature (TRB or GCB) John Larsen

TRB Chair

11/06/2014

November 2014 Page 2 of 2 yarjv60 Stamp

Stamp

PBGC Business Needs Analysis Methodology v2.0

Enterprise Architecture

Revision History Version Date Change Description Point of Contact

2.01 12/31/2013 This update is a major revision of the BNA standard driven by significant changes in prevailing federal guidance and best practices. BNA integration with the PBGC enterprise architecture is defined. All references of FSAM were removed and replaced with guidance from FEAF v2 and the Common Approach to Federal Enterprise Architecture.

Sage Kim

Approval

Signer/Title Signature Date

John Larsen Chief Enterprise Architect Manager, Enterprise Architecture Division

John Larsen Chair, Technology Review Board (TRB)

1 This version is a rewrite of the standard and as a result, the revision history begins with version 2.0 i

Stamp

Table of Contents Executive Summary

Introduction .......................................................................................................................................... 5 1 Business Needs Analysis Standard Overview ........................................................................................ 7 2

2.1 Enterprise Architecture Definition and Value

2.2 Business Needs Analysis Definition and Value

2.3 BNA Federal Alignment

2.4 Architect-Invest-Implement Paradigm

2.5 BNA Line of Sight

2.6 BNA Success Factors

PBGC Common Architecture Methodology ........................................................................................ 12 3

3.1 Roles and Responsibilities

3.2 Methodology for Conducting the Business Needs Analysis

3.2.1 Phase 1: Identify and Validate

3.2.2 Phase 2: Research and Leverage Phase

3.2.3 Phase 3: Define and Plan Phase

Scaling Framework .............................................................................................................................. 20 4

4.1 Scaling Framework Matrix

4.2 Artifacts Matrix

Configuration and Change Management ............................................................................................ 28 5

5.1 Change Management Overview

5.2 BNA Next Steps

Appendix I: BNA Planning Appendix II: Definitions Appendix III: Authority/References

List of Figures Figure 1: PBGC Common Architecture Methodology Figure 2: Line of Sight Figure 3: Architect-Invest-Implement Paradigm Figure 4: EA Guiding Principles Figure 5: Architect-Invest-Implement Paradigm Processes Figure 6: BNA Line of Sight Figure 7: PCAM alignment to CPM – Organize and Plan Phase Figure 8: BNA Roles and Responsibilities Figure 9: Identify and Validate Phase Figure 10: Research and Leverage Phase Figure 11: Define and Plan Phase

List of Tables Table 1: Step 1 – Kickoff Summary Table 2: Step 2 – Discover Summary Table 3: Step 3 – Interview Summary Table 4: Step 4 – Analyze Summary ii

Table 5: Step 5 – Identify Summary Table 6: Step 6 – Define Summary Table 7: Step 7 – Recommend Summary Table 8: Step 8 – Present and Socialize Summary Table 9: Step 9 – Close-out Summary Table 10: BNA Selection Criteria Table 11: BNA Artifact Matrix Table 12: Expected Duration for Completing BNA Phases iii

Executive Summary

The purpose of the Pension Benefit Guaranty Corporation (PBGC) Business Needs Analysis (BNA) Standard and Methodology is to communicate the definition, value and process of conducting segment and other architectural analyses as part of an overall Enterprise Architecture (EA) at PBGC.

EA is a management practice focused on performance improvement through the alignment of strategic objectives, business needs, and information technology capabilities. EA helps PBGC identify whether its resources are properly aligned to the agency mission and strategic goals and objectives. This document further defines EA and how it is used to drive business decisions toward a more effective and efficient agency.

A Business Needs Analysis is a planning and analysis effort that may recommend performance, business, data, application, infrastructure and security, improvements to be achieved in the target state. BNAs are driven by PBGC’s Strategic Plan and PBGC’s IT Strategic Plan and are intended for use by all businesses within the agency that require an Information Technology (IT) solution. The types of BNAs include Segment Architecture, Architectural Analysis, and Small-Scope Analysis. The applicable BNA type is determined based on size, complexity, and scope of the effort and is discussed in further detail in this document.

This document also describes the PBGC Common Architecture Methodology (PCAM) as a method for conducting a BNA. This process, highlighted below, is a simple and repeatable three-phase process as a suggested method for conducting a BNA.

Figure 1: PBGC Common Architecture Methodology

A scaling framework is provided as a guide for how to tailor this process for any size of analysis as well as suggested deliverables for each phase of the BNA. This scaling framework also suggests timelines for completing each phase of the PCAM depending on the size and scope of the analysis.

This BNA Methodology also provides a Line of Sight (as shown in Figure 2) that shows the relationships between the architectural layers within PBGC’s IT. This Line of Sight is used to identifying potential gaps or redundancies in between the architectural layers.

Addressing these gaps and redundancies leads to performance and process improvements, reduction in the IT footprint, as well as significant cost-savings for the agency.

Finally, this BNA Methodology provides guidance for maintenance of the BNAs as well as offer “next steps” following the completion of the analysis. BNA recommendations should be prioritized by the business units within PBGC and then conduct an alternatives/options analysis as appropriate.

Interview Discover

Phase 1 Identify and Validate

Phase 2 Research and Leverage

Phase 3 Define and Plan

Kickoff 1 2 3

Identify (Baseline) Analyze

4 5 Recommend Define

(Target) Close-out Present & Socialize

6 7 8 9

Figure 2: Line of Sight

Introduction 1

The Pension Benefit Guaranty Corporation (PBGC) Business Needs Analysis Standard leverages federal and industry best practices and aligns with Corporation’s Architect-Invest-Implement paradigm, as shown below, to integrate strategic drivers, business requirements, and technology solutions to support planning, decision-making and strategic goal achievement.

Figure 3: Architect-Invest-Implement Paradigm

A Business Needs Analysis (BNA) is a planning and analysis effort that recommends business, security, technology, and/or data improvements to be achieved in the target state. The BNA Standard and methodology establishes a common approach to architectural analysis known as PBGC Common Architecture Methodology (PCAM). PCAM is a customized methodology that provides guidance for conducting business needs analyses to support the definition of a target state, performance improvement, prioritization, investment and planning decisions. It also establishes or confirms the alignment of these decisions to PBGC’s business plans and strategic goals through a series of workshops.

The PCAM may be tailored in terms of process, roles, and artifacts based on size, complexity, and scope of the analysis efforts to ensure the analysis goals are accomplished. The three types of architectural analysis efforts at PBGC are Segment Architecture, Architectural Analysis, and Small-Scope Analysis, and the PCAM provides a detailed guidance for conducting each type of business needs analysis:

Segment Architecture A Segment Architecture is a planning effort to produce a holistic view of a business area (e.g., a segment) from an architectural perspective. The architectural perspective may address elements of strategy, performance, business, data, applications, infrastructure and security of a given domain. The Segment Architecture Approach provides guidance to develop a new or refresh an existing segment, and is designed to accommodate increased flexibility, applicability, and inclusivity of the larger set of the planning processes.

Architectural Analysis An Architectural Analysis is a focused research or planning effort, and the scope is smaller than a full segment, or segment architecture work has been completed and needs additional details. The Architectural Analysis Approach is designed to meet the investment owners’ specific technical or budget planning goals for architectural analyses of all sizes.

Small-Scope Analysis A Small-Scope Analysis is a limited-scale analysis where goals, objectives, weaknesses and opportunities are

Architect Invest Implement Solution

Implementation Investment Planning &

EA Support BNA: Segment Architecture &

Architectural/Small-Scope Analysis known. The Small-Scope Analysis Approach follows the same general guidelines and principles for an Architectural Analysis except that some activities and deliverables may be removed due to the decreased size and complexity of the analysis scope.

The Segment Architecture Approach, Architectural Analysis Approach and Small-Scope Analysis Approach are leveraged by the Enterprise Architecture Division (EAD) to ensure all necessary details of the subject domain are documented to inform the enterprise target architecture, investment prioritization decisions, product selections, development timeframe decisions, and ultimately develop an effective enterprise architectures that support PBGC’s mission.

Business Needs Analysis Standard Overview 2

2.1 Enterprise Architecture Definition and Value

Enterprise Architecture (EA) is a management discipline focused on performance improvement through the alignment of strategic objectives, business needs, and information technology capabilities. EA facilitates the consensus and definition of the organizational future state.2 EA helps an organization identify whether its resources are properly aligned to the mission and strategic goals and objectives. EA is used to drive decisions about the information technology (IT) investment portfolio as a whole.3

The business and technical advantages that result from an enterprise architecture bring important business benefits that are clearly visible in the bottom line:

Improved organizational performance o Identification of strategic, tactical and operational performance needs o Providing a framework to analyze the relationships and common business needs across functional organizations A more efficient IT operation:

- Lower software development, support, and maintenance costs;

- Increased portability of applications;

- Improved interoperability and easier system and network management;

- Improved ability to address critical enterprise-wide issues like security; and

- Easier upgrade and exchange of system components.

Better return on existing investment, reduced risk for future investment:

- Reduced complexity in IT infrastructure;

- Maximum return on investment in existing IT infrastructure;

- The flexibility to make, buy, or out-source IT solutions; and

- Reduced risk overall in new investment, and the costs of IT ownership.

Faster, simpler, and cheaper procurement:

- Buying decisions are simpler, because the information governing procurement is readily available in a coherent plan; and

- The procurement process is faster - maximizing procurement speed and flexibility without sacrificing architectural coherence.4

PBGC understands that the effective management of information through IT is the key to business success. An Enterprise Architecture addresses this need, by providing a strategic context for the evolution of the IT system in response to the constantly changing needs of the business environment.5 Enterprise Architecture delivers value to the PBGC by:

Describing the current and future state of the PBGC;

Defining the desired results for PBGC;

Determining what resources are used to achieve measurable performance improvements for an

PBGC’s core mission areas and common or shared services;

Leveraging business and information management resources across the agency;

2 PBGC Intranet: Information Technology- Enterprise Architecture http://intranet/it/ea/default.cfm 3 Office of Management and Budget, FEA Practice Guidance, November 2007, 1-5.

4 Ibid.

5 Ibid.

Developing a transition strategy to achieve strategic goals and objectives and target performance improvements; and

Measuring the value of EA products and services to inform decisions in other practice areas and support business results.6

2.2 Business Needs Analysis Definition and Value

In order to develop the baseline (“As-Is” or Current State) architecture, target architecture, and a sequencing plan, PBGC uses a planning effort that recommends business, security, technology and/or data improvements to be achieved in the target state. This planning effort is known as the Business Needs Analysis (BNA).

The purpose of the BNA is to:

Ensure a business need or performance gap is considered in the enterprise context and based on analysis;

Facilitate deliberate prioritization, investment, and planning decision making and establish/confirm alignment with PBGC and Information Technology (IT) strategic goals, performance goals and priorities, and strategies;

Recommend the target state with performance measures; and Enable prioritization of business needs.

BNAs define a simple roadmap for a core mission area, business service or enterprise service, is driven by business management, and delivers products that improve the delivery of services to PBGC staff and customers. From an investment perspective, BNAs drives decisions for a business case or group of business cases supporting a core mission area or common or shared service. The primary stakeholders for BNAs are business owners and managers.7

BNA is related to EA through three principles: structure, reuse and alignment. First, the BNA inherits the framework used by the EA, although it may be extended and specialized to meet the specific needs of a core mission area or common or shared service. Second, BNA reuses important assets defined at the enterprise level including: data; common business processes and investments; and applications and technologies. Third, BNA aligns with elements defined at the enterprise level, such as business strategies, mandates, standards and performance goals.8

The BNAs are driven by PBGC Strategic Plan and IT Strategic Plan that “provides the framework to align IT resources with PBGC’s strategies, describes the IT goals and objectives that support PBGC’s strategic focus areas, and drive IT Portfolio Management decisions,”9 and are intended for use by all PBGC departments that require an IT solution. BNAs are required in the following scenarios:

A BNA for the requirement has never been conducted;

The previous BNA was completed three or more years ago; or The previous BNA was completed within the last three years but requires a re-evaluation due to a shift in business or technology environment.

The BNA is facilitated by the EA Project Team consisting of a Federal EAD Lead and other team members assigned to perform research and analysis and produce the agreed-upon artifacts. All analyses must

6 Office of Management and Budget, FEA Practice Guidance, November 2007, 1-2.

7 Office of Management and Budget, FEA Practice Guidance, November 2007, 1-5.

8 Ibid.

9 Pension Benefit Guaranty Corporation, Information Technology Strategic Plan v1.1, 31 December 2013, 7.

consider the EA Guiding Principles (Figure 2) during the BNA effort. Though these principles are prescribed for EAD, they leverage federal and industry best practices and guidance to inform planning decisions.

Figure 4: EA Guiding Principles10

A BNA also ensures that the target state is aligned with PBGC’s business and technology strategic direction, and occurs before any specific technology solutions are considered funded for procurement before implementation begins. Therefore, BNAs must take place before Capital Planning and Investment Control (CPIC) and other investment, budgeting or acquisition activities.

2.3 PBGC BNA and Federal Alignment

To assist organizations in successfully developing, maintaining, and using an EA, the Government Accountability Office (GAO) issued an Enterprise Architecture Management Maturity Framework. The framework consists of three interrelated components: (1) seven hierarchical stages of management maturity; (2) four representations of management attributes that are critical to the success of any program or organizational endeavor; and (3) 59 elements, or building blocks, of EA management that

10 PBGC, Enterprise Architecture Program Management Plan, October 2013, 2.

EA Guiding Principles

Demonstrate Business Need Before Investing – Before making a new technology investment, agencies must be able to articulate clearly the investment’s purpose and how business requirements will be met by the investment.

Evaluate Cloud First – Consistent with Office of Management and Budget (OMB) “Cloud First Policy,” a cloud alternative should be evaluated as an option in solution planning, product and service selection, and solution implementation whenever possible.

Design Effectively and Efficiently – Make greater use of cloud and shared service providers and off-the-shelf technology solutions rather than defaulting to costly, customized ones. Do not reinvent functionality. Common needs should be met by constructing and using common, scalable services.

Build and Implement Gracefully – Utilize iterative methods to promote adaptive planning, evolutionary development and delivery, and encourage rapid and flexible response to change.

Emphasize development, teamwork, collaboration, and process adaptability throughout the life-cycle of the project.

Leverage Industry Standards or Best Practices – The use of industry standards increases the robustness of the standard and reduces deployment time and costs for PBGC to adopt that standard. These standards could include the National Institute of Standards and Technology, World Wide Web Consortium, or other professional communities of interest.

Design with the Enterprise in Mind – Any solution design must consider the needs of the Corporation by being modular and scalable, allowing for new technologies and configurations to be deployed with minimal cost and impact.

are at the core of an EA program. Each of the seven maturity stages reflects those EA management conditions that an enterprise should meet to logically build on the capability established at the preceding stage. As such, the stages provide a road map for systematically maturing or evolving an organization's capacity to manage an EA.11 In alignment with the GAO Maturity Model, BNAs fall under Step 3 (Developing Initial EA Versions) and Step 4 (Completing and Using an Initial EA Version for Targeted Results) of the seven maturity stages.12

The BNA also aligns with Federal Enterprise Architecture Framework (FEAF) v2 Consolidated Reference Models (see section 4.2 Artifacts Matrix for specifics), and defines the PBGC Common Architecture Methodology (PCAM) for conducting research to enable analysis and produce recommendations and deliverables. The PCAM aligns with Collaborative Planning Methodology (CPM) that is intended to account for the full lifecycle of analysis at all levels of scope as defined in The Common Approach to Federal Enterprise Architecture (CAFEA).

2.4 Architect-Invest-Implement Paradigm

BNA development is a collaborative process forming a bridge between enterprise-level planning and the development and implementation of solution architecture. This process is a critical element of an integrated lifecycle process to define stakeholder requirements, drive investment, and implement business and information management solutions.

As illustrated in Figure 1, the BNA Standard is a part of the “Architect” phase of PBGC’s Architect-Invest- Implement paradigm. This paradigm provides the foundation for sound IT management practices, end-to-end governance of IT investments, and the alignment of IT investments with PBGC’s strategic goals.13 The Figure below further illustrates the processes included in each phase of the paradigm as well as the processes included in the transition between phases.

Phase Processes

Architect

Develop and maintain the EA as the shared view of the current and future state of PBGC

Define and prioritize segments as part of the EA transition strategy that defines the sequencing of BNAs

Develop architecture to provide a bridge between the enterprise vision (EA and EA transition strategy) and the investment in and implementation of individual business and information management solutions

Invest

Define the implementation and funding strategy for individual solutions identified in the EA transition strategy and described in the BNA

Create the program management plan to implement the individual solutions identified in the implementation and funding strategy

11 United States Government Accountability Office: Organizational Transformation, A Framework for Assessing and Improving Enterprise Architecture Management (Version 2.0), August 2010.

12 Ibid.

13 Office of Management and Budget, FEA Practice Guidance, November 2007, 1-1.

Phase Processes

Implement

Execute projects according to the program management plans.

Measure performance to determine how well the implemented solutions achieve the desired results and mission outcomes and provide feedback into the enterprise and segment architecture development processes

Figure 5: Architect-Invest-Implement Paradigm Processes14

BNA work products describe detailed results-oriented architecture and a transition strategy for core mission areas, business services and enterprise services. They also drive investment planning and resource allocation for a core mission area or common or shared service. Sufficient resources are identified and justified to execute the BNA recommendations and achieve measurable performance improvements.

2.5 BNA Line of Sight

PBGC has adopted the Federal Enterprise Architecture Framework (FEAF) version 2 as its enterprise architecture framework.

Published by the Office of Management and Budget in 2010, the restructured framework now includes information security, and updates to all other architectural layers. These layers form the basis of the PBGC enterprise architecture. Figure 6 shows a Line of Sight that depict where relationships exist between the different architectural layers within PBGC IT. These layers include Strategy and Performance, Business, Data and Information, Applications, Infrastructure, and Security. Developing this Line of Sight is a key activity in the BNA process.

A break in the Line of Sight may indicate a potential gap that may impact performance, quality, or strategic goal achievement.

Multiple items in one relationship may indicate overlap or redundancies. These gaps and redundancies reveal opportunities to improve or develop business capabilities that achieve strategic goals or change technology services that will help PBGC become more effective or efficient.

2.6 BNA Success Factors

One of the key contributors to the success of a BNA is to have a simple and concise vision for the BNA defined and understand how it relates to PBGC’s overall vision and strategic goals. Performance goals should also be defined and progress should be monitored. The following success factors reflect PBGC best practices and can be applied to enhance the effectiveness of the BNA:

Identify key business questions the BNA should address;

Develop work products to support business questions;

Focus work product development on priority business questions;

Evaluate opportunities to increase agency and government-wide collaboration and reuse; and Monitor progress, measure performance, and verify outcomes.15

14 Office of Management and Budget, FEA Practice Guidance, November 2007, Table 1-1.

15 Ibid at 2-6.

Figure 6: BNA Line of Sight

PBGC Common Architecture Methodology 3

The PBGC Common Architecture Methodology (PCAM) is a simple and repeatable three-phase process that leads the Enterprise Architecture (EA) Project Team through a collaborative analysis effort of assessing the baseline, developing the desired state, and defining recommendations and roadmap for the target state. The PCAM aligns with Federal Enterprise Architecture Framework (FEAF) v2 allowing for flexible scope for different types of analyses and establishing a customizable set of required artifacts.

The three phases of the PCAM align to the Organize and Plan phase of the Collaborative Planning Methodology (CPM), as demonstrated in the graphic below.

Figure 7: PCAM alignment to CPM – Organize and Plan Phase

The PCAM was customized based on the following considerations:

• PBGC is a small government agency created by the Employee Retirement Income Security Act of 1974;

• Clinger Cohen Act statutory authority;

• PBGC has established an EA Program under the authority of OMB Circular A-130; and

• The Chief Information Officer (CIO) and the CIO Leadership team carefully review Federal guidance to determine applicability to PBGC.

The PCAM ensures that PBGC’s EA programs are complete and are effective in developing solutions that support planning and decision-making. The Enterprise Architecture Division’s (EAD) role is to “provide facilitation and integration to enable this collaborative planning discipline, and work with [business and IT] subject matter experts from these planning groups in order to formulate a plan of action that not only meets needs but is also implementable within financial…and organizational constraints.”16

3.1 Roles and Responsibilities

One of the key components to a successful BNA effort is to have a clear understanding of roles and responsibilities of all the participants. Not all roles are required for each type of BNA (see table below) but must be considered as potential participants by the BNA Executive Sponsor and Federal EAD Lead when preparing for an analysis. In all analyses, the BNA Executive Sponsor and Federal EAD Lead work together to determine the Core Team members who are required for each BNA.

16 Office of Management and Budget, The Common Approach to Federal Enterprise Architecture, 2 May 2012, 15.

Collaborative Planning Methodology (CPM) – Organize and Plan Phase 1

Identify and Validate Phase 2 Research and Leverage

Phase 3 Define and Plan

Kickoff 1 2 3

Identify (Baseline) Analyze

4 5 Recommend Define

(Target) Close-out Present & Socialize

6 7 8 9

PBGC Common Architecture Methodology (PCAM)

Role Description Responsibilities

Senior Management

Senior Management at PBGC set agency/department strategic goals and priorities

Define business drivers, business issues and performance goals for the agency

BNA Executive Sponsor / Owner /

Stakeholders

The senior PBGC personnel who obtain Subject Matter Expert (SME), business and technical personnel (including contractors) and funding for the analysis. These roles may include any combination of the following:

Business manager(s) Department director(s) Investment owner(s) Program manager(s)

Confirm Core Team Members & Alternates Define change drivers and business and information management requirements for

BNA

Identify goals and objectives and performance measures

Alert Core Team & EAD to Inspector General (IG) or other concerns

Accept Core Team recommendations Attend Final Executive Briefing Executive Stakeholders receive updates during Executive Sponsor Check In Meetings

Apply BNA recommendations and maintain a line of sight from programs and projects to PBGC strategic goals and objectives

Federal EAD Lead

The federal EAD employee assigned to manage the analysis from start to finish.

This individual is the federal point of contact for all other participants in the analysis.

Provide leadership Provide project management support Assist with any administrative support required from the analysis

Chief Architect and

EA Project Team

The federal and contractor team assigned to provide guidance and knowledge, to perform research and analysis, and to produce the agreed-upon artifacts.

Share knowledge and information and serve as advocate for architecture development and implementation within

PBGC

Support the governance structure and help promote the use of common technologies, standards, and services

Identify new performance improvement opportunities and opportunities to increase collaboration and reuse

Advocate common goals and objectives in EAD and define and institutionalize sound architectural development processes

Facilitate architecture process and communications

Perform interviews and discovery Perform analysis Develop documentation Provide guidance based on knowledge of overall organization

Role Description Responsibilities

Core Team

The Core Team includes representatives from at least the following departments:

EAD

Enterprise Cybersecurity Division

(ECD)

Information Technology

Infrastructure Operations Department (ITIOD)

Information Technology & Business Modernization Department

(ITBMD)

Business representatives

Identifies Stakeholders and SMEs Represents business interests and provides subject matter expertise Alerts EAD of concerns throughout analysis Makes decisions on recommendations Communicates progress Attends workshops & Final Executive

Briefing

SME and Admin Staff

Business organizational element personnel and supporting contractor staff who perform business processes, maintain IT systems or participate in any other way in the business activity within the scope of the architecture analysis

Participates in SME interviews and answers follow up questions

Provides relevant subject matter expertise

Figure 8: BNA Roles and Responsibilities

The following sub-sections describe at the high-level purpose, goals, and activities associated with each of the three phases of the PCAM.

3.2 Methodology for Conducting the Business Needs Analysis

3.2.1 Phase 1: Identify and Validate

Figure 9: Identify and Validate Phase

The Identify and Validate Phase contains the first three steps of the PCAM, and ensures “leadership, stakeholder, and customer needs and the operational requirements are validated so that ultimately, all stakeholder groups are working towards the same, well understood, validated outcome”.17

Step 1: Kickoff

The purpose of the Kickoff step is to gain approval of the high level enhancement goals, scope and intent for the analysis effort. During Step 1, the EA Project Team prepares, conducts and follows up on all tasks related to the kickoff meeting.

17 Ibid at 17.

Kickoff Identify (Baseline) Analyze

1 2 3 4 5 Recommend Define

(Target) Close-out Present & Socialize

6 7 8 9 PBGC Common Architecture Methodology

Phase 1 Phase 2 Phase 3

Prior to the kickoff meeting, with the assistance from the BNA Executive Sponsors, the EA Project Team identifies the Core Team Members (business and OIT representatives) who will support the BNA. The EA Project Team also develops the kickoff presentation that includes information about objectives, scope, roles and responsibilities, and a high level timeline. Once the Core Team members are identified, the EA Project Team works to socialize the approach with executives from OIT and the business segment(s) involved in the analysis to ensure buy-in on the objective, approach and resulting deliverables. The EA Project Team also researches previous applicable analyses, including known opportunities and issues, and the status of the recommendations to ensure organizational elements substantially impacted by the effort are represented by the Core Team. During the kickoff meeting, the EA Project Team validates the information included in the kickoff presentation.

After the kickoff meeting, the EA Project Team is responsible for all the follow-up activities, including collecting contact information for the Core Team, back-up alternate(s) information, black-out dates, updating the timeline based on the outcome of the kickoff meeting, and uploading all the post-kickoff artifacts to a designated Core Team collaboration space.

Anticipated Timeframe

REQUIRED ARTIFACTS – STEP 1

Segment Architecture Architectural Analysis Small-Scope Analysis

1-4 Weeks Kickoff Presentation Kickoff Presentation Kickoff Presentation

Table 1: Step 1 – Kickoff Summary

Step 2: Discover18

The purpose of the Discover step is for the EA Project Team to discover and review pertinent artifacts necessary for the baseline analysis and validate the information with the Core Team during Workshop #1.

During Step 2, the EA Project Team reviews all relevant data and documentation as well as federal and industry best practices, the team creates an inventory of reviewed artifacts for tracking purposes. Basic architectural perspective information that should be gathered includes:

Strategic Goal Alignment Performance Measures Business Processes Applications Data and Information Infrastructure and Network Information Security Other human, technical and financial resources External drivers and stakeholders Emerging business models Emerging and state of the practice technologies

18 This is the official time the Discover Step begins; however, the EAD Lead and Core Team may begin pre-discovery work at any time.

Relationships between the gathered architectural data that will be developed in the following steps.

These Architectural Layers are discussed in further detail in Appendix II.

Depending on the size of the project, the EA Project Team may also facilitate a Strengths, Weaknesses, Opportunities, and Threats (SWOT) analysis with the Core Team during Workshop #1 to identify common themes and define priorities. SWOT analysis may be included as an optional in addition to addressing the architectural perspectives identified above. If interviews are required, the Core Team will begin identifying Subject Matter Expert (SME) interviewees at the end of Step 2.

REQUIRED ARTIFACTS – STEP 2

Segment Architecture Architectural Analysis Small-Scope Analysis

1-4 Weeks Artifact Inventory Workshop #1

Presentation Existing Reference

Models, if applicable

Artifact Inventory Workshop #1

Presentation Existing Reference

Models, if applicable

SWOT Analysis, if applicable

Existing Reference Models, if applicable

Table 2: Step 2 – Discover Summary

Step 3: Interview

The purpose of the Interview step is to confirm and elaborate on data gathered in Step 2 and gain a thorough understanding of current services, business processes, supporting technology, and other resources, that will identify and confirm the relationships between the data points in the architectural layers. The majority of the interviewees are identified by the Core Team members, but in all analyses representatives from EISO, ITIOD, and IT&BMD are always interviewed for each BNA.

During Step 3, the EA Project Team prepares an interview questionnaire, finalizes the SME interviewee list, and identifies artifacts that may be impacted. The EA Project Team then schedules and conducts all applicable interviews and develops interview questions that will be validated with the interviewees. The SME interviews, in conjunction with the information gathered during the Discovery Step helps the EA Project Team gain a holistic assessment of the current architecture, including insights into challenges and benefits into the way the business currently functions, and determine any performance gaps and/or business needs to support development of a Baseline Observations Report. Also during this step, information regarding emerging technologies, business trends and business model in the federal government space are gathered. The interview step marks the last PCAM step in the Identify and Validate phase.

REQUIRED ARTIFACTS – STEP 3

Segment Architecture Architectural Analysis Small-Scope Analysis

1-4 Weeks Interview Questionnaire Interview Transcripts

Interview Questionnaire Interview Transcripts

Step 3 is optional

Table 3: Step 3 – Interview Summary

3.2.2 Phase 2: Research and Leverage Phase

Figure 10: Research and Leverage Phase

There are two PCAM steps aligned to the Research and Leverage phase of the CPM, which “identify external organizations and service providers that may have already met, or are currently facing needs similar to the ones identified in [Identify and Validate Phase], and then to analyze their experiences and results to determine if they can be applied and leveraged or if a partnership can be formed to address the needs together.”19

Step 4: Analyze

The purpose of the Analyze step is to solidify the understanding of the baseline in order to inform the desired outcomes of the target state (e.g., performance improvements).

During Step 4, the EA Project Team:

• Organizes the information that was gathered;

• Reviews interview transcripts and information provided by interviewees; and

• Maps information to the Architectural layers (e.g. performance, business)

After completing a detailed analysis of the observations, the EA Project Team then prepares for Workshop #2 where they introduce architecture concepts and alignment to performance, people, process, technology, present the interview findings, and information mapping of the data gathered to the architectural layers.

Anticipated Timeframe

REQUIRED ARTIFACTS – STEP 4

Segment Architecture Architectural Analysis Small-Scope Analysis

2-6 Weeks Workshop #2 Presentation

Workshop #2 Presentation

Step 4 is optional

Table 4: Step 4 – Analyze Summary

Step 5: Identify

The purpose of the Identify step is to review documentation, identify gaps, begin development of the Baseline Architecture Diagram, and validate all aforementioned documentation with the Core Team during Workshop #3.During Step 5, the EA Project Team develops a draft of the Baseline (“As-Is”) Architecture Diagram. The baseline architecture diagram consists of the relationships between the architectural data gathered.

This relationship model creates an objective, fact based model of the baseline environment. This model is analyzed by the team to identify gaps, redundancies and opportunities to improve performance. The EA Project Team identifies high level gaps in business processes, and identifies preliminary areas of process improvement that may include technology enhancements and any security considerations.

19 Ibid at 18.

Interview Discover Kickoff Identify

1 2 3 4 5 Recommend Define

(Target) Close-out

Present & Socialize

Once the Baseline Architecture Diagram is created, Workshop #3 is held to validate stakeholder understanding, answer any questions, and collect feedback. At the conclusion of Workshop #3, all stakeholders should have a clear understanding of the baseline and an idea of what they can leverage in preparation for developing the Target Architecture. The EA Project Team then creates the Baseline Observation Report incorporating the validated Baseline Architecture Diagram. The Identify step marks the last PCAM step in Phase 2, the Research and Leverage phase.

REQUIRED ARTIFACTS – STEP 5

Segment Architecture Architectural Analysis Small-Scope Analysis

2-6 Weeks Baseline Architecture diagram and Observations Report

Workshop #3 Presentation

Baseline Observations Report

Workshop #3 Presentation

Baseline Observations Report

Workshop #3 Presentation

Table 5: Step 5 – Identify Summary

3.2.3 Phase 3: Define and Plan Phase

Figure 11: Define and Plan Phase

In Phase 3, there are four PCAM steps aligned to the CPM. In this phase, “current capabilities and environments result in recommended adjustments to meet the needs identified in the Identify and Validate Phase. Also during this phase, the formal design and planning of the target capabilities and environment is performed.”20

Step 6: Define

The purpose of the Define step is to begin development of the Target Report and Modernization Roadmap and validate these documents with the Core Team at Workshop #4.

In alignment with the OMB’s “Cloud First Policy,” a cloud solution should be evaluated as an option whenever possible. During Step 6, the EA Project Team ensures the Target Architecture clearly identifies any impacts (including security impacts) the analysis has on the PBGC data architecture. If there are no impacts, it must specifically be noted that the analysis was completed and there were no impacts on PBGC enterprise data. The EA Project Team also continues to communicate with the SMEs and interviewees to confirm understanding and ensure agreement in the development of the target state.

In addition, the Core Elements of the GAO Maturity Model should be considered, as applicable, during the development of the Target Architecture and Modernization Roadmap. “The 59 Core Elements are

20 Ibid at 19.

Interview Discover Kickoff Identify

1 2 3 4 5 Recommend Define

(Target) Close-out Present & Socialize

Phase 1 Phase 2 Phase 3 collectively the EA practices, structures, activities, and conditions that, when properly employed based on the unique facts and circumstances of each organization and the stated purpose of its EA program, can permit that organization to progress to increasingly higher states of EA management maturity and thereby maximize its chances of realizing an EA’s institutional value21.

Once the Target Architecture Diagram and Modernization Roadmap are complete, Workshop #4 is held to validate the Core Team’s understanding, answer any questions, and collect feedback. During Workshop #4, the EA Project Team helps the Core Team build consensus, and facilitates the approval of the Target Architecture Diagram. Upon approval, supporting narrative, including performance measures and success criteria, is added to finalize the Target Report and the Modernization Roadmap.

REQUIRED ARTIFACTS – STEP 6

Segment Architecture Architectural Analysis Small-Scope Analysis

2-6 Weeks Updated Artifact Inventory

Workshop #4 Presentation

Target Report Modernization

Roadmap

Updated Artifact Inventory

Workshop #4 Presentation

Target Report Modernization

Roadmap

Target Report Modernization Roadmap

Table 6: Step 6 – Define Summary

Step 7: Recommend

The purpose of the Recommend step is to develop the Executive Briefing, share it with the Core Team during Workshop #5 and collect feedback.

During Step 7, the EA Project Team facilitates Workshop #5 that introduces the Executive Briefing presentation and the Recommendations Report. The Recommendation Report includes the Core Team approved Baseline Observations Report, Target Report, and Modernization Roadmap. The Recommendations Report provides an overview of the baseline, identifies gaps and pain-points, defines benefits related to modernization, and highlights recommendations and key next steps. During this step, practice sessions for the Executive Briefing presentation is discussed with the Core Team.

REQUIRED ARTIFACTS – STEP 7

Segment Architecture Architectural Analysis Small-Scope Analysis

1-4 Weeks Recommendations Report

Executive Briefing

Recommendations Report

Executive Briefing

Recommendations Report

Executive Briefing

Table 7: Step 7 – Recommend Summary

Step 8: Present and Socialize

21 United States Government Accountability Office: Organizational Transformation, A Framework for Assessing and Improving Enterprise Architecture Management (Version 2.0), August 2010.

The purpose of the Present and Socialize step is to help facilitate the Executive Briefing, and collect signatures from Core Team members and BNA Executive Sponsors.

During Step 8, the EA Project Team conducts practice sessions with the entire Core Team, conducts one-on-one preparation sessions with Core Team members (as needed), and provides any additional support that is needed. Once all documents have been approved by the Core Team, the BNA Executive Sponsor/Owner and the Federal EAD Lead provide a pre-briefing to the Executive Sponsor and key stakeholders in order to highlight the results of the analysis. The Executive Briefing is then conducted, and if applicable, security aspects of the target architecture will be briefed by the security team member of the Core Team. Following the Executive Briefing, the EA Project Team facilitates the binding process and delivers the final Recommendations Report to the BNA Executive Sponsor and other executives for formal acceptance and signoff. The review period for the Executive Briefing will depend on the size and scope of the effort (see 4.1 Scaling Framework Matrix for more details).

REQUIRED ARTIFACTS – STEP 8

Segment Architecture Architectural Analysis Small-Scope Analysis

1-6 Weeks Signature Form Signature Form Signature Form

Table 8: Step 8 – Present and Socialize Summary

Step 9: Close-out

The purpose of the Close-out step is to conduct a lessons learned session with the Core Team members.

During Step 9, the EA Project Team communicates the positive aspects and improvement areas, and solicits feedback from the Core Team members. At the conclusion of the analysis, all approved artifacts will be posted to the appropriate PBGC-wide collaboration location (electronic and/or hard copy). The Close-out meeting marks the end of the Define and Plan Phase of the CPM and the PCAM.

Anticipated Timeframe

REQUIRED ARTIFACTS – STEP 9

Segment Architecture Architectural Analysis Small-Scope Analysis

1-4 Weeks Lessons Learned Presentation

Close-out Memo

Lessons Learned Presentation

Close-out Memo

N/A

Table 9: Step 9 – Close-out Summary

Scaling Framework 4

The PBGC Common Architecture Methodology (PCAM) promotes architectural consistency and allows for flexibility for different types of Business Needs Analyses (BNA) through a customizable set of activities and artifacts. The PCAM can be tailored depending upon the type of BNA and offers the following types of approaches:

Segment Architecture Approach Architectural Analysis Approach Small-Scope Analysis Approach

The BNA type is determined based on size, complexity, and scope of the effort. The selection criteria guideline is as follows:

Analysis Attributes

Segment Architecture Selection Approach22

Architectural Analysis Selection Approach

Small-Scope Analysis Selection Approach

Size

Defined either functionally (crosscutting mission or support service) or organizationally (e.g., as a business unit and per the organization chart)

May impact one or more organization(s) or applications/systems

Impacts single organization and/or application/system

Scope

Focuses on a particular service area or business unit within an agency or between agencies that is not Federal-, Sector-, or Agency-wide

Scope may cross segment boundaries

Smaller than full segment, or architecture work has been completed and needs additional detail

Scope may not cross segment boundaries

Scope is single system, no technical re-engineering, covered by single investment and <1% of IT budget

Complexity

A new business or IT service, may be federally mandated

Changes to current PBGC business functions

Goals, objectives, weaknesses, opportunities and threats are either not known or need to be validated

May include significant business process or technical re-engineering

Goals, objectives, weaknesses, opportunities and threats are either not known or need to be validated

May include some business process or technical re-engineering

Goals, objectives, weaknesses, opportunities and threats are likely known

May not require contractor support

Impact

Impacts core business functions

Provides comprehensive understanding of current business challenges

Recommends future business, technical approach, and data improvements

May impact core business functions

Simplifies implementation of target state formulated by the Enterprise Target Architecture (ETA)

May not impact core business functions

Table 10: BNA Selection Criteria

The next section introduces the Scaling Framework Matrix, which provides additional guidance for the different types of BNA.

22 Ibid at 19.

4.1 Scaling Framework Matrix

To use as a guide during a BNA, the scaling framework matrix below summarizes the activities within each of the PCAM step, and outlines the tailored approach for Segment Architecture, Architectural Analysis, and Small-Scope Analysis.

PCAM

Phase

PCAM

Step

PCAM

Step Description

Segment Architecture Analyses Guidance

Architectural Analyses Guidance

Small-Scope Analyses Guidance

Ph as e 1:

Id en tif y an d

Va lid at e

S…