What You Need to Know About Modernization
© Copyright 2015 by Don Estes
Modernization of existing software applications, including especially the rationalization of multiple applications with similar purposes into one, has to be evaluated on the basis of cost, risk, and business value within the constraints of available resources. Doing so is not a skill possessed by most IT professionals, so all estimates should be suspect unless the person has a solid track record with modernization projects and sufficient range of experience to be credible.
Even then, it is advisable to retain a healthy skepticism, as the next project may range outside their experience. When we conduct such assessments, we challenge ourselves the same way. What have we missed? What could go wrong? And most importantly, what is the consequence of getting something wrong? It’s one thing if there is a 5% uptick in cost and delivery time, it’s something else if an airplane could fall out of the sky.
When confronted with a jumble of software applications, dozens or hundreds, how do you make sense of them? We start with a rough order of magnitude assessment of each application with a primary focus on business issues:
- Category: Commercial Off The Shelf software (COTS), custom, or customized COTS.
- Technical code base: language(s), database(s), platform(s), and size of each, i.e., number of source file records (lines of code), number of files or database tables, number of platform types (hardware type and operating system) and deployed instances.
- Currently anticipated strategy: do nothing, decommissioning, data migration to a similar application, wrapping to enable access to services or a new user interface, re-hosting, renovation (source code language and/or database translation), re-architecting, re-design & re-write, rationalization, replacement with a COTS solution, or a combination.
- Business value: value of the application to the business today and if modernized; estimated ROI from modernization, either tactical (within IT) or strategic (across the organization).
- Financial development value: actual or estimated investment in developing and maintaining the application over its lifetime, offset by estimates of accumulated technical debt, plus continuing annual investment in maintenance.
- Financial operational expense: annual expense to operate
- Cost: existing cost estimates or guesstimates for currently anticipated modernization strategy.
- Time frames: existing start/finish time estimates or guesstimates for modernization.
- Risk: what is the potential likelihood and cost of project failure, cost overruns, or delivery overruns, and the potential cost of a processing defect in production use when the replacement application is deployed.
The emphasis here is fast, and we accept rough as the price of quickly getting our arms around the scope of the portfolio. Over time, we can drill down and replace rough with accurate once we have established the business priorities.
This overall analysis has to be considered in light of resources and willingness to tolerate risk, and related issues as we drill down into each area. From this an overall strategy has to be derived and optimized within the available information.
Action Plans Within the Portfolio
Each significant application in the Portfolio will have to be evaluated in sufficient detail to validate the estimated information from the portfolio assessment before any action plan for it can be considered. The greatest concerns should be from assumptions – all assumptions should be explicit and available to challenge.
The simplest (but not simple!) applications are those that require a technology refresh of some sort, platform, database or in some cases the language. Decommissioning is always the easiest strategy, but it is rare that we can actually shut down an application and archive the data. Rationalizing multiple COTS applications such as email is an entirely different category from rationalizing multiple payroll systems, as climbing a flight of stairs is in a different category from climbing Mt. Everest.
All of the likely alternative modernization approaches should be considered, of which the preceding paragraph only discusses two. The simplest modernization situations usually have the lowest cost, lowest risk and lowest value. Our focus is usually on the complex modernization projects, where the cost can be very high, the risk of an error in production is unacceptable, and/or the potential for substantial value creation exists.
If you were a freshly commissioned lieutenant and ordered to take a battlefield target, your first order of business would be reconnaissance – what are you facing? 100 enemy soldiers, or 100,000? What are your resources? How much time do you have? What is an acceptable casualty rate? What about collateral damage? Far too many modernization projects are like the green lieutenant that takes his company and charges the enemy, with predictable consequences.
The elephant in the room for modernization is complexity, but nobody wants to talk about it. In fact, by and large we don’t know how to talk about it, so we reduce it to something we do know how to discuss – which are lines of code and number of files/database tables. There are technical deficiencies in doing so – you don’t want to base a budget on lines of code – but it gives us a starting point that at least most everyone can understand what we are discussing. If you don’t have at least a guesstimate of the size and complexity of an application, any plans you make are a shot in the dark.
Let’s take a moment and discuss the risk that comes from complexity. For a starting point, we take the logarithm of the number of lines of code in an application for which you have the source code:
- 3 or less, i.e., 1,000-10,000 lines of code, and we probably have low risk; this is like an Excel macro in a spreadsheet
- 4, i.e., 10,000-100,000 lines of code, and this will be low to moderate risk, depending on technical issues; this is like a small to medium sized mid-range or client/server application
- 5, i.e., 100,000-1,000,000 lines of code, which will provide moderate to significant risk, depending on technical issues; this is like a medium to large sized mid-range, client/server or mainframe application
- 6, i.e., 1,000,000-10,000,000 lines of code, this will almost certainly be significant to high risk; most significant “legacy” mainframe applications fall into this range
- 7 or greater, i.e., more than 10,000,000 lines of code will involve potentially career or even company destroying risk; think of the Microsoft Windows operating system for comparable complexity, and then think of what happened with Windows Vista.
Obviously, these are rough order of magnitude assessments and are subject to variation based on a number of technical factors, but one thing stands out: complexity has an exponential relationship to size. 1,000,000 lines of code is not 10 times the complexity of 100,000 lines of comparable code – it is more like 20-50 times as complex – because of the interconnectedness of the strands of logic and data.
Closely related to the likelihood of a risk being triggered is the potential business consequence of the defect in the software related to the risk. If we simply ask a client “what is an acceptable level of defects in the new software?” we get an unhelpful answer – “none!” On the other hand, if we ask, “what will you pay to eliminate errors and omissions in the new software?” then we can have a meaningful conversation. Is it worth a million dollars to assure there are no errors and omissions in the business rules? If a defect could cost you $100 million, the answer is probably “yes”. If a defect would cost you $10, the answer is probably “no”.
What Goes Wrong In Modernization
Problems in modernization projects often catch executives by surprise. All the project review reports show on schedule or within a reasonable variation. Testing results are good. There is no reason to suspect a problem.
Then the project gets to the pre-production stage, and stalls while a seemingly unending series of big and small problems keep being revealed. Eventually, when the level of reported problems falls to a tolerable level (or you just can’t wait any longer), the modernized system goes into production and you just live with the problems, which do become fewer and fewer over time. In some cases, the problems are so bad that the system is rejected, but the more common experience is unplanned delays and cost overruns – delays that last for months or even years. What’s going on here?
When one probes deeply enough into the weeds, what is revealed is that, while the system may have passed all functional tests, the business rules were incompletely understood and/or implemented, so the results of processing are wrong – intermittently – because all the combinations and permutations of business rules were never tested. As Bill Ulrich said in a 2001 paper,
…the first two years in the life of a replacement system is spent putting in “lost” business rules that analysts missed during the replacement design process.
At the outset of any project, one must always remember: you don’t know what you don’t know, and therein lies the source of potential problems. Confidence is the enemy; fear is encouraging.
So far, we have spoken about modernizing a single, standalone application. But many large organizations are faced with a proliferation of applications with both unique and overlapping functionality.
We spoke with one insurance company which had just completed the purchase of four smaller companies, each of which had its own unique rating engine to assess risks and price a policy for their own unique competitive offerings which their new owner wanted to continiue. Getting this wrong could cause either significant loss of business from overpricing, or serious financial loss from underpricing. The four different engines were on four different platforms in four different languages. They wanted to merge them into a single rating engine.
To do so safely, without creating a marketing loss from overpricing or an underwriting loss from underpricing, meant that the business rules in those calculations had to be completely extracted and merged, i.e., with no errors and omissions, sorting out contradictions in the process. Some people might assume that one new system would cost little more than modernizing one of them. In fact, the cost is closer to the sum of the costs of modernizing each one, because the financial cost of getting the business rules wrong could be very high.
Optimization of Business Processes
When attempting to establish business value for return on investment calculations for a proposed modernization program, we often find that people will try to justify it by savings within IT alone, which we consider to be tactical modernizations. Unfortunately, while the savings are certainly there, it is rare that the payback period is in the range required for most corporate investments, which is usually 2 to 3 years. Some projects would have a very long payback, 5 to 10 years, and some will have a negative payback. There may be other reasons for seeking a modernization, such as concerns about the availability of technical staff with the necessary training, but raw financial savings can be tough to justify on that basis alone.
The more interesting modernization projects are the strategic modernizations, which seek increased productivity across the whole organization and/or improved top line revenue possibilities from better marketing or customer satisfaction. These require the re-engineering of the business processes or the use of optimized process architectural approaches such those taught through the Business Architecture Guild and other organizations.
Strategic modernizations can cost 10-100 times the cost of various tactical modernizations, but they can also return sufficient business value to justify the investment given sufficient resource availability. This includes modernizations that target a customized solution as well as a COTS or ERP solution.
Controlling the risk in any strategic modernization but especially in a rationalization program requires understanding and controlling the risks from errors and omissions in the business rules within each application, as discussed at length in our Business Rules Extraction essay.
These are the key issues, and in the other essays in this series we go into depth on these and other issues. But at the end of the day, it comes down primarily to needing to predict and control four aspects of the modernization:
- resources (financial and personnel)
- time (schedule)
- risk (likelihood and impact)
- value to the organization