I continued my adventures in reading about problem management in MOF!
It states: "Problem Management should begin at the start of a service’s life cycle and should be applied to all aspects of IT—including application development, server building, desktop deployment, user training, and service operation. As more problems are discovered, recorded, researched, and resolved, IT will experience fewer failures.
If Problem Management is performed during the period when a service is envisioned, planned, designed, built, and stabilized, the service will be deployed into productive use with fewer failures and higher customer satisfaction."
Methinks confusion exists here between the holy trinity of change, release and configuration management and with problem management. Underpinning the holy trinity should be a strong testing culture and methodology. Dead cats should not be hurled over the fence for problem management to deal with and the issues and results from testing should be available to problem management, as a reference. However, testing is still testing and the logs of development fixes and testing initiated corrections should be clearly distinguished from actual real service failures to prevent problem management data from being falsely polluted! Likewise testing should be aware of the lessons learnt that problem management has discovered and the dead cats should be hurled back over the wall with PostIT notes attached.
Problem management is performed to identify the unknown underlying causes of failures. This happens in an operational context. And is not time dependant with no deadlines. YOU DO NOT WANT THIS PHILOSOPHY IN DEVELOPMENT! Eliminating failures and having graceful failure handling routines is part of a sound development methodology. It remains development and testing, not problem management. MOF correctly categories problem management under the Operate Tab, then proceeds to contradict itself.
If Problem Management is performed during the period when a service is envisioned, planned, designed, built, and stabilized, the service will be deployed into productive use with fewer failures and higher customer satisfaction."
Methinks confusion exists here between the holy trinity of change, release and configuration management and with problem management. Underpinning the holy trinity should be a strong testing culture and methodology. Dead cats should not be hurled over the fence for problem management to deal with and the issues and results from testing should be available to problem management, as a reference. However, testing is still testing and the logs of development fixes and testing initiated corrections should be clearly distinguished from actual real service failures to prevent problem management data from being falsely polluted! Likewise testing should be aware of the lessons learnt that problem management has discovered and the dead cats should be hurled back over the wall with PostIT notes attached.
Problem management is performed to identify the unknown underlying causes of failures. This happens in an operational context. And is not time dependant with no deadlines. YOU DO NOT WANT THIS PHILOSOPHY IN DEVELOPMENT! Eliminating failures and having graceful failure handling routines is part of a sound development methodology. It remains development and testing, not problem management. MOF correctly categories problem management under the Operate Tab, then proceeds to contradict itself.
0 comments:
Post a Comment