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.

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.

1. BMC – Remedy for Incident and Problem Management, Atrium CMDB for Configuration Management.
2. mValent – for Configuration Management
3. Mecury/HP – for Patch Management  (erstwhile Kintana)
4. Infra – for Change Management
5. Oracle – for Patching as part of Oracle Enterprise Manager.
6. IBM Tivoli – For Change, Configuration, Release Manager and a CMDB

Hope this list will help companies compare their offerings and map them to their needs.

1. Service Delivery, includes Service level management, Capacity Management, Availability Management and Continuity Management
2. Service Support – Incident Management, Problem Management, Configuration Management, Change Management, Release Management all housed in a Configuration Management Database – CMDB

If you check the definition of ITIL/ITSM in Wikipedia, you will find that a more clearer definition of the Service Delivery and Support functions.

I will focus on the Service Support aspects to begin with and then delve into Service Delivery. Also since the focus is on how to adapt these process in support of a Enterprise Application I will will map the ITIL disciplines as they apply to Oracle E-Business Suite Application Management.

Traditional Application Management Vendors like the BMC, Mercury, CAs of the world implement one or both of the main disciplines of ITIL Service Management in some shape or form. While most of them do a very good job of providing ready to use features in the Infrastructure area, the same cannot be said about the features that are built to support the Application Lifecycle.

As you probably know, besides the infrastructure configurations, most enterprise applications (SAP, Oracle, Documentum…) are controlled by hundreds knobs and switches in the form of Application Profiles, User Profiles, Setups, System Parameters to name a few. When you consider each of these suite of products that is comprised of hundreds of products (last count of products in Oracle E-Business Suite was 279) products that integrate with one another in some fashion. None of the aforementioned industry leaders in the ITSM space take this into account in their Auto-Discovery engine, Change Management Process, CI Dependency etc.

With IT increasingly becoming a differentiator and enabler of business opportunities, companies have started to increasingly align teams managing applications around the business process they cater to. Instead of having teams defined by products like GL Support, Order Management support, smarter organizations have started defining teams around the business processes like Quote-To-Cash, Procure-To-Pay etc. This is also in line with any typical implementation/upgrade cycles of these large applications. While some companies still do Big-Bang implementations, partly compelled by Vendors, most of them adopt the phased approach. So managing these applications in the context of the business process makes a lot of sense to me. Any change done to the application should/will be done in the context of the business process it is impacting, that way the steps you take to mitigate risks will also appropriate and measured.

Focus
Many solution providers attempt to provide generic solutions that address needs of various applications like SAP, Oracle, Documentum (with all the consolidation in the industry, I think these are three big vendors left) the very fact that there is so much heterogenity in these applications renders any solution limited in their utility. In my years with dealing with customers of Oracle E-Business Suite, I had first hand experience in understanding the challenges they faced. I will use Oracle E-Business Suite as the basis and where applicable will compare the challenges faced by SAP and Documentum.

Application Management
Application Management over the years has graduated from being a tactical necessity to a strategic imperative. Considering the mission critical nature of the Business Applications, the application management is measured and its quality constantly improved upon to ensure business continuity. In that regard it has become a specialized systems management area. While the management systems were measured for standard IT metrics like system uptime, execution throughput etc, the application management systems would be measured by the business metrics like orders processed and other business tasks performed by business users.

Here are some of the key things to keep in mind about Application Management, contrasting that with Traditional Systems Management.

1. Requires deep understanding of the inner working of the application, the process flows, setups.
2. More Functional, Business Process view compared to IT Components.
3. Top Down view when it comes to change management, risk management.
4. Need to meet compliance and audit mandates