COBOL Architecture Astronauts: Mountain MOVErs?

This is another entry in my ‘Legacy development paradigms are the greatest source of legacy problems’  series.

Architecture Astronauts are developers who create a complicated solution to a simple problem in order solve a bunch of other potential, and probably imaginary, future problems. Every day developers all over the world fight their inner Architecture Astronaut, and every day, thousands of them lose that fight.

Over the last couple of years I have seen a lot of legacy systems built in COBOL, NATURAL, RPG and PL/1.* Expecting overly designed hyper-abstract “frameworks”, I am always surprised at the incredible pragmatism and restraint shown by the developers of those systems. At worst you’ll find a dynamic call, where the name of the program being called is passed in as a variable, or a common error routine. 

Legacy mainframe code usually is incredibly verbose, not necessarily because the language requires you to write a lot, but because legacy developers did not reuse business logic or at the very least they try to avoid doing it. Or: 20 years ago code reuse was the stuff Architecture Astronauts came up with while mainstream mainframe developers avoided it.

Programmer A: So, I need to validate this postal code. Didn’t you already write code that does that?

Programmer B: Oh yeah, here: copy & paste the bugger!

Programmer A: Eh: can’t we move that in a common function?

Programmer B: ARCHITECTURE ASTRONAUT! ARCHITECTURE ASTRONAUT!

As usual I am exaggerating, but there is a core of truth there: reuse was not harder to implement than in modern languages, but developers just did not do it on a regular basis. I’d like to say that that was caused by unsophisticated specification and design phases and a less mature software engineering practice, but that is not true: most, not all, reuse in modernized development is done by developers, while implementing, after the designs were created.

Developers communicate business needs in code, and computer restrictions into conversations with users. But the whole practice of software development itself is also guided by a higher level of fads: assumptions about what can, should and may be done in code and how it should be implemented. The more I think about it, the more important these ‘paradigms’ seem to be compared to the individual choices of each developer or team. The quality and business alignment of your system is heavily influenced by the paradigm that was used to develop it.

Next in this series: ‘SOA: where Architecture Astronauts mate’.

- Mik Lernout

* Note that I always refer to legacy languages in uppercase but I do not line break after 80 characters. Inconsistent, I know.

It takes two to tango: Winning the clients’ buy-in

What sort of challenges are expected during a large modernization project?

- We can easily think of the technical ones which are generally considered “fun” to tackle by technical teams.

- Difficulty in collecting and assembling the full picture of business processes and requirements from various sources/departments.

- Designing the modernized solution in a way that would serve the client’s business needs. This will be the topic of this blog:

The moment Business Analysts (in charge of analyzing business requirements) or System Analysts (in charge of analyzing technical requirements) get exposure to a legacy technology implementation of a business solution (user interface screens, batches, etc.), they can not help stop trying to think how to modernize it because that is the fun part of the game. In doing so, the BAs and SAs think of how to make the screens more efficient, how they might be able to replace an interface with a screen or a report and all kinds of exciting possibilities would come in mind.

It becomes as a shock or at least a disappointment (depending on how much effort was spent) when the client is presented with the exciting ideas of modernization and rejects them. This unfortunately happens more often than expected. So why does it happen?

- Either the new approach/workflow/design fails to address some unforeseen aspects of the business that the client with their experience can foresee. Once the client has expressed their concerns, a discussion can ensue to tweak the suggested solution to better serve the business requirements, or perhaps find another approach all together with the client’s help.

- Or the modernized approach employs modern technology paradigm that are still incomprehensible to the business user who is used to legacy screens and batches. This is where things get tricky for the following 2 reasons:

1. The client is unable to foresee any possible difficulties and warn against them. In this case, the client might accept the new design which could prove inadequates at a later time.

2. The client could reject the design because they don’t understand it fully and it could cause frustrations on both sides (BAs and SAs believing that it is the best solution, and the client being nervous about accepting a design that they do not understand).

The solution for the first problem is for the BAs and SAs to do their best possible efforts to ensure the safety of the design (mining related logic and understanding related business processes and data model). If this kind of effort is put in place, there would almost always be a way to tweak the design to bypass obstacles discovered at a later time with minimum to medium effort (risk management).

The solution to the second problem is for the BAs and SAs to try and put themselves in the client’s shoes and try to envision how it feels to be presented with a solution to your problem that you do not technically understand or unable to envision while expected to make a decision on. By thinking of it that way, the BAs and SAs would most of the time be able to find better ways to further explain their ideas more simply and clearly (screen mockups, presentations, use cases, meetings with white-board drawings).

Keep in mind that no matter how smart your solution is and how much you would love to fight to keep it, if the client simply rejects it, it would be of no value. When all fails to win the client’s buy-in, then we can still succeed by admitting that our brilliant idea will not work for the client and settle for a less brilliant solution that would be acceptable.

Sometimes we will have to draw our satisfaction from winning the client’s buy-in on less lustrous solutions that they accept than the more elegant ones that they won’t!

- Sinan Ali

When Enterprise Software and Web 2.0 Mix

See this funny set of customer reviews of Sun JCAPS on the Sun product site. I would really like to be in the room at the Sun Marketing HQ, especially when they chose ‘Yes, I would recommend this to a friend’ as a review metric for an SOA toolset.

- Mik Lernout

PS: I am just bitter because SOA toolsets are actually the only thing I can advise my friends on… I really need to get out more

COBOL is not evil, but COBOL programmers are….

It is always interesting to see an extreme opinion on legacy languages, such as The mainframe is not evil, but COBOL is… by James McGovern . Especially when they are dead wrong, or at the very least, misguided.

Most of the reasons listed on why COBOL really is evil (like ‘everything is a MOVE’, ‘Data layer is too tightly coupled’, etc.) can just as easily be applied to any modern programming platform. Ruby on Rails is all about coupling the data layer and has anyone ever figured out how many lines it takes in an EJB to write a Hello World? Without spoiling the surprise: a lot.

The problem with COBOL is not the code, nor the language and not even the mainframe. The problem is the people programming it. Nearly all COBOL programs out there follow programming paradigms which were very relevant about 20 years ago:

Computer! Take this crazy fixed width file filled with customers and produce another file with the same data and an added column to mark the customers that have overdue payments.

Now that we are up to our ears with computing power and network bandwidth, we much rather like to have realtime conversations:

Computer! Is ‘John Doe’ overdue? Hmm… And what about ‘Jane Doe’? Sweet.

The inherent batch processing embedded in legacy system does not exist by virtue of the programming platform, it is there because people coded it that way. And the reason they coded it that way is because it was the reigning paradigm. Which is why I should really blame an abstract entity such as the ‘batch processing paradigm’ for being evil, but that would be not as catchy as a title.

At MAKE, we modernize legacy system usually to the JEE platform. But we would love to modernize one to from batch-COBOL to realtime-COBOL one of these days. You know, just for the heck of it.

- Mik Lernout

PS: Some of my friends are COBOL programmers and they are really nice people, but this blogosphere-conversation-thing does not work without some controversy

“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

Is it time to modernize?

When does your system become legacy and needs to be modernized?

The answer is not straight forward, but there are 3 key factors to consider:

• Cost of Maintenance
• Risks
• Divergence from Business Needs (in legacy systems it is not easy to keep code up to date)

It is really an act of balance between these 3 factors where the balancing point is different from one business to another.

Let’s review a few examples from real-life:

Vital Statistics application for the Government of Nova Scotia:

• Cost of Maintenance: Very High
• Risks: High
• Divergence from Business Needs: Very Low

- Divergence from Business Needs: This application was tailor made to fit the needs of the business and kept up to date through extensive efforts. The business owners wished to keep it and not to modernize it. The right option seemed to extend it by exposing its data using interfaces and web-services.

The business had to also consider the other two factors:

- Risks: The IT resources experienced in the legacy technology were becoming more difficult to find. In the future, it may not be possible to find any. The legacy server equipment is no longer manufactured.

- Cost of Maintenance: It was becoming extremely expensive to maintain the software and hardware. The server hardware equipment can only be purchased from vendors who stocked them at astronomical figures.

The decision to modernize was the right one.

* FBI Information Sharing Systems:

• - Cost of Maintenance: Not an issue
• - Risks: Very High
• - Divergence from Business Needs: High

Many information sharing applications were tailored to the FBI needs over the years using different legacy technologies.

- Cost of Maintenance: From the business’s perspective, Maintenance Cost is secondary to providing timely security information.

- Risks: Running critical security information applications on old hardware that can no longer be supported by the vendors is a great risk.

- Divergence from Business Needs: Limitation of legacy technologies has caused the systems to diverge widely from new requirements.

The decision to modernize was the right one.

* Futureshop Data Warehouse application:

• - Cost of Maintenance:Low
• - Risks: Very Low
• - Divergence from Business Needs: High

Data Warehouse solutions are becoming the backbone for large retail operations. The ability to analyze sales by regional locations, time periods, gender and age of client and other dimensions, empowers the retailer to make the right purchase and marketing decisions. It really uncovers where the profit is hidden.

Futureshop has an in-house IT team that has built a data warehouse solution over the years.

- Cost of Maintenance: The IT department is a part of the business running costs.

- Risks: The Data Warehouse application was built using relatively new technology (an earlier version of Cognos). Futureshop runs its own IT department where new recruits can be trained.

- Divergence from Business Needs: The original Data Warehouse was not designed according to best practices. With time, it was getting much harder to add more dimensions to it to analyse sales by.

The decisions to modernize was the right one.

After reviewing the examples above, we should not forget that there are options to keep the legacy systems running:

- The Cost of Maintenance could be overridden by the other 2 factors (depending on the business nature and the actual cost which may be low for PC running legacy systems).

- Some of the risks could be managed: (in-house training on old technologies for new resources, stocking of out-of-production hardware components).

- Divergence from Business Needs could sometimes be rectified by exposing some system elements through web-services and interfaces.

It may not be easy to reach the right decision, so start by reviewing your options to keep the legacy system running. If that does not meet your needs, consider modernizing!

- Sinan Ali

POC: A Keeper or Start Over

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

Do it mechanically – we want you to

Presented with the phrase “legacy modernization”, most people think of mechanical methods. You know: take your old source code, pump it through a tool of some kind, and out comes the same system in a different language. Well technically it’s in a different language, at least at a syntactic level, although the actual generated code may not look like anyone’s hand-coded code. Terms like “Procedural Java” come to mind. Fundamentally, you can’t change the design in a mechanical fashion, so the output will still feature the design of the old system, from the architecture right down to the line-by-line organization.

However, if you’re desperate to get off your platform and you’re going to kill the system in five years anyway, or you know you’ll never have to change it, mechanical methods might be just the ticket. At least, they tend to be cheap.

Now to the point of this article. We at MAKE regard every mechanical modernization as a great potential client for a future modernization with TLM, because fundamentally a mechanical approach does not produce a good foundation for future maintenance. Eventually, all the folks who do it mechanically are going to start looking for someone who can do it right. The market for TLM is so enormous, it’s not possible to help everyone at once, so delaying some future clients for a few years would suit us just fine!

- Tom Metzger