Why should we separate ADF from SOA/BPM components onto multiple servers - Single node or Clustered?

This post explores at a high level why we should split all ADF related components (ADF/BPM UI task pages) from relating SOA/BPM components onto separate servers. The post concludes with a link to another post which shows the steps required to implement one of the offered solutions.

I worked on a BPM application that was made up of SOA, BPM processes, relating BPM UI's and an ADF application that managed the BPM solution. All of these components were initially deployed onto 1 managed  SOA server.

When the application was given to the client and it reached the UAT phase, the stress load on it increased as more users were using the system, this led to a massive drop in performance and left the application sometimes unusable. Due to the lack of resources whilst developing the application, we did not know that there would essentially be a performance issue as the number of users increased. After further investigation, we found that the initial architecture of having deployed all components on 1 server was a bad approach, and concluded that we needed the SOA/BPM and UI components onto separate managed servers so that each would have its own JVM and memory allocations, rather than 1 big memory allocation responsible for processing the whole application concurrently.

Architecture solution options
The solution offers essentially 2 architecture options:

Option A) A single node solution: This will lead to multiple managed servers running under 1 node (SOA/BPM server; ADF server). Each server will have its own port and the solution will lead to the BPM UI's successfully communicating with their respective BPM processes on the SOA server.

Pro's: Each server will have its own JVM and RAM allocation.

Con's: Each server will share the overall CPU power available on the system and cannot be allocated to 1 server more than the other.

Option B) A multiple node solution (Clustered): This will involve multiple servers and each server will have multiple nodes. Each server will run only specific components (SOA/BPM; ADF). Load balancing can be implemented to support multiple nodes under each server.

Pro's: Each server will have its own JVM, RAM and CPU power allocation. It is a future proof solution as it is easier to scale up, e.g. If the number of users increase, we can install more memory for a certain component and increase the number of nodes that will process the required work. This option provides a very flexible and recommended architecture.

Con's: More expensive and a little more complex to implement than option A. This option may require more licenses from Oracle due to the extra CPU cores utilized.

Conclusion
Obviously, utilizing any of the above solutions will result in much better performance compared to having everything deployed under 1 server. The solutions lead to ADF being less dependence on the SOA components, thus minimizing the workload for all separate components. However, you must weigh up the pro's and con's of each and decide given your requirements/constraints what solution to implement. I believe that option B will be the solution that would be recommended by Oracle due to it offering the best working practices from a future proof perspective.

Steps to implement solution option A
Due to time and budget constraints, we agreed to go ahead and offer + implement a solution for Option A. The following post link highlights what is required to separate the ADF UI components from the SOA server to fulfill Option A. We will create a new UI server, configure server settings, make a change to the application code, and then re-deploy the UI components to the new UI managed server (different port number).

How to separate BPM 11g ADF Task page components from SOA/BPM to a new ADF managed server