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.