Configuration Management for Oracle E-Business Suite

By Subraya Mallya - May 2007 | Topics - Application Management, Compliance, Configuration Management

After defining what Configuration Management should be in my last post, let us look at what that means to Oracle E-Business Suite.

Application Configurations include a lot of switches and knobs within the application besides the IT Infrastructure components like Database, Servers, Processes, Networks, Directories. In Oracle E-Business Suite, the switches and knobs are Profiles, Extensible Attributes, Workflows, Concurrent Programs, Responsibilities…. you get the idea. They are sometimes hierarchical and composite in nature. Check the screen shot that illustrates a typical CI hierarchy.

Oracle E-Business Suite Configuration Hierarchy

Majority of the CIs govern the functioning of one or more products within the E-Business Suite if you consider all the inter-dependencies between the products in the suite.

If you notice in the screen shot above it reflects the big area that has been the chagrin of all the customers, the configurations (Configurations, Extensions, Modifications, Localizations and Integrations – CEMLI).  One of the biggest pain points for customers today, when it comes to taking a software patch or upgrade to a major release, is to identify the impact it has on their Configurations. Assuming that software vendor would have done the impact analysis for the out-of-the box features, the effort involved in identifying the impact on CEMLIs (not taking into account the effort to adapt them) is substantial. A CMDB and Configuration Management accounting for all the CEMLIs and defining relationships and dependencies would go a long way in reducing the time involved in impact analysis and more importantly identifying the accurate impact.

Today majority of the customers use solutions ranging from spreadsheets on file shares and CVS tools to manage the inventory  of their CEMLIs. That while ensures that all the files related to the extensions, modifications are version controlled in one place does not provide ability to report and map them to the other CIs. I cannot think of a reason why a CMDB which is supposed to be a repository of all the CIs provide an inbuilt source control management system to manage CEMLIs, Test artifacts, documents related to CIs.

Back to Oracle E-Business Suite, the CIs can be classified into two classes. Physical CIs (the files) and Deployed CIs (the representation that application relies upon for its functioning).

Case in Point – Oracle EBS ships the application profile options using a proprietary text file format (.ldt) which get loaded into the database as part of installation. Once installed profile options in the database that can assigned a value at Company Level, Operating Unit Level, Server Level, Responsibility Level or User Level. Now you have two CIs – the file that created the profile under physical CI and the profile itself as a deployed CI. Same concept can be extended to Workflows, Responsibilities, Database Packages.

Then there is a category classification of the CIs into Nodes, Products, Processes, Configurations, Modules, Schemas etc… to give you some idea.

I think even some of the key entities that are overarching and impact the entire suite of products like Users, Banks, Suppliers, Customers should be under Change Control to provide a comprehensive audit on the changes. Would explore that issue another day.

Automatic Discovery
Considering that majority of the CIs in Oracle EBS reside in the database, agent based and remote query options are two options to be considered. In a SaaS model, agent based approach is the only viable option.

Future
If you look into the crystal ball and see the future, you will see more fun down the road. Think of a time we are completely a Services based world. If it is not already challenging enough for companies to manage hard wired integrations, inter-relationships, dependencies, SOA/Composite Applications will only exasperate the situation. In SOA, we will be dealing with outbound services that will be invoked, inbound services that will be entertained and to make it more interesting the companies will not have much control on the services themselves. As a service provider company you will not know who is using your service and a consumer company you will not know if something has changed.
Yes, sure there will be contracts between the service providers and consumers, but while service providers keep enhancing their services the consumers will continually required to conduct fire drills everyday to ensure business continuity. I have some thoughts on it and how we can address some of the challenges. But that is fun for another day.

Back to Top
%d bloggers like this: