Aside from being big users of Oracle Middleware we use  make use of a range of Oracle application capabilities from the EBusiness Suite family. This includes several of the ‘hub’ products such as Product Data Hub which is central to our Master Data Management strategy for product data definition and creation. A commitment to remove all the different components in the legacy estate that can author or modify product data was made and has been rolled out – not all legacy authoring solutions have been decommissioned although this is more the nature of our legacy deployment strategy.

When we setup PDH the organisation went through a lot of internal debate on whether to deploy PDH as part of our core transactional  EBusiness Suite which performs all our accounting (and a lot more complex than may appear to be) or to adopt a separate deployment approach and keep the instances in sync using the Product Data MDM Process Integration Pack (PIP) which includes an extension to integrate with EBusiness. This later approach prevailed. However we are now in a place where we are having to re-examine this decision as a result of the PIP’s EBusiness extension hitting end of life (Oracle’s declared position being that the extension has so little adoption that it is economically not sensible to maintain it).

Rather than drag through our decision history, I thought it might be insightful to share the considerations being made on how do we go forward. So what are the perceived options? We see it as:

1. Retain the deployment split and taken on the responsibility of maintaining the PIP
2. As PDH is a discrete solution we could take the hit of adopting the Fusion Applications version of Product Data Hub and solve the synchronisation through the co-existence strategy
3. Merge PDH into our main transactional EBusiness instance and remove the integration challenge by eliminating the need for it
4. Build an alternate integration solution through the use of something like Golden Gate.

Clearly several of these options challenge the reasoning for separating the instances in the first place. So it is worth looking at the arguments for the separation and against it.

The key factors for separate instances:

• System workloads in the transactional solution (for example end of month or year process runs) could impact user experience and productivity around the work of product data management. If this is the case and you can share the data but isolate the servers you will see a benefit
• PDH and other hub solutions have dependencies on the core EBusiness suite, so if you want to capitalise on the improvements around the hub capability by upgrading, then isolating the instance minimises the upgrade depends considerations. If the hub was part of an EBusiness deployment with many components such as billing, manufacturing etc there is potentially a complex dependency chain to be resolved and upgrade activity that may become necessary with all the regression testing etc to be addressed with it.

The factors for keeping everything as one large EBusiness suite are:

• The co-location of the hub and other features means that if you product authoring processes are complex and result in dependencies within the setup of other modules for example you want to align activities so buyers can both author the product data but also work with the purchasing processes you either have a multi phase authoring process – PDH to author the SKU which is distributed and then enriched within the other EBusiness instance of you end up with more modules in your hub instance and a data synchronisation challenge greater than can be resolved by the PIP.
• remove the need for the additional licensed components – I.e. The PIP (therefore AIA foundation pack, SOA Suite, Weblogic,  OEM SOA Suite  monitoring etc).

The Fusion apps option creates some interesting questions. So the messaging around Fusion is that you can migrate from the non Fusion environments in a phased approach through the idea of co-existance (effectively data replication and transformation). However, despite the fact Fusion apps are maturing, the capability atleast here we’re told this green, although the migration process is well established as a mix of automation and manual process all packaged up as a consulting engagement. In addition to this the AIA Product MDM connector which supports EBusiness needs some small changes to work with the Fusion application.

Why even look at Fusion, aside from we know that Fusion is Oracle’s long term strategic product, from the information provided to us, it has a number of handy features for us that are unlikely to be retrofitted to the EBusiness product.