Legacy systems are often misunderstood by both executives and technology lovers. The views are often stark, with vehement opinions expressed that pivot around the voice being heard and who has been around long enough to know why it was purchased, built, or bought in the first place. Some will scream “it’s dated,” that “we can’t maintain it,” or “it has to go” -- while others bark that “our business is tuned to it,” that “it meets our compliance needs,” or “there is nothing in the market that can do exactly what this does!” Over time, other dependencies grow attached to these systems, which make change even harder to visualize and wrap your arms around. This is particularly true in 5AM’s fields of choice, where rapid change is the norm across technology, science, and medicine, adding to the pressure cooker where those advances appear to be within one’s grasp but remain elusive. This is true even when paper is the legacy system--and it often is. So how can you move forward and not be trapped when your organization begins to see the end of life for a legacy system?
Up at 5AM: The 5AM Solutions Blog
Tags: software development, problem solving, Legacy Systems, adapting to change
For the past 6+ years, since I
escaped was sent off lovingly with a diploma from college, I have been working on contracts that have all dealt with improving workflows and systems through technology. This has provided me with opportunity for many musings on the process of changing these workflows and how to make sure you can make a system that not only does what it’s supposed to, but does it better.
First and foremost, you’ve got to keep in mind the problem that has to be solved. Often you won’t be solving new problems right off the bat, but it will begin with translating a workflow from one process to another. In most cases this will mean you will be taking a paper process that has been in place for years (even decades) and replacing it with a digital process, though there are occasions where this might just be moving from an older clunky digital system to a new fancy state of the art system. Henry Ford is often quoted as saying, (which may not actually be true) "If I had asked people what they wanted, they would have said faster horses.” We can use this in how we think about transitioning from old workflows to new ones as well. Think about if Ford’s car wasn’t the Model T as we know it, but was a flying car instead. Users would still be able to travel much faster than they could on horse and could even take things (or more people) with them, but the result is so different that people who were used to horses wouldn’t know what to do with it. We need to be conscious of these same changes as we change workflows, as we want to innovate and build a more efficient version of their current workflow but we don’t want to overwhelm the users too much. We want to change how they work without too many surprises.
Why are we doing this project if not to improve? The worst feeling in the world is to know that you are wasting your time working on something that isn’t going to be used. So while you are working towards change, you need to keep in mind the major hassles that users go through with the current process. How can you make their lives easier and make the user WANT to use your new application over the way they’ve been doing it for years? Look at how they do things and how things could be better. If the user constantly has to be going to their computer or calling someone up to find the same information over and over again, think about how you can link that system into yours. Does the user have to go through the hassle of gathering up documents and mailing them off and hoping they get there in time (or at all)? How about figuring out a way for them to be able to digitally submit all of that to the recipient? What also needs to be kept in mind is that the system can’t have steps that prove to be a greater hassle as compared to how much easier it is to use as this might drive users away. You don’t want the user to feel like there is greater relative burden on them now that they are in a system that they don’t encounter on paper. The first iteration of any system is to entice and bring users into the fold of the application and to start convincing them that your system gives them more benefits vs. sticking with the old way, while not introducing new hassles.
Evolution occurs over time...
Although not biological by definition, applications are growing organisms in their own right. They change and evolve as time progresses absorbing new capabilities and losing some of now useless features that were moved over from the old processes / systems it was deemed to replace. This is an expectation that needs to be accepted from the very beginning, making sure that the initial scope is actually doable and the expected features match those of the current process. As the application is built and once it has been released, you will receive user feedback from those who actually will be using the application. During this time you find out even more about what direction the application will begin to grow as users provide feedback about what is good and what isn’t. This allows the application to adjust to its environment becoming stronger and better equipped to handle the tasks at hand.
Learn from the Phoenix...
The application you are working on now will die. It might not be soon and you might not have anything to do with it when it does, but you might wind up working on a different application to replace an existing application. In these circumstances we must remember the Phoenix in that from the ashes of the existing application a new one will be born. An application tends to die for a few different reasons:
It is no longer useful as the processes it was meant to cover no longer exist.
It is outdated, or the technology used in it is no longer relevant and it is more beneficial to rewrite from scratch than put a new coat of paint on the old one.
It has been replaced by something different.
In the second two situations the need still exists for the project and likely a lot of the business rules and knowledge about the application can be reused. The application might be completely different but the work and knowledge of everything can be used as a foundation to build that new application to replace the old. In the first situation, it’s hard to defeat irrelevancy so the application and its functionality won’t be replaced by anything. It is likely that the pieces of the old application could be re-purposed to other closely related areas. In any situation, keeping the application evolving with the needs and the technology of the times can maximize the duration that the application will hold its existence and the longer the application is useful the most worthwhile the application was to build in the first place. But in the end, don’t we all just want what we build to be useful?
-Adam Swift, 5AM Solutions
Tags: agile development, software development, problem solving, workflows
As engineers, scientists, consultants, etc. we are frequently presented with complex problems in our daily lives. In fact, this is sometimes the only purpose of our work lives--to solve these problems for ourselves (and others) and probably more often than not we will sit down and think about the solution ourselves or perhaps discuss the problem with colleagues to bat around ideas for a solution. Perhaps when we get the problem refined to a particularly low level and we still don’t have a clear answer we might try researching, even asking around on the internet to find other people who might have encountered the same problem (all too often encountering this problem). But how often do we just go out to listen and learn from people in similar domains to discover things we may not encounter in our day to day life, but might translate to help solve problems we might face down the road?
Tags: problem solving, learning styles, application developers, FlipBoard, Zite