See also how to configure Multiple Business Units in One Partition.

General Considerations

When considering whether to add new business units into the same partition or have them in separate partitions, there are several aspects to evaluate:

• Is the customer ready to align to global pricing process?
• Are the business processes the same or similar across the individual business units? Or are they different? In other words, can there be the same pricing/workflow logics for different units?
• Are the data (= table) structures the same for different units?
• What data (= records) are shared across business units? Especially, is Customer Master / Product Master / Transaction Data / Rebate data the same?
• Does the same customer ID/SKU represent the same customer/product in different business units? If not, are the IDs unique within all units? Can the customer/product picker display the same records for different units?
• What is the complexity level of security setup or data entitlements? Can the users see data of other business units? Or should they strictly see only their business unit?
• Is the pricing done by a central pricing manager or by local pricing managers?
• What is the number of users working in the partition at the same time?
• What is the maximum number of expected records in Product Extensions, Data Sources, Live Price Grids, Quotes, Contracts, Rebates? (This has impact on performance.)
• What is the number of business units and expected number of partitions? Should they be clustered or spread in different time zones?

Logics:

Regardless whether it is a single partition or multiple ones, the general recommendation is to use the identical calculation logics and ideally the same table structure of all tables. If case there are local specifics, those should ideally be implemented as features that can be turned on/off using a Company Parameter (something like Feature Flags for configuration).

If you do not know yet what the decision will be, the general the recommendation is to start with a single partition, since it is very difficult to merge data from multiple partitions if you need to change your decision later on. You can split at any time with a relatively small effort, but merging data together can take months.

Single-Partition Architecture

Advantages:

In a highly harmonized setup, single-partition architecture has the following advantages:

• Lower software subscription costs, but higher implementation, testing, and maintenance costs due to regression considerations. Pricefx sales can try to find a way to minimize the cost.
• Easier maintenance if there are harmonized pricing logics (single global logics) and if the data tables have the same/similar structure (Product and Customer Master, Company Parameters, etc.).
• Easier support since everything is at one place (data, logics, integrations, users...).
• Instant global analytics. All transactional data are loaded and available in a single partition. (But in the multi-partition scenario – if this is required – a “global” shared partition with consolidated transactional data can be set up.)
• Easier maintenance of “global” master data (i.e. customers) across countries. (But this can also be achieved through the use of a shared “global” master data partition.)
• Increased cross-country collaboration if quotes are created for global customers across multiple countries. (But if quotes are valid only for the particular country, there is no difference.)

• Difference in data structures can be handled by creating a Product Extensions and/or Customer Extensions to store business unit specific data. The shared data attributes are stored in the Product and Customer tables. The Product/Customer picker is always shared.

• Users log in using the same URL and the see the data for all business units at the same place.

Multi-Partition Architecture

Advantages:

• Scalability (=performance). In case of high utilization of a cluster, any partition can be moved to a different cluster.
• Generally better performance for PX tables since DB index is built for partitionId which, in this scenario, is identical to business unit ID.
• Faster and less expensive individual country implementations due to much lower complexity and no regression considerations.
  • Lower complexity of price logic and maintenance of customer/product master data/price parameters.
  • Allows differences in price logics for price-setting and quoting, easier to configure/maintain different price logics (however the best is to have them the same).
  • No adjustments at other partitions for other countries/regions (regression).
  • Fewer pricing parameters per each country iteration, easier for users to understand and maintain.
• Higher differentiation in country-specific setup and configuration(s).
  • More differentiated logics and processes (if required) without global considerations.
  • Separate release schedules corresponding more to local business time.
  • Partition specific settings (time zone, the home page, convert a quote to deal, …).
  • Easier to maintain different templates (for Price Lists, Quotes) – one template per partition may be sufficient.
  • Independence between countries if material number / SKU is not unique for different countries / BU etc.
• Allows differences in data (= table) structures. However, it is recommended to keep them the same or create separate tables.
• No interference between different units.
• Less complexity and easier maintenance of data entitlement and user administration.
• Typically, a better performance due to simpler logic(s), less data, less complex interfaces per partition. 
• Increased security for access to data across partitions (compared to just within one).
• Decreased IT dependency to harmonize data and processes.
• Physically separate businesses (different BU, way of doing business).
• When the customer does not have the standardized global pricing process or capacity to establish it in such a short time that our projects usually take.

Disadvantages:

• Users log in using URLs specific for each partition. To see the data of a different business unit, an additional login is required.
• Data entitlement is difficult or too complex.

Logics Approach Comparison

A. Single-Partition architecture

When you have to implement a country-specific feature while sharing the global calculation logic, it should be done by creating new feature-related PP, PX, etc. The feature itself should be turned on/off by setting a country PP. This is the only way to scale. You should consider the following:

•  A higher number of price parameters may be more difficult for users to learn.
•  An increasing number of features per each country iteration -> training is necessary for the users from already running countries.
•  Every adjustment might have an impact on other countries -> regression testing per each country per adjustment/rollout is required.
• More effort with setting up data entitlement and visibility of fields or logic elements for a particular country.

B. Multi-Partition by country/business unit architecture

• You need only a country-specific set of PP, PX, etc. Common PX tables can be stored in the global partition.
• The calculation logic is country-specific only -> performance can be better.
•  A rollout does not affect other countries in any way.
•  Higher software subscription costs. Enterprise customers usually have an enterprise license anyway, so this may not be an issue.
•  In case of global product and customer data, it will get multiplied; the integration will have to send the data to each partition.
• In case of different logics, much higher cost of future implementations of every new global feature. E.g. for 5 partitions = up to 5 times higher implementation cost of a new global feature (each partition has to be modified and tested individually). The same is valid for global feature bugs.
•  A global partition may be required to support global analytics or business processes.
•  A user is maintained at the partition level, global users will have to log in to multiple partitions to perform assigned tasks or approve country-specific price lists, quotes, etc.

Multi-ERP Environments

If integration into a multi-ERP environment is required, it may be difficult to stick to the general rule of a single partition. It may be required to create a partition per ERP instance.

Decision criteria:

• Are customer and product master data already harmonized?
• Is there a global data repository available, for example, a Data Lake or global ERP instance?
• Are there different types of ERP with different master and pricing data structures that you need to integrate? For example, Oracle vs. SAP vs. MS Dynamics. When this data is not harmonized, a partition by ERP type or even per ERP instance could make more sense.
• Is a middleware solution in place to shield the Pricefx application from the multi-ERP environment? If so, a single partition may still be possible. The middleware handles the different source systems. It will most likely still require product/customer extensions to store the ERP specific data.

Single vs. Multiple Clusters Comparison

Area	Single Cluster	Multiple Clusters
Big data volumes	Big data can cause poor performance	Split of the data generally helps better performance
General maintenance	Easier, lower costs	More complex infrastructure and maintenance costs
Upgradability	All partitions must be ready for the upgrade by the moment of joint upgrade Upgrade "outside working hours" can get more difficult	Each cluster can be upgraded individually (by customer readiness, time zone)
Hardware requirements (memory, CPU, ...)	Lower	Higher