|
There was a time when Application
Development and IT Operations had little or no communication
with each other. As the complexity
of both applications and infrastructure increased-initially as a result of client-server
computing and later by the emergence
of service-oriented architecture (SOA)-the wall between these silos had to be
demolished in order to accommodate
growing dependencies between them. Over the last 10 years, IT project
management has evolved to a level where most organizations have implemented a
formal Project Management Office (PMO) whose charter is to track progress,
contain costs, and keep projects moving forward. The PMO brings together the stakeholders
from development, operations, systems, service management, and sponsoring
business units to ensure collective progress through project milestones.
Over the same period, ERP companies such as SAP, Oracle and Lawson have evolved business thinking about the interaction of operational data and related processes. The notions of universal processes and standards for business policy enforcement are now the norm. IT itself is ripe for a similar type of epiphany and transformation. Rather than focusing on software that only automates specific teams, we need to think in terms of universal software and process that unify all of IT. In short, IT is ready for the universal process concept that created the major ERP packages. This article describes a vision for a unified software-and-process infrastructure in a fully integrated IT environment. The Challenge: Managing Change and Problems From Beginning to End In the same way that a change doesn't start with code check-out, a problem doesn't start when it is reported to the Help Desk. The challenge is to determine what systems should be part of a universal process for all of IT to manage change and problems from beginning to end. Traditionally, IT has been siloed. The Help Desk, for example, typically had no visibility into the changes that affected the end users it had to help. Changes, however, are often a major cause of the service disruptions that cause end users to call the Help Desk-so this lack of visibility is obviously problematic. That's why the Help Desk needs access to the tools that allow them to quickly answer the question, "What has changed?" Conversely, developers need access to operational system configurations so that they can understand the potential impact of their change. According to Stephen Elliot, research manager at IDC, "over 80% of business-critical service disruptions can be attributed to poor change control processes including flawed change impact assessment." In today's change planning, all the Help Desk typically knows is that a new release is scheduled for a specific date. To move to the next plateau in change management, we need to change our thinking about the amount of change information we provide to the Help Desk. It may be necessary to inform the Help Desk about the details of the 500 components and four servers that are to be changed by the release. This level of detail is only possible if the change management process and the system that manages the software changes are integrated with the Service Desk system. To have a true universal IT change process, Operations and Development need to unify and combine their operational systems. The PMO also needs to be involved as the third member of the universal process triad. To truly run IT as a business, we need to more efficiently manage all change-not just those associated with large projects. This way, IT can get a clear understanding of all proposed changes so it can assess demand and available resources in order to ensure its ability to meet the business need. In addition, to provide a measure of demand management, all changes should be reviewed, approved and scheduled, or rejected as appropriate. Only by exercising these options can IT intelligently manage the costs and resource allocation. In other words, IT can truly manage problems and changes from beginning to end by integrating core system by integrating Operations, Development, and PMO in a single universal process. The key IT applications that need to be integrated to support the universal service model include the Service Desk (SD), Configuration Management Data Base (CMDB), Project & Portfolio Management (PPM), and Software Change Management (SCM). By integrating these IT systems into a unified solution, IT can both deliver significantly greater value to the business and become more accountable for delivering that value. Service Desk: A single Point-of Contact That ITIL Endorses One of the key concepts in ITIL is that business customers should have a single place to interact with IT to get their questions answered, to report problems, and to and monitor change. In most organizations, a Service Desk system is used by the Help Desk to track all interactions with the business customers and to provide self service for IT requests. The SD should therefore become the single point of contact ITIL endorses. ITIL breaks down requests into Incidents, Requests for Change (RFC), and Problems. When a business customer has a request they should be able to contact the Help Desk or interact directly with the Service Desk application to create an Incident. A customer Incident could be a problem, RFC, or a request for information. One of the hardest jobs of the Help Desk Analyst is to determine if an Incident is really a Problem. A customer Incident of "Slow Response" may be a problem in the system, a request for additional hardware, or the system could be performing according to agreed upon service levels. With the advent of CMDB technology a Help Desk Analyst has visibility into how the production environment is configured with associated relationships and Service Level Agreements. With the additional information provided by the change management process and SCM system the Analyst can check to see if there was a recent change that could be causing a problem. This visibility into IT configuration environment and change process allows the Help Desk Analyst to respond promptly and accurately to customer requests. If a Problem or RFC is created from the Incident, then it is important that the business be kept apprised of the status of changes required. With this level of system integrations the business customer can now check for them selves the status of all change requests, eliminating the need to call the Help Desk. The CMDB: Improving Change and Configuration Management Functions CMDB technology should be used extensively by both Operations and Development staff in planning and managing change. CMDBs vary by company; however, their most common use is to improve change and configuration management functions. The approved configurations represented within a CMDB are used to plan hardware swaps or software deployments and should be used for performing impact analysis, for planning change, and when performing problem root-cause problem analysis. A CMDB is not a common database for storing changes and problems for the systems that are part of the universal process, nor is it a communication system for transferring requests between systems. A CMDB stores only the information necessary to model the current IT environment. This model enables IT to understand how IT resources integrate to provide services to their business customers. Data stored in the CMDB is known by the collective term Configuration Item (CI). In its most basic form, a CI is any item that is managed under change control, and can vary widely in complexity, size, and type ranging from an entire Business Application to a single source module. CIs can also be hardware, documentation, and even Service Level Agreements. A CI can contain other CIs. For example, a Server can host one or more Applications, and each Application can be made up of hundreds of programs. The next step in the evolution of CMDB technology is the integration of software component level relationship data in the CMDB provided by the SCM system. This process allows true cross-platform and cross-SCM system impact analysis before changes are started. A typical company may have three different SCM systems: one for mainframe development, one for the Windows development team in New York and one for the Windows team in San Francisco. By incorporating SCM information from all these systems in the CMDB, common code that spans all development environments can be developed and automatically tracked to where it is used. CMDBs typically only hold data on production systems. As usage matures, however, companies are finding that information from Test and Development systems is also very useful. Remember that CMDBs don't store everything-only the data and relationships that are the most useful for managing change and configurations. Project and Portfolio Management: Returning the Highest Value to the Business A key goal of the universal process is to provide IT with the ability to manage all tasks and IT spending. Therefore, when an RFC is created by the Service Desk, it needs to be logged as an IT Service request in the PPM system, since the PPM system contains the processes to review, approve, and prioritize the RFC. PPM systems provide the ability to review all changes together and make sure that IT is working on the projects that will return the highest value to the business. PPM systems coordinate the work efforts and make sure all teams are kept informed. Once the RFC is approved, the PPM system then allocates the resources, scheduling, and budget to complete the changes. The status of projects and tasks are a critical part of a PPM system. Often, the update process for these tasks is the bane of Development or Project Managers. PPM and SCM should be tightly linked, allowing developers to work within their chosen development environment. With a universal process, as the development tasks are completed, the updates in the PPM system can be made automatically and reflected in the Service Desk application. The Expanding Role of Software Change Management SCM has grown substantially in recent years. Simple check-out and check-in of source and branch management is no longer sufficient for modern development. It is just as important to be working on the right tasks as the right source modules, and coordinating these activities with all other developers is critical to overall change management success. It doesn't matter if your development team uses Waterfall or Agile development methodologies; task and activities against those tasks need to be tracked against business priorities. The SCM system must collect information on the release-identifying which software modules are part of a release, including modules used during the Build process. The SCM system has new additional responsibility to track the bill of materials for production components. This bill of materials provides the information needed to populate the CMDB, thereby allowing users of the CMDB to drill down to the lowest level possible. As we have seen in the PPM and CMDB sections, the role of the SCM system is expanding into a system supporting the needs of Developers, Project Managers, Operation Analysts, and Help Desk Analysts. For an integrated solution, it is critical that as developers move software changes to Test and Production, the PPM system will be updated-making the status of those changes visible to customers via the Service Desk. Bridging the Information Gap Between Operations, Project Management, and Development solutions The ultimate goal of this universal process is to have people work with tools, process, and procedures optimized for their respective roles. Help Desk Analysts work with a tool optimized to manage Incidents and RFCs. Project Management works within a PPM application. Developers interface with the process via SCM. Developers probably have the most diverse needs, since they work with multiple development IDEs and languages. An automated SCM system needs to be able to work in these varied environments while still providing updates on tasks and activities to the PPM and SD systems. The CMDB is used by all to determine change impact and to research problems. Having a CMDB that spans hardware and software allows users to drill down to any level and identify change impact at the most granular level. As the RFC is completed in the SCM system, the CI data for the change needs to be captured by the SCM system. When the change is deployed into production, the updates need to be made in the CMDB--- as well as in the PPM system by marking the project "complete." These actions should close the Incident or RFC in the Service Desk with proper notification to the requestor that the change has been completed. The time is right for a universal service model that bridges the information gap between Operations, Project Management, and Development solutions. There is no single vendor system available today to do for IT what ERP systems have done for the business. Companies that embrace this vision will need to focus on the solutions they have today, fill gaps where needed, and then focus on integration opportunities. Steve Solomon is a senior product marketing manager in CA's Business Services Optimization (BSO) organization, focusing on Change and Configuration Management (CCM). Steve has been evolved in software change and configuration management for 15 years including being the ChangeMan ZMF product manager at Serena Software, and a director of worldwide software change management at American Express.
Set as favorite
Bookmark
Email this
Hits: 4562 Trackback(0)Comments (1)
|
|
... Steve, That was a great article, a must read by many Sr. Managers, VPs I know. Corporate America is moving slow on this one; PMs are clients of CM, but they consistently ignore or strangle it. Right now I encounter strong resistance by including CM overview in other phases of SLDC than development. It's a matter of time and management maturity. Cristian |
|
Write comment
You must be logged in to post a comment. Please register if you do not have an account yet.


There was a time when Application
Development and IT Operations had little or no communication
with each other. As the complexity
of both applications and infrastructure increased-initially as a result of client-server
computing and later by the emergence
of service-oriented architecture (SOA)-the wall between these silos had to be
demolished in order to accommodate
growing dependencies between them. Over the last 10 years, IT project
management has evolved to a level where most organizations have implemented a
formal Project Management Office (PMO) whose charter is to track progress,
contain costs, and keep projects moving forward. The PMO brings together the stakeholders
from development, operations, systems, service management, and sponsoring
business units to ensure collective progress through project milestones.

