Got Legacy?

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

SAP just announced they will increase the maintenance charges on some of their products by about 22%. And when the vendor who runs your business requires you to pay money, you comply.

I saw the rise of ERP, and SAP, first hand during the last internet bubble, working in or close to Brussels, a major capital of the European Union and of SAP adoption. I saw companies burn millions of euros on moving to the platform, wreaking havoc on established, custom and sometimes highly optimized business processes. I saw a company I worked at, called Home Shopping Europe, crash under the pressures caused by an eternal, over-due & over-budget SAP implementation, diverting enormous amounts of cash and effort into what is virtually a commodity. (I should note here that just like any feature, there were more factors involved in HSE going under, but the SAP implementation most definitely contributed to its decline.)

What angered me at that time was rooted in my developers ethics:

Why use those expensive consultants, using expensive tools to build something that didn’t even really ‘work’ in the traditional software engineering sense, especially when a bunch of marginally competent developers, with some marginally competent business analysts can create a solution at a fraction of the time and cost? Also: aren’t our business processes connected to our competitive advantage? If those become commoditized we will never be able to compete on process.

And then, after working in the enterprise content management space for a couple of years, I stopped worrying, and accepted reality: massive COTS ERPs will be running every corporation in the foreseeable future. And what is so bad about that? Custom development is hard, most processes are commodities and if everyone does it, it cannot be that wrong. I started to learn to love the bomb.

When I read about SAP jacking up the maintenance price this morning, the bomb became scary again:

With an economy slowing down, companies start to reach for their built-in survival instincts. ERP vendors, like SAP, will be forced to offset the decrease in new implementations by increasing the per-corporation licensing and maintenance fees. And companies will have to pay up, or their business will no longer run. Some people will call that corporate extortion, and those people would be correct.

An ERP vendor and its client have a parasitic relationship, which is OK when the economy is fun and games, but can turn ugly quickly, when the going gets rough. I cannot think of any other corporate relationships that are so entangled with each other (except for maybe those Facebook application development shops ). Another, ironic, example: Supply Chain Management is all about maintaining control over your supply chain, and is usually implemented on a platform that forces you to relent your control.

See you in the fallout shelter.

Share on Facebook

This is pretty funny. And it is also very common.

Some technical people can hardly imagine this, but there is an entire universe around production applications. We, as an industry, dismiss that universe as ‘the end-users’ or ‘the business’. We invent labels,  processes and documents, like SOA, stakeholders, subject matter experts, specs and SCRUM, to shield us as much as possible from that harsh world we call reality. 

Much like a house, an enterprise application is a clean, pristine construction. All foundations in place, freshly painted and not spoiled by that harsh world we call reality. Afterwards, actual people move in (imagine that) and start to fill it up with stuff, repaint random rooms, replace the light fixtures, have a party and kick some holes in the dry wall. And they keep doing that for years: hiring different handy men, following different decoration trends and subletting it to those crazy college kids who completely wrecked the basement.

Enterprise applications follow the same life-cycle: trends, developers and users change of the years, all adding cruft and inconsistency to the application, but more importantly: mixing and entrenching it in the real world it exists in. This is not necessarily a bad thing either: the application were made to function by its users, either by changing the application itself, or by adding strange processes around them. 

TLM is MAKE’s process of modernizing legacy applications which have been in production for usually 20 years or so. Often, they are the real estate equivalent of a crack-house: completely integrated with thatharsh world we call reality. Re-architecting a new application allows our customers to start from a blank slate, but has limited influence on its environment. To a certain degree, we are placing a new application in a legacy environment. Not taking this in account is a recipe for failure. TLM is not a recipe for failure (we actually sell it as a recipe for success!) and goes to quite some lengths to really understand what the meaning of the legacy system in its specific ecosystem of users, developers and other systems.

I am in the process of writing another post on how we do that and the kinds of things we have found. You know, in our very own harsh world we call reality.

- Mik Lernout

Share on Facebook