Time required to read: < 10 minutes

Introduction

We all have heard several quotes around “Together we are stronger”. Relating this to Oracle’s Fusion SaaS (Software as a Service) applications cloud implementation, you may realize the importance of having front office and back office applications integrated and working together.  Oracle's Fusion SaaS applications cloud is built on a single unified data model with consistent user and developer experience, that connects end-to-end business processes across Human Capital Management (HCM), Enterprise Resource Planning (ERP), Projects & Portfolio Management (PPM), Customer Experience (CX) and Supply Chain Management (SCM) functionalities. 

There are two aspects of instance strategy. First one is to decide how you are deploying your modules and functionalities (single instance vs multiple instances) in production, and the second aspect is how to leverage the test instances / environments during the implementation.

Objective for this blog, is to provide you with a high-level overview on instance strategy and factors that you should consider during your Fusion SaaS application implementation.

Global Single Instance (GSI)

A Global Single Instance (GSI) is an environment provisioned that can support the entire Oracle Fusion SaaS cloud applications including HCM, ERP, CX, PPM, and SCM. You would use Functional Setup Manager (FSM) to enable the modules / offerings and setup the functionalities based on your subscriptions and business requirements. Generally, for every subscription you will be provisioned with two instances – One Production (PROD), and one Test (TEST). You may get additional TEST environments based on your implementation requirements if needed.

Benefits

Deploying all available offerings and functionalities in GSI, provides the following benefits.

• Sharing common data model & objects such as customers, suppliers/vendors, partners, products, customer hierarchies across modules, which eliminates the additional integrations. Refer to my previous blog on Best Practices on modeling master objects and hierarchies.

• Faster deployment and easier maintenance leveraging common setup and development tools/utilities/ such as Functional Setup Manager, Application Composer, Page Composer, Job Scheduler, and Reports & analytics. Refer to Best Practices on configuring and extending Fusion applications.

• Flexible approach for implementation supports both modular, multi-phased and big-bang (not a recommended one) approach that helps to meet your business requirements.

• Business process standardization and consolidation with flexibility in configuration/extension of business rules for global deployment.

• Consistent transactional business intelligence reports and analysis across all pillars and functional modules (Sales, Service, Order management, Inventory management, Financials, etc.)

Single Production Instance versus Multiple Production Instances

Choosing the instance strategy is a critical component that will have to be decided during the initial period of planning any implementation. I recommend you to consider deploying Oracle Fusion SaaS application cloud in a single instance which will give you all the benefits we discussed above. There are legal, regional data security policies and some business use cases that could warrant multiple production instances.

The diagram below will give the potential considerations for deciding single versus multiple production instances for your deployment.

List of considerations are given below for your reference:

1. Review your current development team organization – global versus local, and the strategy for configuration / extension, release management and change management needs. Your business requirements and commitment to manage global configurations, and how you would manage the variances based on regional needs.

2. Data governance policies & procedures need to be defined & designed on your master data objects such as Chart of Accounts, Customers, Products, Suppliers, Partners, etc.

3. When you are deploying multiple modules, you should plan the project / release management for co-ordination across the development and user teams, communication and governance.

4. Planning for regression testing schedules on all modules deployed and being deployed during the upgrades / patches.

5. Development activities involved in configuring and extending applications which potentially could duplicate the development activities, and maintenance of different versions of configurations would become a tedious project by itself.

6. Consider the following use-cases prior to finalizing multiple production instances for your deployment

   • Need for additional test instances to manage / maintain your post-production support activities.

   • Effort, resources required for building integrations required across these production instances if data need to be shared.

   • Global reporting needs for consolidating the data from multiple production instances.

   • What legacy applications you need to sun-set from your enterprise and how it can be achieved.

   • Data volumes across regions, and service level agreements around performance. 

   • Internationalization, security, legal, compliance and user experience requirements.

7. In a global single instance, by definition one of the operating units assumes control over the master data and sets the agenda for it. Consider your business requirements around on-boarding, and managing master data such as customers, partners, suppliers, products, hierarchies, product catalogs and financial master data.

Guidelines to leverage the TEST instance(s) during your implementation

As mentioned earlier, your subscription would come with one TEST environment and you will have additional non-production environments if you have subscribed as needed.

Always, global deployment’s will be planned in phased approach. The phases defined can be modular or region/country wise or combination of both. For example, North America, Europe, Asia Pacific etc. or start with global Financials, Procurement, Payroll, Sales, Order Management and so on. 

Irrespective of your deployment, you need to plan how you would be using your non-production environments effectively during the implementation.

Key guidelines to be considered during your implementation:

1. Cross-pillar teams co-ordination is the key success factor for your global deployment and need to be engaged in planning your release management, project tasks and schedule. Key areas for cross teams co-ordination are given below: 

   1. Project scheduling, environment planning, environment refresh planning & scheduling, patches & monthly/quarterly updates, cross-pillar reporting, communication, quality assurance, monitoring & measuring your cloud subscriptions.

2. Create an environment management plan early in the implementation and proactively identify the services/tasks required for environment management. The table below provides a sample environment plan.

After Phase 1 go-live TEST environment could be used as a production fix and DEV1 environment will be your Phase 2 development environment. When Phase 2 testing is being done, you have to plan your go-live and production fix activities accordingly using additional P2T and T2T environment refreshes to re-purpose your available environments in your environment planning and release management.

3. Plan ahead your environment for a purpose (such as development, functional testing, integration testing, data load, user acceptance testing, training etc.) and required period.

4. Understand your upgrade/maintenance cadence, and make sure you have these upgrades, maintenance timelines, down-time, and availability included in your project plan.

5. Do not miss the environment refresh requests and requirements in your schedule. 

6. Understand the environment refresh and masking requirements and plan accordingly. Do not miss out additional configurations/testing effort & time after environment refresh is completed based on your requirements.

7. Plan your project tasks to understand new features and roadmap on upcoming releases. This will help you in deciding work-arounds and extensions.

8. Plan to test the quarterly updates in a non-production environment.

9. Define the process for testing new releases / updates and patches in advance.

10. Involve all key stake holders, functional, technical, administrators, back-office and front-office users while planning the project tasks.

11. When you are planning more than one phase, do not miss out to plan the production support tasks, and resource separated out from the project development tasks. 

12. While planning the cut-over dates and go-live for production environment, make sure that you take the quarterly/monthly cloud updates/upgrades in your plan.

Summary

By defining the environment strategy and instance management tasks early in your implementation planning, you can address all the environments availability related risks proactively.

The recommendations and options described on this blog are general guidelines that you can use to plan your environment management strategy.

References

Oracle Applications Cloud – Fusion Applications Environment Management Best Practices (Doc ID 2848566.1)

Oracle ERP Cloud Implementation Leading Practices