Days of productivity are lost cleaning up unexpected side effects of IT software changes. This lost productivity translates in many ways to higher labor costs and delays in processing the Government’s business, which can also be translated to lost revenue. This is often due to the lack of knowledge of what an IT enterprise has running in its production environment and the dependencies between the software tools. Changes break functionality, which can halt employee’s work.
Fix: Communicate changes through an enterprise process and tool that will fully track lifecycles of configuration items through the use of an inter-Divisional Change Management Database (CMBD). Using Java as an example, if a change to a Java version is proposed, most organizations do not have one place they can communicate that change request to and in turn, yield the answer to the questions, “Who needs to know about this change and what systems need to be tested for software interoperability and continuity of applications that rely on Java?” Many SLM processes do not track all production applications. While Change Control Boards provide a forum for awareness and acceptance, it does not address system owners that do not participate in that process.
Once these fundamental questions answered, communicating changes and engaging relevant system owners becomes a simplified process as the communications can be targeted well in advance of the actual changes.
A proactive effort to solicit, collect, process, and present this information in a repeatable process is required.
Eventually it should become routine that configuration information is routinely requested, collected, and made available for searches when understanding change impacts. This repeatable process, however, needs to be rooted in a comprehensive, enterprise CMDB tool. This eventually translates to cost avoidance.