When I was working as a staff officer, a key concept that constantly came up was that of a battle rhythm. For the unfamiliar, the term seems to be a bit strange. I believe the only organization with more terminology that IT is the military. I may be treading into dangerous territory by combining the two cultures but I learned quite a bit from my time with the military and I try to apply some of the concepts to the IT profession.
Supporting Oracle Applications 11i is one of our team's primary missions. I am frequently asked the question, "What do you do in a typical day". IT is difficult to explain to people who are not actively engaged in profession. I often find myself drifting towards other IT professionals at parties and other social events because we speak the same language. Explaining the operational support requirements of an ERP system is even more difficult. Since military staffs are used to working in a complex environment, I decided to apply to battle rhythm concept to the Oracle 11i operational environment.
I need to clarify what battle rhythm is before getting too much further. A battle rhythm is basically a schedule of important recurring events. The twist is that a battle rhythm typically includes subordinate, peer and parent units. The concept is to create a schedule where all of the related units (departments) are in synch with each other. Also, there is typically a plan and execute dimension to the concept. While one unit is planning, the other one is executing. Militarily speaking, units gain great advantage by compressing their battle rhythms as much as possible. This allows them to respond and react much faster than their opponents. While most organizations do not have a need to operate at such a high tempo, the organization discipline is important for other reasons, see the benefits section at the end. I found a great definition and example on Globalsecurity.org.
Once again the term "battle rhythm" describes those events that a unit conducts on a recurring basis that facilitates setting the conditions for success. Many factors help determine and establish a unit's battle rhythm. Some of these factors are your unit's state of training, the battle rhythm of your higher headquarters, and your current mission. Your battle rhythm must remain flexible. Some missions require much more time and effort to plan and prepare for than others. Additionally, your battle rhythm cannot be so inflexible that you fail to react to targets of opportunity as they present themselves on the battlefield.

With Oracle Applications, the main support requirement is patching. We have to patch constantly. It is a common and recurring task. Patching comes in two forms; regular updates and bug fixes. The regular updates include quarterly CPUs (critical patch updates), annual legislative updates and Vertex tax updates.
For our organization, we have two full time DBAs and one QA resource whose main job is patching. We have a large 11i footprint including HR, Financials, Project Management and several self-service applications. I took a quick review of our patching effort over the last 12 months and discovered that we applied 175 patches and repaired 13,452 bugs. These numbers should be multiplied by three since we have three non-production environments for testing and QA. As a rule of thumb, we apply at least one patch a day. If we can get a handle on the patching, then we should be able to free up more time for "targets of opportunity" such as development or emergent bug fixes.
I reviewed all of our patching tasks and applied the battle rhythm concept to our department. The chart below is my first stab at defining a battle rhythm for Oracle Applications 11i:
|
Daily
|
|
|
0900
|
Review and terminate latent sessions
|
|
1100
|
Place new patches in non-production environments
|
| |
|
|
Weekly
|
|
|
Monday
|
Review and stage patches slated for production
|
|
Tuesday
|
Migrate patches to production
|
|
Thursday
|
Staff Meeting to discuss emergent requests
|
| |
|
|
Monthly
|
|
|
Week 1
|
Clone and refresh Development
|
|
Week 2
|
Clone and refresh Test
|
|
Week 3
|
Clone and refresh QA, review monthly Vertex update
|
|
Week 4
|
Review scheduled concurrent requests, verify archive and purge activities, review Vertex tax update
|
| |
|
|
Annual
|
|
|
January
|
Apply CPU
|
|
April
|
Apply CPU
|
|
July
|
Apply CPU
|
|
October
|
Analyze year end legislative HR patch, install in non-production environments, apply CPU, review PEIMS program
|
|
December
|
Install year end legislative HR patch to production
|
The Benefit: There are several benefits to be gained for establishing a battle rhythm. Project managers and team members can accurately schedule times required for system maintenance. Other departments can ensure that their battle rhythms are synchronized with each other. For example, we have an annual financial audit in September and October. We may need to move some of our October activities to another time in order to better support the audit. Another benefit is that we can use our resources more effectively. By understanding exactly what our support requirements are and when they occur, we can more easily level our resources. This type of flexibility would be of tremendous value during a strategic project such as a migration to Oracle Release 12. A constant struggle with projects is resource availability. I have been on both sides of the management fence and I know it is a real struggle when a technical resource has to decide which task they are required to complete. My experience as a project manager has led me to believe that that resource overloading is a major contributor to project failure. Another benefit of establishing a battle rhythm is that organizations can shift support work to external resources and free up internal resources for more strategic targets and opportunities.