Application Management can mean a myriad of different things to people across the enterprise. ITIL broadly classifies Application Management into
- Service Delivery, includes Service level management, Capacity Management, Availability Management and Continuity Management
- 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.
About Subraya Mallya
Subraya Mallya is a technology executive, entrepreneur involved in conceiving, building software businesses. In this blog, he focusses on business and technology strategies around Business Model, Product Development and Marketing. Connect with me on Twitter - @subrayamallya
