WO2001015003A9 - System for planning, deploying and evolving technology infrastructure - Google Patents

Abstract

A system for planning, deploying and evolving technology infrastructure in a large multidisciplinary organization is provided. The system includes a database in which the elements of the infrastructure are held and a database development tool acting as an interface between a plurality of users and the database. The system uses a methodology for defining, implementing and indexing all the elements of technology infrastructure in a given organization. The elements are divided into components, into groups of components called flows, and into groups of flows called infrastructure categories. Data relating to the elements held in the database include a defined scope, a long-term strategy, dependencies on other elements, the supporting role assumed by a particular element in the organization, and the status of projects related to the elements. The database development tool organizes the elements according to a technology orientation guide, which provides easy-to-follow links to the details specific to the different elements held in the database.

Description

SYSTEM FOR PLANNING, DEPLOYING AND EVOLVING TECHNOLOGY INFRASTRUCTURE

Field of the Invention

The present invention is directed to a computer system and method for planning the introduction of new technologies and managing the evolution of existing technologies for a large multi-disciplined organization. More particularly, the present invention is directed to a program controlled computer system interconnected to plural users, which supports the planning, deployment and evolution of new and existing technologies by employing: (1) a methodology for defining, organizing, and indexing an organization's technology infrastructure data, (2) a central database for maintaining the technology infrastructure data generated through the methodology, and (3) a software tool which serves as an interface between the users and the central database.

BACKGROUND OF THE INVENTION There are an increasing number of economists who now believe that the current economic expansion - into its ninth year as of this writing - reflects something significantly more than just an unusually long up cycle in business.

Indeed, there is growing belief that a fundamental paradigm shift has occurred triggering a substantial increase in business efficiency and productivity, resulting in fast growth, more goods, but stable prices.

The prime cause of this shift is debated, but many economists believe that the trigger for continued economic expansion is the influx of computer technology into the workplace. This technology influx includes the integrated networks that are now common in most businesses and the now ubiquitous use of the Internet to communicate and effect complex transactions and commerce. In today's global economy, businesses are using increasingly sophisticated software and hardware systems to manage and control their business and communicate to vendors and customers. Planning, deploying, and evolving this influx of new technology has, however, created enormous problems within many organizations. First, the scope and variety of these advanced technological systems is staggering. For example, for personal computers, there are dozens of different vendors, selling machines with perhaps three or four different microprocessor choices. On the software side, these same personal computers can include one of several alternate operating systems, such as Windows 98 ®, Windows-NT ®, Mclntosh ®, Linux ® , Unix ® , etc. In addition, a myriad of software applications are possible each with varying features and costs. Second, there is no easy method or formula for making "good" choices among the available technology options. Typical considerations that can go into making a particular technology choice include the necessary functionality, the features provided by the various technology options, compatibility issues with existing technologies, modifications and testing necessary to implement the technology in the existing technology infrastructure, and the associated revenues and costs in making a particular choice. Third, the procurement selection decision in a large organization is often in the hands of several individuals who may have little or no information or any access to obtain information about the technology choices of other individuals and the knowledge that may have been gained from such choices. Finally, even after a given technology choice is selected, many complex follow-up decisions remain such as how to implement the technology choice so that it will be compatible and work well with the existing technology infrastructure and how to evolve the technology choice so it continues to meet the organization's requirements.

Ultimately, without a comprehensive system and method for planning, deploying and evolving the technology choices across an entire organization, the end result is often the following: (1) little or no standard technology choices are made across the enterprise, (2) duplicative costs are incurred with respect to selecting, configuring, and deploying technology elements, (3) integration and compatibility problems occur throughout the organization as various technology choices are integrated with the existing technology infrastructure and (4) no obsolescence or evolution planning is done to insure that the technology choice continues to meet the objectives of the users and the organization.

Presently, there are no commercial systems available for planning, deploying, and evolving the technology infrastructure for a large multi- disciplined organization. The current tools such as spreadsheets and generic project planning software are ill equipped to address the complexities associated with technology planning. It was with this understanding of the problems of the prior art that formed the impetus for the present invention.

OBJECTS AND SUMMARY OF THE PRESENT INVENTION

It is therefore an object of the present invention to provide a system for planning, deploying, and evolving the computer and information system technology infrastructure for a large multi-disciplined organization.

It is another object of the present invention to provide a data processing system integrated into a communication network to facilitate operation of a system and method for planning, deploying, and evolving technology infrastructure.

It is a further object of the present invention to provide a methodology for defining, organizing and indexing technology infrastructure data for an organization.

It is a further object of the present invention to organize the technology infrastructure elements into the specific hardware, software, product or services tracked by the system referred to as 'Components', an alignment of components into a logical group referred to as a 'Stream', and an aggregation of Streams referred to as 'Infrastructure Categories'.

It is a further object of the present invention to provide a visual display of an organization's entire technology infrastructure (referred to as a 'Map') with easy to follow links to the details of all the individual elements of the technology infrastructure. It is a further object of the present invention to delineate technologies proposed for adoption so as to provide critical planning and implementation data related to introducing that Component into operation within the enterprise. It is a further object of the present invention to manage and track technology dependencies for the purpose of planning the introduction of new technologies and evolving existing technologies.

It is a further object of the present invention to provide a system for tracking the process of technology planning within a large multi-disciplined organization. The above and other objects of the present invention are realized in a network based computer system and method, which facilitates the planning, deployment, management and evolution of new and existing technologies in a large multi-disciplined organization. The computer system includes plural remote terminals in communication with a central database. A programmed database interface tool called the Roadmap Program is configured to enable the users to define the technology infrastructure details for the entire enterprise according to the methodology of the invention. The infrastructure for the system is segmented into a plurality of clearly defined Components, each with an owner, a defined scope and a three year rolling strategic plan. The central database is a repository for information of each Component, and is accessible by the owner of the Component and others as delineated by system access levels.

In accordance with the varying features of the present invention, the computer system organizes the technology infrastructure Components into an overall technology Roadmap. When decisions need to be made with respect to planning new technology or evolving existing technology, the Roadmap Program provides the necessary planning data for making these decisions such as the standard technology platforms being supported by the organization and the dependencies on other components. When new Components and/or new technology projects are registered, they are integrated into the Roadmap and indexed with existing Components so future technology decisions will have a complete and accurate picture of the technology infrastructure.

The Roadmap program contains screens conforming to a web structure, which display the technology infrastructure details. The Roadmap program peπnits strategic Map information to be displayed at a high level or a detailed Component level. For each Component, a rolling three year plan is generated dynamically by the Map tool with milestones defined based on user entered data.

The foregoing features of the present invention are more readily understood when presented in the context of a specific illustrative example thereof described in detail hereinbelow in conjunction with the following figures. BRIEF DESCRIPTION OF THE FIGURES

Figure 1 is a block diagram of an illustrative Intranet based network for implementing the present invention.

Figure 2 is a process flow diagram identifying the steps involved in developing and loading the technology infrastructure data maintained in the central database.

Figure 3 is a sample template for entering the Component Attributes.

Figure 4 is an example Component Attribute template for a Streaming Services Component with all the appropriate information entered.

Figure 5 is a sample template for entering the Component Details. Figure 6 is an example Component Details template for a Streaming

Services Component with all the appropriate information entered.

Figure 7 is a sample template for entering the Product Details for a Component.

Figure 8 is an example Products Details template for a Streaming Services Component with all the appropriate information entered.

Figure 9 is a sample template for entering the Standards, Directives and Guidelines for a Component.

Figure 10 is an example Standards, Directives and Guidelines template for a Streaming Services Component with all the appropriate information entered. Figure 11 is a sample template for entering the Project Details for a Component.

Figure 12 is an example Projects Details template for a Streaming Services Component with all the appropriate information entered. Figure 13 is a sample template for entering the detailed three-year plan for a Component.

Figure 14 is an example three-year plan template for a Streaming Services Component with the appropriate information entered.

Figure 15 is a sample screen depicting the screen whereby a User selects the Infrastructure Category Map to be displayed.

Figure 16 is a sample screen display for the Map view of the present invention in Description Mode.

Figure 17 is a flow chart showing the options that a User can select from the Map View of the present invention. Figure 18 is a sample screen display of the Map view of the present invention in Owner Mode.

Figure 19 is a sample screen display of the Map view of the present invention when a Component is clicked with the Depends On tool selected.

Figure 20 is a sample screen display of the Map view of the present invention when a Component is clicked with the Required By tool selected.

Figure 21 is a sample screen display of the Map view of the present invention when the Overview tool is selected.

Figure 22 is a sample screen display of the Map view of the present invention when the Help tool is selected. Figure 23 is a sample screen display of the Component view of the present invention for a particular Component of the technology infrastructure.

Figure 24 is a flow chart showing the options a User can select from the Component view using the tool bar. Figure 25 is a sample screen display of the Component view of the present invention when a User selects the Scope and Definition Tool.

Figure 26 is a sample screen display of the Component view of the present invention when a User selects the Standards tool. Figure 27 is a sample screen display of the Component view of the present invention when a User selects the Products tool.

Figure 28 is a sample screen display of the Component view of the present invention when a User selects the Projects tool.

Figure 29 is a sample screen display of the Component view of the present invention for a Stream when a User selects the Three- Year Plan tool.

Figure 30 is a sample screen display of the new browser window when a User clicks on the 'red diamond' representing a milestone within a Component's three- year plan.

DETAILED DESCRIPTION OF THE INVENTION

Overview of the Invention

Discussing the present invention first briefly in overview, the technology infrastructure data is maintained in a central database. A network based software tool called the "Roadmap Program" defines, organizes, and indexes the technology infrastructure data based on a defined methodology and select user inputs.

The central database maintains the technology infrastructure details at three levels of aggregation: the Component level, the Stream level, and an Infrastructure Category level. A Component is the basic building block of the technology infrastructure. Each type of hardware, software, product or service tracked by the system is defined as a Component. An example of a Component would be a "Workstation". The details maintained on each Component include the owner of the Component within the enterprise, the defined scope of the Component, projects registered with respect to the Component, dependencies with other Components, and a three-year strategic plan for the Component. A "Stream" is an alignment of Components into a logical group. For example, a Workstation Component might be aligned to a "Hardware" Stream. All Components in the central database are aligned under a particular Stream. Finally, each Stream in the database is aggregated into an Infrastructure

Category, which is simply a logical group of Streams. The technology infrastructure details are identified and defined through a specific methodology, are entered into various templates provided by the Roadmap program, and loaded into the database through macros which extract the data from the templates and load it into the database.

The Roadmap Program provides a web-based interface and supports various web-based tools, which permit a User, depending on appropriate security access, to interact with the technology infrastructure details maintained in the central database. For a view of the entire technology infrastructure, a User can select the "Map" view of the program, which will display all the Components and

Streams of the technology infrastructure, the dependencies between various Components, and other features as will be discussed in more detail below. A User seeking further details can select the "Component" view of the Roadmap program to see the details and planning information maintained on each Component.

The Roadmap System

Referring now to Figure 1 , a network-based system is shown, which provides user access to the system through various workstations and a data network. For illustrative purposes only, the data network is shown as a corporate

Intranet. The invention could be implemented by the Internet or other means of linking users to the Roadmap program. The illustrative network consists of multiple workstations (100,101, 102, 103 & 104), which are interconnected to the server where the Roadmap program resides (112) either directly through a communication line or through various servers (110 & 111) and the Intranet (120). The Roadmap program serves as the interface between a plurality of Users and a central database that maintains the technology infrastructure data. In this implementation of the invention, the database resides on a separate server. Although varying hardware and software combinations could be used, the server where the Roadmap program resides in this implementation is a Compaq

6500, with dual 200 Mhz Pentium processors, 512 megabytes of RAM, and more than 10 gigabytes of disk space. The operating software for the server includes Microsoft NT Server 4.0, SP4, Microsoft IIS 4.0, Microsoft MDAC 2.0, SP2, a Web Browser (Internet Explorer 4.0 or greater or Netscape Communicator 4.06 or greater), and Microsoft Word 97. The SQL Server where the data is maintained is a Compaq 850, with a 200MHz Pentium processor, 256 Mb of RAM, and 4 Gb of disk space. The software on the SQL server includes Microsoft SQL Server 6.5, SP5, Microsoft InterDev 6.0, SP3, Adobe Photoshop 5.0, and Microsoft Query.

Defining. Organizing and Indexing the Technology Infrastructure Data Referring now to Figure 2, a process flow diagram is depicted, which identifies the steps involved in developing and loading the technology infrastructure data maintained in the central database. The first step in this process is to identify the elements of the technology infrastructure within the organization (200), fe,_., the Components (201), Streams (202), and Infrastructure Categories (203), and the Owners of the infrastructure. As noted previously, Components are the smallest building block of the infrastructure. Although varying definitions could be used, the present implementation defines a Component as any one of the following: (1) a logical element of Technology Architecture, such as 'Workstation' or 'Distributed Server'; (2) a logical element of Application Architecture, such as 'Message Services' or 'Directory Services'; (3) a Technology Service that requires a strategy, such as 'Backup/Recovery' or 'Virus Protection'; or (4) the delivery of a Technology service to a User such as 'HelpDesk'. One further consideration in defining a Component is that a Component should be sized so that it can be managed by one person. For example, no one person at most organizations could be responsible for a Component defined as broadly as 'Operating Systems'. A person might be an expert in one operating system and have no knowledge about another operating system. Thus, in such a situation, it might be necessary to define the Components as a type of operating system (e.g. 'Unix Operating System'). Once the Components are identified, an Owner is assigned to each Component.

A Stream is a logical aggregation of Components. For example, in the operating system case, if each type of operating system is defined as a

Component, the aggregation of the types of operating systems could be defined as the Operating System' Stream. Another example of a Stream might be a 'Hardware' Stream, which could be an aggregation of Components such as 'Displays', 'Workstations', and 'Printers'. These groupings of Components into Streams are all user-defined and can be aggregated in whatever fashion makes sense for the particular organization involved.

At a higher level of abstraction, the Infrastructure Category is a logical grouping of Streams. Again, this is a user-defined grouping, which can be made in whatever fashion makes sense for the particular organization involved. While the present implementation of the invention uses two Infrastructure Categories to group logically the technology streams and components, the invention could be implement without using this higher level of abstraction.

After the Components and Owners of the infrastructure have been identified, the next step is for the Component Owner to define the key planning attributes with respect to the Component (210). The attributes are: (1) the Scope of the Component (211), (2) the key entities in the organization that are impacted by the Component (212), and (3) the requirements for the Component (213). The Scope is used to define the elements that are within the scope and out of scope of the Component. The purpose of this is to define the boundaries of the Component. For example, with a workstation Component, an in scope definition might be "machines designed for single user operation in normal working environment" and an out of scope definition might be "machines that provide resources for use by other computers and their users." The key entities within the organization need to be identified because they will be the source of the requirements for the component. The requirements are the functionality needed by the key entities that are impacted by the Component.

Once the planning attributes are identified, the Owner develops a strategy for the Component including a three-year plan (220), which is submitted to the Steering Committee of the organization for approval. In identifying the planning attributes and developing an approved strategy, the Owner and Steering

Committee use the display capabilities of Roadmap program (discussed in more detail in the next section of the Specification) to identify any issues in the existing infrastructure (dependencies, three year plans for other components, approved platforms for certain components, etc.) which might impact defining the planning attributes and developing a strategy for the particular Component being addressed (221 ). The present implementation of the invention uses three years as a planning horizon. However, a different number of years might be appropriate for a planning horizon depending on the needs of a particular organization. Once a technology element has been defined and a strategy developed, the next step is to identify and organize the additional planning data and then load the planning data into the central database through templates provided by the Roadmap program (230 & 240). The first block of data to be identified, organized and loaded is Component Attributes. The Component Attributes are: the Component Name, Description, Map Status, Project Status, Convergence

Status, Dependencies, Stream Name, Owner Name, and Owner Group. A sample template for identifying and entering the Component Attributes is depicted at Figure 3. Component Name is the name as it will appear on the Roadmap. To fit within the cell displayed on the Roadmap, the name must be three words or less with each word twelve letters or less. The Description is a less than 255 character description of the Component. The Map Status is a color code for the completeness of the information within the Roadmap: (R) or red means the data for the Component has not yet been loaded; (A) or amber means the data for the Component has been loaded but a three year plan for the Component has not yet been developed; and (G) means all data for the

Component has been loaded. Project Status uses the same colors to reflect the status of any projects with respect to the Component such as, for example, a project to replace existing workstations with a new workstation having additional capabilities. A status of (G) or green means that the Project is progressing on track and any issues are being resolved without escalation. (A) or amber means that some dates have slipped but necessary steps are being taken to manage the situation. (R) or red means that there are problems occurring within the project that require senior management intervention. Convergence Status is an optional field a Component owner can use to track the status of particular goals with respect to a Component such as obtaining 70 percent penetration of a particular upgrade. In the 'Dependencies' field, a User enters the name of all Components on the Roadmap that the Component being entered is dependent upon. The 'Stream Name' field is where a User enters the name of logical group that the Component should be placed within. The 'Owner Name' field is where the name and contact telephone number for the Component owner is entered. The

'Owner Group' is the name of the group within which the Component owner works. An example template for a Streaming Services Component with all the appropriate Component attributes entered is depicted at Figure 4.

The template for loading the attributes of Streams is identical to the template for Components except that there is no one particular owner that is defined as the owner of the Stream and the logical grouping that is entered for a Stream is the Infrastructure Category rather than the Stream.

The next block of data to be defined is the Component details (232). A sample template for identifying and loading the Component Details is depicted at Figure 5. The details loaded are: the Technical Description, the Component's Scope, the Usage and Penetration, and the Design Principles. This detail is displayable on the Component View of the Roadmap Program. The Technical Description field is a technical summary of the Component. This is a more detailed description of the Component than the description of the Component entered for the Map view of the Roadmap program. Next, the User is required to define the elements that are within the scope and out of scope of the Component. As noted previously, this information defines the boundaries of the Component. The Usage and Penetration field identifies the status of Component use at various locations and business units. The Design Principles field is where the User can enter any strategy considerations governing the planning, deployment and/or evolution of the Component within the technology infrastructure. An example Component Detail template for a Streaming Services Component with the appropriate information entered is depicted at Figure 6.

The next set of data to be identified and loaded is the Product Details (233). A sample template for identifying and entering the Product Details data is depicted at Figure 7. This template requests information regarding the various products the enterprise is using or considering for a particular Component. The fields are the Product Name, Primary Function, Support Status, and Usage information associated with the product. For each Product, Support Status is defined as one of either of the following:

Emerging Under Evaluation No Support

Core Increasing New strategic platform. Supported with deployment program. Core Established Strategic Platform Fully Supported Core Declining Non Strategic platform, being disinvested support declining Specialist Exception Platform Support available at a premium

An example Product Details template for a Streaming Services Component with the appropriate information entered is depicted at Figure 8. Links to vendors are provided where appropriate. After the Product Details are defined, the next set of planning data to be identified and loaded is the Standards, Directives and Guidelines data (234). A sample template for entering the Standards, Directives and Guidelines data is depicted at Figure 9. With this template, the User enters the links to industry and company standards for the particular Component. An example Standards,

Directives and Guidelines template for a Streaming Services Component with the appropriate information entered is depicted at Figure 10.

Finally, the Projects template is used to identify and enter Projects that have some impact or dependency on the Component (235). A sample template for entering Project Details is depicted at Figure 11. No detail or projects plans are stored, although links can be created so that a User can link to the project details from the Component View of the Technology Roadmap. An example Project Details template for a Streaming Services Component with the appropriate information entered is depicted at Figure 12. After Component data has been entered, the User is next prompted with a template to enter the detailed three-year plan for the Component. A sample template for loading the detailed three-year plan is depicted at Figure 13. Under the event date, the User enters the key planning or milestone dates for the Component during the next three years. The document name is a link to the appropriate document, which will display the details for the particular milestone.

An example three-year plan template for a Streaming Services Component with the appropriate information entered is depicted at Figure 14.

After all relevant planning data has been identified and entered on the appropriate templates, the final step of the data creation process is to load the planning data into the database (240). Although other techniques could be used, the present implementation of the invention uses Microsoft Word macros to process the templates and load the data into the database. The above-described steps for defining, organizing, and indexing the technology infrastructure data are set out in a particular order for illustrative purposes only. The invention does not require that the steps be performed in the order in which the steps have been described.

Displaying the Technology Roadmap

When a User initiates the display features of the Roadmap program, the technology infrastructure is displayed as an overall Technology Roadmap, which is referred to as the 'Map' view of the technology infrastructure. If more than one Infrastructure Category has been defined, a User will first be displayed a screen to select the Infrastructure Category Map the User would like displayed. Figure 15 is a sample screen depicting the screen whereby a User selects the Infrastructure Category Map to be displayed. Figure 16 is a sample screen depicting the Map view for a particular Infrastructure Category. In the Map view for a particular Infrastructure Category, each Stream is displayed with the associated components listed below the Stream. For example, Figure 16 depicts various Streams such as Hardware, Market Data and Network Infrastructure that are within the Technology Architecture Infrastructure Category. In addition, under the Hardware Stream, the Map view identifies the associated Components for that Stream as Desk Top Printers, Displays, Distributed Servers, Front-End

Processing, High-Speed Printers, Laptop PC's, Mainframe Server, Mid-Range Servers, Palmtops, Storage and Workstations. The invention uses color to distinguish between a Stream and a Component although other distinguishing techniques could also be used. The display features of the Roadmap Program consist of web-based software tools that permit the User to navigate through the Technology Roadmap using a standard web browser. The program is designed to be compatible with Netscape and Internet Explorer version 4.x or higher. From the Map view, a User has several options, which can be selected via a standard Windows style toolbar. A flow chart showing the options that a User can select from the Map view is depicted at Figure 17. First, from the Map view (300), a User can change the mode for displaying the Map view to one of three modes: (1) Description Mode (301), (2) Owner Mode (302) and (3) Status Mode

(303). When the Description Mode is selected, two different colors will be used to represent Streams and Components. When the mouse is held over a Stream or Component in the Description Mode, text providing a brief description of the Stream or Component will appear. Text displayed by this method is hereinafter referred to as "tooltip text". Figure 16 shows a Map view in Description Mode.

In the Owner Mode, a different color will be used to represent each owner group for the various Streams and Components. In Owner Mode, the tooltip text will identify the owner group name and contact details. Figure 18 shows a Map view in Owner Mode. Status Mode tracks how far through the process each Component is with respect to data entry. As noted previously, this status is defined as red, amber or green when the Component is loaded in the database. Upon selecting this mode, the Components will be displayed as red, amber, or green depending on the data entry status. Similarly, selecting Convergence Mode will display the Components in the appropriate color based upon the information loaded in the database.

In addition to changing the mode, the User can also use the toolbar to click on certain dependencies. When the "Depends On" tool is selected (304), clicking on a Stream or Component will highlight any Components or Streams that are depended on by the Component. Figure 19 shows a Map view when a Component is clicked with the Depends On tool selected.

Another type of dependency can be found by clicking the "Required By" tool (305). With this dependency, clicking on a Stream or Component will highlight any Components that are required by the Component. As with the Depends On tool, two different colors will be used to represent Streams and Components when the Required By tool is selected. Figure 20 shows a Map view when a Component is clicked with the Required By tool selected.

Also from the Map view, the User can click on the Overview tool (306) or Help tool (307). When the Overview tool is selected, the Map area will present static HTML pages describing the Roadmap concept, application, and use. Figure 21 shows the Map view when the Overview Tool is selected. When the

Help Tool is selected, the Map view will present answers to Frequently Asked Questions (FAQ), and give context sensitive guidelines on usage. Figure 22 shows the Map view when the Help Tool is selected.

Finally, from the Map view, when the User clicks on a Component or a Stream, the Roadmap Program will display the Component view for the

Component or the Stream that is clicked (308). The only exception to this is if the Depends On or the Required By dependencies have been selected, in which case clicking a Component shows the dependencies as opposed to the Component view. The Component view enables a User to display the details for that

Component, which are maintained in the central database. Figure 23 shows a sample screen for the Component view of a particular Component. The Component view is composed of three areas: (1) an overview area, (2) an information area, and (3) a toolbar area. The overview area provides basic textual information on the selected Stream or Component. A button is provided in the overview area to return to the Map view. The information area will present information on the selected Component depending upon the tool selected. The toolbar area identifies the various tools the User can select to alter the information appearing in the information area. When a Stream is clicked, the resultant 'Component view' of the Stream is exactly the same, except that all Components for the Stream are shown in alphabetical order arranged down the screen top to bottom. If more Components exist within the Stream than can be shown on one screen view, then the screen becomes scrollable and the User can scroll down to see other Components. With a Stream, the toolbar functions will only show data if it has been loaded at a Stream level.

A flow chart showing the options a User can select from the Component view (400) using the toolbar is depicted at Figure 24. When the Scope and Definition tool is selected (401), the information area will present a static HTML information page, detailing the scope and definition of the Component. A sample screen showing the Component view when a User selects the Scope and Definition Tool is depicted at Figure 25. Similarly, selecting the Standards tool will present a static HTML information page (402), but with this selection the information portion will display any standards relevant to the Component including links to the appropriate intranet/internet page or document store (assuming the User has any necessary access rights). A sample screen showing the Component view when a User selects the Standards Tool is depicted at Figure 26. When the Products Tool is selected (403), the information area will present a static HTML information page, detailing the relevant products for the

Component, which were loaded in the database. The displayed information includes information such as the manufacturers and the support status (Core, Emerging, etc.) of the product. A sample screen showing the Component view when a User selects the Products Tool is depicted at Figure 27. When the Projects Tool is selected (404), the information area will display a static HTML information page, detailing any projects included in the Component. A sample screen showing the Component view when a User selects the Projects Tool is depicted at Figure 28. When the General Tool is selected, the information will display a static HTML information page, detailing any other information relevant to the Component.

Selecting the Three Year Plan tool will display in the information area a data-generated calendar of events (405). If a Stream has been selected, the Component view will show the Stream and any Component members of the Stream. A sample screen showing the Component view of a Stream when the Three Year Plan tool is selected is depicted at Figure 29. If a Component is selected, the Map will show the Component and any Components required by the Component. A sample screen showing the Component view of a Component when the Three Year Plan tool is selected is depicted at Figure 23. In the information area, Components will be arranged vertically down the page and dates will be arranged from left to right across the page and span the range specified in the database. The range of dates being displayed can be configured using two dialogue boxes. The Start Year box defaults to the current year, but can be manually over-ridden to be any future year. The Range box defaults to three years, but can be manually overridden to 2, 4 or 5 years. The dates of any milestone events for the Component will be indicated on the calendar by a red diamond. Placing the curser over any red-diamond (or milestone) will provide the tooltip text for the milestone. If more information is available, a graphic depicting the availability of additional information will appear. Clicking on the graphic will launch a separate browser window where any additional documentation will be shown. This documentation could be in any form supported by a User's workstation. For example, the "document" could be a spreadsheet file for budget information, an HTML file for graphical representation or a text file for written material. A sample screen showing the new browser window when clicking on vertical line for a calendar event is depicted at Figure 30. The progress can be tracked for a selected Component by entering "an effective progress date" showing the progress that has been made on achieving the entered milestones. For example, if a particular milestone is schedule to be achieved in November of the Year 2000 and the milestone is two months from being completed the "effective progress date" can be entered as September 2000. This progress will appear will as a solid gray bar on the calendar.

Although the invention has been described in detail for the purpose of illustration, it is to be understood that such detail is solely for that purpose and that variations can be made therein by those skilled in the art without departing from the spirit and scope of the invention.

Claims

What is claimed is:

1. A data processing system for planning, deploying, and evolving technology infrastructure of an organization, comprising: a server containing a database configured to maintain planning data on each of a plurality of elements of a technology infrastructure; a data collection means for selectively entering the planning data in the database; a program for retrieving the planning data from the database and organizing the planning data into a technology roadmap; a display means for providing a plurality of users with a map view of the elements; and a display means for providing links from the map view so that the users can display the planning data for each of the elements.

2. The system of claim 1, wherein the elements consist of: (a) components, (b) logical groups of components which are called streams, and (c) logical groups of streams which are called technology infrastructure categories.

3. The system of claim 2, wherein the components are defined as a logical element of the technology infrastructure, a service or set of software services that require a strategy, or a service or set of software services delivered to the users.

4. The system of claim 1 , wherein the planning data maintained in the database includes: (a) an owner of the element, (b) a scope for the element, (c) dependencies on other elements, and (d) a three year plan for the element.

5. The system of claim 2, wherein the planning data entered in the database for each component includes: (a) the owner, (b) a group name within the organization to which the owner reports, (c) a description of the component, (d) a scope for the component, (e) dependencies on other components, (f) products for the components and support status of the products, (g) a long range plan, (h) a stream to which the component is grouped, and (i) projects registered for the component.

6. The system of claim 5, wherein the map view provides a means for the user to display the description of each of the components.

7. The system of claim 5, wherein the map view provides a means for the user to display the owner group for each of the components.

8. The system of claim 5, wherein the map view provides a means for the user to display the status of the data that has been entered for each of the components.

9. The system of claim 5, wherein the map view provides a means for the user to display what components are dependent on a particular component.

10. The system of claim 5, wherein the map view provides a means for the user to display what components are required by a particular component.

11. The system of claim 5, wherein the component view provides a means for the user to display the scope and definition for each of the components.

12. The system of claim 5, wherein the component view provides a means for the user to display the relevant products and the support status for each of the components.

13. The system of claim 5, wherein the component view provides a means for the user to display the projects registered for each of the components.

14. The system of claim 5, wherein the component view provides a means for the user to display the long range plan for each of the components.

15. The system of claim 14, wherein the long range plan is three years.

16. The system of claim 14, wherein the long range plan provides a means for displaying user selected milestones entered at time intervals along the long range plan and a means for displaying any data files associated with the milestones.

17. The system of claim 1, wherein the planning data is entered on templates and loaded into the database by a macro that retrieves the data from the templates and populates the database.

18. A method for planning, deploying, and evolving technology infrastructure for an organization, which comprises the steps of: identifying all elements of a technology infrastructure; defining planning attributes for each of the elements; developing a planning strategy for each of the elements; entering in a central database the elements, planning attributes, and planning strategy and any additional data relevant to the element, which data is collectively referred to as planning data; organizing the data into a technology roadmap; displaying the technology roadmap as a map view of all the elements of the technology infrastructure; and linking from the map view to display the planning data for each of the elements.

19. The method of claim 18, wherein the step of identifying all elements of a technology infrastructure further comprises the step of defining each element as: (a) a component, (b) a logical group of components which is called a stream, or (c) a logical group of streams which is called an infrastructure category.

20. The method of claim 18, wherein the step of defining planning attributes for each of the elements further comprises the steps of: (a) determining the element's scope, (b) determining entities in the organization impacted by the element, and (c) identifying the element's functional requirements.

21. The method of claim 18, wherein the step of developing a planning strategy for each of the elements further comprises the step of displaying the map view of the technology roadmap and linking to the planning data so as to consider the impact of existing planning data on developing the planning strategy.

22. The method of claim 18, wherein the step of entering the planning data in the database further comprises the step of organizing the planning data into element attributes, product details, standards, project information, and a long range plan prior to entering the planning data in the database.

23. The method of claim 22, comprising the further step of organizing the element attributes into: name, description, project status, dependencies on other elements, element owner, and the owner group within the organization prior to entering the element attributes in the database.

24. The method of claim 21 , comprising the further step of organizing the product detail data for the plurality of elements into: product name, product description, product support status prior to entering the product detail data in the database.

25. The method of claim 22, comprising the further step of organizing the standards data into a set of links to industry and company standards for each of a plurality of elements prior to entering the standards data in the database

26. The method of claim 22, comprising the further step of organizing the project information data so as to identify for each of a plurality of elements the projects that may have some impact or dependency on the respective element.

27. The method of claim 22, comprising the further step of organizing the long range plan into a three year plan with milestones over the three year period and links to documentation describing the milestones prior to entering the long range plan data in the database.