To frame the discussion, we decided to organize our material around application lifecycle phases, and based our discussion loosely around Oracle Unified Method, Oracle's implementation methodology for both application and technology products. Oracle Unified Method, as the name implies, is a unified implementation methodology that combined the best practices of the older Oracle Application Implementation Method as well as the methodologies from many acquired companies. The result is a very comprehensive set off best practices that should lead to implementation and operational successes if the methodology is applied properly.
At the earliest phase of an application project, known as the inception phase, there are two sets of activities that need to be done to set the foundation for achieving success later on in production. The first is to control the scope of customizations. Customization is often seen as a controversial topic, and some application vendors even go as far as telling customers to avoid customizations altogether. In our view, some customizations can be justified. One ways that different organizations compete with each other is through process innovation, and process innovation often require application customizations in order to support the processes.
However, bugs and performance problems may also get introduced into customizations alongside new capabilities. Before packaged applications are released to customers, they usually undergo extensive functional and load tests to ensure the proper functioning, stability, performance and scalability of the products. However, once customizations are introduced into these applications, these test results effectively become invalidated, as the actual application is not the same as the version that the vendor tested. In other words, there are potential costs and risks associated with customizations, so they should be made very selectively.
How to be selective?
We have observed the following practices at some of the best run application implementation projects by our customers.
- Spend time to really understand the full capabilities of the applications. The whole point of buying a packaged application is to take advantage of the business practices that are baked into the product and leverage the economy of scale of sharing their development costs with other customers. To make intelligent decisions on what to customize, it is important to know what is already in the box.
- Analyze the current business processes and adjust them as necessary to fit the application. Customizations are usually done to support specific business process activities. If the out-of-box application does not work the exact way that maps to various business tasks, perhaps it would be easier to change the way that people use the application. Furthermore, simply converting existing inefficient business processes to run in an application usually is not the best way to improve effectiveness.
- Make whoever requested for customizations justify the needs. Evaluate the requests against potential costs and risks for approval and prioritization. This process should both be quantitative and qualitative. For example, justify benefits in terms of task step reduction, or even potential incremental revenue affected. For costs, have rough estimates on implementation and testing times. A scoring system, with clearly defined criteria, could also be very useful.
The most important thing is that these activities need to be carried out by the organization's own staff as much as possible, as it can be problematic to rely solely on the advice of outside consultants. While the best consultants would provide sound advice, there are also some bad apples that would encourage customers to over customize because they stand to profit from it.
By controlling the scope of customizations, not only would you make your application implementation more manageable, but you would also increase the chance that your application will run smoothly in production.
Improved Alert State Management – Prior to 10gR5, once an alert is raised when a metric threshold is crossed, the alert would stay in Enterprise Manager until the next scheduled evaluation of the metric. This was not very convenient, as administrators want to get more timely feedback on the corrective actions that they take, and have the alert state be cleared as soon as possible. Starting with 10gR5, administrators can force a metric re-evaluation to be carried out immediately in order to verify the effectiveness of the fix. In addition, administrators can better manage their log file based alerts by setting duration based notification rules that clear such alerts on a periodic basis, or by using new EMCLI verbs that support bulk clearing of such alerts.
Repeated Notification – Repeat notifications are now supported for all notification methods – OS Command, PL/SQL procedures and SNMP traps.
Automatic Enterprise Agent Software Download – Grid Control has provided several means to automate the process of deploying agents in the past, but one task has been manual – getting the agent software package from Oracle in the first place! We have automated this step too in 10gR5. Just go to the agent page and pick out what you want and the tool will take care of getting it from My Oracle Support. Yes, this is another long overdue item.
Privilege Propagating Group – Group is one of the most useful platform features of Enterprise Manager. It lets you arrange a set of related targets together so that they can be monitored together more easily. Privilege Propagating Group extends this concept further by simplifying the allocation of access privilege to the set of targets under a group. Once you grant an access privilege to a Privilege Propagating Group, all member targets of that group inherits the same access privilege.
Posts
