Got Legacy?

We’re hiring for the following positions:

Technical Writer: We’re looking for someone who can refresh our technical documents while keeping it simple. If this sounds like you, check out the requirements and application information on our career website.

Education Manager: if you have experience in corporate education and training, take a look at our job description for an education manager.

Share on Facebook

I was simply looking for a catchy title for this post. The devil in this case would be: Change. And there is a type of change that we, the deliverers at MAKE, don’t particularly like too much of during modernization projects. But that is a different subject. Now that I have your attention, here I go:

Daily Change

As humans, we face change in many forms during our lives. As I was drafting this I realized that change is very much omnipresent. It’s hard to come up with a compact list of things that we change at some point; and I’m referring to the changes we consciously decide upon, not the inherent or consequential ones. For instance, in our lifetime we will eventually decide to change (or not): Image (hair, piercings, tattoos, dress styles, etc), habits (hygiene, punctuality, nutrition, etc), religious beliefs (or non-religious for that matter), schools, friends, partners, spouses, careers, jobs, homes, cities, countries, nationalities, technologies, and so on. What drives our decisions to change? Is it only our level of comfort? To what degree? Is it the desire to experience (or not) something new versus  something old? Read the rest of this entry »

Share on Facebook

We’ve got some job positions opening up here at MAKE headquarters! Click to view and apply to the following positions:

Quality Assurance Specialist

Java Software Engineer

Web User Interface Specialist

Still open:

System Analyst

Business Analyst

Java Developer

Sales Executive

Share on Facebook

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

Share on Facebook

The client was reviewing the Modernization Proof of Concept and wondered if this is how the final system will be implemented in the area concerned. As we discussed the things that the client discovered I realized that I hadn’t been clear about what to expect of the POC. Yes, it should look and act like the real system will be expected to act. No, it isn’t cast in stone and might end up being somewhat or quite different in the real system.

We both agreed that the POC’s ability to represent the new system’s look and feel would help with the “Transformation” of many of the users. We also agreed that it would help identify the next level of refinements necessary. The client felt that the overall POC had met the objective of implementing most of the functionality of the narrow area within its scope. It did have its problems.

What do we do now? We don’t refine the POC to get the bugs out, instead we go back to the requirements and update them to drive the Real solution in the right direction. While we might not totally throw away the POC, we mustn’t feel obliged to keep any particular part of it. If we end up starting (almost) from scratch has the POC failed?

On the contrary, in fact it has given us all we could hope for. We have moved everyone a good way down the road toward the new system; we’ve proved that “Adequate” vs. “Detailed” modeling during the Design phase achieved a good approximation that can be refined during the Build phase. We’ve also started the melting of the current state that will allow movement to the future state. Everyone is again on the same page.

From the technical side we’ve achieved the all important objective of proving that the architecture supports the functionality. Let’s not forget that no attempt should have been made to tune or optimize the solution. That of course must wait for the real system in its near final state.

Lessons learned:

1. Before delivering the POC review with the users the goals and objectives along with the constraints of the Proof of Concept;
2. Reap the benefits of greater clarity from the users’ perspective and don’t seek perfection yet.

- Rod Brindamour

Share on Facebook