As the organization moves towards a Global Single Instance, there are four phases that it has to cross. Each phase builds on the previous one. The phases are:
1. Database Consolidation: The various databases which are spread across various instances are moved into a single data center. In this process all the databases exist as they are, but in a single data center. This enables reduction in database admin costs. This is just location consolidation.
2. Technical Consolidation: In this phase, all the different databases are moved into a single database instance. In this case the benifits include further reduciton in cost and improved access to database. Some of the challenges include UTF8.
3. Process standardisation: Here you identify the common processes and your local processes. Try to integrate these and try to bring in as much process standardization as possible. This leads to common parameters for comparison, reduction in costs and a 'single internal view' of the organization.
4. Shared Support / Service Center: This is the highest level of consolidation where you are supporting multiple country users from your single shared service center. Main benefit is the reduction in service expertise duplication.
The main challenges in this endeavour include:
1. Setup: How do you determine the global set up and local set up ? How do you bring a buy in for the global set ups? How do you determine the set ups since they are linked to processes? How do you handle set up changes based on process changes?
2. Migration: How do you structure your migration? Issues involve data structure differences, Transaction types, Primary & Foreign key mappings etc. , How many test migrations, User involvement, when should you migrate (after period end?), How many instances should be migrated at a single time, How do you handle historical data, How much of historical data needed etc...
3.Data Integrity: How do you ensure data quality? How much of data quality to aim for? How much of cleaning to be done etc..
4. Performance Issues: System performance is what the user faces. This need to be checked thoroughly during UAT. Plan should be in place to ensure that any additional hardware requirements are brought in when needed. Migration related performance applies to handling huge volume of data during migration. This leads to a question of number of parallel consolidations, regional consolidation v/s global consolidation and duplicate consolidation etc. And finally the third part of consolidation relates to the performance of consolidated entity and how to ensure optimal performance.
A very good article on how Oracle went about moving to a global single instance can be found here.
1. Database Consolidation: The various databases which are spread across various instances are moved into a single data center. In this process all the databases exist as they are, but in a single data center. This enables reduction in database admin costs. This is just location consolidation.
2. Technical Consolidation: In this phase, all the different databases are moved into a single database instance. In this case the benifits include further reduciton in cost and improved access to database. Some of the challenges include UTF8.
3. Process standardisation: Here you identify the common processes and your local processes. Try to integrate these and try to bring in as much process standardization as possible. This leads to common parameters for comparison, reduction in costs and a 'single internal view' of the organization.
4. Shared Support / Service Center: This is the highest level of consolidation where you are supporting multiple country users from your single shared service center. Main benefit is the reduction in service expertise duplication.
The main challenges in this endeavour include:
1. Setup: How do you determine the global set up and local set up ? How do you bring a buy in for the global set ups? How do you determine the set ups since they are linked to processes? How do you handle set up changes based on process changes?
2. Migration: How do you structure your migration? Issues involve data structure differences, Transaction types, Primary & Foreign key mappings etc. , How many test migrations, User involvement, when should you migrate (after period end?), How many instances should be migrated at a single time, How do you handle historical data, How much of historical data needed etc...
3.Data Integrity: How do you ensure data quality? How much of data quality to aim for? How much of cleaning to be done etc..
4. Performance Issues: System performance is what the user faces. This need to be checked thoroughly during UAT. Plan should be in place to ensure that any additional hardware requirements are brought in when needed. Migration related performance applies to handling huge volume of data during migration. This leads to a question of number of parallel consolidations, regional consolidation v/s global consolidation and duplicate consolidation etc. And finally the third part of consolidation relates to the performance of consolidated entity and how to ensure optimal performance.
A very good article on how Oracle went about moving to a global single instance can be found here.
2 comments:
I work for a financial institution where we have widespread operations. Each will have its own local processing, in its own timezone. In each location, during the day it is largely OLTP, overnight it is batch. I am concerned about the IO of the batch impacting the performance of the OLTP. And if I prioritize OLTP over batch, that the batch will not complete in time for the start of day. We are working on things like tuning the batch jobs, table partioning and the like. We are also moving to solid state disk to improve IO. Are there other things we could be looking at? DB: 11G, Tech Stack EBS 11i
Hi, Do you have any customization programs running as a batch jobs? You might want to look at optimizing these programs. Do you have an info on the data volumes of each of these batch jobs. You could look at scheduling high data volume programs at night and low data volume jobs during the day when there is lower data load (early morning, durng lunch time recess etc). Since you are working in multiple timezones,you have an advantage of 36 hour days. Also, you could schedule some of the programs to run on weekends (esp. those which do not have impact on daily reporting). Oracle has some very good expert teams who can provide support for you in optimizing the performance of your jobs.
Post a Comment