 |
|
 |
|
| Home > Best Practices > Information Technology | Search: | for |
|
|
|
|
|
Lowering The Cost Of Ownership For Software Lifecycles
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 Production / Operations (28%) The challenges are twofold: 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 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:
1. Defining the current state of an application software portfolio 2. Measuring the performance of an application 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. 3. Implementing the portfolio review process 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:
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. 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 About The Author Reproduction Without Permission Is Strictly Prohibited – Copyright Requests Publish an Article: Do you have a Six Sigma tip, learning or case study? Share it with the largest community of Six Sigma professionals, and be recognized by your peers. It's a great way to promote your expertise and/or build your resume. Read more about submitting an article. "The Bottom Line" Links
|
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|
| Home | Discussion Forum | Event Calendar | Job Shop | |
 | |
| Link To iSixSigma | Rate This Page | Report A Problem | Free Content For Your Site | Submit Article For Publishing | |
| |
| Terms of Service. ©2000-2008 iSixSigma. All rights reserved. v3.0lb, 2.6-A-244 |
About iSixSigma · Contact Us · Privacy Policy · Site Map. |
|
