Architecture and Software Design Considerations

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