Professional Documents
Culture Documents
Oracle Fusion Applications Cloud Instance Strategy and Global Single Instance Guidelines
Oracle Fusion Applications Cloud Instance Strategy and Global Single Instance Guidelines
A-Team Chronicles
Bala Mahalingam
Consulting Solution Architect A-Team
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
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.
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.
Consistent transactional business intelligence reports and analysis across all pillars and functional
modules (Sales, Service, Order management, Inventory management, Financials, etc.)
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.
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
1. Need for additional test instances to manage / maintain your post-production support activities.
2. Effort, resources required for building integrations required across these production instances if
data need to be shared.
3. Global reporting needs for consolidating the data from multiple production instances.
4. What legacy applications you need to sun-set from your enterprise and how it can be achieved.
5. Data volumes across regions, and service level agreements around performance.
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.
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.
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
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)
Bala has over 27 years of techno-functional and hands-on product development, implementation,
solution architecture and consulting delivery experience with most of his career spent in architecture,
design, development and deployment of applications and technology both on-premises and cloud. His
Show more
© 2022 Oracle Site Map Privacy / Do Not Sell My Info Cookie Preferences Ad Choices Careers