Attachment_15_-_Design_Standard.pdf

EA-STD-01-06

PBGC Design Standard

Purpose To define a consistent set of information that must be provided in the Information Technology Solutions Life Cycle Management’s (ITSLCM) Design Document deliverable.

Scope

The Design Standard refers to the designing of an IT solution or externally hosted IT solutions. It identifies the architectural and design information required to communicate to relevant stakeholders such as business sponsors, IT Infrastructure, the integrated program team (IPgT), integrated project team (IPT), and appropriate governance boards.

Authority/ References

Information Technology Solutions Life Cycle Management (ITSLCM) Framework

Approving Body Governance Coordination Board (GCB)

Owner Enterprise Architecture Division (EAD)/ IT & Business Modernization Department

(IT&BMD)

Collaborators IT&BMD Service Managers, Chief Enterprise Architect, Program Management Office, IT&BMD Department Director, Enterprise Cybersecurity Division (ECD) CISO and Information Technology Infrastructure Operations Department (ITIOD) Service Division Managers

Implementer Integrated Project Team (IPT)

Standard Type

Operational – The standard pertains to actions that are primarily implemented in the enterprise and executed by people (as opposed to systems) in the implement phase of an information system, IT project, program, or initiative.

Control Number Version: DSS-V1-2015

Standard It is essential for members of the Integrated Project Team (IPT) and/or Integrated Program Team (IPgT) to participate in and contribute to the development and review of the Design Document deliverable. IPT/IPgT members (including, but not limited to, representatives from Enterprise Architecture Division (EAD), Enterprise Cybersecurity Division (ECD), IT Infrastructure Operations, IT Assets and Technology Requirements Management and IT Business Change Management Divisions, Release Management, Records Officer, and business stakeholders) should ensure the documented designfully reflects the requirements in the design document and that the documented requirements in the project’s Requirements Document adequately address applicable PBGC standards, business processes, federal and local mandates and laws, and relevant policies, directives, and regulations from the area(s) they represent.

The Solution Design Document must contain, at a minimum, the applicable information/items highlighted below. The detailed references for designs are provided in the PBGC Design Methodology.

1. Revision History – Include revision number, content changes, date of change, and author.

2. Technical Design – Describe the specific technical aspects and behaviors of the IT solution’s components shall follow the IT Technical Design Methodology.

A description and logical view of the hardware, software, components/modules, interfaces, processes, disciplines and the rules and relationships among those elements are necessary to provide for effectively implement the IT solution being developed. Designs should include the following applicable subcomponents:

Summary and Solution Overview Design Approach Reference and Justification Strategy and Performance Business Architecture Data Architecture Data and Information Exchange Infrastructure Technology Stack Information Security Non-Functional Requirements User Interface/User Experience Reports and Business Intelligence Post-Deployment Management Considerations Design Governance and Compliance Design Risk Management Detailed Technical Solution and Service Designs

If any project is not able to provide required information, a justification is necessary to provide in the document.

Approvals – Include signature(s) and date(s) of appropriate business, OIT, and Integrated Project Team approval authorities.

Metrics DME IPTs are required to conduct a Technical Review Board (TRB) Technical Design review at the appropriate point in the ITSLCM. The type of DME projects that require TRB Technical Design Reviews are required to be presented to the TRB. The target metric for this 100% of applicable DME project designs are reviewed by the TRB each year.

Owner Signature John Larsen, Chief Enterprise Architect

Approval Signature John Larsen, TRB Chair

PBGC Design Methodology V1.0

Enterprise Architecture

Revision History

Document Version

Release Date

Section(s) Changed

Description/Comments

1.0 January 2015 All Initial release

Approval Signer/Title Signature Date

John Larsen Chief Enterprise Architect Manager, Enterprise Architecture Division John Larsen Chair, Technology Review Board (TRB) i

Contents

1 INTRODUCTION

2 TRB TECHNCIAL DESIGN REVIEWS

3 TECHNICAL DESIGN METHODOLOGY

3.1 Structure of the Design Document

3.2 Technical Design

3.3 Elements of the Design Document

3.3.1 Summary and Solution Overview

3.3.2 Design Approach

3.3.3 Reference and Justification

3.3.4 Strategy and Performance

3.3.5 Business Architecture

3.3.6 Data Architecture

3.3.7 Data and Information Exchange

3.3.8 Infrastructure

3.3.9 Technology Stack

3.3.10 Information Security

3.3.11 Performance Requirements

3.3.12 User Interface/User Experience

3.3.13 Reports and Business Intelligence

3.3.14 Post-Deployment Management Considerations

3.3.15 Design Governance and Compliance

3.3.16 Design Risk Management

3.3.17 Detailed Technical System and Service Designs

4 SUMMARY

APPENDIX A: PBGC STANDARDS

APPENDIX B: PROCESS & ARCHITECTURE PRESENTATION SAMPLES

Business Process Diagram (using BPMN Notation)

Technical Architecture Diagram

Application Architecture Diagram

Data Architecture Diagram

Data Modeling Diagram

Interface and Data Exchange Diagram ii

1 Introduction This document describes the process for identifying and documenting design information for technology solutions used in PBGC’s business and IT environments. The PBGC Design Methodology provides a repeatable process that defines relevant criteria and standardizes the design information structure. This methodology is required to be used by all PBGC IT and Integrated Project Teams (IPTs) including federal and contractor developers. Integrated Project Teams (IPTs) must use this methodology to develop a Design Document to ensure that all necessary information is captured.

2 TRB Techncial Design Reviews The Technical Review Board (TRB) is responsible for evaluating IPT designs and solution architectures for compliance against PBGC standards which is accomplished through the TRB Technical Design Reviews.

TRB Technical Design Reviews are an effective way of ensuring design quality and addressing architectural concerns. The principal objective of a design review is to assess the project architecture’s ability to deliver a system or infrastructure solution capable of fulfilling the quality requirements in the project’s Requirements document and to identify potential risks. The TRB conducts Technical Design Reviews to ensure the design:

Provides a coherent description of the system before and after the envisioned change;

Conforms to PBGC principles, standards, and directives;

Is compatible with the legacy and target technical landscape;

Will achieve the project’s goals and objectives; and

Is well-documented.

Once approved, the IPT will continue on with the solution and will present a final Design Review that includes submission of the final Design Document as well as an explanation of any changes made to the preliminary design and justification for the changes made. Design Reviews are conducted on primarily Development, Modernization and Enhancement (DME) funded projects. Consult the TRB Processes and Procedures document for additional information.

Technical Design Reviews are a standard business practices in both the private and public sectors.

Benefits of conducting Technical Design Review include:

Identify the potential risks in the proposed architecture;

iIdentify opportunities for reuse of artifacts and components;

Promote good architecture design and evaluation practices;

Facilitate clear articulation of nonfunctional requirements (e.g. scalability, performance, security, etc.);

Reduce project cost caused by undetected design problems;

Capture the rationale for important design decisions; and

Uncover problems and conflicts in requirements

3 Technical Design Methodology

3.1 Structure of the Design Document

When creating a Design Document, IPTs should follow the structure under Section 3.3: Technical Design, addressing all applicable sections. Development teams should obtain information to answer the questions where it is applicable but unknown. Design Documents should include detailed narrative as well as diagrams that are useful in describing the architectural story. For very large or complex projects, alternative documents are possible; though coordination with Enterprise Architecture representative on the IPT is advised. The Design document is tailorable by the project manager and IPT based on the type of solution.

3.2 Technical Design

The Design Document describes the specific technical aspects and behaviors of the IT solution’s components. The Technical Design includes a description and logical view of the hardware, processes, data, and relationships for an IT solution being developed. The Technical Design should address the following applicable elements:

Summary and Solution Overview

Design Approach

Reference and Justification

Strategy and Performance

Business Architecture

Data Architecture

Data and Information Exchange

Infrastructure

Technology Stack

Information Security

Performance Requirements

User Interface/User Experience

Reports and Business Intelligence

Post-Deployment Management Considerations

Design Governance and Compliance

Design Risk Management

Detailed Technical Solution and Service Designs

If any project is not able to provide required information, a justification is necessary and should be described in the Design Document. Each of the above elements will be described in detail in the sections below.

3.3 Elements of the Design Document

The Design Document may include both conceptual, logical or physical design diagrams as well as detailed narrative. Design diagrams provide a roadmap for the solution and reflects important design features. The diagrams allow stakeholders to see relationships and connectivity that are difficult for narrative to articulate clearly. Diagrams may represent data, application modules, infrastructure, business processes, interfaces, and may represent several viewpoints as needed to accurately describe the design. Narratives complete the picture and can tell a story about data flow, about business interactions, nonfunctional requirements, or about system relationships in more detail than a diagram can represent.

3.3.1 Summary and Solution Overview

The Design Document needs to provide a general description of the complete system design architecture. This section includes a discussion of the basic design approach and organization as well as technical and relatively static components to include:

A list of assumptions (e.g. availability of a hardware/software platform, or developments in technology);

A list of conditions or constraints outside the control of the project that limits the design alternatives (e.g. domain technologies, enterprise general specifications, standards, guidelines imposed on the IT solution and strategic decisions, public and international laws and regulations, technology base, human availability, recruitment, and selection);

A list of any dependencies that impact externally or internally hosted IT solutions and provide a description of each dependency including requirement of contingencies, performances, technologies, etc.;

A context diagram showing the As-Is state that system as it exists today and the proposed future state at a conceptual level (see Appendix B as an example).

This section of the Design Document should address the following applicable questions:

Is there a high level technical architecture diagram?

What is the planned Technology Stack used in the solution? How does it relate to the TRM?

Is SAAS, Managed Service or Cloud Deployment considered? If not, why not?

Has COTS been considered?

Have enterprise shared services been considered as part of the design?

Has all hardware and software to be acquired been identified? Are TRB product selection reviews required? Is this in the project schedule?

Does the architecture design facilitate code re-use/efficient debugging?

Has the simplest, most modular and extensible approach been adopted?

Is the manner in which services and logic are partitioned within the architecture intuitive?

3.3.2 Design Approach

A design approach requires the development team choosing between a Commercial Off-the-Shelf (COTS) solution or a custom solution. A COTS solution requires that there be a product in the marketplace that is able to meet a project's requirements either out of the box or with some customization of components.

When evaluating use of COTS as a solution approach, the following items should be considered:

Relationship to internal requirements.

What modules are provided in COTS?

What modules are being used in the PBGC IT solution?

How they support the implementation of function requirements?

What custom modules, database/schemas/tables and interfaces are going to build?

The matrices map requirements in requirements to the design.

Integration with information security requirments

If a custom approach is selected, the following items should be considered:

What the IT solution will do.

Functional flowcharts to describe how the design will support the implementation of the requirements (helps stakeholders understand how the design translates business requirements to IT solution in the design).

What the modules, databases/schemas/tables and interfaces are going to build?

The matrices map function of design to requirement.

Whether a custom or COTS approach is adopted, a major design consideration is whether a Service Oriented Architecture (SOA) will be employed for exchanging data between application components.

SOA is more thoroughly described in the Software Services Standard and Methodology and can be described generally as an architectural style that enables the realization of architectural best practices.

At its core, SOA is about architectural components interacting with one another by consuming or providing services which have a well-defined interface. PBGC IT Standards encourage the adoption of a SOA approach for information and data exchange whenever possible.

For Service Oriented Architecture, the following items should be considered:

Description of specific capabilities of designed service and/or required orchestration of services.

The owner of services required/consumed by the system being designed.

Consult the Software Services Standard for additional information.

3.3.3 Reference and Justification

All existing reference documents that support the project and current release are required to be included in the Technical Design Document. The references should include the name of the reference, a location of reference, and a link/URL of the reference.

In addition, the Technical Design must be in compliance with PBGC IT Standards. The Design Document should identify which PBGC IT Standards were used in the development of the design and which were not. The Design Document should also include justification as to why any technical IT Standards were not used and a justification if applicable.

3.3.4 Strategy and Performance

The Design Document should first address how the solution is applicable to PBGC’s business strategy (if appropriate) and what business issue the particular solution seeks to address and how it will improve the performance of that specific business strateguy or issue. The Design Document should address what are the current state metrics and data as well as the expected performance improvements and the metrics that will be used to measure solution success as well as the possible ramifications of not implementing the solution. Questions to address in this section include:

Does this solution directly support a PBGC strategic priority? If so, which one?

How is this strategy measured and how does the project contribute to the achievement of the strategic goal progress and measurement?

What business / performance issue is this solution solving?

What are the current performance metrics and the target metric results after deployment?

What detrimental strategic or performance issues will occur if the project is not implemented?

3.3.5 Business Architecture

The Design Document should include a Business Architecture section which describes the business processes the Design will use or modify. This section will also capture if this Design is eliminating a redundant business process or if the solution will be creating new processes that need to be followed.

This section should address the following questions:

http://intranet/it/it_governance/ppl/dsp_quick_dir_docnum.cfm

What business processes are impacted by this solution? What are the up and downstream processes impacted?

What existing application supports the same and adjoining business processes?

Is a solution business workflow diagram included?

Have the applications related to these business processes been analyzed to determine if there is a redundancy in function and/or data?

Have business process models been developed to capture business processes?

Are there external policies or PBGC directives that impact the solution?

3.3.6 Data Architecture

The Data Architecture section of the Design Document should discuss what the data is attempting to describe, the relationship between data entities, and the hardware that contains the data including physical databases, servers, or where the data is stored. The Data Architecture should adhere to the principles in the PBGC Enterprise Data Standard.

If the data contained within is sensitive (PII, SPII), the data protection method should be described and documented. This section of the Design document should also include diagrams and descriptions of the data access layer, data access mechanisms, and a logical diagram of database layers.

If there is no data change made in this release (such as database, schema, entity or attribute), a previous document name, version number, section name, page number, and link are required to be provided.

The following table depicts a sample table showing the Data Model reference and file location that should be included in the Design Document:

Data Model Name

Data Model Creation Tool

Data Model Location (links for both Erwin and PDF formats) Comments

Table 1: Sample of Data Model Reference and File Location

The following applicable questions regarding data should be addressed:

Is the data design consistent with existing PBGC orders, procedures, standards, and technological directives?

Is there a conceptual data model?

Are the Logical Data Models and Data Dictionary documented and/or updated?

Have all data models been created using a PBGC approved data modeling tool?

Have “golden sources” of authoritative data been identified for use by the design?

http://intranet/it/it_governance/ppl/documents/EA-STD-01-03-PBGC-Enterprise-Data-Standard-and-Methodologies.pdf

Was the EDM used in developing the conceptual and logical models?

What data entities will the solution create and what entities are reused from other sources?

Is the mapping of the functions of the data in the current and new systems complete?

Does the application create or store PII, SPII or other sensitive data?

What is the records retention period and does the design support it?

3.3.7 Data and Information Exchange

Data and Information Exchange should contain information regarding the transport mechanisms and/or networks for using data. This section should contain, when applicable:

A diagram showing all interfaces to other applications internally or externally with the type of technology/method used, data flow direction and scalability in each interface. The diagram should also show network nodes and security boundaries as needed.

A list of interfacing components and technologies/methods, such as communication protocol and the schema for the information exchanged, or reference to an updated Interface Control Document.

A specification on data exchange, including:

o data exchange mechanism(s);

o data exchange details, such as data (list of data being exchanged) from or to, trigged by an application (name) with mechanism(s) of (store procedure, query, service, etc.);

o data exchange dependency;

o estimated exchanges frequency, schedule, and volume; and o security requirements for data exchange.

A description of the communication, processes, disciplines, the rules and relationships among those elements necessary to effectively communicate among components of the IT solutions or the other systems or data stores, consumers or producers.

With regards to Service Oriented Architecture, a Service Description typically exists in Web Service Design Language (WSDL) format. A link should be provided to the service description, which thoroughly describes the service and interfaces. There should also be a Service Level Agreement (SLA) that governs the terms under which a service provider will provide data exchange with one or more consumers. A link to relevant SLA’s should be provided as well.

The Data and Information Exchange section of the Design Document should address any of the following applicable questions:

Are the frequency, size, and method of transport identified?

Is the flow of data through the software system well defined to ensure a logically consistent structure?

Are data flow diagrams used to show the level of detail needed to reach a clear, complete picture of processes, data flow, and data stores?

Are the system’s data transformation design and rules described? (if applicable)

Have the number of interfaces been identified?

If there are external data interfaces, does the system’s data design specify the purpose for each of the available data elements? If the solution involves moving data from a legacy solution to a new replacement solution:

Is the data availability during the conversion process determined?

Have any data cleansing related tasks been identified and properly staffed?

Have the types, data items, sizes, frequencies, and direction of messages across each interface been documented?

Does this system process, store or transmit any sensitive data such as PII that requires special protection such as encryption in database or in transit?

The following table depicts a sample table showing the Data and Information Exchange amound systems/databases that should be included in the Design Document:

Data/Information

Type (financial, participant, plan, etc.)

Source Data/Information (from a system, database, etc.)

Destination Data/Information

(to a system, database, etc.))

Exchange Methord

(web service, databaselink, etc.)

Frequency of data exchange

Comments

Table 2: Sample of Data and Information exchange

3.3.8 Infrastructure

The Design Document should include a description and logical graphic view of the IT infrastructure resources engaged, owned, or hosted by PBGC, such as servers used for the application and database, network, etc. It should also include a diagram showing all database servers, network, etc. If applicable, the specification of new hardware requirements for the release should be included, such as processor speed, total physical memory, total hard disk capacity, database, database instance, data size, data type, network interface type, operating system, number of processors, load balance, etc. for both development and production environments, as well as ITC. The Design Document should also include peak loads as well as backup and restoration requirements such as recovery point and time objectives.

This section should also include a Configuration requirement and provide SaaS or Cloud Deployment specification if the current release has employed SaaS or Cloud Solution.

The Infrastructure section should address the following questions:

Is there a description and logical graphic view of the IT infrastructure resources engaged, owned, or hosted by PBGC, such as servers and physical boxes used for the application and database, network, etc.?

Is there a specification of new hardware requirements such as processor speed, total physical memory, total hard disk capacity, database?

Does the infrastructure approach have long term viability?

Does the proposed infrastructure have an acceptable Cost of Ownership?

Was SaaS or cloud deployment considered?

Have performance, scalability, and other non-functional requirements been properly addressed?

3.3.9 Technology Stack

The Technology Stack should be presented with all technologies used for the current release. System development is required to use PBGC approved technologies presented in TRM with a Grade Level of “Current” or “Recommended”. Technologies utilized for the design with Grade Levels of “At Risk” or “Restricted” require a justification for use and include the results of research conducted in which no current technology can be leveraged from the TRM. The table below is an example of Technology Stack:

Name of Technology or

Product Description Purpose TRM Grade

Justification for using a grade of “At Risk” or Restricted”

RDBMS

Server OS Middleware

COTS

Other Web and App Tier DB Tier Storage

Table 3: Sample Technology Stack

3.3.10 Information Security

The Design Document should include a description and logical graphic view of the IT solution’s security, processes, disciplines, and the rules and relations among those elements necessary to effectively secure the IT solution being developed. The document should also address authentication and authorization, http://intranet/it/trb/trf.cfm data sensitivity (such as PII, Plan, financial, etc.), and provide a list of security control which are applied to the release.

Examples of relevant questions to be addressed in this section of the Design Document include:

Is the service/solution currently provided by a PBGC’s common control service provider?

Has the service/solution been approved by the business area representative, and an IT Compliance Checklist has been completed?

Does this system process, store or transmit any sensitive data such as PII that requires special protection such as encryption in database or in transit?

Will a current PBGC required solution be used for the identification and authentication? If not, what approach is being used?

What are the System Security Requirements need to comply?

What is the System Security Architecture been proposed?

3.3.11 Performance Requirements

The Design Document should provide information sufficient to meet the following basic requirements as defined the in the Requirements Document:

Performance:

o the specific performance matrices and how they are associated with the project requirements from business and functionalities under both normal and peak operational conditions; and o operational performance metrics, such as ability to quickly route HTTP traffic, handle SSL sessions, return a 3rd party service call, etc. identified by business.

Scalability, Flexibility, and Reliability:

o provide solution scalability and flexibility requirements from both business and IT; and o the scalability and flexibility metrics on how solution is able to expand or reduce in size to optimize operation and level of reliability and flexibility to meet the performance criteria in expanding or reducing the performance capacities under both normal and adverse operational conditions without disturbing business operation.

Manageability:

o provide any required normal operation instructions or tools for operation group daily monitoring and management

The following applicable questions regarding Non-Functional Requirements should be addressed in the Design Document:

Performance: Does the solution meet the performance metrics required by the business? (e.g.

ability to quickly route HTTP traffic, handle SSL sessions, return a 3rd party service call, etc.)

Scalability: Can the solution be expanded or reduced in size to meet business requirements?

Flexibility: Can the solution guarantee the level of reliability required by the business for performing consistently under both normal and adverse operational conditions?

Reliability: Can the solution be failure-free, such as 24/7 or a specified period of time to meet business and performance requirements?

Manageability: Does the solution contain the instrumentation or tool to be proactively managed?

3.3.12 User Interface/User Experience

If applicable, the Design Document should include the specifications and functions of each user interface as well as the descriptions and mockups of the user's experiences and interactions with the IT solution to meet business requirements. The Design Document should answer the following applicable questions:

Is the user interface for the system specified, including use of appropriate screen mockups?

Are the user interface requirements (e.g., performance or usability) associated with the entire user experience addressed?

Is the screen navigation hierarchy specified?

Is the appropriate screen field attribute information for each screen addressed?

Are other major categories of user functions (e.g., transactions, reports, administration) that require an interface addressed at an appropriate level of detail?

Is the user interface design consistent with existing policies, procedures, standards, and technological directives?

Does the design include documents that contain any Intellectual property or “copyrighted” material, e.g. images?

Were all content documents constructed using PBGC standards?

Was a web-based user interface adopted as opposed to platform or desktop specific applications?

3.3.13 Reports and Business Intelligence

Reports and Business Intelligence should include descriptions of the type and functionality of the reports provided from the IT solution. It should also contain descriptions for any out of box report functions that meet business requirements and/or the requirements for custom reports required from the IT http://intranet/it/it_governance/ppl/documents/EA-STD-01-05-PBGC-Software-Service-Standard-and-Methodology.pdf solution. This section should also address data sources, queries, and logical view of data flows for the reports created in the application. Questions to be answered in this section of the Design Document include the following:

Are the selected BI tool and the report design consistent with existing policies, procedures, technology/TRM, data and standards?

Have the number and types of reports been identified, mocked up, and approved by their prospective users prior to development?

Have the report designs been specified?

For each report, are the access permissions and frequency defined?

3.3.14 Post-Deployment Management Considerations

If the system needs a special service in specific criteria such as service desk (SLA requirements for response)1, maintenance (federal and contractor support and schedule), infrastructure environment (network, database, servers), or COOP requirement, the Design Document should address the specifications. Relevant questions addressed in this section of the Design Document include:

Are Help desk requirements documented? Will existing Help Desk/ Support be used?

Does the design allow for ease of maintenance? Are unique skills required that are not easily obtainable in the marketplace?

Has the system been fully documented?

What is the plan for application and database management in the O&M phase.

Is there a change control board?

If reusable parts of other designs are being used, has their effect on design and integration been stated in the relevant documentation?

Does the design identify the systems (if any) that are planned to be retired as a result of this solution being implemented?

Are any systems retired due to this solution?

3.3.15 Design Governance and Compliance

The Design Document should include a Governance and Compliance section which identifies the planning, decision-making, and oversight processes and groups that will determine how the design is developed, verified, versioned, used, and sustained over time with respect to measures of

1 Development Teams are recommended to contact infrastructure COR to ensure the current O&M contract is supporting your requests.

completeness, consistency, coherence, and accuracy from the perspectives of all stakeholders2. This section may address such relevant questions as:

Have legal/regulatory requirements been assessed and accounted for?

Was concurrence to proceed to the next phase given by Project Sponsors?

Does the User interface comply with the Americans with Disabilities Act (ADA) Section 508?

Is Section 508 Accessibility testing conducted or planned? Are the results documented?

3.3.16 Design Risk Management

Design risk management is determining potential risk in a design process, either in a concept design or a detailed design which enable you to eliminate possible failures and reduce the impact of potential failures through the development of a Risk Plan. The Risk Plan includes the identification of potential risks, analysis of possible impacts, and mitigation strategies. This process ensures the thorough evaluation of the reliability of the design. Questions to be captured in this section of the Design Document include:

Have known design risks been identified, analyzed, and planned for or mitigated by use of a Risk Plan?

Has the Risk Plan been modified with any new risks posed by the Design?

Has the Risk Plan been updated weekly/monthly and conveyed to the Project Sponsors?

What are the risks, if any, that the TRB perceives?

3.3.17 Detailed Technical System and Service Designs

The Design Document must also include a diagram (or diagrams) with corresponding narrative with that depicts an accurate, detailed, and complete description of the detail design. The design must also document how each of the requirements specified in the high-level design will be physically accomplished. The detailed design must align with all applicable PBGC IT Standards.

The detailed design should include specific hardware related information utilized by the hosting service provider as well as all aspects of the application, network, security, and integration architecture. This section should answer such relevant questions as:

Is there a system and/or service architecture diagram that shows how the components, systems, and services covered by the design fit together?

Does the architecture diagram show N-tier architecture from database layer to presentation layer?

Is there an integration diagram that shows how the solution being designed fits within the larger PBGC application context?

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

For service design, are service-specific technical details addressed (e.g. message exchange, discoverability)?

Are diagrams backed up by narratives that provide detail about modules, interfaces, systems?

Has configuration management been addressed?

Is development approach fully compliant with development and software services EA standard?

4 Summary The PBGC Design Methodology, in support of the Design Standard, is the governance and methodology to be used by development teams when designing and communicating an IT solution. This method is a transparent and repeatable process which provides stakeholders with consistent information on IT designs and development as well as business requirements. The Technical Review Board also uses Design Reviews, which include a review of the Design Document, to determine compliance with PBGC IT Standards. This standard and methodology is to be followed by all development/design teams including federal and contractor support staff.

Appendix A: PBGC Standards

ITSLCM Lifecycle Phase

Standard Description

Planning, Business Needs Analysis Standard

• Assures that the business needs are identified and prioritized to support investments (business-driven analysis effort)

• Used for Program planning, project scoping, and building a business case for ITPRB (by PgM)

Planning, Requirements Standard

• Defines a consistent set of information that must be contained in the Requirements Document Deliverable

• IPTs follow the process in “Solution Implementation” phase, but IPgTs should utilize the standard in “Planning” phase for project scoping as well

Need/Concept, Planning

IT Product and Technology Selection Standard

• Ensures that technology components or IT products utilized at PBGC provide the best value overall by urging full utilization of available products, controlling IT footprint, minimizing O&M costs, and reducing number of technologies requiring security monitoring and patching)

• Utilizes the TRB processes and TRM as mechanisms to document available products and technologies and their disposition for use in PBGC

• Requires consideration of technologies in TRM to justify addition of products or technologies

• IPgTs and IPTs are urged to follow the standard in “Concept/Need” or “Planning” phase, but the standard may be followed at later phases

Planning, Solution Implementation

Enterprise Data Standard

• Defines a set of practices that drive PBGC toward reusable, correct, current, consistent information and metadata

• Helps create a foundation for continuous and sustainable information planning, design, sharing, and maintenance

• Applied during the “Solution Implementation” phase, but IPgTs should utilize the standard in “Planning” phase for project scoping as well

Planning, Solution Implementation

Software Services Standard

• Establishes framework for planning, development and maintaining enterprise services and information sharing mechanisms through a set of practices that drive PBGC toward a Services Oriented Architecture (SOA)

• Specifies the criteria and requirements for DME efforts when building applications that require interfacing with other internal and external solutions or that can provide reuse and

ITSLCM Lifecycle

Phase Standard Description sharing of functionality

• IPTs follow the process in “Solution Implementation” phase, but IPgTs should utilize the standard in “Planning” phase for project scoping as well

Implementation Design Standard • Provides a standardized approach and elements used to document a solutions design – technical, functional, data

• Documents the information required to communicate architectural and system designs to the integrated program team (IPgT), integrated project team (IPT), and appropriate governance boards.

Implementation Development Standard

• Enables standardization of the runtime platforms, development and production environments, and coding and design approaches

• Drives PBGC towards reliable, secure, maintainable, agile, well-designed, and well-documented custom (home-grown) systems with predictable, reasonable cost

• IPTs follow the process in “Solution Implementation” phase, but IPgTs should utilize the standard in “Planning” phase for project scoping as well

Implementation Deployment and Disposition Plan (DDP) Standard

• Provides and outline of the minimum accepted artifacts and content needed to produce ‘plans’ for system deployment efforts progressing through remaining IT lifecycle

• Links to required content from select ITSLCM artifacts to facilitate communication throughout the IT solutions lifecycle

• The information collected in the DDP will be leveraged by board members to make go/no go decisions at planned CAB meetings (1st CAB: Review Infrastructure Requirements; 2nd CAB: Review Readiness for Prod/COOP Deployment)

Appendix B: Process & Architecture Presentation Samples

Business Process Diagram (using BPMN Notation)

Technical Architecture Diagram

Back Up

Production

ITC – Test Environment

Technical Architecture – Sample Template

Network/WANCDE – Development Environment Rack #/Location:

VM Names:

IP Address:

OS:

High Availability:

Firewall

RDBMS:

Web Tier:

App Tier:

DB Tier:

Rack #/Location:

VM Names:

IP Address:

OS:

High Availability:

RDBMS:

Web Tier:

App Tier:

DB Tier:

Rack #/Location:

VM Name:

IP Address:

OS:

High Avail:

RDBMS:

Web Tier:

App Tier:

Database Tier:

App 1

App 2

App 3

Interface 1:

Storage Dev:

Rack #/Location:

GB Allocation:

Test:

Rack#/Location:

GB Allocation:

Prod:

Rack #/Location:

GB Allocation:

Tape/Disk Location:

Frequency:

Restoration SLA:

RTO

RPO

COOP

SLA:

Hot:

Warm:

Cold:

Asynchronous or Synchronous

Interface 1:

Interface 1:

Method of Transport:

Frequency:

Method of Transport:

Frequency:

Method of Transport:

Frequency:

Technical Architecture Diagram Example:

Technical Architecture Diagram

Production

Data Service Tier

Access Control Tier

Web Tier

Web Service Tier

Database Tier

Storage

Storage Group Backup

Data Access Method1

Data Access Method N

Service N

Service 1

Application Tier

Development

List Server name Service name Versions

List Database names Schema names Versions Locations Blades VM names

List Type of medium Method of backup

List Application name Service name & Method Versions Application server name

List Server name Service name Type of services Method of data access

COOP Site

Data Service Tier

Web Tier

Database Tier

Storage

Storage GroupBackup

Data Access Method1

Data Access Method N

Service N

Service 1

Application Tier

Access Control Tier

Web Service Tier

Integrated Test Center

Data Service Tier

Web Tier

Database Tier Storage

Storage GroupBackup

Data Access Method1 Data Access

Method N

Service N

Service

Application Tier

Access Control Tier

Web Service Tier

Data Service Tier

Web Tier

Database Tier Storage

Storage GroupBackup

Data Access Method1 Data Access

Method N

Service N

Service 1

Application Tier

Access Control Tier

Web Service Tier

Application Architecture Diagram

Application Architecture Diagram

Business Logical Layer

Component 1 Component N

Module 1 Module 2

Data Access Layer

Data Access Methods Procedures

Web Service

Data Access Services

Service Layer

Services

Web Service

Data Layer

Schema Name 1

Schema Name 2

Schema Name N

Database 1

Schema Name 1

Schema Name 2

Schema Name N

Database 2

Schema Name 1

Schema Name 2

Schema Name N

Database N

Presentation Layer

1 2 3 4 5

Report 2

10%10%10% 10%

10%

10%

10% 10%10%10%

Report 1Function 1 Function 2 Function N

List all databases and Schemas utilized by current application in the Data Layer

List all data access methods utilized by current application in the Data Access Layer

List all components and modules utilized by current application in the Business Logical Layer

List all Functional components, modules and reports utilized by current application in the Presentation Layer

List all services utilized by current application in the Service Layer

Data Architecture Diagram

Data Service

Data Sources

Data Quality Management

Database 1 Database 2 Database N-1 Database N

Data Access Management

Data Access Methods ProceduresData Access Services Batch ETL

ETLQuality Control

Applications

Data Modeling Diagram

Data Architecture – Data Model

Physical Model

Schema Name 1

Entity_N

PK_Attribute_N

FK_ATTRIBUTE_N3

ATTRIBUTE_N1

ATTRIBUTE_NN

EFCTV_DT

XPRTN_DT

Entity_3

PK_Attribute_3

FK_ATTRIBUTE_31

ATTRIBUTE_31

ATTRIBUTE_3N

EFCTV_DT

XPRTN_DT

Entity_2

PK_Attribute_2

FK_ATTRIBUTE_32

ATTRIBUTE_21

ATTRIBUTE_2N

EFCTV_DT

XPRTN_DT

Entity_1

PK_Attribute_1

FK_ATTRIBUTE_13

ATTRIBUTE_11

ATTRIBUTE_1N

EFCTV_DT

XPRTN_DT

Schema Name N

Entity_N’ PK_Attribute_N31

FK_ATTRIBUTE_N31

ATTRIBUTE_N31

ATTRIBUTE_N3N

EFCTV_DT

XPRTN_DT

Entity_3' PK_Attribute_N31

FK_ATTRIBUTE_N31

ATTRIBUTE_N31

ATTRIBUTE_N3N

EFCTV_DT

XPRTN_DT

Entity_2'

PK_Attribute_N21

FK_ATTRIBUTE_N23

ATTRIBUTE_N21

ATTRIBUTE_N2N

EFCTV_DT

XPRTN_DT

Entity_1'

PK_Attribute_N21

FK_ATTRIBUTE_N13

ATTRIBUTE_N21

ATTRIBUTE_N2N

EFCTV_DT

XPRTN_DT

Logical Model

EDM Function Area 2EDM Function Area 1

Entity 1’

Primary Key Attributes Foreign Key Attributes Major Attributes Effective Date Expiration Date

Entity N

Primary Key Attributes Foreign Key Attributes Major Attributes Effective Date Expiration Date

Entity 2

Primary Key Attributes Foreign Key Attributes

Major Attribute 1 Major Attribute 2 Effective Date Expiration Date

Entity 1

Primary Key Attributes Foreign Key Attributes Major Attributes Effective Date Expiration Date

Interface and Data Exchange Diagram

ISP Image View

MyPBA

Spectrum/BPMPRO

Web Service

Web Service

CRM

Com m on service

Spectrum

ISP DM

Web Service

BPMPROD

Genesis

CRM

Spectrum/Genesis

MyPBA Data Exchange:

Method of Transport: Web Service Frequency: Real Time Security: PII encrypted

Data Exchange List:

Name: Spectrum/Genesis Method of Transport: JDBC Frequency: Real Time and On Demand Security: PII non-encrypted Direction: Bi-Directional Type: both batch and individual call

Name: Spectrum/BPMPROD Method of Transport: Web Service Frequency: On Demand Security: PII non-encrypted Direction: Bi-Directional Type: batch

The Diagram needs to provide following information on each connection Application Name:

Method of Transport: such as Web service, XML, JDBC, HTTP, FTP, SFTP, DB Link, etc.

Frequency: such as Real Time, On Demand, Hourly, Daily, Weekly, Monthly, etc.

Security: Encrypted, non-Encrypted, SSL, etc.

Direction: such as Incoming, Outgoing, Bi-Directional Type: Batch, Non-Batch, Permanent, Non-Permanent, etc.

Frequency:

Method of Transport:

Data:

Frequency:

Method of Transport:

Data:

Frequency:

Method of Transport:

Data:

Frequency:

Method of Transport:

Data:

Frequency:

Method of Transport:

Data:

Frequency:

Method of Transport:

Data:

Frequency:

Method of Transport:

Data: