Building the Core – Enterprise Business Flows - Applied SOA Patterns on the Oracle Platform - page 177

• Variations within an individual process for different countries are insignificant.
Usually, it's just a sequence of invocations of similar applications. Anyway, it
makes processes different.
• A single branch (or decomposed process with concise and formalized functional
boundaries) has up to 10 invocations (one application can be called several
times).
No wonder the realization of all of these in practically every single BPEL process was
problematic; simple math can provide us with this: 3 products * 20 business cases * 10
countries * 2 affiliates = 1200 different combinations of single order provisioning (this is
a quite modest number; we could have more combinations).
Thus, potentially, we have 1,200 services (task-orchestrated models) to maintain in our
Service Inventory, and it's definitely clear that it cannot be implemented as a single Order
Management process (sorry, Order Fusion Demo). However, what's wrong with 1,000
BPEL processes? Firstly, it's quite a big number to maintain on the server. It will require
quite a powerful server farm and considerable Governance efforts to control versions, DB
utilization when a state is dehydrated, and significant memory resources for services run-
ning in parallel. It seems that this extreme level of functional decomposition is not good
either as so many similar services will complicate Governance and error recovery, plus,
again, the hardware resources' consumption will be considerable.