Infosys’ blog on industry solutions, trends, business process transformation and global implementation in Oracle.

« Customer Experience cloud options for Telcos | Main | INTEGRATION ON CLOUD - A STUDY IN KRONOS »

Centralized Vs Decentralized VCP Architecture

 

One of the critical decisions that businesses considering VCP implementation have to make is to choose between the centralized and decentralized architecture of VCP. This decision is very crucial not just from the operational perspective once they have implemented, but also due to the fact that the cost of the overall project is dependent on this. For a decentralized environment, business have to invest in new infrastructure and hardware required for the new VCP instance. For smaller businesses, these costs could be higher than the overall implementation cost itself.  Through this article, I would like to discuss the pros and cons of each of those approaches and throw light on the aspects which businesses need to consider for making an informed decision.

A centralized architecture is where both the EBS and the VCP reside on the same server. In a decentralized architecture EBS and VCP reside in two different servers connected through the database links for exchange of data.

Before talking about the pros and cons of these architectures, let us understand the need for a decentralized architecture when by default we have the centralized architecture enabled.

Unlike most of the transactional systems, where the transactions are done at database level, the planning in the VCP modules happen in the application server memory. The planning engine processes are highly memory intensive and the plans require great amount of memory while the planning engines are running.

One of the most common issues encountered in ASCP (one of the important module of VCP), are the plan failures related to the application memory where the plans fail after exhausting all the dedicated/available memory.  These errors could be caused by an inappropriate setup in EBS or even by manual errors as simple as creating an internal requisition with inappropriate source. These transactional errors takes a lot of process maturity and user knowledge\training to control but still very difficult to avoid. What this means is that in case the application sizing wasn't done scientifically or in the case of above errors, the planning engine run impacts the performance of all the applications that reside on that server.

Most of the businesses going with centralized architecture face challenges during the month end\period closure activities where the finance processes (which process a huge volume of data) overlap with the planning processes

Also the amount of memory consumed depends on multiple factors such as volume of finished goods, depth of BOM, volume of transactional data , type of plans being run, amount of constraints and the list continues. In our experience we have seen businesses where the plans have a peak application memory consumption of over 64 GB. What this means is that an unscientific application sizing would not just impact planning but the activities in transactional modules in a centralized environment.

For businesses which have operations spread geographically across globe and have multiple plans catering to different geographies, it is imperative that they run those plans at different times in a day meaning the server resources need to be made available at all points in time such that the plans complete smoothly.

Having said that below are the pros and cons of the available architectures:

Centralized

Decentralized

Pros:

·     Lesser investment in infrastructure and its maintenance.

·     Simple architecture.

Pros:

 

·     Issues related to planning engine will have least impact on the transactional systems.

·    Supports different versions of EBS and VCP. EBS can be at the same or lower version than VCP.

·     VCP can be easily upgraded without any changes to EBS. VCP can be patched with a minimal impact on the EBS.

·     Ideal for implementation of multiple VCP modules.

·     Ideal for businesses with multiple plans running at different times.

·     Scaling up solution (such as adding new organizations, businesses) to the existing VCP instance is easy.

·     Ideal for businesses with multiple EBS instances which can be connected to a single VCP instance.

·     Can maintain multiple but not so powerful servers.

 

Cons:

 

·    Risk of facing issues related to memory.

·    Does not support different versions for planning and EBS.

·    Difficult to patch and upgrade. Upgrading VCP would be possible only when the entire instance is upgraded.

·     Limitation in terms of scalability of the solution.

·     Not ideal when multiple VCP modules have to be implemented.

·     Need to maintain huge and powerful servers.

 

Cons:

 

·     Higher investment in infrastructure and maintenance.

 

 

To conclude, a decentralized architecture is the most preferred and recommended architecture. Small organizations which could not afford multiple servers and the businesses with very limited and minimal planning requirements can choose OR start with a centralized implementation and move over to de-centralized architecture slowly.

 

For any inputs, clarifications and feedback, please feel free to write to me at mohan.chimakurthy@infosys.com. Our specialist team of VCP consultants will assist you in taking the right decisions at the right time.

Comments

There are few more things to be considered for Centralized vs Decentralized instances.

1. Instance availability: It has been mostly found that planning generally has a different and unique set of users (planners) who are not using OM, Inventory and other EBS modules. So they would like to have an uninterrupted availability of VCP instance which is immune from EBS patches or downtime. If so is the case they may like to have a decentralized instance.
2. Functionality Impact: Another aspect is the functionality impact from EBS patches. Most planners would like to be immune from EBS patches and would like to go for Decentralized environment. So that whatever patches are applied to EBS doesn't really impact VCP functions.
3. Flexibility: Decentralized environment also provides flexibility for its own reporting servers and can thus be separated from EBS
4. Performance: As EBS gets more and more data over time but only a small fraction of that data is required for planning. So Decentralized environment for VCP provides the ability to separate out the EBS transactions from VCP and VCP remains immune from EBS data volume or performance impacts. Planners can work of their own in their pace in their instance.Also running Gather Schema Stats (GSS)is easier if instance are separated as then it works on a smaller set of data and are thus faster and more efficient.

Overall i do agree with the author that Decentralized is a more efficient instance strategy provided it justifies the investment and volume.

Post a comment

(If you haven't left a comment here before, you may need to be approved by the site owner before your comment will appear. Until then, it won't appear on the entry. Thanks for waiting.)

Please key in the two words you see in the box to validate your identity as an authentic user and reduce spam.

Subscribe to this blog's feed

Follow us on

Blogger Profiles