Gartner and Sector7 Agree

"Organizations must use legacy functionality as the foundation for ebusiness killer applications - not as software to be discarded," says Massimo Pezzini, research director at analyst Gartner.

[see article]

Business Logic Extraction

Or the art of “NOT throwing the baby out with the bath water”

Introduction

“Don’t throw the baby out with the bath water” is a caution all companies with older applications must heed. Often the core “goodness” and focus of the application (baby) is lost when peripheral disorganization (dirty bath water) is eliminated.

Already, the drift is obvious — there is goodness and focus in your legacy applications. The goodness is the data manipulation that has been crafted from your business needs, commonly refered to as “business logic.” The bath water is the old tired code used to express these concepts to the computer system (the computer language, database structure, user interface).

Unless the way you do business has significantly changed, the business rules encapsulated by your legacy programs are as valid today as they ever were.

Sector7 has developed proprietary processes and procedures to extract this business logic and re-express it in a modern computer environment. It is Sector7’s Enterprise Application Business Logic Extraction and Reassembly (ENABLER™) process.

Sector7 started in 1985, migrating code from one platform and operating system to another. With experience and thousands of projects under our belt we became expert at accurately costing and scoping the effort. These are plannable projects — the start point is well defined and the end point is also well defined, which means the programs work the same on the new system as the old one.

Over the years, Sector7 has watched clients undertake a new development or buy a package that “almost” met their needs. And we’ve watched as clients modify these packages in-house. Without exception, every one of these projects has failed. When clients’ come back for a migration, having run out of money and time, we see that it’s not that the clients’ IT staff were incompetent. The reason for failure is always “scope creep” — the inability to accurately cost and plan the development project. From the very beginning, fuzzy rules were created without using the legacy application as a template.

In most cases, what our clients sought was the well-tried business rules formed under the infrastructure of modern program architectures (Oracle, J2EE, PL/SQL, C++, Java etc etc). Once the core of business rules were coded, future and on-going development, as a result of changing business requirements, should be simple: a clean, well-documented, modern architecture.

With Sector7’s understanding of the clients’ business logic as part of a “sterile” migration (the debugging) we are able to extract the work processes developed from migration and formalize the rules prior to coding a solution.

By using the legacy code to determine the logic flow, all of the rules and — most importantly — all of the exceptions are extractable. Therefore, we have a very high degree of confidence regarding the full scope of the re-engineering effort.

If you have to pick up 12 sticks and it takes 10 seconds to pick up just one of them, then you know with some degree of accuracy that you are looking at between 100 seconds (getting better with each stick) and 140 seconds (time lost to back ache). The critical assumptions here are that there are indeed 12 sticks (scope) and that each stick takes 10 seconds to pick up (planning and experience).

Accurately extracting the business logic gives us the number of sticks (scope). Sixteen years of living in other people’s nasty code (experience) gives us the average time.

Put this together, add very detailed planning and dependencies, intense project management, highly-experienced staff and you have the recipe for on-time, on-budget solutions.

Our clients also kept telling us that they wanted ownership of the code when the project was completed. “Knowledge transfer.” “Hit the ground running.” These were phrases we heard time after time. Our solution was to find workable methodologies that allow the client to become as involved in the project as required (or as resources could be allocated).

Following the project, the client wanted to be confident that the team which created the solution would be available for support and on-going enhancement when and if required.

These issues were easy to deal with. Sector7 does not send projects off-shore and we have enormous staff retention. Your project will be performed in the USA (or country of origin), by salty, very experienced professionals who enjoy short time-frame projects. And that’s the key to it all: short time-frame projects. We try to complete all projects — no matter how big — in fewer than 18 months (typically the time it takes for a business change to require a logic change). That is not to say that we don’t take on projects that exceed this. After all, even with the best planning “nine women cannot have a baby in a month.”

What is the dollar value of a legacy application?

This is very hard to quantify, but we have tried. Most legacy applications Sector7 works on are between 5 and 10 years old. Most have had an average development-and-maintenance staffing level of between 10 and 14. So assuming “averages,” seven-and-a-half years in production, with 12 IT professionals, the average investment in a typical legacy application is $6.3M. These numbers are based upon a “typical” application of 600,000 lines of 3GL code, relational or indexed file system, and some screen or forms management.

Case Study

With many older application written in obsolete 3GLs — patched and patched over the years — the classical migration approach of “simply” modifying the 3GL into a form compilable on modern platforms does not make business sense. You can not just provide a “layer” to translate the obsolete file management or operating system calls from the new target host system into a format that the existing logic will recognize.

A good example of this is a system that Sector7 recently rehosted:

The application — like so many that have been in continual use for 15 years — was becoming complex to maintain, yet it perfectly serviced the needs of the business.

The problems that our client faced are all too familiar to those of you in established corporations:

It became obvious that simply converting PL/I to use newer PL/I compilers (IBM or LIANT) was not a solution. Most of the PL/I would have to be rewritten to access relational data structures and organizational methods (application logic assumed a hierarchical structure).

The client wanted their old business logic — which had been fined-tuned over 18 years — to run on a modern computer architecture and to be easily maintainable and modifiable.

Even in the old system, making changes to cope with changing business requirements was becoming an expensive and time consuming proposition.

Succinctly stated: if any of the company’s programmers “quit,” the learning curve was putting the organizations business at risk.

The client had an Oracle standard, had implemented Oracle solutions in other divisions, and had the ability to maintain and support an Oracle infrastructure on modern Linux and UNIX systems.

The problem was how to get them there quickly and within budget.

One way to approach this problem was as a typical development project. Unfortunately we all know about “typical” development projects that run over budget by orders of magnitude and never get implemented.

Sector7 has developed a new approach to new application development based upon the logic contained in existing legacy systems.

We make the following assumptions:

So, given the above, what is our methodology?

Legacy Application Design Documentation

Interestingly enough, every legacy (and non-legacy) application in active production has perfect documentation — it is generally called THE PROGRAM. The hard part is going through what could be millions of lines of code, weird forms generators (or embedded screen outputs) and odd databases (hierarchical, networked, none) and extracting the important (and used) business logic, then reassembling this into a form that can be used to recreate the application in a modern Oracle and/or J2EE application environment. Sector7 has developed proprietary methodologies for Enterprise Application Business Logic Extraction and Reassembly (ENABLER) — not rocket science, but fine-tuned after migrating legacy systems for 16 years (since October 1985). However, the really hard part is: “How do you accurately scope cost and project the time-frame for such a project?”

Scope, Cost and Time-Frame Projection

Sector7 has a straightforward method for planning and, more importantly, costing a Business Logic Extraction (BLE). We put every activity that needs to be performed into a Microsoft Project plan, allocate the resources for each line-item, create the dependencies and then level the plan for resource allotment and final elapsed time target. Of course, knowing what tasks have to be done in what order and the correct time for each task is the product of having completed more than 1000 application rehostings. Every project plan is, of course, different and specific to the project being estimated, but in each plan we have a few inviolate rules:

Typically for a BLE and recode, the project plan will be somewhere between 3000 and 10000 individual line-items.

Our method for pricing a project is simple, we feed the hourly rate for each assigned resource into Microsoft Project and the project cost is automatically driven out.

We do not believe in unaccountable price estimates — our clients see every task and where every dollar is being spent.

In addition, we track our project estimation against “reality” (or baseline) and make the updated project plan available via the web so that our clients can see on a day-by-day schedule the status of the project.

Combined Project Teams

The secret to giving our clients a new system of which their IT staff has ownership, is to include the clients’ IT staff (where possible) in the project. Obviously, to do this increases the complexity of the project planning phase as the clients’ resource scheduling and availability is a critical-path component. Competent risk appraisal and mitigation is always essential when dealing with multiple teams — especially where some critical-path member of the client team is pulled away for important maintenance/development work (as seems to be the “norm” not the exception). The only way around this is for the client and Sector7 to have a contingency plan which allows for detailed data regarding the clients’ work items to be available for experienced Sector7 engineers to step in.

Sector7 Resources

As mentioned earlier, we do not send work “offshore.” All our projects are performed with USA resources in the USA (or country of origin). We have a straightforward philosophy regarding the skill level of resources that we allocate to any of our projects: we only use very experienced, seasoned professionals. The client does not pay professional rate structures and get “students” or rookies. We believe that each member of the team should be self-motivated, understand project management, understand the financial implications of on time deliveries (both for the client and Sector7) and voice their concerns in a timely manner should the need arise. Any member of the team should be able to step into a technical lead role if the need arises. Use the best and you get the best. Too often, these days, we focus on the hourly rate of pay — not the hourly rate of productivity — which has a direct relationship to the error rate. At Sector7, we do it right the first time.

Proposal Methodology

Like our other processes, our proposal methodology follows a true and trusted format.

ENABLER Assessment – Take a “quick” look at the application to be ENABLEd, determine the size of the project by a mixture of metric analyses (lines of code, databases, interfaces, complexity, forms, fields) and function point analysis. We then cross reference the data with historical projects of similar technology and complexity and make a ballpark cost determination. The internal cost is checked against the function point analysis and pricing points. Once the analysis has been completed the following is delivered to the client: