Inventory/Analysis

Introduction

To gain a perspective on the Comsys-TIM Inventory/Analysis stage, let's examine management's historical motivation behind decisions driving large scale IS initiatives. When faced with pressure to enact radical or significant change requests, IS typically makes either a build or a buy decision. These requests usually involve non-trivial, architectural changes to multiple systems and effectively shifts the focus from maintenance to a replacement scenario. Organizations readily admit that many of these decisions have resulted in poor results. Inventory/Analysis works to circumvent these problems.

Redevelopment is typically a component of a hybrid solution that, coupled with a build/buy scenario, drives the decision process well beyond the perceived three-way matrix. Decisions must also include numerous business and technical variables.

While this new and complex set of options may be confusing, redevelopment presents significant opportunities to leverage current software assets over the long term. Inventory/Analysis allows IS management to evaluate system upgrade or replacement alternatives based on objective business and technical criteria from which the best available option can be selected..

Objectives and Benefits

Inventory/Analysis is designed to augment, not replace, the planning process integral to Information Engineering (IE) and similar types of development methodologies. Inventory/Analysis offers several additional benefits over traditional approaches. First, it strives to determine how value can be gained by analyzing existing systems as a key component of the assessment process. Inventory/Analysis determines how reuse may be applied to subsequent phases of the development cycle to minimize the time, cost and risk involved in replacing applications. Minimally, high-level models representing replacement systems may be validated against the current environment.

Second, Inventory/Analysis delivers a short term plan to accommodate high priority maintenance requirements. If a replacement effort is not planned near term, the maintenance plan can stand alone based on projected quality and productivity gains. If a replacement project is scheduled, personnel reallocation to the replacement project is a strong selling point. Typically, these people are required to redesign and rebuild the replacement application.

Third, Inventory/Analysis cuts through political issues that accompany most replacement decisions. Since all relevant facts are gathered through the assessment process and a predetermined set of alternatives are evaluated as part of the effort, management can make objective decisions based on facts rather than guess work or political posturing.

Finally, Inventory/Analysis provides direct benefit. One byproduct of the process is valuable functional and technical documentation that is useful for individuals supporting current systems. This information is valuable for developers, planners, managers and designers.

Identifying Applications of Interest

The first and most critical aspect of Inventory/Analysis is to identify the "system or systems of interest". Systems included in an assessment project are determined by the scope of the business objective under review. The premise may be a simple code improvement, a multi-system integration effort, a package assimilation project or some other type of redevelopment scenario. All application systems directly impacted by these scenarios should be included in the Inventory/Analysis assessment.

For example, if a replacement system is being proposed that will eliminate or replace three distinct stand alone systems, all three impacted stand alone systems should be included in the assessment.

This is critical because an interim plan for each system will be developed along with a strategic redevelopment plan for that business area. Systems directly impacted and not included could invalidate those plans.

Systems that send or receive information to or from the systems of interest, but that are not directly impacted by the redevelopment effort, need not be included in the assessment. If the status of these "interface" systems is unclear, then include them with the understanding that this is the case.

Scenarios specify how systems should either be grouped as an aggregate or assessed as stand alone units. They also indicate which steps should be invoked to complete an assessment plan. The scenario driven planning process, completed during the objective setting/proposal development task, further confirms system identification and scenario selection. The symptoms and requirements section of a scenario establishes boundaries for creating a realistic and comprehensive assessment project plan for the systems of interest.

Assessment results further bound systems of interest in the resulting redevelopment implementation plan. Not being clear on which systems should be included in an assessment project could cause significant reworking since many assessment tasks view systems as aggregate units.

Assessment Process

An Inventory/Analysis "assessment" is performed within an application area when a specific requirement for a given line of business has been identified by senior management. Requirements driving an assessment include cost reduction, process redesign, technology migration requirements, system integration requests and a wide range of related activities.

An assessment is driven by the Comsys-TIM scenario selected to address a given set of symptoms within an application area. The first step of the assessment establishes various hypotheses, or suggested alternative approaches, that are tested throughout the Inventory/Analysis assessment. These hypotheses are eventually narrowed to a single, implementable redevelopment plan.

The assessment uncovers as much information as possible about current systems, short and long term requirements, the business strategy for that application area and cross organizational integration strategies. Once this information is gathered, a plan is created to meet short term system demands and long term strategic requirements for that area of business.

Inventory/Analysis -- Task Summary

The following tasks are included in the Inventory/Analysis stage.

Role of Metrics

Metrics within the industry today represent a great paradox. While no one argues that gathering and quantifying objective and subjective data on systems and the supporting environment is not a valid endeavor, few organizations commit resources to do so. Nowhere is the need for this data more prevalent than in the assessment effort required to build and execute a redevelopment plan.

A complete set of metrics is required to plan and manage a comprehensive redevelopment process. These redevelopment metrics have been defined and categorized in Comsys-TIM and present a complete picture of an application's technical, functional and architectural attributes. Additional metrics assist in determining the maturity of application support groups.

Summary level metric scores paint an aggregate picture of an application to determine maintainability and reuse under target architectures. All metric rating factors work on a 1 to 5 scale with a 1 being very poor and a 5 being excellent. This scale is applied consistently throughout Comsys-TIM.

The risk is in applying any type of metrical statistics. But the application of metrics gathered under Inventory/Analysis, applied via Comsys-TIM forms, is context sensitive based on specific redevelopment objectives. These metrics rapidly convey the quality of applications to IS management in order to create a realistic and feasible redevelopment plan based on the scenario driving the overall effort. These metrics also drive the development of the work plan.

Finally, metrics should not be gathered if they do not apply to the situation. Use common sense whenever possible to avoid getting buried too deeply in the metric analysis effort.

Building the Redevelopment Plan

Determining the feasibility of one or more alternatives and costing those alternatives is a difficult process to formalize. The inputs and outcomes are limitless. Comsys-TIM provides a process whereby an organization can objectively assess and select alternative redevelopment options and build cost justification for those options. Although the tasks described within the Comsys-TIM framework are generic, individual scenarios guide analysts through the process of developing cost analysis for specific types of redevelopment projects.

Objective Setting / Proposal Development contains a "straw man" work breakdown structure that includes all Inventory/Analysis estimating steps - one step per Inventory/Analysis step. Organizations should rely on the work breakdown structure for the scenario they are using to determine which of these planning steps specifically apply to a given project.

The Interim Support Plan and Strategic Redevelopment Plan, the last two tasks within Inventory/Analysis, allow cost/benefit factors to be tied back to scenario specific IS requirements. This is accomplished by building detailed work plans for one or more redevelopment alternatives and comparing relative cost, time and risk. The term interim, as used in Comsys-TIM, refers to activities to be completed under the existing or "interim" architecture. This time frame, practically speaking, may involve a window of 5 to 10 years for certain systems. In other cases, it could be as brief as 1 to 2 years. This depends on the goals of the individual application area.

With few exceptions, systems must continue to be maintained for some period of time. Therefore, the interim maintenance plan is the minimum deliverable from an assessment effort. It usually includes recommendations to improve the system using various Positioning tasks. It may also include recommendations, based on results of the IS Infrastructure assessment, to upgrade personnel skills, implement new development techniques and provide impact analysis technology to maintenance teams.

When specified as an objective for a given assessment project proposal, a strategic redevelopment plan will be produced. This assumes that the existing system (s), for whatever reason, has outgrown its usefulness and must be replaced. The strategic redevelopment plan is based on tasks identified in the interim maintenance plan, coupled with reuse of certain system or program level components from the existing environment.

The plan is further based on a phased process that couples formal development methodology with bottom up analysis, design recovery and component reuse from current applications. This approach augments the traditional top down development process where it is possible to increase the quality and reduce the cost, time and risk of delivering replacement systems under a strategic architecture.

Research supporting this approach is a key component of the Inventory/Analysis assessment when a scenario dictates migration to or replacement under a new target architecture. Architectural changes may include the business, data and/or technical architecture as defined by strategic information requirements. If little or no value can be ascertained from the current environment, this is acknowledged. Otherwise, system and/or program level reuse is clearly articulated as an integral part of the replacement plan.

The purpose of this approach becomes clearer as one becomes more familiar with the overall redevelopment process. The bottom line is that, historically, IS departments have left the decision of component reuse to programmers when this is a decision that should be made during the planning process by the management team.

The baseline work breakdown structure for Interim Support Planning includes all estimating steps for the Positioning tasks, with the exception of Middleware Enabling. Middleware Enabling steps tend to be used with equal frequency across interim and strategic planning efforts. Strategic Redevelopment Planning similarly contains all estimating steps for the Transformation tasks, and includes Middleware Enabling estimating guidelines. Given that Positioning and Transformation work steps can be used interchangeably across interim and strategic planning efforts, the best guide to the actual use of these planning step guidelines may be found in the scenario driving the project.

Practical Suggestions and Guidelines

It is sometimes appropriate to phase an assessment project. Highly complicated projects, projects that require the concatenation of multiple scenarios or very large systems may force this to occur. Other factors include first time Comsys-TIM users or the application of this process to non-standard situations - such as real time systems or home grown technologies.

One must use discretion and common sense when building a plan. If an assessment plan spans more than 2 to 3 months, consider phasing the project. This could provide short term assessment results where an interim plan is produced first. Subsequent analysis would then build upon this first phase and go into more depth on a specific subset of systems or topic areas. Adjust strategies, planning windows and systems of interest as needed to ensure success.

The Comsys-TIM Inventory/Analysis stage establishes concise objectives, work tasks, deliverables and proposed alternatives for a given redevelopment project. The overall assessment and planning process is highly dependent on the specific business goals of an application area.

The best way to apply Inventory/Analysis tasks is through specific Comsys-TIM scenarios. Scenarios control the scope and breadth of an assessment and the extent of the resulting redevelopment plan.

Valuable byproducts of Inventory/Analysis include technical and functional documentation of the current environment as well as an in-depth understanding of current applications and how they interact with related systems. Attempting any type of redevelopment effort without the proper level of planning, as provided in the Inventory/Analysis, is a high risk and unnecessary undertaking.