A Transition Strategy for Moving IT Beyond the Year 2000
Fueled by globalization and the view that existing management structures are becoming more archaic as technology surges forward, corporations are reinventing themselves at a rapidly increasing pace. As we enter the coming millennium, we can expect changes in organizational structures that will make the reengineering craze of the 1990’s pale by comparison. Will IT organizations be ready to deal with these changes, or will they be stuck in the mire of the past? The year 2000 issue holds some interesting answers.
The year 2000 problem has forced us into dealing with many of the large-scale systemic problems inherent in aging information systems. But the year 2000 is just the tip of the iceberg. Formidable tasks, including business strategy and IT realignment, data and application redesign, ERP and e-commerce implementation, and new technology deployment, still lie ahead. Fortunately, the year 2000 work completed to date provides a solid foundation for tackling these and other issues as we enter the new millennium.
Leveraging a multi-million dollar year 2000 investment is not only prudent, but essential to ensuring that future information management projects are delivered as efficiently and effectively as possible. How can companies leverage year 2000-centric solutions to support mission critical business requirements?
The process requires evaluating backlogged information requirements, assessing new business opportunities and determining how to glean value from year 2000 project infrastructures as a way to meet these needs. Gleaning value from a year 2000 initiative requires extending project infrastructures across a variety of IT domains. This includes using system inventory data as input to maintenance and redevelopment projects, expanding the role of formal processes, redeploying software tools and technologies, extending contingency planning models as input to functional realignment efforts, institutionalizing crisis plans and leveraging management infrastructures.
Systems Inventory
At the early stages of many year 2000 projects, management lacked detailed knowledge about their systems and technology inventory. Year 2000 inventory efforts, geared at collecting and synthesizing meta-data on production systems, took months or even years to complete. This painstakingly accrued knowledge base provides tremendous leverage to business and IT planning and implementation initiatives. Project teams should be able to access this information on demand and not be forced into recreating it for each project that they undertake.
Analysts can use system inventory data to update disaster recovery plans, enhance configuration management integrity, streamline internal audit analysis, allow security teams to develop more accurate risk profiles and provide operational teams an accounting of all system software. Mangers and technical staff can also use this information as a blueprint for planning and implementing system maintenance, integration, replacement and deactivation projects.
Management should ensure that system inventory data is loaded into a repository or database, like the one in figure one, so that it can be readily accessed and updated by those needing this data. Figure one highlights relationships between a system and the physical components that comprise that system. Many of the tools used to build the systems inventory at the onset of a year 2000 project also have the ability to load this data into a repository or database. This repository concept is discussed further in the contingency planning section below.
Once this information has been put into an easily accessible format, analysts can apply it to projects ranging from a simple maintenance request to a major system retooling effort. Telescopic views of legacy environments, where complex dependencies may not be apparent, are a major reason why package implementation and replacement projects run into trouble. Having access to this cross-functional meta-data goes a long way to resolving this dilemma.
Lastly, executives can use this inventory data to perform software asset valuation. For the first time they have an accounting of all application, package, distributed, utility and system software used to control various elements of a business. Replacement cost estimates, said to be $50 per line of code, put the value of many software portfolios at over a billion dollars. These statistics, and the fact that companies have spent hundreds of millions of dollars on year 2000 compliance, make it clear that these software portfolios represent real value to corporations. It also offers a reality check to executives that mistakenly believe they can replace these systems for a fraction of their value – even as they allow legacy systems to slip into disrepair.
Processes & Software Tools
To succeed, year 2000 projects had to introduce new disciplines into the IT environment. This resulted in the development or acquisition of a variety of processes and software tools that can provide benefits to other projects. Executives should consider the fact that many of the processes and tools deployed during the year 2000 project might end up being tossed aside as the project ends. Now is the time to institutionalize the use of these processes and tools as the year 2000 effort winds down.
The year 2000 project has been responsible for introducing project management, configuration and change control, testing and quality assurance processes that can be applied to future projects. Project management and configuration control procedures are essential to all software development and maintenance projects. If, for example, a business unit outsourced its year 2000-remediation work, project teams can extrapolate the change control techniques used during that effort to support other outsourcing initiatives.
Similarly, enterprise-wide deployment of testing and quality assurance procedures developed during the latter stages of a year 2000 project can minimize quality problems in maintenance and development projects. In particular, analysts should universally deploy processes that track and enhance test coverage, facilitate regression testing, help create test data and support cross-functional testing. Management should deploy year 2000-derived testing and quality assurance procedures on a priority basis.
Until recently, the use of automated software tools within IT environments had been limited. The year 2000 project, however, drove the acquisition of software inventory tools, code analyzers, automated change facilities, project workbenches, testing tools, configuration and change management technology, quality assurance tools and repositories. These tools can benefit analysts in ways that may have not been considered.
Inventory tools, for example, can be used to update software portfolio data. This data can then be fed into a repository as a vehicle for creating "living" documentation on systems. Coupled with code analyzers, maintenance teams can use repository cross-reference data to determine which components, in which systems, are impacted by a change request. Code analyzers, project workbenches and automated change facilities provide technicians with the ability to update a wide variety of constructs across a multitude of programs. Analysts could, for example, apply the same tools used in a year 2000 project to implement pending area code changes.
Management will want to capitalize on the shift in mind-set from not using software tools prior to the year 2000 to the recognition that tools can leverage the efforts of the most gifted technician. This should pave the way for the introduction of even more sophisticated tools that allow the manipulation of system meta-data to facilitate major system retooling projects across functional boundaries. Other technologies, including data rationalization and system migration tools, could see resurgence as a result of the year 2000.
Because standardization and productivity are ongoing goals at most companies, managers should strive to leverage all relevant processes and tools emerging from a year 2000 project. This may require maintaining a small group of experts to enable these processes and tools on a variety of projects. This team of experts can also investigate new methods and technologies while managing the current suite of processes and tools.
Contingency Planning ModelYear 2000 contingency planning expanded millennium preparation activities into the realm of the business unit. While contingency planning projects drained resources beyond what was initially anticipated, companies have an opportunity to accrue real benefits as a result. Contingency planning clarifies the relationships between the business functions that run an enterprise and the technology resources that support those functions. This newly documented understanding is a seed of knowledge that executives can apply to a wide variety of system transformation projects.
The manifestation of this knowledge base linking the business and IT communities can be found within the contingency planning database (see figure two) that many companies are using to track items requiring a contingency plan. Organizations perform contingency planning at a business unit and a technical level to ensure that each functional area has develops a comprehensive cross-section of backup plans. Because of this, a complete contingency plan includes relationship definitions linking business functions and technology resources as shown in the repository model in figure two.
Historically, this knowledge base has been absent from many organizations. One can assume that, barring another year 2000 crisis, it will never emerge again. This is due to the fact that it has taken a Herculean effort to draw business analysts away from their day-to-day jobs to document this information. With a limited window of opportunity, executives must expand upon and institutionalize this knowledge base while the information is still fresh.
Coupling data from the contingency database with physical inventory data stored in other repositories provides management with a detailed understanding of how technology supports a given business sector. Figure one, which represents the physical and logical abstractions of these relationships, highlights how an analyst can track a logical business function back to the physical components that support that function. Knowing this is essential to a replacement, migration, integration, extraction or other type of project impacting a business unit and the systems that support it.
Take, for example, an ERP implementation project. Much time is spent determining which of the existing system components should be deactivated and which ones must co-exist with the ERP system. This is like building a railroad, one-foot at a time, with no idea where it will go. As the ERP system is implemented, analysts must track the ERP components yet to be implemented, the legacy components that have been deactivated, the legacy components yet to be deactivated, the legacy components that must remain intact and where all the interfaces go. The repository in figure one supports this analysis process.
Another example of how this repository can track development and deployment activity can be found in a web-enablement project. When we examine the confusion that could result from a project linking the Internet to complex legacy systems, we can see why these interfaces should be documented in a repository model. The repository model in figure one supports both the front-end analysis and back-end tracking process. What happens when companies must redesign a spider web of legacy / Internet interfaces a few years from now? If they track this information in a repository, they will be able to decipher these systems and create a feasible migration path.
The expanded version of the contingency planning model can accommodate current-system-to-target-system mapping data that lays out a blueprint for virtually any reengineering / retooling, package deployment, data warehouse, web integration or system integration project. This is essential to any company undergoing major structural changes such as a merger or an acquisition. A transition management team should consider the value of this model and begin to expand it as required by IT projects now on the drawing board.
Crisis Management PlansCrisis management planning defines the approach, the resources and the personnel requirements needed to navigate the millennium transition window. This plan, which incorporates individual contingency plans as a component, defines an integrated crisis response strategy for business unit and technology organizations. These plans go well beyond traditional disaster recovery plans because they deal with external and internal failures at a logical and physical business unit level. Because these plans represent the collective work of so many skilled people, management should use them as a basis for crisis and disaster recovery planning beyond 2000.
In other words, once the year 2000 impact subsides, executives can refine risk models, contingency plans and crisis management approaches into a more generalized crisis plan. While companies may not have the time to incorporate these plans into an enterprise-wide tracking and management facility, management should plan to do this as a follow-up activity when they determine how well the plans worked. A well considered, thoroughly tested contingency and crisis management plan can then be put in place for whatever type of small or major crisis strikes beyond the year 2000.
Management InfrastructureHistorically, a monthly or quarterly status meeting might have been the sole link between senior executives and various project leaders. Many senior executives do not even track individual projects on an ongoing basis. As a result, redundant and conflicting projects emerged; many of which were not synchronized with long-term business strategies. The year 2000 changed all of this. The well managed, year 2000 project office tracked every year 2000-related project across the enterprise. This level of scrutiny enhanced the odds of success and forced remote areas to take action.
The concept of a centralized project office has been around for decades. Unfortunately, few companies actually had such an organization. Numerous benefits can be derived from the project office concept. Coordination and streamlining of skills and resources became commonplace under the auspices of the central project office. A second factor is that people took their status reports more seriously when they knew that a project was under a high degree of scrutiny by a central tracking team.
One other project office benefit also emerged. The fact that projects were being tracked, with status reports raised to an executive level of awareness, actually impacted the executive decision making process. In other words, executives were less likely to let bad decisions run unchecked because someone would question the wisdom of a given strategy. The project office is one year 2000 institution that should be made a permanent fixture within corporate structures.
Seize the OpportunityIn addition to the all of the other benefits that can be attributed to the year 2000 project, businesses have found that relationships between IT, the business community and suppliers have been solidified. This coupled with an appreciation for the complexities inherent in the technology that we have built over the past 40 years, may be the most lasting legacy of the year 2000 project.
It is difficult to see many of the benefits that the year 2000 has brought us when living in the eye of the storm. Consider that many of the inventions that we use everyday come from research work linked to early space flight. Also consider that necessity is truly the mother of invention and we can begin to see how the year 2000 challenge has turned into an opportunity.
We still, however, have a long way to go. Many of the benefits from a year 2000 project provide only the first steps in developing a transition strategy to the post-2000 world. Year 2000 repositories, for example, could easily fall into disuse. But they could also be deployed as a strategic transition vehicle that end up benefiting countless projects for years to come. It is up to you to grasp these opportunities from the jaws of a crisis. The time to begin is now.