In-depth experience report shares how one company saved seven years by modernizing a portfolio of Smalltalk applications to Java with Synchrony Systems
Six Smalltalk applications to Java. The company estimated it would take another ten years to complete the portfolio modernization and retire Smalltalk altogether.
This experience report goes behind the scenes to expose the unique three-year collaboration between Synchrony and a German IT services provider for the financial sector.
This in-depth report is available for limited release to companies interested in understanding the details of modernizing large, legacy applications.
Readiness phase (Application portfolio, Work breakdown, Team collaboration, Project timeline)
Implementation phase (Splitting the work, Progress of parallel tracks, Progress of the entire project, Halfway point evaluation, Functional testing, Code quality, Integration testing, Final deliverable
Conclusions and take-a-ways
Appendix (Codebase, Pipelines, Operations, KB and CL, Issues, Deliveries, Datapoints)
DevOps has revolutionized software engineering methodology by unifying development and operations to accelerate software delivery. The older-style waterfall approaches to greenfield application development are being put aside as DevOps principles of agility, iteration, continuous delivery, and automation take center stage.
Modernization must deal with the challenge of transforming millions of lines of existing legacy code, built over decades by dozens, if not hundreds, of engineers, most of whom have moved on or retired altogether. Yet outdated approaches such as “rip and replace” are still the default modernization methodology, employing manual rewrites and disjointed automation tools. This approach is costly, takes an enormous amount of time and resources, and introduces significant risk to the business.
At Synchrony Systems, we believe it’s time to apply the DevOps principles, adopted for greenfield development, to software modernization—or ModOps—to keep pace with the rapid digital transformation.
Accelerating modernization delivery
Modernization focuses on transforming existing legacy systems and applications to the latest platforms and architectures. Unlike greenfield development, where very frequent and incremental changes are made to small bodies of code, modernization requires making wholesale transformations of the entire body of code at once and en masse. Therefore, the traditional manual approaches to modernizations can no longer be justified in today’s rapidly moving digital economy.
As the chart illustrates, ModOps accelerates modernization delivery and does so at a fraction of the cost and with faster time-to-value. It balances the overall speed, cost, quality, and risk while creating a unified experience that addresses a complex modernization process in a predictable way.
Continuous modernization
Continuous Development (CD), along with Continuous Integration (CI), have become the cornerstones of DevOps— the way applications are being developed and released into production. By replacing CD with Continuous Modernization (CM), ModOps will achieve the same—the way existing applications are to be modernized. Continuous Modernization will bring a high degree of automation and a systematic approach to managing the entire modernization lifecycle.
The three main pillars of ModOps are:
automation-driven modernization and transformation of legacy applications to modern programming languages and platforms;
coexistence of modernization activities with ongoing development activities, without any code freezes; and
functional and UX equivalency with no hidden costs or operational disruptions to the business.
ModOps is the answer for any company whose objective is to preserve its IP and its original investment in mission-critical legacy applications by adapting to and effectively competing in a rapidly moving digital economy.
As in DevOps, ModOps promotes agility, collaboration, and complete transparency. Project managers, migration engineers, testers, and other business stakeholders have full visibility into the overall status and progress of an ongoing modernization at every stage. With built-in planning, tracking, monitoring and dashboards, extensible workflows, automated testing and real-time feedback, a modernization is guaranteed to run smoothly and to be completed on time and on budget.
Tools for ModOps
The evolution of DevOps has spurred the development of tools to help teams more easily apply DevOps principles to the application development process. Modernization Lifecycle Platform (MLP) is doing the same for the application modernization process. It is a DevOps-driven, integrated, Modernization-as-a-Service platform that creates a unified approach to modernizing legacy applications. Whether it’s a modernization of COBOL to Java, PowerBuilder to C# or Smalltalk to Java, the underlying process, methodology, and user experience are uniform, no matter the chosen source and target platform combination. As a result, organizations are just months—not years—away from having their legacy applications transformed to the digital economy of web, mobile, and cloud.
No more legacy applications
We see a future where the application software is never “left behind” or lost to obsolescence. The major business challenges created by legacy applications—growing technical debt and shrinking technical talent—would themselves become obsolete.
Adding Continuous Modernization (CM) alongside CI/CD would give developers the ability to systematically and incrementally apply new software updates, adapt new APIs, or any other software components to in-house applications, thus doing away with any future wholesale modernization initiatives. By embracing ModOps and adopting a platform like MLP, businesses will become more agile, competitive, efficient, and responsive in addressing the demands of today’s digital economy.
Modernize your legacy code for a cloud-native world
Many organizations have already moved to the cloud. Yet the tech debt remains. Applications that were once considered “legacy” now run in modern infrastructure, but they’re still monolithic, tightly coupled, and difficult to change. Cloud hosting alone doesn’t make software cloud-native.
The business logic still matters. These systems still run underwriting, billing, claims, supply chains, and core operations. They cannot simply be replaced. But they can’t stay frozen either.
So what actually reduces tech debt? In this white paper, Jason Bloomberg, President of Intellyx, takes a practical look at legacy modernization — what works, what doesn’t, and where many organizations miscalculate.
Inside the paper:
Why lift and shift often fails to reduce tech debt
The architectural challenges behind monolith-to-cloud transitions
The limits of line-by-line code translation
Balancing automation with human engineering expertise
In-house applications, once associated with good fortune, have now become an albatross. These systems may still run business-critical processes or orchestrate data between commercial systems, but their underlying, aging technology has become a real liability. You know it’s only a matter of time before something fails, and it won’t be pretty.
You may be hearing a lot of bluster about the best way to go about modernizing legacy applications. “Refactor,” “re-platform,” “encapsulate and expose for microservices,” “lift and shift,” and “low-code rebuilds” are just a few of the buzz-phrases floating out there. At Synchrony systems, we also have our own view of how best to modernize. But the how is not always as straightforward as some try to make it seem. How to modernize depends on many factors that span well beyond source code or target technology.
So where do you begin? The following steps should not only help you prepare for legacy application modernization; they also should help you clarify the right modernization methodology to pursue.
Know what you have: document your current state
While this may sound like a no-brainer, you’d be surprised at how many companies don’t have a complete, up-to-date overview of their technology stack. Perhaps that’s because they’re busy putting out daily fires or launching new initiatives. Or maybe staff turnover put the critical, technical documentation on the back burner. Regardless of the reason(s), before starting any potential modernization initiatives, you must possess a full technical understanding of your IT portfolio and which parts of it are mission-critical to your business operations.
Three dimensions of the current state must be well understood: architecture, timeline, and capital.
Architecture: While it’s ok to not have all the answers, accurately describing what you know—and highlighting what you don’t—is important.
Do you have access to the source code of your in-house applications?
Do you understand your applications’ source platform dependency?
Do you understand your applications’ component architecture?
Do you understand your applications’ runtime architecture?
Timeline: Many in-house applications are built using licensed, 3rd-party software. Understanding the timing of the maintenance and support contracts is an important input to the modernization effort.
Capital: Capital includes the dollars used to support the in-house applications, as well as the resources and time spent maintaining them. You also need to understand what other IT projects your company is currently funding, the budget for the modernization initiatives, and when those funds will be available.
With this information, you can start to map out the priorities for your modernization.
Know where you want to be: document the future state
Sometimes the future state has a strategic mandate from the top—become cloud-first or consolidate technologies onto a single platform. Other times, the future state evolves more organically. Regardless of the path, you need a documented roadmap of the new vision for IT. This plan is really a risk-mitigation strategy for your legacy applications. It’s only a matter of time before the old versions start to fail, their security gets breached, a 3rd-party vendor stops supporting the software, or some other business-impacting event occurs.
Like the current state, your future state plan has the same three dimensions: architecture, timeline, and capital.
Architecture: Future state technology architecture needs to be aligned with the business need, and not just be technology for technology’s sake. The tech vision must map to the business vision and support the business value of investing in modernization. Along with technology, the future state should include recommendations about the people and process changes required to operate in this new architecture.
Timeline: Modernizations can be lengthy projects with many concurrently moving parts. A strong roadmap includes critical dates such as contract renewals, end of support, and/or end of life. It includes budget cycles for funding, and it maps critical hires such as short-term contractors, modernization specialists, and/or full-time developers/IT professionals. The roadmap also should include important business dates like acquisitions, major product launches, peak selling seasons, etc. All these factors can help shape your modernization priorities and urgency.
Capital: In addition to the investment allocation for the initiative, you also need to understand the capital outlay needed for resources—internal and external—required for success.
Determine the path forward
Now you can perform a gap analysis of the current and future states. The timeline and available capital will be key factors—the “how”—that inform your approach to modernization.
Another factor to consider is the relative effort of modernization. For example, rewriting an application from scratch is not only time-intensive from a greenfield development standpoint, but the effort to make it operational would include retraining users, rewriting documentation, re-tooling support, etc. Many hidden costs of rip-and-replace strategies that may be overlooked during the initial scoping will later become quite burdensome.
For very small, in-house applications with minimal business impact, simple migration tools may be all you need for the modernization. For very large, in-house applications, the strategy may be more complex and consist of several approaches, including:
Rip and Replace: replace with an off-the-shelf alternative
Lift and Shift: re-platform or re-host the entire legacy workload onto a virtual cloud environment
Rewrite: retire and invest in ground-up greenfield development
Re-architect: attempt to improve in place the underlying legacy application architecture into a more modern, service-based, web architecture.
Migrate: using automation, migrate “as-is” to a new target platform, preserving functionality and user experience
At this stage, talking with companies that specialize in modernizations is a wise idea. With the groundwork you’ve done, modernization experts should be able to give you a proposal for moving forward, a timeline, and a cost estimate for the modernization.
Start now
As Benjamin Franklin once said, “By failing to prepare, you are preparing to fail.” It’s never too early to begin the work necessary for a clear strategy to move away from your legacy applications.
At Synchrony Systems, we have over two decades of experience helping companies modernize their legacy, mission-critical applications in the most cost-effective and transparent way possible. Whether you are just starting to think about modernization or have an urgent need, we are happy to talk with you about your specific situation.
Tech debt usually carries a negative connotation. While it may sound like something to be ashamed of, in truth, every enterprise operates with some degree of tech debt. It’s really an indicator of success—you’ve grown so much, over such a long time that your technology could not keep up. Millions of lines of existing computing code undergird most enterprise operations, and sooner or later, “all code is technical debt.”
So tech debt is not inherently “bad” but it can certainly prevent enterprise businesses from achieving the agility required to maintain relevance in our evolving digital economy. As proprietary legacy systems continue to age, the modern technology stack is advancing at increasing speed. Newer platforms offer greater interoperability and help organizations leverage the full value of their business data through analytics and AI.
Technology-driven competitive pressures are building
Traditionally conservative industries, such as financial services and insurance, tend to carry a higher tech debt load. Banks and insurers rightly wish to avoid any mistakes with software systems that underpin their customers’ financial security.
Mission-critical systems are often architected on legacy platforms with proprietary codebases that expanded over multiple decades, making them difficult to replace or update. Eliminating tech debt comes with fear of significant business disruption. However, executives do recognize that customers demand a better customer experience from brands. Today, 96% of insurers believe digital ecosystems are making an impact on the industry.
Customers expect to be able to personalize the services they need. They crave a fully digital experience with 24/7/365 access to accounts, quotes, and information, as well as multiple channels of customer support. Enterprises need to employ digital, mobile, cloud, and IoT technologies to drive new value for customers. Laggards risk being outmaneuvered by innovative fintech and insurtech businesses using advanced technologies to differentiate themselves. Here are a few examples:
Many legacy platforms simply can’t support the types of new services that banks and insurers want to offer customers nor the new tools to empower employees. To fully leverage the value of big data and utilize advanced technologies, enterprises need a modern tech stack.
Unfortunately, many continue to try to bolt new technologies onto outdated platforms, with limited success. After studying the state of digital transformation in the banking and insurance sector, Forrester analysts concluded that innovations were largely being built on top of outdated technology and that risk-averse cultures slowed digital transformation and got in the way of efforts to learn how to monetize data and offer greater value to customers.
When surveyed by Capita and Citrix last year, 56% of CIOs admitted that legacy applications are delaying digital transformation for the entire organization, and 84% said an inability to roll out new services is affecting business competitiveness. When asked why enterprises don’t rid their legacy applications of tech debt, CIOs cited: The cost of re-architecting or transforming applications (68%), user disruption (43%), and lack of in-house skills (36%).
Executives may lack visibility into the true cost imposed on their organizations by tech debt in their legacy systems. Let’s look at how to quantify tech debt in dollars and cents, and then look at the bigger picture of business risk.
Assessing your tech debt: the math
When deciding when or if it is the right time to pay off tech debt, most organizations assess it in terms of the dollars required. Kelly Sutton described the math behind paying off tech debt. To quantify how much debt is currently carried by the organization, it is necessary to calculate the principal and interest:
The investment required to pay off the debt (programmer hours or contractor developers) can be thought of as the principal.
The cost of continuing business-as-usual by using engineering resources to bridge the debt on existing platforms can be thought of as the interest. This can be measured in terms of the number of incidents to resolve or the person-hours required.
With this way of quantifying the cost of tech debt, enterprises can compare the ongoing cost of the tech debt versus the one-time cost to fix it. This provides a framework for decision-making about which debts are worth paying off and how IT projects should be prioritized. But this assessment only captures the short-term (near current) condition of your tech debt. For a longer-term assessment, we have to expand the thought process to include the softer costs.
Calculating the true cost of tech debt: opportunities lost
Once you can perform the math of tech debt today, it’s time to think in bigger terms. After all, tech debt is not solely based on the cost of hampered organizational productivity today. The much larger cost may be found in how tech debt will constrain your business in the future.
To calculate the true cost of tech debt, we need to think in terms of risk. What current business opportunities could be jeopardized or even lost in the future due to excess tech debt? Consider these questions:
Will tech debt prevent your product teams from delivering new features, products, or services that customers demand?
Does tech debt obstruct your organization’s ability to work effectively and efficiently? For example, is your organization able to collect and visualize data, in real-time, from every global location for complete enterprise visibility?
Is tech debt limiting workforce recruiting and retention? For example, does a lack of support for cloud platforms prevent hiring remote employees? Does a convoluted codebase make it difficult to attract top IT developers?
Are there opportunities to partner with (or acquire) promising fintech or insurtech startups that cannot be explored because technology stacks are too disparate?
Is the organization already losing customers due to a stale/outdated customer experience? How quickly might that accelerate as new competitors arrive?
How might tech debt prevent full monetization of enterprise data?
In the larger competitive landscape, what does your organization stand to lose in both the near- and long-term? The long-term is more difficult to predict, because you do not yet know all of the opportunities that will arise in the future, given the rapid pace of technological change. But bank on this: If tech debt is already slowing your organization, or forcing you to pivot away from new opportunities, the “rising inflation on technical debt” will only compound the problem with time. Characterize the full risk profile of tech debt now, so the executive team can gain greater visibility into its true cost for decision-making purposes.
About Synchrony Systems
At Synchrony Systems, we help companies reduce tech debt by transforming legacy, in-house applications to modern technologies while preserving business-critical functionality. With our Modernization Lifecycle Platform, we provide an automated, reliable, and transparent modernization while ensuring 100% functional equivalency with no operational interruptions. And with our continuous upgrades, your in-house applications will never fall behind again.
Our business is the modernization of legacy applications, and we talk about it a lot. Recently, Kathy Bazinet, an IBM Software Technical Sales leader, reached out to us on Twitter and asked:
“I would be really interested in your definition of “legacy applications”. Are you referring to monolithic Java or to COBOL or even something else?”
We thought this was a great question and wanted to share our definition with a broader audience.
How we define legacy applications
You can have a monolithic application written in a modern programming language or environment. Adjectives like “monolithic” or “fat-client” describes how the application is architected. You could argue whether or not a monolithic architecture makes an application legacy.
To us, an application becomes a legacy when what is under the application “layer” — be it a software library or framework, a programming language, or a database — goes out of style or worse, is no longer supported.
Today applications can experience such fate rather quickly. For example, Angular/JS is a modern-day SPA framework from Google that is quite popular. But that technology is now obsolete and has been replaced by another version of that framework renamed to Angular (dropping the JS part). While similar in name, applications are developed quite differently with it. So, a “modern-day” web application developed using Angular/JS is now considered a legacy application.
You can consider a programming language such as PHP to be a legacy web development language as well. Any web applications built with PHP are arguable legacy. Therefore, it’s not only monolithic mainframe or fat-client desktop applications that are legacy. Anytime a software environment or language is no longer supported by its vendor or loses its following, all applications built with it turn into legacy.
Tech debt, therefore, is literally the “drag” that antiquated software platform imparts on its host applications. To modernize these applications, you must first modernize their underlying software platform on top of which they were developed. Once an application is on the modern platform, you are ready to modernize its architecture.
Do you have a modernization question for our team? Shoot us a quick message and we’ll get back in touch with you.
Thanks again to Kathy for the question and the opportunity to share our point of view!
Mission-critical IT applications that are built in-house have been in development for hundreds of person-years, with many dozens of engineers and testers responsible for their years of maintenance, which would translate to hundreds of millions of dollars. More often than not, the documentation is scarce and inadequate to effectively support and especially to maintain these systems. Yet the users of the system are very proficient and efficient in implementing it. They have developed their own custom shortcuts and tricks for getting their jobs done.
Rewrites or wholesale replacements of the mission-critical application inevitably leave the company with an entirely different system. In addition to the cost, time, and effort needed to replace a legacy system, an IT organization also would be required to retrain the end-users on the new system and replace all the manuals and documentation. This costs the company not only money but precious time.
Retraining the workforce is a big disruption for a business. This is why many modernizations are delayed until the situation turns dire—when the infrastructure will no longer support the system or there isn’t anyone left to maintain it.
But it doesn’t have to be this way.
What is UX equivalency?
What we mean by user experience (UX) equivalency is that the modernized system would remain recognizable to the end-user and would be 100% equivalent from a usability perspective. With today’s technology, we can take a hosted/mainframe or desktop system and recreate the exact same look, feel, and behavior in a browser.
Similarly, a Windows-based MDI-type GUI application that uses drag and drop, tables, spreadsheets, graphics, modal/modeless dialogs, etc., also can be modernized to work in the browser as an HTML5 Single Page Application (SPA) with equivalent GUI functionality, richness, and presentation semantics. And we can do this without any special browser plug-ins or any desktop deployments. When the user types in a URL, the usability and functionality of their system will remain equivalent inside the browser, with all the benefits of being in a modern programming language and platform.
What are the benefits of UX equivalency?
A pure technologist may argue against having the modernized application look and feel like the dated application, but the business benefits are far too great to ignore. These include:
No end-user retraining for internal, external, or even paying customers
No need to update support, knowledge bases, training manuals, or any other documentation
No need for a massive change management overhaul
No degradation in performance; preserves all built-in performance efficiencies developed by engineers over the years
No productivity loss; preserves all the known productivity shortcuts already developed by end-users
No production release delays; following user acceptance (UAT), a modernized application is ready to go live
Only a modernization that guarantees UX equivalency can ensure no operational disruptions to the business. UX equivalency really focuses on eliminating the hidden costs associated with modernizations.
Hidden costs savings of UX equivalency
These hidden costs of modernizations due to a new UX can be quite staggering, especially if it necessitates retraining a sizable workforce or one that is dispersed worldwide. To illustrate the impact, here’s an example of an enterprise insurance company.
This insurance company had a propriety system that handled all their rating and quoting. Customers would call the company to obtain quotes on their automobile, homeowners, or other insurance, and the agents would enter this information into the system to supply the quotes. In addition, the company also relied on a distribution channel of third-party agents to help drive new business. These third-party agents typically were employed by small insurance companies that also used the system to provide quotes to prospective customers.
In the case of a new UX, this company would need to retrain all of its 10,000 employees on the new system, as well as their external workforce, a network of 20,000 independent insurance agents. Once the company began adding these additional costs, the modernization would become both expensive and disruptive. While this is feasible, the opportunity costs are quite high and the impact on the end-user experience could be overwhelming.
A modernization approach that ensures 100% UX equivalency would prevent the pitfalls described above and allow the entire workforce of 30,000 agents to continue their day-to-day operations with no interruption and little to no impact on the overall business.
UX equivalency helps the developers, too
UX equivalency also is important for the developers who update, modify, and support the modernized application. The learning curve of a modernization application would be limited to only the adoption of a new programming language. Structurally, the source code would remain the same. Any test automation scenarios built over the years would remain unchanged, and the engineers and testers would be able to use them on the target platform. Therefore, developers would be able to smoothly transition to the new platform and apply their domain expertise to further enhance and maintain the system, with minimal impact. Once the modernized application goes live, both the end-users and the developers would remain 100% productive in running and maintaining the modernized system.
Synchrony Systems guarantees 100% UX equivalency in modernizations
Synchrony understands that modernizing a large and complex legacy application can be a major undertaking, fraught with high risk and expense. It doesn’t have to be this way. Our approach and methodology, backed by the power of MLP, accelerate the modernization time-to-value and guarantees functional and UX equivalency. We balance the overall speed, cost, quality, and risk while creating a unified experience, in order to address the inherent complexity of a modernization process in a frictionless and predictable way.
Contact us to learn more about how we can help you maintain 100% UX equivalency on your modernization initiative. Your users will thank you!
