Overview

Businesses should believe that every team is in the business of creating great customer experiences.

To achieve that, the application must do more than just provide control, reporting and audibility. The business needs to tap into data signals from across its business and use them to drive ongoing improvements in the products, services, and experiences they intend to deliver to its customers.

Data-first cloud strategy

The opportunity contained in the shift from reactive to predictive— knowing that the car is on its way to failure before it fails—is hard to overstate. For the business and for the customers, every product, service, and business process is ripe for reinvention. The business has invested in applications, an application platform, and an infrastructure platform spanning from enterprise and independent software vendor (ISV) developers to citizen developers. The entire business cloud comes together as a unified digital-transformation platform with consistent security, identity, and compliance boundaries.

Introduction

Defining the environment strategy is one of the most important steps in the implementation of the application.

Environment-related decisions affect every aspect of the application, from application lifecycle management (ALM) to deployment and compliance. At a fundamental level, a good environment strategy is about obtaining the right balance with multiple layers of compliance and security, productivity, collaboration, isolation, performance, and maintainability. A strategy to manage environment provisioning and access, and controlling resources within them, is key to

• Securing data and resource access
• Organizing and structuring solution components
• Governing and managing capacity

Environment strategy

Environments are containers that store, manage, and share our data. They also store the data model, application metadata, process definitions, and security constructs to control access to data and applications. A successful environment strategy defines the core principles and policies for creating, granting access to, and decommissioning environments of different types, along with the necessary governance process.

The project plan plays a crucial role in defining the environment strategy. Some activities could run in parallel, for example, training and data migration, as long as there are enough environments available. Constraints such as timeline and cost need to be considered as well.

To get started with creating the environment strategy, I’d like to ask the following questions:

• Where are my users physically located?
• What are business data compliance and residency requirements?
• What types of environments are required, and when?
• What are the different roles (such as developers, testers, admins, business analysts and trainers), and which environments do they need access to?
• Do we have overlapping activities in the project plan that will require an environment (such as training, testing, and data migration)?
• Is there enough time allocated in the plan for preparing an environment for a specific use (such as refresh and restore operations before training)?
• What’s the access procedure for an environment?
• Which apps will be installed in the environment?
• Will the solution require more than one production environment?
• Which services and third-party applications do I need to integrate with?

It should be apparent from these questions that the environment strategy is not the responsibility of a single person or team. It can involve IT admins, the architects responsible for the design and implementation of the solution, the information security and compliance teams, and the business stakeholders. Environment-related decisions are hard and expensive to change. The environment strategy affects how solutions are implemented.

Environment planning?

Environment planning is the process of describing the details of all the environments required during and after implementation. It includes procuring and preparing all environments that the team will need to adequately develop and test the application solution. The environment plan is a matrix format that lists the type, topology, deployment option, and due date for each environment. This plan is a living document that should be revisited after each milestone of the project.

Key factors affected by an environment strategy

The key factors directly affected by an environment strategy, include security and compliance, ALM, operations, and functional and non-functional aspects of the solution.

Compliance

Security and compliance are critical considerations for our environment strategy. We need to ensure that data is stored and processed in accordance with local or regional laws, such as data residency requirements for a specific region.

The most common elements affecting compliance are:

• The physical location of the environment(s), which usually determines data residency
• The specific features and apps in the scope and their data processing requirements
• The encryption (at rest and in transit for confidential information)
• The disaster recovery procedures to restore the service and data
• The data retention policies, and the ability to back up and restore data
• The personally identifiable information (PII) standards for data protection, and ensuring the service is compliant with the regulatory requirements for the industry and region

Performance and scalability

Cloud services provide a high degree of scalability and performance. Based on considerations such as network latency, firewalls, network traffic monitoring, organisational proxies, and routing by the internet service provider (ISP), globally distributed users can experience higher latencies when accessing the cloud.

Environment Location	User Location	Device	Network	Latency	Bandwidth
London	London	Browser	Corporate network	80ms	6 Mbs
			Internet

This exercise gives a fair idea of how the network latency will affect the user experience based on the location of application environment in use. This information can be used to make a balanced choice so most users have an acceptable level of latency, and application design can be optimised for users in high-latency locations.

The environment types should be chosen carefully, based on the workload and the capacity needed. Using trial or low tier sandbox environments, for example, will not deliver the same level of performance as live production environments, so it may not be suitable to develop or test the solution on a trial or low tier sandboxes.

The scalability of the SaaS platform is a critical consideration for the application. The scalability parameters for a SaaS could be:

• How many parallel connections or concurrent users can you support with the application or in a single environment?
• How many API calls is a user entitled to make?
• What are the limits on workflow or code executions?
• What is the peak transaction volume per hour?
• What is the imported transactions volume during the peak hour?

The following is a perspective of the SaaS cloud interpretation for scale-up/ vertical and scale-out/ horizontal scalability for the application.

Maintainability

Maintainability measures the ease and speed of maintaining the application, including service updates, bug fixes, and rolling out change requests and new functionality. If you have several applications sharing common components in the same environment, we should consider maintainability when upgrading or deploying a new release. It’s also important to invest in automation testing so you can run regression tests and quickly identify any dependencies that could cause issues. The effort to maintain the solution is directly proportional to the number of environments involved.

ALM

ALM includes the tools and processes that manage the solution’s lifecycle and can affect the long-term success of a solution. When following the ALM of a solution, consider the entire lifespan of the solution, along with maintainability and future-proofing. Changes to our environment strategy will directly affect the ALM (and vice versa), but it’s important to be clear that environments are not the repository of your code and customizations. Environments can be used to separate business functions or for different purposes, such as development, testing, and production. Typically, at least three environments are necessary to support a mature release-management process.

Types of Enviroements

Production environments are meant to support the business. By default, production environments are more protected for operations that can cause disruption, such as copy and restore operations. Sandbox environments can be used to develop, test, and delete as required.

The effort to maintain the solution is directly proportional to the number of environments involved.

Purposes of environments

• Development One or more development environments are usually required, depending on the customisation requirements and time available. Development environments should be set up with proper DevSecOps to allow for smooth CI/CD.
• Quality assurance (QA) Allows for solution testing from both a functionality and deployment perspective before the solutions are given to the business teams in a user acceptance testing (UAT) environment. Only managed solutions should be deployed here. Depending on project requirements, there can be multiple testing environments, including regression testing, performance testing, and data migration testing.
• UAT is Generally the first environment that business users will have access to. It will allow them to perform UAT testing before signing off a deployment to the production environment for going live.
• Training Utilised to deliver training. It allows business users to practice in a simulated environment without the risk of interfering with live data.
• Pre-Production An environment allowing for final customer sign off before deployment of the latest version to Production
• Production The live system for business users.

Future-proofing

Future-proofing is the process of developing methods to minimize any potential negative effects in the future. It can also be referred to as resilience of the solution to future events. The environment strategy needs to take into consideration any future phases and rollouts of the solution and allow us to deal with changing requirements and build a solution that will not limit the business or take away necessary control.

Environments and project complexity

When you buy the PEGA, you get three environments. One is the production environment, which is where the business will be conducted. It’s a robust environment, with high availability (HA) and disaster recovery (DR) capabilities. In addition to the production environment, we will receive one sandbox environment that’s a standard acceptance testing (tier 2) instance for the life of the tenant. It’s a nonproduction, multi-box instance that can be used for testing, UAT, integration, and training needs. (Because it’s a basic tier 2 instance, it may not be enough for every type of testing. For example, performance testing needs a bigger instance to handle larger data volumes and more users.) Depending on the project complexity, these environments may not be sufficient. The Figure below depicts a chart comparing the additional requirements of the application.

Environment purpose	Finance and Operations	Dataverse	Standard subscription	Less complex project	More complex project
Production	Large	Production
Pre-Production	Large	Production
Training	Small	Sandbox
MAT	Standard	Sandbox
UAT	Standard	Sandbox
E2E	Standard	Sandbox
System Testing	Small	Sandbox
Development	Small	Development

Production environment and go-live assessment

When we are preparing to go live, the first thing we need is access to our production environment. Project-wise, a production environment is deployed after all customisations are code-complete, UAT is finished, the customer has signed off, and there are no blocking issues. In a go-live assessment, a solution architect is assigned to review the project and provide an assessment of potential risks, best practices, and recommendations for a successful go-live. In some cases, the solution architect might highlight risk factors and ask for a mitigation plan. When the assessment is completed, the solution architect will indicate that you’re ready to request the production environment.

General recommendations

• Plan for environments early in the project as this may impact the project’s budget and consider the lead time needed to purchase the environment as this may impact the project timeline. Revisit the plan at regular intervals.
• Define a consistent naming standard for your environments.
• Have a regular schedule to deploy updates and import fresh data Please note that the production environment is used exclusively for running your business operations and shouldn’t be used for testing. More, the production environment is not available until the go-live assessment is finalized, a stage in which most of the testing should already be complete. You will be able to perform the cutover and, if planned, “mock” the cutover in production.
• Keep all environments in the same region if your business is in one region. For example, avoid having a test environment in one geographical location and production in another.
• Deploy environments by using an unnamed account. Assign the environments to an owner who will be responsible for their status and maintenance. It is strongly recommended using the same dedicated admin account in all environments.

Test environments landscape example

Test environment	Purpose	Release version (actual on Jan 10)
Prod	Use by end users	Release 1.1
Pre-Prod	Checking any release candidates before deployment to Prod	Release 1.1
Training	Training-related activities, MAT phase, DDM MAT phase	Release 1.1
MAT	UAT and regression for BAU releases, DDM UAT phase	Release 1.1
UAT	UAT phase for the ongoing release including functional, integration, data migration, and system regression testing. Penetration testing	Release 1.2
E2E	UAT phase for the ongoing or future releases including functional, integration, data migration, and system regression testing	Release 1.2
Sys Test	Sys Test phase, automation testing. Performance testing considering env limitation (size, scale, etc.)	Release 1.3
Dev	Unit Testings	Release 1.3