Understand BPPM As A Decision Maker - Part 2: Required skills

In the previous post, I listed five aspects to be considered for any enterprise monitoring software.  Because each aspect has a different skill set requirement, it can potentially require separate resource though some resources can be shared.

1) Implementation - requires designing, capacity planning, installation, and framework creation skills.
2) Development - requires designing, coding, and framework creation skills.
3) Integration - requires coding, 3rd-party software, and framework creation skills.
4) Administration - requires user interaction, configuration, and framework following skills.
5) Operation - requires user interaction, monitoring, procedure following skills.

In general, aspects 1), 2) and 3) are the responsibilities of one (or more) implementation team(s).  Aspects 4) and 5) are the responsibilities of separate (or combined) administration and operations team. In this post, I want to spend some time addressing how they relate to each other.  To make it more intuitive, I am using my previous 'home construction' example again.  In home construction, here is how each aspect looks like:

1) Implementation - drawing blueprints and building a house
2) Development - replacing a standard jacuzzi bathtub with a wheelchair-accessible shower
3) Integration - installing solar panels on the roof
4) Administration - installing ceiling fans or repairing a leaking kitchen sink
5) Operation - cleaning floor when it is dirty or turning on/off porch lights at dusk/dawn everyday

For resources, here is how each aspect looks like:

1) Implementation - builder
2) Development - specialized crew from the same builder
3) Integration - specialized crew from the same builder or another company
4) Administration - handyman
5) Operation - homeowner

By the above comparison, here are some general points to help you understand BPPM as a decision maker:

1) Begin with the end in mind: How do you want to use an enterprise monitoring software in your IT organization?  For example, do you want your operations team to use this tool to perform root cause analysis, or do you want to leave root cause analysis to the assigned system administrator or DBA? The more details you know how you will be using the monitoring software, the easier your decision will be.

2) Good implementation is crucial: Implementation is like plumbing of a house.  It would be very expensive to add another bathroom if the plumbing wasn't there at the first place.  If the implementation is not done correctly, you may not have any other choice but redo the entire implementation.  For example, one of my previous clients handed me a partially implemented environment where BPPM and Entuity were running on the same server.  I could not find any way to repair it but had to re-do the entire implementation on two separate servers.

3) Not all BPPM experiences are the same: BPPM experience in implementation and BPPM experience in administration are two different kinds of experience though they share some common technical skill sets.  An implementation team's goal is to create a consistent framework that administration team and operation team can adapt quickly without consulting them so they can move on to another implementation project.  An administration team's goal is to use special knowledge in configuration so that they have 'job security' to stay forever.

4) One time vs repetitive work: Aspect 1), 2), and 3) are part of implementation project.  They are one time cost.  Aspect 4) and 5) are repetitive operations.  They are recurring cost.  If an implementation project is done right, it can cut down tremendous amount of recurring operation cost because the amount of work required for administrators and operators is minimized.  The recent trend from my observation seemed to indicate that many organizations didn't have their BPPM implementation done right and now they are trying to hire the best full-time administrators to make it up. Keep in mind, the supply of 'super handyman' is very limited.  At some point, it may cost less to re-do the incorrect implementation than to rely on a permanent 'super handyman'.