“To streamline, or not to streamline, that is the Question”

According to the Merriam-Webster dictionary:

streamline – transitive verb

1: to design or construct with a streamline

2: to bring up to date: MODERNIZE

3a: to put in order: organize

3b: to make simpler or more efficient <a system that streamlines the process>

I’m not afraid to say that a very high percentage of people can quickly spot areas of improvement. Think about it for a minute and try to remember when was the last time you heard a comment like this: “I wonder why they decided not to put more cars to this train” or “Who was the ‘genius’ that came up with the idea of putting this stupid little voice in the elevator?”, or “Are you kidding me? A four year old could have done this job better”. I hear comments like these during my commute, at lineups, on the news, etc; it becomes clear that pretty much everybody has a natural ability to recognize potential for improvement or to fiercely criticize unnecessary made ‘improvements’.

In software development scenarios and, more specifically, in the legacy modernization arena, this becomes the daily bread and butter of teams that have to deal with modernizing old computer systems. I won’t speak for others (although I’ve heard them loud and clear… let me rephrase that: I hear them. Everyday.). I’ll speak just for myself: When I’m comfortably sitting and watching a client’s presentation of a system we’re about to embark on modernizing and how things are done in it, a frenzy of streamlining ideas come fast and furious to mind. It’s almost as if there was an entire new universe of opportunities for improvement. And this is only taking the notes at a preliminary session. Once the project begins and throughout the various phases of the engagement, more opportunities start to surface from all fronts: User interface, data model, batch and business processes, you name it. But we have to be extremely careful. Despite the natural human tendency of wanting to make these inherent to modernization decisions, we have to control ourselves and keep in mind that this particular screen, table, or process, if changed, even if it is for the better, may end up being for worse, much worse. Trust me on this. There could be way too many negative implications and, before shifting the gear to full streamlining mode, a thorough, constant analysis needs to be made by all team members and come to the very difficult conclusion of which ones can and will be implemented and which ones won’t. Not an easy task. Our clients usually complain and they have a valid argument: How come you can’t normalize this table/screen/process? Aren’t you supposed to be modernizing our entire system? We then have to explain to them the reasons that support the decision.

Sometimes these are logical decisions; very easy to back up. For example, one of our clients had at least a dozen search screens that did exactly the same thing for different departments. I guess during the twenty -something year stretch the system lived for, programmers simply used the good old copy and paste technique and tweaked here and there to accommodate their users’ needs at the time. When the new system was delivered, they ended up with only two new and improved search screens for the two largest departments with embedded logic and security that satisfied everybody’s needs. Result: lots of present and future happiness. The developers who will maintain two screens instead of two dozens will appreciate this.

Now, what happens when some of those items, in both the client’s and our own (as solution providers) wish list, don’t make the cut? I could answer this question in different diplomatic ways but in reality the answer is FRUSTRATION. Oh yes, big time. It may have been determined that moving forward would’ve had such an impact that it could be too costly in other areas. One of the trickiest areas is data migration. The rule of thumb in legacy modernization is that you shouldn’t go too far streamlining your data model; otherwise you’ll lose traceability to the present case scenario and that is too risky. So if we have a screen or a process that is screaming for streamlining but it would mean that drastic and complex data model changes are required… How do we deal with the old data that has to come across to its new home? It can’t be just tossed away, right?

But data migration is not the only difficult area. The standard architecture poses another challenge for streamlining. The requirement may be something that simply doesn’t exist in the menu. It can be added, but again, what’s the impact going to be like? Sometimes, we have to say no, unless there is room and willingness to accommodate the impact to the project’s budget and schedule. The good news is that this is a temporary no. By modernizing an entire system, it is a given that it will be strongly enabled for future changes, more streamlining, faster development time, and happier stakeholders.

- Alberto Rodriguez

What is a legacy system, really?

I was working on a post defining legacy modernization when I realized that, in order to describe modernization, I first need to describe what a legacy system is. That might seem like a simple thing, but, from the view of modernization, a legacy system something quite different.

To us, a legacy system is a working system. It’s a system that has evolved over the years due to changing needs. People tend to complain about its limitations and problems (with good reason). But behind that is a system that’s at the heart of an organization. A system that the organization depends on daily.

It’s a legacy system, not a software program. According to Oxford, system is defined as a set of connected things or parts forming a complex whole. A legacy system consists of these parts:

1. A set of people, reacting to events, performing tasks in a logical manner in order to reach an acceptable end result (Users performing Process)
2. Software, providing access to information to the users and enforcing some business logic (Code)
3. Stored information, representing the results of the work performed by the users (Data)

Most legacy systems are also very complex systems. A typical legacy system consists of 2M or more lines of code. Each line of code tells the CPU where to go, what to look at and what to do. Printed out, a system this size would consist of 30,000 pages of detailed instructions. Not only that, but this 2M lines of code is surrounded by a set of human beings trying to wrestle with the differences between the literal logic of the system and the fuzzy real world.

Here’s the kicker. These three parts (Users/Code/Data) exist in an interdependent relationship. This means that the only way to understand the system is to look at it holistically. You cannot understand the purpose or value of a piece of code without understanding the context of its use (Users performing Process) and the information structure it executes against (Data).

All too often when we’re asked to look at a legacy system, we’re only asked to look at the code. To me this is like asking a doctor to cure a crippled leg by only looking a the crutch. It often takes some wrestling to get them to let us analyze all three layers of a legacy system.

- Christian Cotichini

Is “Business Centricity” a buzzword yet?

No, at least not yet. Google returned about 430 instances, many relating to a GE product. What I’m getting at is the shift that information technology vendors need to make in order to serve the mission of their customers, whatever that mission looks like. Gone are the days when monolithic IT approaches were brought into unsuspecting organizations under the guise of “re-engineering”, a trend that began when I was a BCIT neophyte studying Operations Management in the early 1980s. We laughingly called ourselves the “Op-Man Axemen”, not realizing that the Re-engineering movement would actually put a lot of people out of work in favor of automation solutions.

These automation solutions now form the fabric of what is called “legacy” systems today. Characterized by stovepipe and (often) client/server architecture, arcane and/or obsolete code (except COBOL still soldiers on), and green screen terminals, legacy systems represent a crumbling foundation upon which many medium and large-scale enterprise and government operations are built. It is no wonder that the term “legacy modernization” is becoming an increasingly-heard siren call.

The market has, of course, responded with a flood of out-of-the-box “solutions” for these old software systems, mostly in the flavor of technology fixes that leaves the code base as-is but connected to the web, or converted into a modern language, resulting essentially in a GIGO* situation. Tools-only approaches still ignore the business, and are therefore the antithesis of “Business Centricity”.

At a provincial government Department of Motor Vehicles (DMV) modernization project we recently completed, the story was much more than dollars saved (~$280,000 per month), screens reduced (4,100 down to 650), reduction of code base (2.4m LOC of Natural to 250K LOC of Java) and elimination of batches. These are just the IT and brute cost metrics. The real story lies in the significant streamlining of business operations that result in lower costs and improvements in productivity, customer service, security and business intelligence, just to name a few.

Massive hierarchical menus were reduced to attractive web-based UIs with drop-down menus. The entire system now is entity-based, around the driver, so any piece of information entered, such as a license plate, ticket number, etc. automatically locates the driver and exposes all of the relevant information about that individual. Data is now shared with the (also modernized) Vital Statistics system so birth certificates, marriage/divorce certificates, etc. can all be accessed directly from the driver. Taxes can be calculated at the time of a transaction, such as a vehicle purchase, rather than shuffled off to a tax group for later deciphering. You get the picture. These are benefits above and beyond the computer system operating costs, and they provide tangible ROI for many years to come.

We have found that the actual modernization of the application comes at the end of the process. It must be front-ended by careful consultation with business stakeholders, IT stakeholders and C-level executives. In order to serve the business needs for agility and competitive advantage, legacy replacement strategies need to grow from a business-centric approach.

Perhaps someday we’ll see Business-centric Modernization, or BCM. Just what we need. Another technology industry abbreviation to kick around.

- Chris Dollard

* Garbage In, Garbage Out

Modernizing Elevators

The building maintenance team of our office building has been modernizing our elevators over the last couple of months. Things have not gone well: the new elevators are slower than the old ones, the selected floors deselect at random and on occasion the elevator decides to show you every floor, just in case.

The worst part of the modernization is a computerized, female, voice which announces each floor. A new, futuristic, addition nobody needs, seemingly at the expense of core functionality. It loudly and consistently confronts all of its disgruntled users, by proclaiming phrases such as: ‘You are on the 18th floor’. Although I wanted to go to the 17th. Where I am late for a meeting.

IT Legacy modernization projects are the same: no organization will ever start a modernization project which just replaces existing functionality, and because of that, the ones that will fail, will spend all of their energy on snazzy technologies or new functionalities.

And when that system is turned on and the daily accounting cycle is a couple of digits off, the user will not care that the brand-new report with the wrong numbers has a glossy shine and accessible through the company intranet, it will probably only make it worse.

 

- Mik Lernout