Deciphering Oracle Fusion Applications Architecture

Dears,

Before we start this fusion series ,My many thanks to Alex for enlightening us with his simple but powerful thoughts around Fusion Apps.I have taken the privilege to share this in my blog post.

The unique and highly anticipated product offering that Oracle has in its portfolio - namely Oracle Fusion Applications - is a complete enterprise application suite ranging from CRM over Financials, SCM and HCM, just to name a few of the modules available.

We all know the story. Fusion Applications is both old and new, having been in the making for almost 8 years and having been released not much more than a year ago as version 1. It kind of reminds me of Aesop's fable "The Tortoise and the Hare" which teaches us that slow and steady wins the race.

Many a myth ranks around the still young software which will (a truly personal opinion of mine) slowly but steady make its way into enterprises around the world over the next decade (and evolve further with that, of course). One of these myths is that the architecture of Fusion Applications is complicated or even frightening.

I'll try to bust that myth today with a diagram I derived from insight gained in a class I'll  finish today as a student.

click to enlarge

This is not the simplest diagram I could have concocted but it's a bit less frightening than this whopper. 

Source: Oracle Enterprise Repository

So let me quickly explain the pieces of the first diagram:

Oracle Identity Management

On the left of the diagram you find all the nice acronyms for the modules that make up Oracle Identity Management (OIM). Being the central instance for user authentication and authorization within the Fusion Applications architecture, it consists of:

• Oracle Internet Directory (OID)
• Oracle Virtual Directory (OVD) (optional)
• Oracle Access Manager (OAM)

OID can connect to a variety of authentication directories, which of course translates to "LDAP" or "Active Directory (AD)" most of the times.

All components of OIM are implemented as applications deployed in two separate WebLogic domains and have their own database (schema) for storing data.

Oracle HTTP Server and WebGate

Connections are routed through the web tier which is comprised of Oracle HTTP Server (OHS) with the WebGate extension.

Fusion Application Server

As you can see from the diagrams above, the Fusion Application Server is quite a beast, a true workhorse having to carry the load - albeit balanced across physical machines - of dozens and dozens of applications which are packed into WebLogic domains.

When you open the hood using Enterprise Manager, you can get a glimpse of what goes on:

The above screenshot shows the content of the Common Domain which contains the common modules such as Help, Functional Setup Manager etc. Quite impressive, isn't it?

Conclusion

As many of us will only have contact with Fusion Applications as a cloud offering, many pieces of this architecture will lay beyond reach behind firewalls. Because of the sheer amount of hardware needed to instil  (pun intended) and run a Fusion Applications environment, it is quite challenging to setup a self-study or evaluation system and stick your nose into it like we are used to from Siebel or other "ancient" systems.

I hope this post helps a bit to lift the veils which shade the truth about the Oracle Fusion Applications architecture. When you look at it from the stratosphere it doesn't look so frightening at all, ain't it? ;-)

Thank P&C

DC*