Why Do Companies Start Transformation Projects?

While development shops in companies with OpenEdge applications are as varied as development shops everywhere, there is a tendency for companies with OpenEdge applications to minimize their expenditures on computing. Ironically, this characteristic derives from the low cost of ownership of OpenEdge. Since it is rare for a company to require a full time DBA, as many databases need, the DBA role is a part time job for one of the developers. Since one can typically “load and go” to upgrade to a new version of Progress, unlike the re-engineering for version incompatibilities typical in many languages, there is no budget item for version changes. Since many applications just run and run without much attention, there is no budget for upkeep. Since it is typically inexpensive to make small new reports or screen changes, companies will often keep minimal staff and will resist the idea of expanding to make changes which don’t have an immediate and obvious benefit. Thus, the combination of long term upward compatibility, low cost of ownership, and ease of modification means that there are many companies who have OpenEdge applications of considerable age which have been very inexpensive to own and which often are doing a good job in supporting the business since years and years of small modifications have tailored the software to the company’s specific business needs.

As long as this situation lasts, companies will rarely instigate any meaningful transformation. Possibly a developer whose schedule isn’t too pressed might undertake a small cleanup project in relationship to a module that needs work or might undertake to write a new module using some new techniques, but the vast bulk of the application is likely to remain unchanged. Moreover, it is an extremely common pattern that new work is done in imitation of the architecture that already exists. This can be as explicit as actually copying old code and editing it for a new purpose or it can be just looking at how tasks are done in existing code as a model of how to accomplish similar tasks in new code. Not infrequently, this practice is even enforced by management under the belief that it is more economical or efficient than trying to implement anything new. This practice does mean that the application retains its consistency, but it also means that flaws and limitations written into the system years and years ago are persisted into new code where there is no need.

Given this comfortable, self-reinforcing inertia and low cost, how is it that companies ever decide to do any kind of transformation? Often, this comes in the form of some kind of crisis … and, even if it doesn’t start out looking like a crisis, it often turns into one. Perhaps there is a need to web-enable parts of the application for access by remote users, customers, or vendors and the current application is not only not web-enabled, it is still character interface. Or, maybe it isn’t web screens that are required, but web services for supply chain integration with customers or vendors. Often such demands come from competitive pressures or from having a supply chain partner that is much larger and thus in a position to dictate terms of business. Perhaps it is just new management who takes one look at the character interface of the existing software and announces that it is time for something modern, even if it takes buying a new package and spending heavily to fit it to the business as well as the current package fits.

While the user interface is a common stimulus of the decision to consider some kind of transformation, there are many other possible sources … anything which clashes with the existing architecture of the application will have a similar effect. For the user interface it is the fact that older OpenEdge applications almost universally have the user interface, business logic, and data access all mushed together so that it is very difficult to change any one piece. Another common stimulus is a company that grows from working from a single location to having many locations, possibly geographically diverse, and wanting to manage them as a whole while providing the ability for each location to continue to operate even if communication lines break down. Or, perhaps there is some logic change in a core business process due to changes in business practice or regulatory changes and one discovers that this logic which needs changing is imperfectly duplicated in multiple parts of the application.

The pace of business is changing rapidly in the modern world and processes which used to be handled by month end reconciliations are now often required in days, hours, or even minutes. Old, paper-oriented batch processes that were adequate for the slower pace are unmanageable in a faster paced world, but changing these processes from batch to real time and imposing automated, intelligent management of those processes is typically not possible by making only simple changes to the old application. The whole structure of the application needs to change, at least in the key areas.

Because of the pattern of comfortable inertia previously discussed, companies often don’t have the internal resources for handling this type of change. They often have only enough staff to barely keep pace with a small stream of enhancement requests. Management often has no background or experience with modern architectures and tools. They may have long experience with the OpenEdge product line, but often the tools and techniques which they know are the ones used to originally construct these applications in the 1980s or early 1990s, not the tools and techniques which are available in OpenEdge today. Not knowing what to do, makes the crisis considerably worse than it might otherwise be, since there is no background for understanding when a small, focused change will be sufficient and when something more drastic is required.

Thus, it is easy for companies facing this sort of crisis to decide that they are going to have to start over with a new application which covers the capabilities that are now perceived as needed. But, this is an extremely expensive decision, not only because new software must be purchased, but because one has to go through the cost and disruption of making the change, and one needs to figure in the expense of modifying the new application so that it becomes as well tuned to the business as the current one already is. But, if one doesn’t understand what kind of transformations are possible and has no experience managing such larger projects, it can seem simpler to start over again than to fix what one has. However, this can be a very expensive choice and can easily have risks and downsides which are not apparent from looking at flashy demos.

Do you have stories about the crisis your company is facing? If so, please contact me as I would like to collect stories about what drives companies to consider transformation and possibly I can help you face the crisis.

UPCOMING: Next time I will talk some about the business analysis which should precede any technology decision.

For services related to this material, see my website.