Okay, as an Enterprise Software Architect, you were successfull in the process of implementation of the SOA in your organization. You built SOA services to the highest standard, you adopted all the best practices, you established design-time and run-time SOA governance, however your end users keep complaining about the quality of the data served by your services. As a matter of fact, despite all the efforts that your company has made in order to re-design and to re-implement its services, such that to achieve a very high quality of the business infrastructure, these services still deliver poor quality data. Suddenly, you realize tha your SOA infrastructure doesn’t store operational data and that you need to provide as much management and governance for your enterprise data as you provide for your enterpeise services. Enter Master Data Management (MDM).

Having the right level of sponsorship from your business, you, together with other enterprise architects, create a roadmap meant to define the global strategy towards implementing a full MDM solution in your organization. This solution, based on the utilization of the Oracle MDM Suite and Oracle Data Quality familly products, is designed such that to steward, profile, match, merge and audit your enterprise data. Given the extremly etherogeneous landscape of your enterprise IT software, the business data has critical issues as the fact of being redundant in different systems like CRMs, ERPs, B2C services, etc. and not providing a centralized and unique enterprise wide view. So, one of the most critical challenges of your MDM solution is to unify your data by defining a business comon semantic and to promote this common semantic as being your enterprise master data. But while MDM subject-matter experts recruited to assist you are working hard to construct and implement the solution, you identify a new challenge : using a business common semantic as the enterprise master data requires to constantly collect and replicate data from your enterprise various systems. And since these systems are many, this seems like an onerous task and designing the right interfaces is not trivial.

However, after having conducted several researches, you and your other colleagus in the enterprise architecture team, discovered that Oracle provides so-called Process Integration Packs (PIP) in its Application Integration Architecture Foundation Pack (AIA FP). These PIPs are constructed to address end-to-end integration challenges in processes like « Order to Cash », « Procure to Pay », « Record to Report » and « MDM Integration ». This PIP come out-of-the-box and their implementation and customization requires generally little effort, saving this way many work-hours. One that particularly retains your attention is the Customer MDM Integration Based Pack which aims at being a true Customer Hub for all your enterprise services and systems. This Customer Hub will offer an unified view of the Customer business object to your Siebel CRM, your Oracle e-Business Suite ERP, your Oracle BRM revenue management system, your B2C web-apps, etc.

Implementing PIPs that come out-of-the-box with AIA FP is a win to win scenario because it not only accelerates the MDM rollout but, given that they are SOA based, all the enterprise systems and services are potentially beneficiaries. Moreover, by adopting Oracle AIA FP, the enterprise takes advantage of all the artifacts provided by this foundation, including the use of the Oracle Enterprise Repository (OER) to promte services visibility, re-use and policy enforcement. Also, using the JDeveloper plugins, business services, WSDls and XSDs that come out-of-the-box with Oracle AIA FP, and adopting AIA FP standards and taxonomies, the enterprise should be able to dramatically reduce costs and to mature and enforce its SOA best practicies.

AIA FP features and facilities would be difficult to resume in a couple of lines as they make the object of several hundreds of pages of product documentation. This foundation provides a real development life-cycle with all the required tools, including but not limited to

• Runtime artifacts like policies, composites, pre-built integrations and error handling frameworks.
• Utilities like Business Process Analysis (BPA), Process Lifetime Workbench (PLB), AIA Service Constructor, etc.
• AIA Refernce Architecture providing service re-usability, modularity, granularity, composability, loosing coupling, discoverability, etc.
• AIA Conceptual Architecture providing process, activity, data and utility services.
• Etc.

But one of the most important component of the AIA FP is probably its Shared Service Library, consisting in a number of artifacts and defining the AIA Service Taxonomy. Based on this taxonomy, complex SOA solutions can be implemented using the following building blocks :

• Composite Business Processes (CBP) : application agnostic processes implemented in BPMN2 using BPM Suite 11g or in BPEL using SOA Suite 11g.
• Enterprise Business Services (EBS) : application agnostic activity or data services, exposing coarse grained business logic like CRUD operations against first-class enterprise entities like customers, sales, orders, purchases, etc. They are implemented as SOA Suite 11g Mediators.
• Enterprise Business Flows (EBF) : application agnostic activity services responsible of delivering specific business tasks and implemented as BPEL with SOA Suite 11g.
• Application Business Connector Services (ABCS) : data services providing fine grained business logic and connection logic. They are implemented as SOA 11g Mediators. They come in two flavors : ABCS Requesters and ABCS Providers depending on their responsibility to receive messages or to expose fine grained functionality.
• Application Business Flows (ABF) : dedicated services to support point-to-point integrations. While usefull in scenarios where introducing several layers of abstraction might be penalisant from a performance poit of view, this kind of pattern is to be used carrefuly.

All these service patterns are exchanging abstarctions like Enterprise Business Messages (EBM) and Enterprise Business Objects (EBO) defined as WSDLs and XSDs and comming out-of-the-box with AIA FP. All the first-class enterprise entities are present and, consequently, they don’t have to be any more invented by every application, system or service as it is so often the case.

Download the stuff, try and enjoy !