Skip to main content

Fixing IT's Most Costly Mistake – Part 1

Author by Randy Steinberg

Question: What is the return on investment of an IT solution that cannot be deployed and operated at acceptable cost and risk?

Answer: Amount negative equal to your development investment plus lost opportunity costs and possible fines and penalties.

The magnitude of this problem cannot be underestimated. I personally witness as much as a half billion dollars each year wasted on IT solutions that cannot be deployed or operated at acceptable cost and risk. I personally witness IT operational organizations that go into chaos when new IT solutions are deployed experiencing untold amounts of unplanned labor, cost overruns, delays and service outages. I am just one person.

IT does not implement applications – that is only the utility side of the solution. They implement services. This means that concerns should exist not only for the applications and technologies being deployed, but also warranty requirements such as availability, capacity, working support processes, trained support staff and the need to operate at acceptable cost and risk to the business. This requires IT development teams and operational support organizations to work together. Here is an approach, used successfully, for doing so.

Image1-(1).png

 

As shown in the above diagram,  the ITIL Service Lifecycle stages are shown at the top. These are used as developmental phases for building the operational support. At the bottom, a typical development lifecycle is shown. The top stages are done in parallel with the application development effort at the bottom . For example, during the application requirements stage, Service Strategy activities will take place at the same time. During the application design stage, Service Design activities will take place and so on.

The large boxes under each ITIL stage summarize the kinds of operational activities to take place in that stage. For example, during the ITIL Service Design Stage (which is done in parallel with application design), the operational readiness activities to design the Service Support Organization, processes, technologies, data and reporting infrastructure will also take place. The details of all these activities are described further in this article.

The process, technology, organization, partners and governance tracks are there to show that operational readiness activities address the entire service solution holistically. For example, when designing technologies, other designs may be needed for process activities, support organization roles, governance roles, and supplier (partner) agreements and relationships.

 Checkpoint gates are used at the end of each stage to confirm readiness to proceed with the next stage. This ensures agreement across development and operations to move forward to the next stage.

In Part 1 of this series, a set of considerations is presented for each stage looking at both development and operations. These activities can be done in parallel between IT application development teams and IT service management teams.

A summary of key activities and the division of tasks between development and service delivery teams is described in detail below for each of the lifecycle stages:

Stage 1: Strategy – done in parallel with the application solution strategy

This phase focuses on high level service requirements such as solution key requirements, sourcing strategy, availability needs and expected business volumes. Development team considerations are on the left and operations team considerations are on the right.

Development

Operations

Overall Solution Model

Business Volumes

Specialized Support Needs

Implementation Timeframes

High Level Functional Requirements

Development Organization

Working Standards

Sourcing Partners

Application Architecture

Overall Enterprise Fit

Standards To Be Used

Frameworks To Be Used

Opportunities For Reuse (SOA)

Estimated Build Costs

High Level Service Requirements e.g.

    - Performance

    - Availability

    - Incident Support

Support and Delivery Strategy

Solution Operating Plan

Current Support Capabilities

Hosting/Sourcing Partners

Required Support Suppliers

Timeframes For Production

Ongoing Operational Costs

Management Tooling Architecture

Support Skills Needs

 

 

Stage 2: Design – done in parallel with application design

This phase focuses on design for each solution support area. Design tasks might include selection of specific tools, customizing tools, putting support contracts together, identifying event alarms and alerts, designing backup and recovery procedures or designing support processes.  Development team considerations are on the left and operations team considerations are on the right.

Development Team Considerations

Operations Team Considerations

Application Designs

Software Package Customizations

Testing Requirements

Capacity Requirements

Component Configurations

Procurement Requirements

Operational Detailed Requirements:

Required Alerts

Backup Requirements

Solution Configurations

Data Architecture

Functional Architecture

Technical Architecture:

Application

Middleware/Messaging

Network

Transaction

Database

Data Models/Data Design

Operational Architecture

Availability Designs

Capacity Designs

Capacity Estimates

Service Continuity Designs

Security Designs

Deployment Designs/Strategy

Process and technology designs for each support area in the framework

Support Roles/Responsibilities

Operational Control Tasks

Facilities Designs

Monitoring Designs

Procurement Requirements

Training Artifacts

Management Technology Specifications

 

 

Stage 3: Transition – done in parallel with application build, test and deployment

This phase focuses on build, test and deployment of the designed hardware, software and management processes for each solution support area. Transition tasks might include implementation of systems management tools, implementation of event monitors and agents, building and testing of server and desktop images, software distribution activities, and construction of physical data center facilities and closets.  Development team considerations are on the left and operations team considerations are on the right.

Development Team Considerations

Operations Team Considerations

Application Coding

Package Implementation

Migration/Code Libraries

Rollout Schedules/Volumes

Maintenance Needs

Testing and Validation

User Acceptance

Support Call Lists

Release Deployment

Configurations

Server/Desktop Images

Operational Testing

Site Surveys/Preparation

User/Support Training

Process Implementation

Operational Integration:

Service Desk

Technical Support

Operation Control

Facilities Management

Application Management

Production Cutover

 

 

 

Stage 4: Operation – done in parallel with application early life support and then ongoing

At this point, the solution should already be operating in production. Tasks in this phase represent ongoing activities to deliver services provided by the application solution. These activities focus on meeting service targets, delivering the services, monitoring them, processing incidents, problems and changes, maintaining applications and providing operational data.  Development team considerations are on the left and operations team considerations are on the right.

Development Team Considerations

Operations Team Considerations

None – at this point Application Management takes over for ongoing application maintenance and support

These are considerations by ongoing operational delivery teams:

Delivering Services

Ongoing Support

Monitoring/Event Management

Maintenance of applications

Maintenance of IT infrastructure

Execution of planned operational control tasks

Incident,/Problem Management

Request Fulfillment

Access Management

 

 

 

Stage 5: Improvement – done in parallel with ongoing application management activities

The improvement phase generally operates in parallel with the operations phase. Tasks here focus on reporting service quality and proactively reviewing the solution to identify ongoing improvements.  Development team considerations are on the left and operations team considerations are on the right.

Development Team Considerations

Operations Team Considerations

None – At This Point Application Management Takes Over For Ongoing Application Improvement

Collecting Service Measurements

Service Quality Reporting

Review Of Service And Operational Results To Identify Further Opportunities For Improvements

 

It is hoped the considerations presented here better focus application and operations teams such that they work together towards a solution, deploy that solution together and avoid the chaos that occurs each time a major new service goes into production.

Parts 2 and 3 will examine each stage in more detail identifying the kinds of design considerations that need to be considered for each stage and what to look for at each checkpoint gate.

Author

Randy Steinberg

ITSM Process Architect