How Does Application Modernization Figure Into Your Business Vision?
Application modernization is rarely a goal in and of itself. Rather, it is an enabler of broader goals for your enterprise.
Is your vision one of transformation across the organization? Are you looking to change your business processes to become a digital enterprise, and refocus your IT organization with business driven goals? If so, then we think of this approach as a strategic modernization, and the focus is both inside and outside of IT.
Or, are your goals more modest, or constrained by resources or time frames? Are you looking to save money, upgrade technology, improve integration, or improve access to data and especially data analytics? If so, then we think of this approach as a tactical modernization with the focus and benefits primarily inside of IT.
Modernization Is Not New Development
Developing a new application is like having a baby. Modernizing an existing, mission critical application is like having a heart transplant. Go to a cardiac surgeon if you need a transplant, not an obstetrician.
In some cases, you may not be ready for your transplant. If so, then we want to prepare you in the short term to be ready for the longer term. In modernization terms, we may want to use some tactical techniques to buy time and gain some short term benefits. Then we proceed to the strategic modernization when you are ready in a hybrid project design.
If you are considering a modernization project, or if you have questions about a project in progress, contact us to discuss how our unique approaches to modernization can save you time and money and significantly improve the value of modernization to the organization.
Comparing Modernization Techniques
In order to compare the many approaches to application modernization, we need a metric that allows us to create meaningful comparisons. The most commonly used metric is lines of code (LOC), the number of records in the application program source code files.
Your technical staff will tell you – correctly – that LOC is an inferior measure to other metrics such as function points. However, it has the unique advantage that everyone understands what it means. Furthermore, we are frequently concerned with the order of magnitude, i.e., the logarithm of the LOC, rather than the actual number of lines of code. We discuss this in more detail below in the section Scale Matters.
When the greater accuracy of function points is required in a given context, we use them, but otherwise we use LOC to facilitate understanding at all levels of the organization. Note that when discussing a prospective project, we have to use the existing application source code, in which case we will refer to the legacy LOC.
A strategic modernization will often focus on how to:
- Increase business value across your enterprise
- Re-engineer business processes
- Improve top line and bottom line
A strategic modernization can have a wide, positive impact across your organization, but a serious return on investment does require a serious investment. Roughly speaking, strategic modernizations will cost in the range of $10-$100 per legacy LOC.
Even with these costs, the potential value to the organization can justify the expenditure and provide solid value and ROI. If you want to create an agile digital enterprise, this is the route you must take, either immediately or as the endpoint of a hybrid modernization project.
The overriding issues in a strategic modernization are managing requirements and extracting the business rules, which are tasks that are universally underestimated in difficulty and risk – because you don’t know what you don’t know when you begin to plan. And if you don’t know that you don’t know, then you are already in trouble before you start.
Strategic Modernization Programs Can Add Business Value Safely
There is a false dichotomy between preserving the old systems and building value in the new systems. People will say that you have to rebuild an application from scratch in order to build in the business value that justifies the investment. You can’t preserve the old code or even the old requirements from this point of view.
And, they are almost right, but business rules are not requirements, and requirements are not business rules. You don’t have to preserve the old requirements, but you must preserve the old business rules because the business is not changing while we are modernizing. We say that business rules are invariant across a modernization project.
The business rules will not change during a process optimization as part of the modernization, unless the business is changing in some meaningful fashion at the same time. But in almost all projects, the day to day business is not changing meaningfully, and therefore the business rules do not change.
- Business rules control update transactions and are invariant over the modernization
- Process optimization controls work flow and user experience which primarily use direct queries and/or query transactions, and are free to change as desired over the modernization
- There is no conflict between business rule invariance and process optimization
You may have to use a business architecture or other methodological approach to optimize your business process and create the new software design. And you must extract the pure business rules from the legacy system in order to control transactions that update the database in the new system.
The requirements are free to change as much as you wish to accomplish the process optimization. (Note, however, that a requirement can be to obey a business rule.) A site that understands this distinction is free to optimize as much as is desirable, while preserving the legacy business rules and bringing them forward into the new system. This is the basis of modernization testing discussed in the next section, and is discussed in more detail in our Business Rule Extraction essay.
Only Modernization Testing Can Fully Mitigate Risks
Conventional approaches to software testing in a strategic modernization fail to adequately protect enterprise operations during a strategic modernization, because testing is based on requirements. But in a modernization project, it is the requirements themselves that require testing in addition to the software.
Requirements based testing cannot find a defect in the requirements upon which they are based. We extend your testing methodologies to test the requirements as well as the modernized software functionality.
Our Test Driven Modernization methodology ensures that all business rules are captured and proven correct and complete and is unique in the industry. We can prove analytically that you have 100% of the active business rules needed for daily operation, and create the extended test cases to prove that the new application delivers the value expected.
Business architecture principles and knowledge provide the methodology for ensuring that your project will identify and deliver the business value promised. Our Test Driven Modernization methodology is fully compatible with and complements projects based on business architecture principles.
For tactical modernization projects, which we address in the next section, requirements based testing is simultaneously unnecessarily expensive and inadequate to discover all potential defects. A slight modification to the Test Driven Modernization methodology will provide a complete set of test cases for tactical modernization at much lower cost than requirements based testing.
A tactical modernization will usually focus on how to
- Introduce a technology refresh
- Reduce IT costs and increase productivity within the IT organization
- Maintain continuity of present IT processes, only better/faster/cheaper
- Improve access to data and data analytics
- Improve overall bottom line
There are several tactical methods for reducing costs and improving productivity, particularly if your applications are on a mainframe:
- Re-host to Linux/Unix/Windows on Intel, RISC or mainframe platforms
- Re-architect or re-write
- Make your applications zIIP eligible
- Translate your legacy code to a standard language (COBOL, C, Java/C#, etc.)
- Translate to your legacy database to relational
- Unravel your spaghetti code
These strategies tend to cost in the range of $1 to $10 per legacy LOC. In other words, they can be 10 to 100 times less expensive than a strategic modernization.
Which one(s) should you embrace or spurn? How do you choose? How do you manage the project(s)? How do you manage the vendor(s)? How do you share and divide the risks with your vendor? How do you divide responsibilities? How do you test? Convert data? There is a long list of issues to be considered, all of which we address when performing a modernization assessment study.
All the questions from the assessment methodology should be considered when planning for any tactical modernization, particularly if it is the first step in a hybrid modernization, which we discuss next.
Hybrid Modernization Projects
Of course, both the strategic and tactical strategies rarely occur in a pure form. Many projects are hybrids – the eventual goal is a strategic modernization, but practical concerns indicate that it will have to happen in stages over a period of time rather than in one large project.
Our Incremental Modernization methodology ensures success because you always have a working system. By taking small “baby steps,” each of which can be proven before moving to the next step, we prepare your organization for an incremental modernization that that will be optimized to your goals and unique circumstances. We use tactical methods to move your organization progressively closer to the eventual goal, which is both lower risk and arguably lower cost as well. Incremental Modernization links your unique technical circumstances to tools and processes for extracting the residual value in your legacy assets in an organized, step by step plan.
Replacing your application with a commercial off the shelf (COTS) solution can be considered a hybrid because you must extract your business rules and prove them, just like a strategic modernization, and you must create the test cases for validating the COTS solution using the test cases derived for dynamic business rule extraction. However, you are not going to redesign/rewrite your application. Instead you will be configuring the COTS solution with your business rules and demonstrating that it is correctly processing all the active business rules in use today.
Why Does Application Modernization Require Different Methodologies?
Strategic Modernization Is Significantly Different
Most application modernization projects adopt a strategy of re-design and writing a new system or of replacement with packaged software. Unfortunately, most also fail to fully recognize that modernizing an existing application is fundamentally different from developing a new application totally from scratch. Organizations are dependent upon the correct functioning of these “legacy” applications each and every day. The impact of errors and especially omissions in functionality can range from tolerable to business critical, especially for highly regulated industries.
A wholly new application that will support a process that was not previously automated (think of Facebook or Amazon when they were new rather than payroll or general ledger) does not have this legacy of operational dependencies. Projects that recognize these differences and incorporate procedures to assure correct functioning during testing will be on schedule and on budget, and those that do not will face challenges that grow disproportionately with the scale of the application.
It is important to understand that standard testing methodologies will not detect these errors and omissions. This is because testing is designed to detect deviations from stated requirements. There is no provision in standard testing to detect errors and omissions in the business rules expressed in the requirements.
An existing application is a collection of these very fine grained business rules upon which daily business operations depend, yet these rules are at best only partially documented and imperfectly understood. As these imperfect rules are used to construct requirements, unrecognized errors are incorporated into the design and unrecognized omissions are left out altogether. Adopting a packaged solution still requires that all business rules be incorporated into the configuration of the package, which can become almost as complex as writing new software.
Tactical Modernization Is Completely Different
In a strategic modernization, we are rewriting the application or replacing it with a COTS solution. Superficially, this is similar to greenfield development of a wholly new application (though with major critical differences as discussed above).
In a tactical modernization, we are using tools and/or services to make different degrees of modifications to the existing source code library. This has no similarity whatsoever to greenfield development. Furthermore, relatively few technical staff are familiar with the nature and requirements for a code modification project.
The results are quite different as well. A strategic modernization will produce code that bears little or no resemblance to the legacy source code library. A tactical modernization will preserve the original code to a greater or lesser degree, or at least preserve the original application functionality, so there will be significant degrees of familiarity in the result.
Most importantly, there will be no loss of functionality in the resulting modernized system except through a defect in the transformation process itself. Since we are preserving the original functionality by direct use of the source code, none will be missing. For a strategic modernization, however, we have to work really hard to ensure that no functionality is missing or implemented in error.
And the scale of the application, represented by order of magnitude of the legacy LOC, is directly related to the impact of these shortcomings:
- Smaller applications, on the order of 100,000 lines of code, usually are able to sort these out with a few speed bumps but rarely anything serious. We will usually recommend a rewrite in this size range.
- A moderately sized application, on the order of 1 million lines of code, can experience serious issues. However, using our test driven modernization methodology, we can ensure that all risks are controlled.
- By the time you get to 10+ million lines of code, scale related issues can dominate the project. Depending on the risk profile of the application, we may recommend a hybrid, incremental modernization rather than going directly for a rewrite. If relevant, this allows us to gain some operational benefits while we are working our way through the library with the test driven modernization methodology. Source code libraries of this size can have internal complexities that are difficult to predict fully in advance.
Scale is the underlying reason why modernization has a reputation for being expensive, risky, and delivering late and/or over budget, because you never hear about the small projects that do just fine.You only hear about the problems in the moderate to very large scale applications where a lot of money is at stake. It is difficult to maintain perspective.
Yet even when the system has been thoroughly tested according to standard methods for software development, numerous discrepancies still crop up once it goes into production because of the inadequacies of requirements based testing in a modernization project.
The risks and costs of these projects can be controlled and a positive ROI assured, but doing so requires a departure from the model of modernization as new development. This is the basis of our consultancy.
Choosing a Technical Strategy
No one strategy is clearly preferable for all cases. There may not be an applicable COTS package, or the gap may be too big, or you may lose critical competitive advantages. Code translation may be cheap and fast but does not meet your business goals. Re-architecting may be better but it still does not meet your goals.
A custom re-design and rewrite may be the only approach for a strategic project, because the legacy assets have too little residual value or the value to the enterprise may be so great. So how do we control cost and risk while ensuring that we gain the value promised by the strategic approach?
How do we derive the best strategy? We start with an application modernization assessment study to expose the facts, the issues, and the alternatives in clear business terms.
With the assessment in hand, we have the information to assist you in choosing the best modernization methodology (or combination of methodologies in a hybrid project) according to your specific circumstances. There is no one size fits all solution. Every project has unique characteristics that must be taken into account along with the similarities to other situations.
The decision is non-trivial, and involves understanding the business case, schedule goals, resources available, residual value in the legacy assets, technical details of the application implementations and deployments, and appetite for assuming IT risk, among others. Then, if either a COTS package or outsourcing some or all of the project is under consideration, we add vendor risk to the list.
Choosing the best strategy is primarily a business question, not a technical question, except insofar as technology impacts the business. We argue that the pros and cons of different alternatives should be analyzed according to business criteria and the optimal solution derived for your unique circumstances.
Let us assess your plans and lay out the options that you could consider, and then assist you in implementing your chosen strategy to ensure the successful realization your vision of the future of IT in your organization.