CDC: Integrated Surveillance Portal High Level Design Review September 17, 2014.

CDC: Integrated Surveillance Portal

High Level Design Review

September 17, 2014

Copyright © 2012 Deloitte Development LLC. All rights reserved.2 Confidential Confidential Draft

Contents

Executive Summary 3

Current-State Architecture 4

Proposed Future-State Considerations 6

Key Design Components 9

Environment and Release Management 17

Application Environment Considerations 23

Appendix: AWS Reference Models 27


Executive Summary This high-level design review of the CDC Integrated Surveillance Portal focused on analysis of the functional and non-functional criteria, guiding principles, and considerations for future state adoption.

This review encompassed an analysis of the current state and the future state for the areas of:

• Key Feature Support,• Key Technical Requirements,• Application Integrations,• Data Migration,• Compliance Impacts,• Testing Requirements, and• Security Issues

Analysis Summary:The current system architecture meets all of the current state needs and is also well suited for future scalability. There are few key considerations noted that will provide added benefits for the future state environment.

Current State Architecture


Current State Architecture/Network Diagram Current-state system architecture sufficiently utilizes AWS’s small-scale virtualization and networking capabilities to satisfy expected demand for the initial roll-out phase of the CISP product. The following attributes of the current-state architecture are in line with recommended configurations and provide opportunities to scale based on future system load/demand:

• Division of server components (Neo4J database, Node.JS web server) means database or web server may be scaled independently to alleviate performance bottle necks

• Continuous monitoring and logging hosts operate on separate VMs, offloading associated performance cycles.

• Current practice of spinning down continuous monitoring VMs, while not in use, provides cost savings

• Small/Medium VM instances are price-effective for current state, and may be scaled vertically to handle increased load if needed

• Use of OpenVPN and SSH/SCP provide secure communications to and between host environments

*please see attached network diagram for a detailed layout of the associated components in the current state architecture.

Proposed Future-State Considerations


Proposed Future State Considerations The following recommendations are offered to improve the configuration of the CISP network architecture through the use of protected subnets and restricted external access to database components:

• Isolation of the Neo4J database hosts within a protected, private subnet, reducing security risk and restricting direct HTTP traffic against the database servers to only traffic initiated by the CISP application

• Establishing a public subnet for Node.JS, Nessus, and Splunk hosts for direct public/internet access.

• Future use of AWS load balancing and/or PIV authentication clients is supported by this configuration from within the public subnet.

• HTTP/HTTPS communication with Nessus and Splunk monitoring and logging tools is configured appropriately using the necessary ports

• Independent database and web scalability, both horizontal and vertical, is maintained

*please see attached network diagram for a detailed layout of the associated components in the proposed future-state architecture.


Implementation of Proposed Future-State Implementation of the proposed changes for the future-state will require relatively minor level of effort. The following steps should be taken to transition the current-state to the proposed future-state.

• Create a Virtual Private Cloud (VPC) using Amazon’s built in VPC creation tools• Within the VPC create two sub-nets – one public, one private• Clone images of the existing VMs and add them to the respective sub-nets.• Once configuration of the sub-nets is complete, old (preexisting) VMs may be

shutdown and/or archived.• Update DNS records to IP-switch to the new VM hosts

This implementation approach minimizes risk by setting up the new system architecture using VM clones, rather than reconfiguring the existing VMs. Additionally, this implementation may be conducted concurrently with the existing system operations and “hot-switched” when complete.

* please see the Amazon recommended best practices (appendix) for subnet creation

Key Design Components


Key Design Components – Feature Support

Key Components Current Approach Long-Term Needs Key Considerations

Supported Languages

EnglishThere are no plans to support languages other than English

• When there are needs to support languages other than English, language dependent content will need to be tracked as language specific labels

Currency SupportCurrency support is not needed for the solution

Currency support is not needed for the solution

• N/A

Search Engine Optimization (SEO)

SEO is not needed for the current state

Long-Term needs can take advantage of SEO

• Creating search engine friendly content will optimize the site for relevant keyword searches through search engines

Web AnalyticsGoogle Analytics is implemented

Google Analytics can address long-term needs

• Google Analytics can be prototyped to help determine the right degree of implementation

Responsive Design Responsive design has been implemented

Responsive design can be optimized to meet the long-term needs

• Responsive design shoudl be revisied with each iteration to ensure it will address the long-term needs

Content Management

Content management is not needed for the solution

Content management is not anticipated to be needed for the solution

• Content management may become applicable with expansion of scope, and it can be addressed at that time

The following design components were assessed across the current state and long term


Key Design Components – Technical Requirements


Browser & Browser Version Support

Support for IE 9 or later version IE browser

Support for Chrome, FireFox, Safari browsers

Continue to support all the leading and most used browsers

• Continue to support all the leading and most used browsers, and potentially optimized mobile platforms

Availability Expectations

Dependent on Amazon SLA

Dependent on Amazon SLA, which potentially could be revisited

• Dependent on Amazon SLA, which may have more availability tiers in future iterations

Response Time Expectations

Target page load: 2 to 3 Secs

Target page load: 2 to 3 Secs

• Continue to maintain the response times, as the volumes scale, and as new platforms may be considered

Expected Traffic1,000 unique visits per day

10,000 unique visits per day

• Design for average and peak transaction volumes, and incorporate the transaction growth rate into long-term panning

Use of CookiesThere are no Cookies for the solution

There are no plans to use Cookies for the solution

• End-user Cookie information may be relevant in certain use cases in the future

Printing Capabilities

Printing capabilities are not needed for the solution

Printing capabilities are not expected for the solution

• Cloud-based printing models may become applicable with expanded scope



Key Design Components – Technical Requirements (cont’d)


Email Requirements

Email feature is available, where user’s email client is leveraged

Email feature leverages user’s email client

• None

Exception Framework

Exception framework is currently not present

Long-Term needs can take advantage of exception framework

• An exception framework is a best practice for complex systems

Logging FrameworkSplunk is used for logging aggregation

Splunk is planned to be continued for logging aggregation

• None

Application Security

Application vulnerability scan test was passed

Continous monitoring is present

Continous monitoring will be available

• Continous monitoring should be accompanied with an alert system consistent with the mission requirements

Data Security Data will be public Data will be public• Any future sensitive data will require

analysis of threats and remediation actions



Key Design Components – Integrations


Services Required from CISP

Not needed for the current state

Will be needed for long-term needs

• Will need a comprehensive integration strategy in place for web service integrations

Services Available to consume from CISP



• Will need a comprehensive integration strategy in place for web service integrations



Key Design Components – Data Migration


One Time Data Load

Manual data upload process is in place

Manual data upload process will be used

• None

Schedule Data Load


Not planned for future • None

Data Cleansing and Transformation





Key Design Components - Compliance


PCI (Payment Card Industry) Level 1 Compliance

None None • None

PII (Personally Identifiable Information)

None None • None

PHI (Person Health Information)

None None • None

SOX Compliance None None • None



Key Design Components – Testing Requirements

Key Components Current Approach Long-Term Feasibility Key Assumptions

Automated Load Testing



• Planned for Future state

Automated Functional Testing




Environment and Release Management


Proposed Environment Options Proposed application environment details

Application Environment Option

Application Environment StructureThumbnail Visual

1Robust

Application Environments

DevelopmentSITConversionPerformanceQuality AssuranceUATProductionTraining

(1+)*1111111

Total 7 (Excl. Dev)

2Proposed (Optimized)

Application Environments

DevelopmentSIT / PerformanceQA / ConversionUATProductionTraining

(1+)*11111

Total 5 (Excl. Dev)

Option 1: Robust Application Environments


Proposed Application Environment Proposed IT environment with key release management tasks:

Key Release Management Tasks

• Development components after unit testing from the multiple development environments will be deployed to the System Integration environment

• After System Integration Testing, CISP components will be deployed to conversion and performance environment

• CISP performance fine tuning and performance/scalability testing will happen in the performance environment. Has integrations with all boundary systems to perform the performance/scalability testing

• Quality assurance testing will happen in the QA environment

• User acceptance testing will happen in the User Acceptance environment

• Training will happen in the Training environment

• After QA/UAT approval, CISP components will be deployed into the production environment

QA Environment

System Integration

Environment

Production Environment

User Acceptance Environment

Training Environment

Conversion Environment

Performance Environment

Development Environment(s)

Option 2: Proposed (Optimized) Application Environments


QA / Conversion

Environment

Integration / Performance Environment

Production Environment

UATEnvironment

Development Environment(s)

Proposed (Optimized) Application Environment Optimized CISP IT environment with key release management tasks:

Key Release Management Tasks

• Development components after unit testing from the development environment will be deployed to the Integration / performance environment

• CISP performance fine tuning and performance/scalability testing will happen in the integration environment. Has integrations with all boundary systems to perform the performance/scalability testing

• Quality assurance and conversion testing will happen in the QA / conversion environment

• Training will happen in the Training environment

• After QA and UAT approval, CISP components will be deployed into the production environment

TrainingEnvironment

Application Environment Considerations


Release Complexity Release Management Process Description Reviews / Approvals Timing Environments

• Implement immediate changes such as adding a field, picklist value, updating a role or page layout

• Used to fix defects as part of the current live release that cannot wait until the next release

• Involves minimal impact to the production org• Any change with a dependency on live custom

components should be first configured and tested in the UAT environment

• Changes will be tested by the quality assurance teams and user acceptance teams

• Development Manager(s)

• Production Control

• Review Committee (Post-release in emergency cases)

• Used to develop upgrade releases that only contain configuration and customization for updates, enhancements and features. Additionally, used to test drive 3rd-party apps or develop POC for plug-ins or connectors

• Involves minor impact to existing user base. Can be aligned with platform application/ feature upgrades

• User training maybe limited to a webinar/ one in-person session

• All changes should be unit tested, system tested and regression tested in the Integration environment before releasing to Production

• Review Committee

• Includes major releases (e.g. releases that require more than just configuration & customization) involving significant changes such as roll-out of new process to existing or new set of users

• Major impact on production, existing integrations and features. Requires users to be trained in the Training/UAT environment

• All changes should be unit tested in Training/UAT , system & integration, and regression tested in Integration Environment before releasing to Production

• Review Committee

Adopting a tiered environment structure for managing releases of varying degrees of complexity can reduce deployment time

Release Governance

Immediate Release / Defect fix

Minor Release / Enhancement /

Upgrade

Major Release

UAT/QA/SIT Environment

DevelopmentEnvironment

UAT/QA/SIT Environment

DEV (1..N) Performance/ Conversion

Environment

Every Four-Six weeks

On Demand /

ASAP

Quarterly

ProductionEnvironment

UATEnvironment


Quality AssuranceThe below diagram summarizes industry-leading processes for quality assurance

Unit TestEach part or unit of the application will be tested individually. Unit testing provides a strict, written contract that the piece of code must satisfy

System Integration

Testing

Individual solution modules and components are tested against the functional and integration requirements. Test all interfaces and application components within the solution in a non-integrated environment

DataQualityTesting

Validate that data meets requirements for accuracy, completeness and uniformity

Quality Assurance

Testing

Test application against documented requirements and isolate defects

Migration Testing

Validate data migration scripts and integrity of migrated data in a non-integrated environment

User Acceptance

Testing

Business/end-users validate the holistic integrated solution utilizing real business scenarios and data in a test environment.

Test results threaded to

requirements

Load new/updated configuration

Analyze TestResults

Test Application

Develop Code

Select Test Scenarios

& Data for Cycle

Create TestScenarios & Data

ValidatedRequirements

ObtainSign-Off

Testing Cycles and Descriptions

Unit Test

SystemIntegration

Testing

Data Quality Testing

Text

User Acceptance Testing

Develop DesignDocuments


Summary

The current system architecture meets all of the current state needs and is also well suited for future scalability. There are few key considerations noted that will provide added benefits for the future state environment.

Appendix: AWS Reference Models


AWS Reference Architecture

CDC: Integrated Surveillance Portal High Level Design Review September 17, 2014.

Documents

Transcript of CDC: Integrated Surveillance Portal High Level Design Review September 17, 2014.