Retiring Legacy Applications – Logically January 17, 2012
Posted by Chuck Musciano in Technology.add a comment
A recent article on eliminating legacy applications prompted a bit of back-and-forth on Twitter, centered around why we all do such a bad job of retiring old systems. Such a conversation requires more than a few tweets, however. Why is it so hard to kill off old systems?
We all have no problem listing the theoretical reasons why an application should be retired:
- It no longer meets the users’ needs
- It becomes too costly to maintain
- Better technology is readily available
- Integration with other, newer applications is getting more difficult
Yet we all have applications that no longer meet user needs, are too costly too maintain, could be replaced with better technology, and barely integrate with our other systems. Why is it so hard to kill off old applications?
One word: metrics. Very few CIOs develop, collect, manage, and analyze the metrics to prove that an application is past its prime. Without hard data to document usability issues, cost concerns, or replacement expense, retiring an application shifts from being a matter of fact to a matter of opinion. When opinions start driving the discussion, it becomes almost impossible to kill off anything in IT.
While some things can be difficult to fully measure (what is “better technology?”) other things can be easily tracked to drive retirement decisions. In particular, usability metrics can give great insight into how users use a system, which features matter, and which features can be abandoned.
The right time to think about retiring an application is the day you begin to develop or acquire it. If you engineer usability metrics into a system, that data will be invaluable in five years when you may need to pull the plug.
Imagine a system with a few thousand reports. Imagine being tasked with eliminating the unnecessary reports. Imagine doing that with no empirical data. Imagine having to instead rely on user conjecture and anecdotal data on which reports are the “important ones.” Users are notoriously inaccurate in deciding these things; perception and reality are very different animals.
I once had to retire an old mainframe system which several users insisted they used on a regular basis. We saw no evidence of this, but they were adamant. Finally, we simply locked their userids to see what would happen.
The result? No complaints. It turns out they were using a completely different system that they thought was the mainframe. When we pointed this out, they happily allowed us to proceed with the retirement.
A bit of usage history would have been quite helpful. But no one ever instrumented the system to track such things, so we were left with drastic measures to move forward.
The next time you build a system, instrument the code to record who does what when. Disk is cheap; collect the data and see what users are actually doing in your applications. During the life of the application, such data will help tune the app and allow you to focus on what users really need. As the app approaches its “golden years,” you’ll know when usage drops to the point that you can safely pull the plug. As always, a little planning now saves a lot of pain and heartache later.
Measuring Metrics January 27, 2010
Posted by Chuck Musciano in Leadership, Technology.4 comments
It’s a good bet that most people saw all or part of the Super Bowl, either at home or at a Super Bowl party. Suppose, as the game begins, the cable feed goes out and the television goes dark. Amid the howls of protest of those watching, you grab the phone and frantically dial your cable provider. When you finally reach a real person to complain of the interruption, they provide this explanation:
We’re sorry for the interruption, but our records show that this is our first outage in your area in more than two months. Even though we project that the outage will last for at least four hours, that still means that we provided service 99.72% of the time. This easily exceeds our 99.5% target metric for excellent service! We appreciate your business and thank you for your patience as we work to restore your service. Thanks for calling!
Happy now? Of course not. Yet many folks in IT hide behind metrics in a similar fashion.
It is said that anything you measure will improve. That provides a strong incentive to measure system availability, since we’d all like to hit that elusive goal of 100% uptime. But there is a difference between using those metrics to improve our performance and using those metrics to improve our public relations.
Uptime tracking coupled with root cause analysis will help you find and fix many tiny problems that may exist in your environment. Most mature IT shops have long ago figured out how to run their systems without catastrophic failure. We can all hit availability of about 98 or 99 percent on a regular basis. Getting much higher than that, however, involves ferreting out deep issues that may only surface under unusual circumstances. It takes discipline and focus to get there, and metrics can really help.
Metrics should never be used as a defense. When users are affected by an outage, the last thing they want to hear is how well you’ve been doing prior to the problem. It doesn’t matter, and you’re only annoying people that are already upset.
Similarly, metrics should never be used to tell the world what a great job you are doing. When things are running fine, announcing that they are fine just makes you look boastful. Most users just want IT to work, and they don’t want to think about it beyond that. Building on our cable analogy, how would you like the cable company to call once a month to tell you that the service is running just fine?
From the user’s perspective, availability is measured as a binary value: yes or no. There is no average, there is no track record, there is no target goal. You either provide your service or you don’t. Metrics matter internally so that we can improve our service. But they have little bearing on user opinion and can actually do more harm than good. Use them wisely.
Living In Olden Days January 22, 2010
Posted by Chuck Musciano in Technology.add a comment
Recently, a friend was kind enough to share with me an unusual book: the 1924 Ford Model T parts catalog. This beautiful book includes detailed drawings of most major parts, along with descriptions and pricing for every component of a Model T.
For each part, the catalog includes part numbers and the appropriate model year, as you might expect. But it also includes an odd item: a “code word.” What on earth is a code word, and why would you need one for car parts?
It turns out that back in 1924, people would often send their orders to Ford via telegram, a very early precursor to shopping on the web. Given that you paid by the word to send a telegram and that errors could be costly, you could specify your part using its code word instead of its part number and description.
Thus, if you were in need of a crankcase lower cover (part number 3101) you would send the code word “Closure.” This ensured that you would not wind up with a complete crankcase (part 3100), whose code word was “Closet.” That’s a big difference, since a crankcase lower cover would run you $0.35 while the whole crankcase would set you back $11.00.
There were also code words for shipping, so that the terse message “Closure Topersteen” would order one crankcase lower cover and ship it to you via standard freight. If you want to upgrade to express shipping, you’d use “Closure Toperig” instead.
We live in an age of glorious technology, which leads us to believe that previous eras were backwards and hopeless. In fact, people have always been clever and creative; they simply had different tools at their disposal. Using those tools, they crafted the best possible technical world, one that seemed glorious and amazing compared to previous times. Imagine how they lived in the olden days, when they ordered car parts by mail and had to wait three extra days as a result! Code words and telegrams were an amazing improvement.
As we struggle to build, deploy, and exploit all the new technology that comes our way, both personally and professionally, we would do well to remember that we will be seen as living in a hopelessly backward time. “Imagine,” they will say, “how people lived with such primitive tools. They must have been miserable!”
Not at all. We are always living in the best of all possible worlds, in the best of all possible times. And with luck, determination, and perseverance, we’ll continue to make it better and better.
Pick Your Bridge January 18, 2010
Posted by Chuck Musciano in Leadership, Technology.4 comments
Regular readers know that I have some strong concerns about cloud computing, especially in the arena of security. I’ve enjoyed a number of vigorous debates with both vendors and fellow CIOs regarding their comfort level with cloud-based services. Personally, I’m comfortable moving small, non-material business processes to the cloud, but will continue to manage my core business applications in my own data center. Other CIOs are at different points on this spectrum, with valid reasons for their decisions.
Invariably, many of these discussions reach a point where a proponent of cloud stuff will point out that some very large companies have made big commitments to cloud technology, moving some or all of their infrastructure and systems to the cloud. The implication, of course, is that if these big companies are comfortable with the cloud, I should be, too. As my mother would be quick to point out, if these companies were to jump off a bridge, should I jump off too?
There is a comfort in following the paths of others, but there is no guarantee of success. The only thing that matters in a decision like this is what is important to your company. Other companies are making decisions based on their own criteria; they may or may not match yours. Simply assuming that large companies are somehow smarter than you may not be a wise decision.
In the classic Simpson’s episode Krusty Gets Busted, Bart’s idol, Krusty the Clown, is accused of robbing the local Kwik-E-Mart. The entire town of Springfield rises up in opposition to Krusty. Bart is horrified to find that even his father Homer has turned against Krusty. Bart complains, “Dad, you’re giving in to mob mentality!” To which Homer replies, “No I’m not, I’m hopping on the bandwagon! Now get with the winning team!” In the end, of course, Krusty is exonerated when it is discovered that his evil sidekick, Sideshow Bob, was the real culprit.
So many technology decisions seem to become a choice between mob mentality and joining the bandwagon. In reality, what others do should not factor into the decisions we make for ourselves and our companies. We need to make a decision based on the unique merits of the case.
That said, critical market mass should be factored into a software or system decision, since it affects long-term maintenance and support pricing. Nonetheless, simply assuming that something is right because others are doing it is a poor decision process.
CIOs have to pick their way through these minefields everyday. Where will you find yourself today? As part of the mob, happily on the bandwagon, or following someone off a bridge? What would Bart (or your Mom) think?
Losing Words January 13, 2010
Posted by Chuck Musciano in Random Musings, Technology.4 comments
In their 1972 hit Sylvia’s Mother, pop group Dr. Hook tells the story of a jilted lover trying to reach his ex-girlfriend, only to be stopped by her mother. As he pleads his case on the phone, the memorable hook of the song tells how the operator kept breaking in, demanding “forty cents more, for the next three minutes.”
As I listened to this song recently, it occurred to me that a younger audience might be puzzled by these unusual lyrics. What is an “operator?” Why would they be demanding money? Forty cents for three minutes? How would you pay them? Technology has marched on, leaving language (and old pop hits) behind.
The operator, of course, was a human who helped complete calls. Before cell phones, people used pay phones to make calls away from home, ponying up spare change to stay on the line. While the first three minutes might run you a dime (and later, a quarter), subsequent blocks of three minutes could cost a lot more. To stay on the line, you fed change into the phone.
To the modern ear, this sounds no different from instructions on how to tan your own leather or fashion a thatch roof. The concepts are so foreign that the words barely make sense. Yet this song describes things that were commonplace just thirty years ago!
Much of our language is derived from current technology, forming a common cultural base. As the rate of technological change increases, language cannot keep up, stranding all sorts of shared phrases. While amusing, I think it also creates an ever-wider disconnect between generations, making communication more difficult.
Even in the past ten years, many ideas have simply disappeared. Back last century, people needed to rewind things. Now, no modern device requires rewinding. We’re at the point where nothing spins to make music; how would a 50s DJ describe his world if unable to “spin stacks of wax?” People will soon wonder why we “dial” phones. I suspect that the number of US citizens that have actually operated a dial telephone is rapidly declining.
In a similar fashion, acronyms continue to shrink, encoding more information in shorter sounds. During World War II, acronyms started out as concatenated syllables from related words, pronounced as a single word. “CINCPAC” is the Commander-In-Chief of the Pacific, “CONUS” is the Continental US, and so forth.
By the 1960s, acronyms became individual letters strung together to make words (NASA, ASCII, etc). This happy state has existed for a while, and no product or process worth its salt is without a clever acronym that forms a related word.
Now we’ve started pronouncing the acronyms for shorthand abbreviations, creating new words. I’ve actually heard people say “lol” and “brb” in running conversation, without a hint of sarcasm. This is different from traditional acronyms, which typically represent nouns. Now we are collapsing and pronouncing verb phrases and even whole short sentences. This cannot be good for general communication.
What to do? Not much, I’m afraid. In between more-frequent trips to Urban Dictionary, I’ll go back to listening to Dr. Hook. They had another hit song that involved getting their picture on the cover of a magazine. As I understand it, a “magazine” is like an entire web site, printed and bound as a sequence of “pages.” The “cover” is the first page, and often had a photo on it. Imagine!
