You are here: ZDNet UK > News > Software

Office applications Toolkit

Buy or rebuild core systems?

Tim Landgrave Tech Republic

Published: 01 Sep 2002 20:42 BST

I recently spent a few days reviewing the design and operational issues of an existing system with a CIO and his development manager. The company wrote the system several years ago using Microsoft Access, and it has become a core tool in the budget management process.

The system collects the prior year's budget and actual information from the company's various accounting systems, partitions the database by corporate division, and then sends out germane information to each division. Division heads use the database and associated spreadsheets to enter their budget information, assumptions, and other data for the upcoming year. Throughout the year, division managers can request an updated copy with the prior-year and current-year numbers to see how their divisions are performing. They can also ask for advanced analysis of the company's performance.

It's a classic example of a system that's integral to operations, yet is technologically and operationally challenged to the point that it has to be replaced. These types of systems were written in an era when it was too expensive to connect all of a company's locations. These distributed processing and storage applications -- and their brethren, client-server applications with the assumption of local, high-speed connectivity -- are prime candidates for replacement with new distributed processing technologies.

In this kind of scenario, a CIO has to determine the best strategy for replacing outdated applications. The answer boils down to one or more of the following options: package migration, system migration, and application rewrite.

Package migration
The first option -- likely much to the chagrin of most development managers -- is to look at a package migration. As packaged software continues to evolve, many systems now include features that companies were forced to develop and integrate themselves.

The first place companies should look is off-the-shelf products that provide functionality similar to that of existing custom solutions. In my client's case, the company already was looking at alternative accounting systems that would let it consolidate all accounting operations into a single, integrated package. I urged my client to make sure the packages most likely to be purchased included features that the company's users rely upon to get their work done.

System migration
The system migration option involves taking features of existing systems and finding ways to perform them more efficiently without replacing the application outright.

For example, most of the problems my customer encountered in its budgeting application revolved around one of two issues: the distribution of the databases and the user interface for processing. Although Access works very well as a departmental database with a limited number of users, it was never designed to be an efficient distributed processing system. But since all the code in my client's custom solution was written in Visual Basic, the company could reuse a significant amount of the logic within a new application architecture.

One possibility we considered would move the data from Access databases to a shared, centrally managed SQL Server database; the processing logic for forms would move from the Access code modules to Active Server Pages hosted at the company's data center. In this scenario, the new system would make extensive use of the existing user interface and business processing logic. System migrations generally happen on the same or similar platform and entail the reuse of significant amounts of the existing technology or an application's architecture.

Application rewrite
Existing technology or an application's architecture sometimes don't allow for a system migration. In these cases, the only available option is to rewrite code. This approach generally is the most expensive option, but it allows you to architect the application to take advantage of advances in technologies or platforms.

When considering an application rewrite, CIOs need to determine whether the application is hosted on the appropriate platform. The most common mistake companies make when rewriting applications is developing an architecture that's specific to a given environment (e.g., COM, .NET, Java, or Oracle Forms) instead of first evaluating the business needs.

Once you develop a design document that's platform-agnostic, you can choose the deployment environment that best fits the design, based on cost, features, and scheduling factors. If you have a predefined, immutable deployment environment, creating a generic design allows you to make objective decisions about how to implement the features of your new application design based on best practices rather than relying on prior experience.

Other important issues to consider
When making a decision between package migration, system migration, and application rewrites, you need to consider some other important issues.

Weigh the three major system development factors (cost, features, and schedule) equally before deciding which alternative makes the most sense.
Contrary to common wisdom, a system migration doesn't always cost less than an application rewrite. If you consider the costs of the application rewrite along with the benefits of the new deployment platform, the application rewrite may not only cost less but also be worth more to the company.
A package migration locks you into a vendor's implementation of key features. For example, using the budgeting features of a new accounting system rather than continuing to use your existing application means that the process of moving to a different system later will be more expensive and cumbersome.
If you have several applications that need to be updated, consider whether to upgrade the overall deployment environment first, followed by the applications. A single application often won't justify a change of the deployment environment, but the benefits achieved by considering multiple applications become apparent.

Have your say instantly in the Tech Update forum.

Find out what's where in the new Tech Update with our Guided Tour.

Let the editors know what you think in the Mailroom.