16 - FSA Architecture Standards Template.pdf

Federal Student Aid | StudentAid.gov 830 First St. NE, Washington, DC 20002

FSA Architecture Standards

<Workstream>

Draft 0.1 <Date>

Prepared For

<Agency>

Prepared By

Tirado, Franciso (Contractor)

Note to the Workstream Author

[This document is a template of an FSA Integrated Cloud Architectural Standards document to be completed as an expansion of the FSA Integrated Cloud Strategy documentation. The template includes instructions to the author, boilerplate text, and fields that should be replaced with the values specific to the workstream.

Blue italicized text enclosed in square brackets ([text]) provides instructions to the document author, or describes the intent, assumptions and context for content included in this document.

Blue italicized text enclosed in angle brackets (<text>) indicates a field that should be replaced with information specific to the particular workstream.

Text and tables in black are provided as boilerplate examples of wording and formats that may be used or modified as appropriate to the workstream. These are offered only as suggestions and are not mandatory.

When using this template for your workstream document, it is recommended that you follow these steps:

1. Replace all text enclosed in angle brackets (e.g., <Workstream>) with the correct field values. These angle brackets appear in both the body of the document and in headers and footers. To customize fields in Microsoft Word (which display a gray background when selected):

a. Select File>Info>Properties>Advanced Properties>Summary and fill in the Title field with the Document Name and the Subject field with the Workstream Name.

b. Select File>Properties>Custom and fill in the Last Modified, Status, and Version fields with the appropriate information for this document.

c. After you click OK to close the dialog box, update the fields throughout the document by selecting Edit>Select All (or Ctrl-A) and pressing F9. This must be done separately for Headers and Footers.

2. Modify boilerplate text as appropriate to the specific workstream.

3. To add any new sections to the document, ensure that the appropriate header and body text styles are maintained. Styles used for the Section Headings are Heading 1, Heading 2, and Heading 3. Style used for boilerplate text is Body Text.

4. To update the Table of Contents, right-click and select “Update field” and choose the option- “Update entire table.”

5. Before submission of the first draft of this document, delete this “Notes to the Workstream Author” page and all instructions to the author, which appear throughout the document as blue italicized text enclosed in square brackets and change the font color of modified fields to Black.]

Contents

Executive Summary

Conceptual Architecture

Sample depiction of the Workstream’s services integration with the strategy

<Workstream> Current State Assessment

This is an example format for the Current Assessment

<Workstream> Shared Services Identified

Shared Services in a Multi-Cloud Environment

<Workstream> Cloud Technology Standards

This is an example format for the Cloud Technology Standards recommendation

<Workstream> Architectural Patterns

This is an example of a pattern for a DevSecOps implementation

<Workstream> Integration Roadmap

The following are sample textual and graphical narrative formats

Appendix 1 - Tenant and Platform Definitions

Appendix 2 - Cloud Service Models

PaaS SaaS IaaS

Appendix 3 - List of Acronyms

Executive Summary [This section contains a Workstream-focused expansion to the Integrated Cloud Strategy’s Executive Summary ]

This Integrated Cloud Strategy will ensure FSA is marching towards the same vision. A successful implementation of the integrated cloud environment requires a unified vision of the target state that addresses operational, technical, and security considerations. The vision described in this document serves as a guide to harvest the benefits of such an implementation at FSA.

The Integrated Cloud Strategy introduces the recommended approaches and techniques to guide the implementation of the target integrated cloud. It includes a description of the key shared cloud services to support an integrated multi-cloud environment and an implementation roadmap with specific goals set for both an initial 2-5 year period and a subsequent 5-7 year period.

This strategy recognizes that early adopters have made initial architectural decisions to build on and replicate proven approaches. In particular, existing operational capabilities provide a foundational platform to inform and shape the cloud implementation plans. The strategy aligns with the emerging Federal Data Strategy and leverages the principles, mandates, and best practices of the Federal Cloud Computing Strategy.

HEADING

Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Maecenas porttitor congue massa. Fusce posuere, magna sed pulvinar ultricies, purus lectus malesuada libero, sit amet commodo magna.

EXPANDING THE CLOUD STRATEGY

[Workstream} details. The detailed planning and context-specific decisions necessary to implement the vision were not within the scope of the original Cloud Strategy document but will be addressed now in this document. The specific architectural alternatives and guidance for selecting the most appropriate alternative for a given set of requirements is assembled here in the form of standard products, tools and techniques. It is not a solution architecture itself, but rather a list of standards to guide the adquisition and development of solutions for shared services within the strategy.

Integrated Cloud Vision for <Workstream>

Conceptual Architecture [This section should depict how the Workstream contributes to the Integrated Cloud Strategy’s concept of operations. It should be a birds-eye-view graphic presenting how the overall vision for an Integrated Cloud Platform is supported by the <Workstream> shared services.]

Sample depiction of the Workstream’s services integration with the strategy

<Workstream> Current State Assessment [High Level Current State Assessment: Identify and analyze current gaps, pain points, and limitations in the current enterprise and project-level solutions.]

This is an example format for the Current Assessment.

The current state presents a disparate multi-cloud environment which introduces cost inefficiencies, diminishing functionality and undue complexity. In FSA’s current multi-cloud environment, each cloud has its own support and service contract that needs to be maintained.

Each cloud environment has its own unique configuration that needs to be documented and managed. Furthermore, each cloud hosting contract has its own government oversight and management team who is responsible for overseeing the execution of the contract. This multi-vendor cloud hosting strategy has led to a siloed architecture, duplicative resources, non-integrated processes, and a disjointed operating environment. These management and technical constraints have limited FSA’s ability to enable cross-organization collaboration and improve service to the citizenry, as well as improve transparency within ED and FSA.

<Workstream> Shared Services Identified [This section should list the existing shared services which are recommended to continue being provided along with the new services identified by the Workstream. This section is intended to identify the shared services needed for the realization of the Cloud Strategy. Specific details needed for the development and implementation of those services will be addressed in the subsequent solution architectures documentation.]

Shared Services in a Multi-Cloud Environment

[Description of how the common technologies and tools identified by the Workstream, which present opportunities for establishing shared hardware and software standards, should be leveraged to reduce redundancies]

TABLE 1 Business Support Shared Services

TABLE 2 Security & Operations Shared Services

TABLE 3 Infrastructure and Platform Shared Services

Shared Service Description Business Capability IT Capability

Service Name Data Data Data

Service Name Data Data Data

Service Name Data Data Data

Shared Service Description Business Capability IT Capability

Service Name Data Data Data

Service Name Data Data Data

Service Name Data Data Data

Shared Service Description Business Capability IT Capability

Service Name Data Data Data

<Workstream> Cloud Technology Standards [This section lists the TSPG-Classified Hardware or Software standards recommended by the Workstream. If the TSPG Class ID is known, it should be entered in the first column. If not, the first column can be left blank. Product Name, Vendor, and Context are mandatory.]

Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Maecenas porttitor congue massa.

Fusce posuere, magna sed pulvinar ultricies, purus lectus malesuada libero. [Normal]

This is an example format for the Cloud Technology Standards recommendation.

TABLE 4 Cloud Technology Standard example entries

Headnote text (e.g., Dash (–) indicates no data), if needed, goes here [Table Headnote]

Footnote and/or Source text, if needed, goes here [Table-Figure Footnote-Source]

TSPG Class ID Product Name Vendor Context

2.2.4 AWS Lambda Amazon Serverless Computing Service

5.1.3 Linux Docker Containers Red Hat Containerization Platform

5.2.2 Windows Active Directory Microsoft User Authentication

<Workstream> Architectural Patterns [This section should depict the Architectural Patterns recommended. The architectural patterns are general, reusable solutions to commonly occurring needs within the architecture. These patterns will be provided as solution building blocks to deliver functionality to cloud tenants. This section is intended to identify the Architectural Patterns useful for the realization of the Cloud Strategy. Specific details needed for development and implementation will be addressed in the subsequent solution architectures documentation.

The Architectural Patterns are to be defined here as reusable building blocks to be used while constructing the applications. Their specific use in any given system development will be defined in the detailed solution architecture documentation.]

This is an example of a pattern for a DevSecOps implementation

Both the DevSecOps and the Cybersecurity workstreams will work on the pipeline considerations in collaboration with the other workstreams to define the DevSecOps Architectural Pattern. The infrastructure products standards recommended will be defined in the Cloud Technology Standards section. [Normal]

<Workstream> Integration Roadmap [This section should explain how and when the Workstream services will be implemented. It should depict how the Workstream is Integrated into the Cloud Strategy’s roadmap. It can be a textual or graphical representation of how and when the <Workstream> shared services will be implemented during the various periods of the Cloud Strategy’s roadmap.]

The following are sample textual and graphical narrative formats

Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Maecena s porttitor congue massa.

Fusce posuere, magna sed pulvinar ultricies, purus lectus malesuada libero. [Normal]

Donec blandit feugiat ligula. Donec hendrerit, felis et imperdiet euismod, purus ipsum pretium metus, in lacinia nulla nisl eget sapien. Donec ut est in lectus consequat consequat. Etiam eget dui. Aliquam erat volutpat. Sed at lorem in nunc porta tristique.

Proin nec augue. Quisque aliquam tempor magna. Pellentesque habitant morbi tristique senectus et netus et malesuada fames ac turpis egestas.

HEADING

Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Maecenas porttitor congue massa. Fusce posuere, magna sed pulvinar ultricies, purus lectus malesuada libero, sit amet commodo magna.

Appendix 1 - Tenant and Platform Definitions As part of developing FSA’s Integrated Cloud Strategy, the FSA Enterprise Cloud Platform comprises of various components. The term definitions and example characteristics are outlined below to promote consistency and standard use of the terms.

Table 0: FSA Cloud Strategy Term Definitions

TERM DEFINIT ION SOURCE

FSA

EXAMPLE

CHARACTERIST ICS

Multitenancy Multitenancy is a reference to the mode of operation of software where multiple independent instances of one or multiple applications operate in a shared environment. The instances (tenants) are logically isolated, but physically integrated. The degree of logical isolation must be complete, but the degree of physical integration will vary.

The more physical integration, the harder it is to preserve the logical isolation. The tenants (application instances) can be representations of organizations that obtained access to the multitenant application (this is the scenario of a CSP offering services of an application to multiple customer organizations). The tenants may also be multiple applications competing for shared underlying resources (this is the scenario of a private or public cloud where multiple applications are offered in a common cloud environment).

Gartner OpenShift, Kubernetes, Oracle Database Multitenant

Name Space Container Cluster

TERM DEFINIT ION SOURCE

FSA

EXAMPLE

CHARACTERIST ICS

Application Tenant

An instance of a system, an application, a software package, a database, or similar executables that operate within a shared environment. Each instance is logically isolated but physically integrated.

Gartner DCC, Partner Connect, EDMAPS

ATO System Boundary (e.g., Web Application, Business Rules, Database) Network isolation Use of subnets and security groups Different tenant isolation for Prod

vs. Non-Prod

Platform Tenant

An instance of a service provided by the platform or a sub-component of the platform. Operates within a shared environment. Each instance is logically isolated but physically integrated.

Adapted from Gartner

Token Manager, Logging, Monitoring, Auditing, Content Manager

Platform Service Containerized on virtual host Use of subnets and security groups Different tenant isolation for Prod

vs. Non-Prod

Cloud Platform

A model for enabling convenient, on-demand access and usage to a shared pool of configurable, standardized resources (e.g., services, applications, network, servers, and storage) that can be rapidly provisioned and released with minimal management effort or service provider interaction. This model provides services to build, deploy, operate, and manage tenants as a multitenancy platform.

Adapted from Federal Enterprise Architecture (Page 41)

FSA

Enterprise Cloud Platform

On-demand self-service Broad network access Resource pooling Rapid elasticity Measured service

(NIST SP 800-

145)

Appendix 2 - Cloud Service Models An industry service model will be selected and tailored based on FSA’s unique needs and business requirements to support the cloud solution. The primary types of Cloud Service Models within the industry include Infrastructure as a Service (IaaS), Platform as a Service (PaaS), and Software as a Service (SaaS). Each Cloud Service Model has differing levels of authority and visibility for the cloud owner. This Section outlines the considerations for using each service model.

Table 0-5: Service Model Descriptions

Service Model Type Description

Infrastructure as a Service (IaaS) A computing resource that is automated and scalable. IaaS are resources that are self-provisioned, metered, and made available on-demand (e.g., AWS, Azure, Google, IBM)

Platform as a Service (PaaS) A platform that software/applications can be developed and deployed on. PaaS abstracts the operating system and server levels (e.g., Oracle, OpenShift, Cloud Foundry)

Software as a Service (SaaS) An application or software that is on-demand. SaaS moves the task of managing software and its deployments to third-party services (e.g., Salesforce, Office 365)

Figure 0-1 outlines the different aspects that are self-managed and provider-supplied for each Cloud Service Model. Each Service Model provides varying levels of control and transparency which determine the ensuing roles and responsibilities (e.g., infrastructure, data, security). IaaS offers the most control and therefore more responsibilities, compared to SaaS which offers the most flexibility but least level of visibility.

Figure 0-1: Cloud Service Model Responsibility Distribution

The following table outlines FSA’s business drivers and their alignment to each Cloud Service Model.

Table 0-6: Business Driver Alignment to Service Model

Business Drivers IaaS PaaS SaaS

Outstanding Customer and Partner Experience

High Availability to Meet Partner and Customer Needs

Reduced Time to Market

Reduced Cyber Risk

Utilizing Mission Critical Information

Optimized Service and Cost

Compliance

Acquisition Approach Alignment

The FSA Cloud Strategy and Target Architecture will most commonly use the model optimized for the custom software that fulfills the FSA mission, while allowing for the selection of the other models when required. For example, the selection of a SaaS solution for case management would need to be supported by the strategy. The following sections are organized according to their level of alignment to the Business Drivers, with the most aligned Service Model (PaaS) outlined first.

PaaS

Characteristics of the PaaS Service Model include:

PaaS provides a solution that offers access to a cloud-based environment where FSA can build and deliver applications with a simplified standardized and managed development and execution platform.

Provides FSA visibility and control of the software and applications being built on the platform, including operational behaviors.

Applications using PaaS inherit cloud characteristics (e.g., scalability, high availability, etc.) while requiring reduced infrastructure management and knowledge.

Examples of PaaS include AWS ECS and ECR, RedHat OpenShift.

A tailored PaaS Service model includes the following characteristics, in addition to the ones outlined above:

Platform Services are tailored to the organization’s mission and standards established (e.g., specific organizational security requirements, software versions / platforms defined as standards)

The organization’s existing tools can be integrated with the platform while using the standards established.

Based on FSA’s IT and Business drivers, a tailored PaaS service model best aligns with FSA’s desired cloud capabilities for the standards-based FSA Enterprise Cloud Platform. A PaaS solution will enable FSA to have a centralized pipeline with standards that multiple vendors can use to develop and deploy applications. FSA will have control over the standards vendors will use as they are onboarded and transparency into how applications are being developed all while keeping the solution vendor agnostic.

The tailored PaaS service model will be most effective for FSA, particularly for custom software.

Additionally, tailoring the PaaS solution to meet the unique needs of FSA gives FSA the flexibility to leverage both SaaS and IaaS solutions when needed. SaaS offerings (e.g., CRM, custom applications) can be integrated with the PaaS platform. When an IaaS solution must be selected (e.g., contact center management), FSA will apply the standards and governance of the platform to the IaaS.

SaaS

Characteristics of the SaaS Service Model include:

SaaS provides a solution that offers software managed by the cloud vendor and configured or tailored by the customer.

When using SaaS products, FSA will have limited control over the customization and management of software, data structures, or infrastructure, which can require modifications to business processes that are enabled by SaaS products.

SaaS provides ease of software use without need for on-premises software installations, reducing the cost of maintenance and delays in upgrades.

Examples of SaaS include Office 365 and Salesforce.

With the tailored PaaS service model that best suits FSA’s needs, FSA will also have the ability to integrate customizable SaaS solutions within the platform, including CRM or custom applications.

IaaS

Characteristics of the IaaS Service Model include:

IaaS provides a solution that is made of highly scalable and automated compute and storage resources.

With an IaaS solution, FSA has control over infrastructure selection and the ability to manage aspects such as applications, runtime, middleware, data. Infrastructure is managed by the IaaS provider.

IaaS is often considered the most flexible cloud computing model, as the client has control over the entire infrastructure. With control comes a higher level of management responsibility and knowledge.

Examples of IaaS include GovCloud by Amazon Web Services (AWS) and Azure Government

The IaaS service model is not the most optimal for the FSA as the organization does not require specific control over virtualization, operating systems, and physical aspects of infrastructure.

The tailored PaaS service model will provide FSA the appropriate level of control and transparency into the infrastructure and security aspects of the platform. If FSA does need to implement an IaaS solution (e.g., contact center management), the IaaS solution can be integrated with the PaaS platform.

Appendix 3 - List of Acronyms The table below outlines all acronyms referenced through the document.

Table 0-7: Acronyms

Acronym Expression

AAASG Administrative Actions and Appeals Service Group

AED Award Eligibility Determination

AIMS Access & Identity Management System

AoA Analysis of Alternatives

API Application Programming Interface

ATO Authorization to Operate

ATS Agreement to Serve

AWS Amazon Web Services

BIA Business Impact Analysis

BPO Business Process Operations

BUT Build Verification Test

CD Continuous Development

CDR Cohort Default Rate

CI Continuous Integration

CIO Chief Information Officer

COBOL Common Business-Oriented Language

COD Common Origination and Disbursement

CoE Center of Excellence

ConOps Concept of Operations

COO Chief Operating Officer

COOP Continuity of Operations Plan

COTS Commercial Off the Shelf

CPS Central Processing System

CRM Customer Relationship Management

CSAM Cyber Security Assessment and Management

CSP Cloud Service Provider

CSR Customer Service Representative

DCC Digital and Customer Care

DCCOI PMO Data Center and Cloud Optimization Initiative Program Management Office

DDX Direct Data Exchange

DHS Department of Homeland Security

DMZ Demilitarized Zone

DOED/Perkins Department of ED/Perkins

DR Disaster Recovery

EA Enterprise Architecture

EBMS Enterprise Business Management Solution eCDRA Electronic Cohort Default Rate Appeals

ED Department of Education

EDD Enterprise Data Directorate

EDMAPS Enterprise Data Management and Analytics Platform Services

EDWA Enterprise Data Warehouse and Analytics eMPN Electronic Master Promissory Note

EPMR Enterprise Program Management Review

ESB Enterprise Service Bus

FAA Financial Aid Administrator

FAFSA Free Application for Federal Student Aid

FAQ Frequently Asked Question

FedRAMP Federal Risk and Authorization Management Program

FFEL Federal Family Education Loan

FIPS Federal Information Processing Standards

FISAP Fiscal Operations Report and Application to Participate

FISMA Federal Information Security Management Act

FPS FAFSA Processing System

FMS Financial Management System

FOIA Freedom of Information Act

FSA Federal Student Aid

FSAIC Federal Student Aid Information Center

FTI Federal Tax Information

FUTURE Act Fostering Undergraduate Talent by Unlocking Resources for Education Act

GA Guaranty Agency

GAO Government Accountability Office

GAPS Grants Administration and Payment System

GOTS Government Off the Shelf

GSA General Services Administration

GSS General Support System

HEAL Health Education Assistance Loans

HTTPS Hypertext Transfer Protocol Secure

IAM Identity Access Management

IaaS Infrastructure as a Service

IaC Infrastructure as Code

IDR Income-driven repayment

IFAP Information for Financial Aid Professionals

IGC Information Governance Catalog

IPT Integrated Project Team

IRS Internal Revenue Service

ISIR Institutional Student Information Record

ISS Interim Servicing Solution

IT Information Technology

JAD Joint Application Development

MDM Master Data Management

MPLS Multiprotocol Label Switching

MTIPS Managed Trusted Internet Protocol Service

NGDC Next Gen Delivery Center

NGPO Next Gen Program Office

NIST National Institute of Standards and Technology

NSLDS National Student Loan Data System

ODS Operational Data Store

OFO Office of Financial Operations

OHA Office of Hearings & Appeals

OIG Office of Inspector General

OLAP Online Analytical Processing

OMB Office of Management and Budget

OPE Office of Postsecondary Education

OPS Optimal Processing System

PaaS Platform as a Service

PAS Person Authentication Service

PEPS Postsecondary Education Participants System

PII Personally Identifiable Information

PLUS Parent Loan for Undergraduate Students

PM Project Manager

PPA Partner Participation Agreement

PPO Partner Participation & Oversight

PRM Partner Relationship Management

PSLF Public Service Loan Forgiveness

QA Quality Assurance

RATIONAL FSA Rational Environment

RPA Robotics Process Automation

RTW Rational Test Workbench

SaaS Software as a Service

SAI Student Aid Index

SAIG Student Aid Internet Gateway

SAR Student Aid Report

SAST Static Application Security Testing

SCM Source Code Management

SFTP Secure File Transfer Protocol

SIT Strategy, Innovation, and Transformation

SME Subject Matter Expert

SMTP Secure Mail Transfer Protocol

SOC Security Operations Center

SSA Social Security Administration

SSN Social Security Number

SSO Single Sign-on

SULA Subsidized and Unsubsidized Loans

SUT Subject Under Test

TDD Test-Driven Development

TEACH Teacher Education Assistance for College and Higher Education

TFS Team Foundation Server

TIC Trusted Internet Connection

TIN Taxpayer Identification Number

UAT User Acceptance Testing

UFT Unified Final Testing

UI User Interface

URL Uniform Resource Locator

US United States

VPC Virtual Private Cloud

VPN Virtual Private Network