The Official AIA Blog

That is the topic of Joshua Greenbaum’s recent blog post during OpenWorld, detailing the reasons why he feels AIA is so important to Oracle.

“I used to think that Fusion Apps (did I say I was impressed with what I saw? So what, it’s worth saying twice) would be the make-or-break development on which would ride the future of the company. But more and more that make-or-break role is falling to AIA. This product, which orchestrates all the different processes across the vast, and disparate, Oracle Applications stack, is the place where the vision of Oracle becomes reality: There is no way for Oracle to pull off rationalizing its massive acquisition strategy without AIA making all the interprocess communications between, say, Glog, Siebel, Oracle Financials and PeopleSoft HR (and SAP, while we’re at it) seamless, easy, and fast. Absent a highly performant AIA middleware layer, Oracle’s dream of cross application process functionality becomes a user nightmare.”

A must-read article.

On 08.08.08, Oracle announced the release of Design to Release Process Integration Pack (D2R PIP). There were fireworks in Beijing, though legend has it that they were to celebrate the beginning of some sporting event.

The D2R PIP enables a bi-directional synchronization of product content information between PLM systems (like Oracle Agile PLM) and manufacturing systems (such as Oracle E-Business Suite), and is built leveraging AIA 2.2. Almost every company that uses Agile PLM also uses an ERP system. Irrespective of the ERP system used, the integration requirements are more or less the same:
• Engineering designs are mastered in PLM
• The NPI process releases those designs to manufacturing, where they are costed, transacted and planned for
• All future design changes are also mastered in PLM and similarly released to manufacturing using revisions made on change orders
• Engineering needs access to costing and planning related information from ERP to make decisions on part usage and design phase-in

One of the primary design objectives of the PIP has been to make customers self-sufficient in maintaining and evolving the PIP without having to hire external consulting help. The PIP is designed from the ground-up to maximize configurability and customizability for widely varying manufacturing environments without requiring a change to the base code of the integration. Extra emphasis has been placed on user-friendly exception handling, and ease of detailed drilldown troubleshooting for IT.

What is little known is that the PIP was developed using an "Adaptive Business Solutions (ABS) guided" methodology - this means that the development work was done not by the AIA team, but by other product teams and a partner (Satyam) using standard guidelines published by the AIA team and solution architecture support from the AIA Guided Development team in a consulting role. This is a landmark achievement because it demonstrates beyond doubt the high level of maturity of the AIA platform and development methodologies around it, and its readiness to be adopted by customers and partners for building their own portfolio of integrations, analytics and composite applications.

Download this datasheet to read more about the D2R PIP, and to view some screenshots.

People often ask me if AIA really provides a strategic solution to reducing integration development cycles, costs and improving quality of service and consistency.

Based one what we are hearing from customers, the short answer is a resounding, "Yes!".

If you are looking to consolidate your application integrations on a standardized platform and/or move to SOA, AIA Foundation Pack is the way to go. Customers are telling us that AIA Foundation Pack has helped accelerate efforts by anywhere from 20-30% because of our prebuilt content. (For the sake of legal, I better temper this by adding that individual results may vary.)

A lot of this is attributed to our Enterprise Business Objects and Enterprise Business Services, which are core to what makes AIA so special and where customers are seeing real value. Many of our global customers have tried to build objects themselves. In the end, their experiences have taught them that they would much rather hand this onerous task over to Oracle. A frequent quote is "I wish AIA was available when I first embarked on SOA years ago..."

If you are not familiar with our EBOs/EBSs, the beauty of them is that they are not specific to any application because AIA is designed to be application agnostic. So what you get is a non-proprietary framework to integrate ANY application within your portfolio. This is where the real challenge comes into play, right? It's one thing to integrate Oracle to Oracle apps and an entirely different beast when it comes to integrating legacy apps that have absolutely nothing in common with each other.

So whether you are integrating Oracle applications with FP, or plan to integrate non-Oracle apps to each other, consider AIA Foundation Pack. Either way, you will reap the same benefits of resuability, configurability, extensibility, cost savings, reduced risk, and faster time to value. It's a win-win situation.