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

Based on a true story.

It was the year 2001. At the time, I was working for a company that was contracted by a big bank to develop its web banking application, so my team and I did just that. Over a period of about 3 years, we put on production a whole suite of applications wrapped around the host (the mainframe).

But the point of this post is to talk about how this organization solved one of the biggest challenges legacy systems face today due to their age: The cost of maintenance.

These guys (the bank) were spending a lot of money in maintenance. We all know that banks do have lots of cash, but, in general, they choose to spend it wisely. I said spend, not invest. That’s another topic for another post. So they were paying a number of vendors and these vendors were making a real killing. Hundreds of dollars an hour too often.

I should mention that this bank was located in a tiny island in the Caribbean and one of the main corporate branches worldwide was located in North America where they had safely hosted their own mainframes underground in a specially designed building with very tight security measures, and a back up off site, thousands of miles away that was ready to be fired up seamlessly in case something happened to the bunker I just mentioned. Furthermore, the staff working at this underground facility were not contractors, they were bank’s own young employees that were professionally trained to develop and maintain old technologies. I remember that when I went to this site, I met people my age (I was in my mid 20′s) that knew COBOL, CICS, VSAM, T3270, and so on very well when the rest of us were more familiar with web technologies.

It seemed logical that the little bank in the Caribbean could solve their mainframe’s excessive cost problem (with back up and recovery as a plus) by simply shipping it to this site in North America. So they did. I was there when the enormous computer was carried out of the island site, put on a truck and hauled to a better home. And they lived happily ever after, or so I’ve heard. At least till now.

Today, I modernize legacy systems for a living and when I look back to that time, I wonder if this bank is still wrapping their newer applications around the now cost effective mainframe. They certainly solved the cost of maintenance problem then, but they still face other problems associated with aging systems. According to The Lehman’s laws of Software Evolution* they have a ticking bomb that could eventually go off wreaking havoc on their clients, shareholders, and perhaps on the island’s economy. The thought becomes even scarier when I wonder how many banks/financial institutions worldwide are doing the same.

Do you have an example of an “out of the box” solution to the aging legacy systems problems? Go ahead and share it!

* In case you’re wondering, the Lehman’s Laws of Software Evolution refer to a series of laws that Lehman and Belady formulated starting in 1974 with respect to Software evolution[1]. The laws can be summarized as follows:

• Law of continuing change: A system that is being used undergoes continuing change or degrades in effectiveness .
• Law of increasing complexity: A computer program that is changed, becomes less and less structured. The changes increase the entropy and complexity of the program.

[1] “”Metrics and laws of software evolution—the nineties view”". Proceedings of the 4th International Software Metrics Symposium (METRICS ’97), IEEE. 1997. http://www.ece.utexas.edu/~perry/work/papers/feast1.pdf

Share on Facebook

We all know that Continuous Integration (CI) can deliver real, tangible benefits to our projects. So why are the benefits so elusive? Many software projects claim to be exercising CI, but have builds that run for 30 minutes or more, or worse, just have a nightly build. Build times that exceed a few minutes are excessive; all too commonly we see build times reaching 20 minutes to an hour or two. Real projects tend to have build times that gradually increase as the project evolves, resulting in a failure to reach the full potential that CI promises to deliver. Luckily for many of these projects, there’s a solution that can get your project back on track.

I’ve seen many projects with this problem, and they all have the same pattern: a monolithic build that builds components in a serial fashion. While many of these projects are modular, where modules can be built independently, dependencies between modules prevent them from being built in parallel.

So how do we get shorter build times? We cheat.

By building modules in independent CI jobs, we can get faster feedback for independent modules of our project without reducing the total build time. As we make discrete changes to the source code, only the affected modules will rebuild.

With this approach each module is built separately from the others. As a result we get very fast feedback as to the impact of our changes, possibly even before downstream modules have finished building. Furthermore, in many cases only part of the project will need building — thus resulting in a reduction in total build time. I know, I said that total build time is not reduced using this approach, but for many cases the total build time is in fact reduced since we don’t always need to build the whole project!

So how do we employ this approach in practice? These are the steps that I took on a recent project:

1. Identify logical modules of related functionality in your project. For Eclipse projects, this could be related plug-ins. For my project which involves about 100 Eclipse plug-ins (OSGi bundles) this meant splitting the bundles into about 7 modules.
2. Next, change your build process so that each module builds independently. To do this I started with the module that would need to be built without any dependencies on other modules. After creating a CI job to built it, I moved on to the next module, which could now download its dependencies from the first CI job. Repeat this process until each module is built by an independent CI job that downloads its dependencies as binaries from other CI jobs.
3. After all modules were building on the CI server using binary dependencies, some minor tweaks were required to limit job concurrency and unnecessary thrashing on the build server. This is where the power of Hudson really shines.
   1. Configure each module’s job under Post-build Actions to trigger the next module in the series of dependant modules: check Build other projects and list them there.
   2. Using the Locks and Latches plugin ensure that all module jobs are using the same lock, preventing them from all building at once.

Here’s what I ended up with:

Before: 1 job, 1100 tests, 30 minute build time.

After: 7 jobs, 1075 tests, 20 minute 30 second build time, with a break down as follows in dependency order:

The net result is that most of the time, we get feedback within 6 minutes, whereas we were having to wait 30 minutes. Even if you can’t parallelize your build, splitting your build into independent modules that build serially can produce measurable benefits such as faster feedback and shorter build times.

Share on Facebook

Ensure a successful project through
clear communication.

Writing requirements for a technology team can take some time and practice, but the final outcome can save future headaches. If you’re interested in streamlining your modernization project, this is the webinar for you.

Presenter Grant Dececco will guide you through the methodology used by legacy modernization leaders.

MAKE’s “Requirements Management for Modernization Projects” webinar will take place on April 22 at 10am PST.

Register now for the webinar!

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