Those who ignore history…

Let’s dive into the good stuff — the first of three posts dedicated to legacy modernization best practices.  Credit for this insight goes to Larry Fitzpatrick + Stuart Tweed (our Legacy Modernization practice leader currently supporting modernization efforts at the Department of Homeland Security’s Customs & Border Protection).

1. Learn from the past 
Whether client or service provider, do the homework. Learn about the history of the project:

  • Why was the application created?
  • What led to its success?
  • What drove modifications? 
  • Most importantly, what other efforts preceded this one to rebuild or replace the application? 

Past efforts will have produced valuable artifacts that you can leverage, or can illustrate pitfalls and bad choices. Most important of all, the history will help you learn the stakeholder terrain. Be aware of who will ally and who will repel change, and why, and who has the most knowledge useful to a replacement activity.

2. Re-evaluate the business goals 
Know what problem you are solving and re-validate the business case and get clarity around the business goals. This is a corollary to the carpenter’s dictum: measure twice, cut once. There are many valid reasons to replace a legacy system and some not so good ones. Frequently, the perceived urgency to replace the application or the money to be saved is dramatically overstated. Oft heard is “I won’t be able to find these skills in a few years.” A small investment in salary and training to attract fresh skill is a drop in the bucket compared to the cost to replace a system. You really must answer the question “Why now?” Never underestimate our ability to preserve the status quo.

3. Don’t underestimate the complexity 
Eager to proceed, project managers or engineers often mistakenly assume equivalence between software metrics from old and new systems. Their sense of metrics has been calibrated against systems they have recently created. Thus, they think they know what 100 KLOCS, 500 KLOCS, and 1,000 KLOCS feels like. But they’re wrong – a legacy KLOC and a new-code KLOC are not the same. Old applications have almost always lost architectural integrity, have had man-decades of enhancements that address increasingly complicated exceptions to business process. Logic becomes so complicated that it in critical places it’s impossible to hold even small fragments of code in ones head. Underestimation puts the plan at risk, as well as, all the expectation management that goes along with the plan. Underestimation is sure to alienate the current users and support staff. They will think (rightly) that you are so obviously ignorant that you will fail, so why should they waste their time to help you? You will need their support.


Posted on Friday, October 30th, 2009 at 7:46 am and is filed under Legacy Modernization.

« Previous Entries

By: Computech

« — »


A history lesson

Yesterday, we started to talk about the challenges organizations face as their mission critical custom applications morph into legacy systems.  Today, we’re going to take a step back and share something of a history lesson in terms of modernizing these vital applications.

“A Contractor’s Fable”
Larry Fitzpatrick

Like so many good stories, the legacy modernization one draws inspiration from historic fact. For many years, large systems integrators framed a modernization effort in technology terms. After all, they reasoned, the required replacement stemmed from obsolete technology. Consider the support costs for the underlying commercial platforms: exorbitant they extolled. And your code: far too complicated to modify for legitimate business changes. You need to manage your risk! As production outages hamstrung the business, old technologies precipitated calls — both internal and from these vendors — for radical change to this proverbial house of cards.

To begin the painful legacy modernization cycle comes with a simple declaration: if the system is large, the solution approach must be large, too! After decades of change and growth of the business, lines of code numbered in the millions, transactions processed each day may exceed tens of thousands, budget line items for support are a noticeable percentage of the business expense, and because most of the business staff interact with the application almost every day, the MCCA has become a tolerated way of life. For very large solutions there is only one answer – a large contract with teeth, awarded to one of the big boys, a integrator with the initials sure to appease risk managers and lawyers alike. After all, who else can staff the hordes of programmers required for this massive project?

Who else has the experience solving these problems (they run lots of these applications every day), who else will be so invested in the outcome that failure isn’t an option? Because the modernization activity is a technology problem, the solution can be isolated from the day-to-day of the business. The large vendor stands up a new team skilled in the new technologies that form the target architecture. Because this project is so big and will take a while, vendor and client agree to add lots of features during the replacement. Additional staff is required. Finally, a contract mechanism is created to ensure that the new system does what the old system does – requirements documents. The vendor starts hiring immediately and builds a team ready to work together for the first time. The legacy team isn’t needed for this activity (or even consulted); after all, they are the ones who let the existing system get into such a state! The project managers build glorious schedules with infinite detail that show the first release just three years away. Programming begins. Exuberance dominates the ethos as the excitement of starting a new project infects everyone.

But as the years grind on and the deadline for the first release approaches, doubt emerges. There has been no sighting of working code. Or at least anything that behaves like the existing system. Eventually the deadline looms without a prayer of a delivery and the obvious cannot be hidden anymore. The date needs to move. But, it’s just a matter of planning. We need more planning. Project managers are replaced and new, better ones arrive. You can tell where this ends. The project was framed incorrectly, a number of starting assumptions weren’t validated, a number of clues along the journey were missed, and expectations are now wildly out of whack. No late fourth quarter drive can rescue this campaign.


Posted on Thursday, October 29th, 2009 at 7:53 am and is filed under Legacy Modernization.

« Previous Entries

By: Computech

« — »


Describing your mission critical custom application as an albatross?

As technology continues to evolve and change the way organizations operate, an even greater number of mission critical custom applications (MCCAs) now form the backbone of most businesses and government agencies. Unfortunately, trying to manage these “made-to-order” applications pose a significant challenge to many in technical leadership positions. Business operations may be severely compromised – or even cease altogether – should even one MCCA fail.

Compounding day-to-day maintenance challenges are the cumulative effects borne of necessary enhancements to a MCCA, followed by enhancements to those enhancements. Add in the pressure to contain cost, and most would agree that incremental improvements to a MCCA simply wring out discipline from the constant stream of modifications. In most cases, as MCCAs grow, organizations do not sufficiently maintain documentation or update requirements; over the years, test cases grow stale, and many needed structural changes are avoided – leading to ever more convoluted workarounds.

This begets a vicious cycle: underlying technology ages, the code base grows, and design integrity fades. Typically, the original development team has been replaced several times over, and with each turn, core knowledge of the application recedes from the support team. Alas, the “great circle of life” applies to software: what started as inspiration, grew exuberantly, and matured gracefully into a showpiece of the business eventually becomes a victim of its own success. By its very greatness, the inexorable decay into life-support for an MCCA is cause for grave concern as the applications becomes a legacy system.

Eventually, this legacy MCCA becomes an albatross; business cannot live without it, but increasingly has difficulty living with it. Whether escalating support costs, an inability to effect change, breakage, or all of the above, most executives realize there comes a time to replace the MCCA. In the most common scenario, armies of well-intentioned consultants labor for years and come up empty. Managers age prematurely, and careers are irrevocably damaged.

Still, most failed replacements never make the news. Too many people are invested in a positive outcome and simply cannot accept or afford failure. So, some shred of credibility is delivered, the project is declared a limited success – with the supporting details quickly buried. Yet, the business has not solved its legacy MCCA problem. As the memory fades, another replacement effort begins; in our experience, this failure cycle repeats itself several times with limited return. How, than, to avoid such pitfalls? Over the next few days, we’ll post some of the lessons we’ve learned to help break this painful legacy modernization cycle.

(posted by Larry Fitzpatrick)


Posted on Wednesday, October 28th, 2009 at 1:05 pm and is filed under Legacy Modernization.

« Previous Entries

By: Computech

« —


Come one, come all

Concomitantly: (n) one that occurs or exists concurrently with another

Welcome to Concomitantly, an ideas market delivered by various Computech staff. With this first post, we launch our newest blog, one conceived as a place to share myriad thoughts on business and technology. We hope this quickly becomes a bulletin board for broaching new ideas and bringing forward information on technology-related trends. Please enjoy!

(Posted by Al Dominick)


Posted on Wednesday, October 28th, 2009 at 11:00 am and is filed under News.

« Previous Entries

By: Computech

« — »


Concomitantly (an “ideas market” by Computech)

Concomitantly, an ideas market delivered by various Computech staff, launched today. We conceived our newest blog as a place to share myriad thoughts on business and technology. We hope this quickly becomes an on-line bulletin board for broaching new ideas and bringing forward information on technology-related trends. For example, take a look at what we’re thinking when it comes to legacy modernization…


Posted on Wednesday, October 28th, 2009 at 10:45 am and is filed under News.

« Previous Entries

By: Computech

« — »