Does your BPPM customization process look like building a Winchester house?
For those who are not familiar with it, Winchester House is a famous house located in San Jose, CA. This giant 160-room house was gradually built during a period of 38 years with no overall planning and consistency. Often staircases lead to the ceiling and doors open to solid walls. Visitors are warned not to wander away from the touring group. Otherwise they can be lost for hours.
All my "rescue mission" projects involved substantial effort of reverse engineering, re-designing, and re-implementing the previous customization that suffered from "Winchester House" syndromes. "Winchester House" syndromes substantially increase the cost to maintain and extend BPPM customization.
Here are some examples of typical "Winchester House" syndromes:
1) In custom PATROL knowledge modules, some KMs read data input from pconfig, some KMs read data input from external files. And there is no standard location for external files.
2) In custom BPPM cell knowledge base, some events use mc_object slot to determine their Remedy support group, some events parse the msg string to determine their Remedy support group.
3) In custom BPPM cell knowledge base, different events use different rules for update even their requirements are the same.
The root cause of "Winchester House" syndromes is lack of development experience. As stated in the previous post, many BMC customers use the same resource for installation and for customization. Maintaining an accurate and up-to-date documentation can help reduce "Winchester House" syndromes. However the key to eliminate "Winchester House" syndromes is to have an experienced developer to set up a well-defined framework, name convention, and best practices at the beginning of BPPM customization.
Eliminating "Winchester House" syndromes can dramatically lower your total cost of ownership. We will discuss best practices for BPPM customization in the next few posts.
No comments:
Post a Comment