/
Architecture and Software Design Considerations

Target release

Type // to add a target release date

Epic

Type /Jira to add Jira epics and issues

Document status

DRAFT

Document owner

@ mention owner

Designer

@ designer

Tech lead

@ lead

Technical writers

@ writers

QA


Page Properties

Emoji :dart: Objective

This page provides a centralized location to capture architectural and software design requirements and considerations related to our products, cloud infrastructure, and supporting toolchains.

Emoji :bar_chart: Success metrics


Goal

Metric





Emoji :thinking: Assumptions


Emoji :notepad_spiral: Requirements

Requirement

User Story

Importance

Jira Issue

Notes

Updates to products sometimes require cloud wide maintenance events


HIGH



 Implementation team doesn’t know what component versions to use when updating customers

 

 

 

 

Machine specifications are not standardized





Operating system patches are not regularly applied to cloud assets





Third-party software patches are not regularly applied to cloud assets





Third-party software dependencies are not tracked or managed for OM software





No formalized way for developers to communicate Operating System and Third-party software dependencies or changes to those dependencies





Update and Upgrade processes are a manual





Rolling back changes to customer environments is manual and time consuming





Development overhead for maintaining inter component dependencies reduces productivity and time to market of new features





Association between product components and database servers is not tracked or managed





DB Servers are not shared by multiple software components





Process for migrating customers between versions is not standardized across all product components





Cloud assets are assigned public IP addresses





Accessing cloud assets requires use of Hotel style VPN connection





End to End encryption is not used





Use of non-standard ports for cloud services





One-to-One relationship between customer and deployment





Not formalized way to identify customer test (lower) deployments





Cloud portal users can only see one customer/deployment or all customers/deployments





Can’t restrict portal user’s permissions within products





A new domain is created for each component version causing customer whitelisting issues





Use of load balancers for accessing cloud assets is not consistent





Unable to determine what cloud infrastructure is still being utilized (beanstalks, EC2 instances, db servers)





Cloud assets are deployed in several different AWS regions





Unable to restrict OM employee’s access to various cloud environments (dev/qa/train/demo/prod)





AWS ELB applications are not managed properly and we are at limit





Cloud asset names are not human readable, don’t convey purpose, and are inconsistent





No enforcement of EoL, EoS policies





No ability to provide “Early Access” to releases





Unable to identify and manage limited releases





Manual publishing of build artifacts





Cloud and product APIs do not require authorization or authentication





No consistent session ID used across all product components. Unable to easily track agent activity throughout product components





Customer updates and upgrades too often require an outage and maintenance window





Customer updates and upgrades can’t be “prepped” ahead of time





Customer updates and upgrades can impact other customers. Maintenance windows have to be coordinated










Emoji :art: User interaction and design


Emoji :question_mark: Open Questions

Question

Answer

Date Answered





Emoji :warning: Out of Scope