Got Legacy?

Now program languages and their types are more centralized in the TLM Repository! Your Programs will be thrilled! When you write parsing rules for languages, you can upload your scripts and rules directly to the repository!

• First, write your Program language parse rules in an SVN repository.
• Direct the TLMR to that SVN repository.
• Then, add a type and attach your respective language to it.

You can even update your language or type from SVN: just a single click!

See you in Version 6,
The product development group.

Share on Facebook

Thanks to our friends at MicroFocus for this:

So what skills would THE COBOLATOR have:

• Hunt down executives and force them write copy module code?
• Bill, by force, monthly fees for a platform he no longer intend to support or develop?
• Talk you into moving your legacy mess on UNIX or Windows and make you believe it is modernization?
• Duck every time you ask for a change to the system?
• Convince you lower case is an invention by the devil, and UNICODE its evil twin?
• Battle THE GOVERNATOR and stop him from paying his employees?

Share on Facebook

It’s interesting and very helpful to read the piles of articles on legacy modernization. There is definitely no lack of opinion from architectural, business, methodological and management people. As one of the developers working in the trenches on legacy modernization projects, I’d like to throw in my two cents from the point of view of a POJD, hmm, Plain Old Java Developer.

My first point is this: let the developers in on the conceptual business model and leverage their reasoning power to extract detailed business rules! Why is that? Isn’t the developers’ responsibility to be focused only on the technical part of the application? Doesn’t this area belong to the BAs, SAs, PMs to master the conceptual model? Isn’t it a waste of money and time to teach the techie nerds conceptual business model? No, those premises, which worked well in traditional from-scratch projects are not valid for the “new-generation” of modernization projects.

Behind any effort there is a purpose, or we usually call it requirements in software development. What the purpose of a specific modernization project? Of course, to reproduce the values from an “old” system to a modernized system, in the aspects of programming language, platform, architecture, maintenance; and the list goes longer if timeframe and finances allow. Don’t let the nouns fool you, the essential value to the customers is based on one simple truth, and that is to accurately reproduce the business flows, rules and logic in the new system.

Reasons:

1. Unlike Greenfield projects, the clients don’t have to provide detailed user requirements before the developers begin to implement them. They are hoping, and to some extent they are right, the legacy system itself is the most complete and accurate source of user requirements.
2. Fortunately, the conceptual model is NOT difficult to re-construct if it was nicely documented already.
3. The physical model, however, usually is not fully documented, if at all. They are scattered throughout the legacy code. It’s a huge job, or even impossible, to let the BAs try to extract every detailed rule by communicating and asking clients questions. It’s far from an efficient approach. Some weird business rules are deeply buried in the code, so the client and legacy system operators can’t recall or understand them.
4. From experience a lot of use cases and business rules written by BAs are not accurate, not complete, or simply not understood by developers. Instead, developers can extract and implement those rules by reading legacy code or watch the video walk-through of how the legacy system behaves.
5. The more efficient way is to teach the developers to understand the conceptual business model, then using their reasoning, have them read and recover the detailed business rules buried in the legacy code.
6. This approach implies: developers should be get involved in Phase 2 (Transformation) to understand the business model; Phase 2 can be shortened such that the BAs don’t have to try to extract and document the detailed use cases and business rules, rather they should focus on the bigger picture of essential business model and flow. In phase 3 (Implementation) developers need to read the legacy code to grasp and re-implement the detailed business rules and constraints.

I know it’s difficult for developers to master these two parts simultaneously: business part and technical part. Or even worse, three parts: new technology platforms like J2EE and .NET architecture, dinosaur technologies like Natural and RPG language and hierarchical database, and the out-space business model. I think it’s this extreme on the developers’ brain that contributes to the failures of lot of modernization projects. But the challenge is also the opportunity. By recognizing this problem, researching and training process, talented developers can eventually gain the capabilities to craft a high-quality target system. In the end, it’s all about people.

- Lin Wei, Sr. Java Developer

Share on Facebook

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.

Share on Facebook

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

Share on Facebook