SOW Attachment A6 - EHBs Core Architecture-1.pdf

HE ALTH RESOURCES AND

SERVICES ADM INISTRATION

HRSA

Office of Information

Technology Division of Enterprise Solutions and Applications Management EHBs Core Architecture

Attachment A6

ATTACHMENT A6 - HRSA EHBS ARCHITECTURE

Table of Contents

1.1. Purpose

2.1. System Architecture

2.2. Software Architecture

2.2.1. Solution Architecture

2.2.2. Platform Architecture

2.3. System Integration Architecture

2.4. Security Architecture

2.5. Data Architecture

2.6. Hardware Infrastructure Architecture

2.7. Acronym List

List of Tables

Table 1: Acronyms List

List of Figures

Figure 1: HRSA Ecosystems structure Figure 2: Grants Context Map Figure 3: Look-Alike Context Map Figure 4: Benefits Context Map Figure 5: Loans Context Map Figure 6: Solution Architecture Figure 7: Platform Architecture Figure 8. System Integration Architecture Figure 9. System Integration Overview Figure 10. Integration within Micro services for users to system

1. Introduction

1.1. Purpose

This document presents the current HRSA EHBs Core system design and architecture. Specifically, this document addresses the following:

• System Architecture

• Software Architecture

• Integration Architecture

• Security Architecture

• Data Architecture

2. Architectural Design This section will describe the approach, principles, communication of integration of EHBs ecosystems and technologies which will be used for implementation.

2.1. System Architecture

EHBs overview/ ecosystems structure is shown below (Figure 1).

Figure 1: HRSA Ecosystems structure

These ecosystems are the models that help users to manage the HRSA business domains. Each system represents its users and business processes. The HRSA business contexts that EHBs supports are consists of the following

• Grants

• Grants Look Alike

• Benefits

• Loans

Each context has the business domain and it can be divided further into subdomains and bounded context using DDD principles. The process of division is explained below.

1. Identify ubiquitous language for each domains and subdomains to get the vocabularies that HRSA employees and development teams can use for communication.

2. Define the bounded context and aggregates for each subdomain based on the ubiquitous language and provided business functionalities.

Figure 2: Grants Context Map

Figure 3: Look-Alike Context Map

Figure 4: Benefits Context Map

Figure 5: Loans Context Map

The result of DDD will be independent subdomains that capture business capabilities. Then, each subdomain contains bounded context(s) that capture independent business capability. Next, each bounded context will be implemented using Microservices. Lastly, each Microservices uses Layered Application to structure the implementation. The detail of Microservices will be explained in the Software Architecture section.

2.2. Software Architecture

This section covers Solution Architecture and Platform Architecture. Solution Architecture briefs overall on layers, components, subsystems and interaction between them while Platform Architecture briefs on reusable platform components that every product would be built on. Solution architecture leverages Micro services Architecture which are built around business capabilities and independently deployable. Besides Micro services, software architecture employs device, UI and Data layers for separating the concerns and uses various means to handle interaction among them.

2.2.1. Solution Architecture

Solution architecture explains how various micro services participate and integrate with other layers and components in the solution. Each Micro service can have its own technology stack, database / schema and business logic. SOC, the backbone of this architecture, helps to increase maintainability, testability and other non-functional requirements. This architecture supports Mobile website, mobile apps, and desktop responsive websites based solutions. Routing layers intelligently routes the user to appropriate endpoint by detecting the device type and considering other factors.

Figure 6: Solution Architecture

Virtual Directory: All EHBs web applications are developed on the Microsoft platform and hosted within IIS. The web applications are separated based on the user community and the customer unit that they support. The separation of the applications by customer units support each customer to maintain their own schedule and release priority. Separation by user community ensures separate authentication model that can be used for each community as well as an additional assurance that is added when functionality and information available to internal users is never accessible to external users. Each such separate application is held in its own virtual directory. The Virtual Directory is created with a convention of Web_ProductName_Internal for websites developed for internal HRSA community and Web_ProductName_External for external users such as the Applicant\Grantees.

EPS Portal Service: EPS portal service provides a central login service for users to access all EHBs and its sub systems. Internal users can login using AD authentication. Systems such as Pending Tasks, User Access Control, Workload Tools, Admin Tools, etc. Being a centralized solution for the common needs of all the systems, EPS is designed to support consistent layout standards for uniform user experience. It also integrates with user access controls to ensure that right individuals have right access for right data at the right duration.

Web Links: Web links is a common code and an approach used within all EHBs Solutions, to access resources/pages of other systems integrated with EHBs.

EIS: EIS is framework and a product developed for each product in order to allow other systems to access data with the EHBs Solution. This model is used to prevent unauthorized read/write access to maintain data integrity and avoid system failures due to data model changes.

Function Capabilities: Functional Capabilities represent the core modules developed in EHBs Solution to meet specific business processes. For examples, Application Review process and Grant Folder are the modules for EHB2010 solution.

Business Layer: The business layer consists of various APIs to form internal layered architecture and services to provide data access capabilities

Platform and Third Party Components: EHBs Solution uses EHBs Platform and third party products to develop forms and the business layer to address the complex business needs.

2.2.2. Platform Architecture

GOTS .NET Platform contains a set of fundamental and common features that can be reused by web applications. However, it is not a complete web application by itself which means it requires to be hosted by another web application. The goals of the design are to maximize the reusability of code, allow automated testing, and provide loosely couple of structure and consistency of usage. Providing these goals, several design patterns are used to solve certain design problems in order to achieve them. Each layer in the application has unique responsibility as described in the following sections

Figure 7: Platform Architecture

2.2.2.1. Presentation Layer

Web applications require some level of user interaction. The code that manages this user interaction is in the presentation layer. Most simple presentation layers contain user interface components, such as ASP.NET Web Forms. These components typically contain code to perform functions such as configuring the visual appearance of controls; accepting and validating user input; and acquiring and rendering data from Resource Access layer or Business layer.

The presentation layer can also include user interface process components. User interface process components perform presentation layer tasks that are not directly concerned with user interactions. For example, user interface process components orchestrate the flow of control between forms in the presentation layer and coordinate background tasks such as state management and handling of concurrent user activities. This kind of user interface process components are represented as Windows services or console applications.

Web pages that are created using ASP.NET Web forms have certain limitation that probably was not a concern when it was originally designed.

• Separation of concerns for code-behind is not clearly defined. The code inside code-behind file could be related presentation logic, workflow of application or data access.

• Unable to reuse presentation logic. If multiple web pages have similar presentation logic, it's not possible share it between them.

• Impossible to perform automated unit tests. Automating unit test relies on having a generic type that can be used to create dynamic mock object for unit test which is not provided by default with ASP.NET Web form.

A Model-View-Presenter (MVP) design pattern is considered to solve these problems. The implementation of MVP is to create a separate view, model and presenter classes for each web page.

The presentation logic and processing are placed inside presenter class. The view class is represented as web form files (.aspx and .aspx.cs). The model class contains data to be displayed by the view class.

With MVP pattern, separation of concerns is clearly defined, presentation logic can be reused with multiple views and automated unit tests for data rendering can be performed against the presenter class.

All user interface related development with Platform project will be utilizing this design pattern.

2.2.2.2. Manageability Layer

This layer contains core features and basic infrastructure of Platform. It is an integral part of all other layers. Basic functionalities from this layer are

• Security encryption/decryption

• Configuration management

• Log management

• Exception management

• Trace management

• Resource management such as error messages and images

• Basic data structure

• Constants

• Extension methods

• Shared utilities helper methods

2.2.2.3. Security Layer

This layer encapsulates communications for access control for all solutions that use Platform. The access control is divided into 2 parts: authentication and authorization. Authentication happens to every single request from client browser to web server to identify the user of the request. User name and password are used to authenticate with data model as a method of authentication. After the request is authenticated, a user principal will be attached to the request as either anonymous or named user. Then, authorization process begins to validate whether the current user principal is allowed to perform certain operations of the web application.

2.2.2.4. Resource Access Layer

In every web application that requires data persistence need to have a mechanism to access resource or data storage. This layer lies between the business layer and a database or external services. The data access logic is responsible for persisting business entities to a database and retrieving individual business entities or sets of business entities on behalf of the business layer. The resource access layer may also contain service agents which are responsible for contacting other services to retrieve resources.

The resource access layer should encapsulate all the code that deals with external resources (such as databases or other services), without leaking any of these implementation details to higher layers.

Platform provides 2 mechanisms to access resources: database and web service.

2.2.2.5. Business Logic Layer

This layer separates the business logic from other layers, such as the resource access layer and presentation layer. By doing this, the business logic of an application can often withstand modifications or replacements of other layers and can be reused. Business logic layer is composed of

• Business rules that express business policy

• Business work flows that are the ordered tasks of passing documents or data from one participant to another.

Platform provides generic business entities to allow solution developers to quickly build specialized ones.

These entities do not contain business rules or work flow logic and need to be used by specialized business entities within a web application. They are listed as following Address validation

• Provides a user interface to capture and display domestic and international mailing and physical addresses.

• Validates and standardize domestic addresses based on USPS database using the zp4 tool.

Task assignment

• Maintain direct and indirect hierarchical user role assignment in the context to an object (application, issue, etc.).

• Maintain backup for user role during the user's absence.

• Return all the users for a role and get a user assigned to the given resource either directly or indirectly.

• Given a user, it gets all other users that are his/her subordinates.

Checklist

• Framework to store questions and potential answer that can be dynamically rendered on a web page.

• Support changes to questions over period over time while maintaining the look and feel of the previously captured data.

• Supports quick development of capture web pages.

User comment

• Provides a generic approach to capture and display comment with WYSIWYG feature.

• Allows a user to easily enter or edit rich text comment with a set of built-in tools.

• Allows user to remove the comment if necessary.

Document

• Supports attachment functionality.

• Provides consistent user interface to capture attachment.

• Maintains relationship between uploaded attachments and other objects within the system.

• Supports virus scanning of the attachment.

• Supports other file management activities such as moving, copying and deleting an uploaded attachment.

Data lookup

• Supports the retrieval and caching of lookup values from database, XML file or web service

Messaging and notification service

• Sending notifications to external email accounts while maintaining a copy within the system.

• Retrieving of the sent emails.

• Maintaining the notification in context to an object.

• Generation of parameterized standard messages.

• Sending notification based on a schedule.

• Allow sending messages on-demand or scheduled.

Pending and asynchronous task

• Provides a single interface to display tasks across different phases and solutions.

• Encapsulates the display and search of tasks from the complicated business logic.

• Supports quick search and display of tasks.

• Allow asynchronous task processing.

Page status

• Supports organization of web pages’ status.

• Finding status of individual section and updating it.

• Finding the previous and next section for navigation.

• Checking over all completion status.

Document template

• Allow users to download the data files or the pre-designed documents with prepopulated data.

• Combines the functionalities provided by the Document Manager component to allow users to upload the downloaded documents.

User action

• Supports capture and display of user actions in a consistent format.

• Support filtering and search of user actions.

Task work flow

• Supports processes work flow to figure out the different activities and appropriately redirect tasks.

• Supports Pull and Push tasks

Rule validation

• Supports definition and execution of validation rules.

• Supports categorization of rules as Rigid and Non rigid validation.

• Integrated with regular expression validation.

• Supports dynamic generation of validation rules.

• Automatically display validation error based on the rule type and custom location.

• Built in validation error summary with navigation to individual error.

Favorite page

• Allow user to add favorite page for quick access.

• Allow user to manage list of favorite pages.

Recently accessed page

• Automatically add accessed page and display to user for quick access.

Item tracking

• Display a list of user items based on given criteria.

Ticker service

• Display a list of upcoming events which belong to the user.

• Notify user of important actions.

Event scheduler

• Display user events schedule.

• Display all events schedule.

Page table of content

• Display page status with table of content style.

• Allow exporting a page to different file format like ZIP and PDF.

2.3. System Integration Architecture

The EHBs solution software architecture is designed to meet all requirements such as seamless integration, single sign on and robust data exchange mechanisms while optimizing common quality attributes, such as performance, security, and manageability. It involves a series of decisions based on a wide range of factors.

Each of these decisions can have been made with consideration to quality, performance, maintainability, and overall success of the application. The solution employs layered architecture for its functionality and user interface and uses service oriented architecture for solution visualizations.

Below figure is a generic architecture diagram for EHBs solution developed. The diagram shows how the different layers and modules in the EHBs Solution interact with each other and also the various layers of the EHBs Solution and how it integrates with EPS and other common modules within EHBs.

Figure 8. System Integration Architecture

The following section describes the system integration architecture for HRSA EHBs Mobility. There are two types of integrations: system to system and users to system.

Figure 9. System Integration Overview

The following practices will be used for system to system communication:

• Integration through service layer which implemented as RESTful web services (HTTPs), Transactional web services and messaging protocol (AMQP).

• Prefer asynchronous model for communication between external systems, another domain, subdomains, and bounded context.

• Avoid direct database integration.

Figure 10. Integration within Micro services for users to system.

The following practices will be used for users to system communication:

• Integration through email notifications, COTS applications such as MS Outlook, Excel, etc.

• Notification to users while working on the system without refreshing the page.

• Prefer asynchronous model for communication to COTS tools.

• Prefer synchronous model for communication within the bounded context.

2.4. Security Architecture

This section describes the security principles for HRSA EHB. It defines the guiding principles which will be followed to make sure that system is not vulnerable. Access Control & Authorizations are two major components of security architecture. Various security principles can be defined under the following categories:

User Authentication:

o Provides support for user authentication against AMS through Active Directory Federation

Services.

o Provides support for two factor authentication.

o Provides single sign-on support using Federation Services across EHBs Eco system.

o Provides the various API/services for authentication methods like login, logout and Is User

Logged in, etc.

o Provides supports for Token based authentication. Tokens are stores in cookies for websites and local storage for mobile devices.

o Supports authentication for various user community like internal HRSA users (Grantor), external users (Grantee) & Reviewer community.

o Single sign-on / Cookies based authentication is supported with the same domains.

Figure 10. Integration between AMS and EHBs

User Authorization:

o Provides support to verify whether user has access to different resources.

o Provides authorization support at roles, sub roles, and privileges levels.

Authentication within EHBs Eco System o Provides support for system to system authentication within EHBs Eco System.

o Provides support for authentication across various bounded context with shared secret keys.

Authentication with External Partners o Provides support for system to system authentication with external integration partners.

o Provides support for authentication with shared secret keys.

2.5. Data Architecture

Figure 11: Data architecture

The current EHBs Data Architecture (Figure 11) supported in EHBs consists of multiple DB servers, and three types of communication. Each type of database supports a unique business purpose described below.

• Administrative database stores the meta-data of EHBs and SQL Server to support other databases to operate.

• Transaction databases stores transactional data collected and managed by EHBs Solutions.

Some of the examples for enterprise data are Awards, Funding Memo, and example of Program specific data are GAAM, UDS, Formula, BPMH, and FTCA.

• Report/ODS databases stores one-day old copy from EHBs transactional databases in a de-normalized data for simplified reporting. It also provides views for other non-EHBs integrating partners such as HRSA data warehouse (HGDW), and IRMIS.

• Master Data Repository (MDR) stores transformed transactional data into data schemas that can be shared across EHBs sub systems. It helps in effective distribution of bulk data. It also leverages replication to minimize the impact on the transactional data source.

• Staging/Crosscut databases stores de-normalized tables with data from multiple data sources. It also stores flat tables for crosscut data sets prepared by merging data from GAAM, UDS, and awards data. It is an intermediate storage area used for data processing during extract, transform and load (ETL) process. It is used for reporting, dashboards and analytical OLAP. It typically stores flat tables that help with incremental data load.

• Snapshot database stores historical point in time data that cannot be updated. It needs to ensure consistent reporting of publicly shared point in time data while the current transactional data may be changing. E.g. UDS frozen data for preserving historical data.

• Analytical database includes OLAP data with multiple measures which can be sliced and diced by various dimensions to help with online/ad hoc analysis. It also stores 1000+ measures covering all UDS reporting forms. These measures can be aggregated at grantee, state and national level, also can be sliced by categories of UDS forms (dimensions).

• Knowledge Management (Wiki) database stores EHBs help content to support users on how to use the EHBs.

• Search database stores datasets used for keyword search feature from EHBs.

2.6. Hardware Infrastructure Architecture

Figure 12: Hardware Production infrastructure

The following virtual machines (hardware) are required in order to host the EHBs solution:

Server Entity Operating System Domain Server Description (Technologies)

IS Microsoft WS 2012-R2 OITNET CORE EHBs and Program Specific Systems (.NET 3.5/4. x/.NET Core 2.X/3.1.x)

EIS Microsoft WS 2012-R2 OITNET Web Services (.NET 3.5)

ERS Microsoft WS 2012-R2 OITNET Reporting Applications and .NET Dashboards (.NET 2.0/3.5/4.5)

SSO Microsoft WS 2012-R2 HRSA Single Sign-On / Authentication Module (.NET 3.5/4.5)

TXN Microsoft WS 2016 HRSA Transactional Databases (SQL Server 2017 w/ SSIS)

ODS Microsoft WS 2016 HRSA Operational Data Store (SQL Server 2017 w/ SSAS, SSIS)

Data Mart Microsoft WS 2012-R2 HRSA Reporting Databases (SQL Server 2012 w/ SSIS)

FS Microsoft WS 2012-R2 OITNET File Server for EHBs Applications

Wiki-Web Microsoft WS 2012-R2 OITNET Wiki Application (Atlassian Confluence)

RS Microsoft WS 2012-R2 HRSA BRS Reporting DB (SQL Server 2017 w/ SSAS, SSRS)

Wiki-DB Microsoft WS 2016 HRSA Wiki Databases (SQL Server 2017)

Solr Microsoft WS 2012-R2 OITNET Global Search (Apache Solr)

1. IS, EIS, ERS, and SSO are web servers with applications hosted on IIS 8.5 on the Windows Server 2012-R2 operating system. These servers all have .NET 3.5 and 4.5 installed and run applications on the .NET 2.x/4.x runtime environment.

2. RS is a report server with SQL Server 2017 Reporting Services hosted on Windows Server 2012- R2. The ReportManager and ReportServer applications serve traffic over HTTPS over port 443.

3. TXN and ODS are database servers hosting HRSA EHBs business data on SQL Server 2017 on the Windows Server 2016 operating system. The TXN server uses the Core Database Engine and SQL Server Integration Services (SSIS) components while the ODS server uses the Core Database Engine, SQL Server Integration Service (SSIS), and SQL Server Analysis Service (SSAS). SSAS is used to host dimensional data sets in cubes.

4. FS is a file server hosting HRSA EHBs business data using SMB 3.0 file shares on Windows Server 2012-R2.

5. Wiki-Web is a web server hosting Atlassian Confluence’s wiki application on IIS 8.5 with routing to Apache Tomcat web server on the Windows Server 2012-R2 operating system. Wiki-DB is a database server hosting wiki metadata on SQL Server 2017 on the Windows Server 2016 operating system.

6. Solr is an application server hosting search and indexing functionality using Apache Solr on Apache Tomcat web server on the Windows Server 2012-R2 operating system.

The network architecture for the HRSA EHBs consists of the following features to maximize security, availability, and manageability:

• All web servers, except single-sign on (SSO) servers, reside within the OITNET DMZ to separate application solutions which are exposed to end-users from the HRSA EHBs business data which resides within the internal HRSA network.

• Firewall rules restrict access between the OITNET DMZ and HRSA network to only the ports and servers required for data access to applications (i.e. port 1433 for SQL Server)

• Citrix NetScaler load balancers are used to manage HTTP/S traffic to each web server, including SSL offloading and server availability detection. The default configuration exposes the virtual IP address of the load balancer to the public internet over HTTP/S and internally routes traffic to the target server. The only server which is exposed to the public directly without a load balancer is the RS server entity.

2.7. Acronym List

Table 1: Acronyms List

Term Definition

HRSA Health Resources and Services Administration

EHBs Electronic Handbooks

TCO Lower Total Cost of Ownership

SOA Service Oriented Architecture

OOP Object Oriented Programming

TTLB Time to Last Byte

MTBF Mean Time Between Failures

DDD Domain Driven Design

CQRS Command Query Responsibility Separation

HTTPS Hypertext Transfer Protocol Secure

AMQP Advanced Message Queue Protocol

COTS Commercial of-the-shelf

ETL Extract Transform Load

Term Definition

DSC Microsoft Desired State Configuration

TFS Team Foundation Server

SDLC Software Development Life Cycle

ODS Operational Data Store

MDR Master Data Repository

AOP Aspect Oriented Programming