WEDNESDAY, SEPTEMBER 03, 2014
Font Size
Industries Software/IT Lowering The Cost Of Ownership For Software Lifecycles

Lowering The Cost Of Ownership For Software Lifecycles

From CIO to CFO, the writing is on the wall – lower the cost of ownership. This article discusses strategic choices IT organizations can make in lowering the cost of ownership for the entire software lifecycle in order to minimize overall costs and deliver return-on-investment. Reducing their budget in the short term can motivate IT organizations to create innovative approaches to systems development that will reduce costs.

How will we remember the past eighteen months? Many will remember it as a time of economic slump, with lay-offs, low spending and a war in Iraq. The economic situation is not likely to improve during the remainder of 2003, leading organizations to focus on delivering value to their customers while demonstrating hard return-on-investment. Any investment decision is likely to follow a simple rule of thumb – no value, no investment. Decreased budgets, lower technology spending and a cap on resource hiring are the corporate mandates given to department heads. From CIO to CFO, the writing is on the wall – lower the cost of ownership.

At IT companies as well, it’s clear that delivering value is the focus. It’s unlikely that any company will buy or build systems without knowing when, where and how they will pay off. This article discusses strategic choices IT organizations can make in lowering the cost of ownership for the entire software lifecycle in order to minimize overall costs and deliver return-on-investment. Reducing their budget in the short term can motivate IT organizations to create innovative approaches to systems development that will reduce costs.

Challenges Of Software Lifecycle Management
A major cause of concern for all IT organizations is software application maintenance. According to Gartner, 79% of IT budgets are spent on maintaining existing systems. Gartner reports that the largest number of internal IT staff members (36%) are assigned to application support and maintenance with additional resources focused on:

Production / Operations (28%)
New Development / Major Enhancements (21%)
Administration – 14% (Gomolski 2001)

The challenges are twofold:
(a) How can we lower software maintenance costs? and
(b) How can we build software in such a way that allows for reduction of maintenance costs?

While many companies have taken steps to lower costs, real breakthroughs are rare. Most companies have adopted the offshore model. Unfortunately, many offshore facilities have reached their maturity. IT organizations continue to demand lower rates from vendors while vendors are working against a very tight cost model to provide the best possible service. In effect, offshore facilities have reached a level where any further reduction in rates will ultimately involve compromising quality or agreed commitments. This situation has provided incentive for IT organizations and vendor communities to find innovative solutions to the problem.

Need For A Comprehensive Strategy
Effective means to manage this problem requires a comprehensive strategy backed by a management commitment to welcome change into the organization. The change may require a set of new capabilities, improvement of existing capabilities, or both. The following provides a strategy that IT organizations may find useful in determining the current and desired future states of software lifecycles. The strategy includes two main elements, the Conceptual Model and the Governance Model.

Conceptual Model: The purpose of this model is to determine the current state of the software portfolio and to design a future state. The strategy to drive this model is based on an iterative process as it impacts many parts of the organization. The individual stages described below must be supplemented and adjusted until no objections remain. At the end of the conceptual modeling process, the organization selects from among three decisions:

  • no-change
  • rationalize existing systems
  • transform

1. Defining the current state of an application software portfolio
A good starting point is to take stock of the current situation. In addition to listing the software applications, rank them from multiple perspectives using a scorecard. Use an iterative approach to assess the merit of each perspective relative to the others and adjust or supplement until no objections remain. The perspective can include elements such as business value, productivity issues, operations costs, competitive advantage, skill availability and technology issues.

2. Measuring the performance of an application
In addition to organizing the application software portfolio, consider the metrics needed to measure the process. The basic assumption is that you can’t manage what you don’t measure. However, while it’s a good start, measurement alone does not get the job done.

First, make an assessment of the total cost of ownership associated with the current software portfolio. Evaluate the cost figures from development, integration, deployment, operations, maintenance, and enhancement standpoints.

Second, once the cost figures are determined, manage them within the context of service level requirements. The goal is to convince the management team that the proposal is worthy of attention and to obtain approval for funding. At this stage it’s worth making a comparison of various cost drivers within the organization to other peer groups. Use this comparison to create awareness of the complexity and the opportunity to improve service levels and reduce costs.

Third, evaluate the cost model to illustrate how costs tend to shift from IT to individual business units. Managers are often shocked to see how IT costs are borne by their departments and therefore become interested in learning strategies to better manage these costs.

Fourth, evaluate the value business units derive from the existing application and identify opportunities to reduce costs and provide greater value and improved service levels.

3. Implementing the portfolio review process
Apply a multi-dimensional approach to the review process using metrics gathered so far to determine what actions are necessary to lower the cost of software lifecycles. This is where the decision to change or do nothing is made. One of the objectives of the Conceptual Model is to create an iterative process. Therefore, it’s likely to take a few rounds of review to come to a final decision. If the decision is to make a change, the next step is to either rationalize the existing system or to transform it.

The Conceptual Model is supplemented with an understanding of the value a business can expect from an IT enabled initiative. It stands to follow then that, in addition to deciding on application portfolio, the Model should provide answers to some of the following questions:

  • What is the initiative?
  • What is the business value?
  • How much benefit is received in terms of lowering the cost of software lifecycles?
  • How much will it cost to implement the initiative?
  • What is the response to changes in future technology and business trends?

For a complete value analysis, it’s essential that each of the above questions be answered in adequate detail. The following figure describes the expected return in terms of business value.

Figure 1: Investment Versus Business Value
Investment Versus Business Value

No Change: With an older generation application architecture and outdated technology, the lifecycle cost is significant, preventing generation of business value. This approach constrains progress and creates recurring maintenance costs over time.

Rationalization: This choice may involve decisions such as elimination, retention and integration of existing applications. While the decision involves a comprehensive review process, the general approach reflected below is also useful.

Eliminate the systems generating no business value to the organization and are expensive to maintain. While it may make sense to retain these systems, an assessment of the architecture and underlying technology is critical. In the long run, these systems would experience difficulty in responding to ongoing changes. As a result, recurring maintenance is expensive and the skills necessary to support the systems difficult to find.

Integrate legacy applications when you want to extend the reach of your existing data or business logic to new application systems.

Transform the system if the software constrains growth, cannot change or involves high maintenance costs, even if it provides good business value. In most cases the underlying software architecture plays a critical role in responding to ongoing changes. In order to become agile, the application architecture must accept change, facilitate collaboration and allow the addition of new processes more quickly and efficiently than in the current environment. This requires a new approach to building software.

Organizations are increasing the focus on building software based on Model-Driven-Architecture. What is most significant about this approach is the independence of software specifications from the implementation of technology and platform. The model stores the definitions and software is generated out of the model and assembled for a given technology platform. The platform can be J2EE or .Net. The target applications are loosely coupled business functionality (component) with web service enabled capability. The advantage of building such a system with components exposing services for well-defined functionality is to allow flexibility.

When change becomes necessary, it is made at the model and not at the code base thus allowing easy and cost effective maintenance. Another advantage of this approach is that organizations can reuse existing legacy logic if required and wrap it into a reusable software component. The transformation program for existing software requires moderate investment, allowing a gradual or phased implementation while utilizing a good amount of existing investment.

Governance Model: To succeed with the IT enabled initiative to lower the cost of software lifecycles, a good Conceptual Model requires the backing of an effective Governance Model. A well defined Conceptual Model with a poor Governance Model is ineffective in delivering business value.

A structured Governance Model is the foundation for a successful comprehensive strategy. It provides direction for resource utilization and establishes the necessary types of IT enabled initiatives regardless of the decision to implement limited change or embark on an extensive transformation program. Performance of the model is measured throughout implementation. Feedback from the management team is critical, allowing sponsors to determine the business value generated by the investment. Most importantly, the Model allows business users to partner with IT in the new initiative.

References
Gomolski, B., Grigg, J., Potter K. (Sept 2001). 2001 IT Spending and Staffing Survey Results. Strategic Analysis Report, Gartner RAS Services.

About The Author
Subrata Kar is Director of Solution Consulting for Ramco Systems Corporation, North America. He leads IS strategic consulting and Program management services and has more than 18 years experience in application development, ERP product development & implementation and global project management. He can be reached at skr@rsc.ramco.com, telephone (609) 620-4828.

Register Now

  • Stop this in-your-face notice
  • Reserve your username
  • Follow people you like, learn from
  • Extend your profile
  • Gain reputation for your contributions
  • No annoying captchas across site
And much more! C'mon, register now.

Leave a Comment



Login Form