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 |
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 |
---|---|---|