When Business Users Drive Technology Issues
by Thom Kolton

This author recently learned of another TPF installation whose company divisions are demanding its replacement with a modern, state-of-the-art computer system. What precipitated this event is interesting: after the company will have spent millions of dollars developing a new product for a new market segment, the divisions cannot conceive of using their old TPF system to sell it. That individuals within the organization cannot reach consensus on what they need or want, and that they cannot clearly articulate the reasons to jettison TPF, are immaterial. Also apparently immaterial are the millions of dollars already invested in the current reservation system; its TPF base is viewed as out of date and unsalvageable.

Needless to say, the Information Technology (IT) group is busy scurrying around trying to perform damage control from the latest attack on their bastion. Heated arguments are more common than not, and the situation has become a political hot bed rather than an important business issue to resolve.

What's an IT professional to do?
First, it's important to acknowledge that the current environment no longer meets the needs of the business. Rapid technological advances have rendered this fact true in most businesses today. But when push comes to shove, even the financially healthiest of companies have not been willing to throw the baby out with the bath water.

Second, understand the business needs driving this initiative. It is not enough for business users to simply say they need a new system. They need to explain in a non-technical fashion what their business needs are and in what ways those needs are not being met. Their business should be your business, and it is crucial for IT to hear and understand them. Remember that business users have always driven technology issues, either directly or indirectly.

Third, be frank and up-front with the business users about current system limitations. Admit that no system, including TPF, can satisfy all business needs. Don't permit bias or arrogance to lead you to assume that your position is safe; a company will ultimately make business decisions based on business reasons, period.

Fourth, be creative in finding new solutions. It is IT's job to find out how to meet those needs. If IT has a history of shunning innovation and telling business units that something cannot be done rather than finding ways to satisfy their needs, it is only a matter of time until those business units gain the clout to drive technology issues.

Fifth, enter uncharted waters. There are many processing models out there from which to choose. It is important to choose solutions which are industry-standard, "open" architectures wherever possible. Unless absolutely necessary, steer clear from proprietary "in-house" solutions. These solutions might fulfill a business need for the moment, but will prove themselves inflexible for the next situation.

Finally, if you lack the technical expertise to create a new solution, find it. No reasonable person expects IT to have all the answers. But a reasonable person does expects IT to be able to get those answers and offer solutions. That is your job.

Enough of theory. Let's talk in practical terms. For the majority of organizations, TPF is the point-of-sale system, the company's lifeline. It performs those fundamental processes needed to generate revenue. And, for the most part, it performs these functions well and dependably. But TPF falls short in several areas.

The user perception is that it takes too long to make changes to TPF, and that TPF is seemingly so inflexible. While it may be true that changes require a lot of time, what the business user fails to understand is that there are at least three separate components to any change in TPF: 1) application programming, or changes to business rules, 2) changes to the database and associated programming, and 3) changes to the input/output streams, or user interface.

Even though "C" language has finally arrived, most TPF installations continue to use assembler because that is the skill set of the programming staff. But most TPF programmers possess excellent assembler skills. The problem is actually that of shared --- and often undocumented --- work areas which programmers must modify, and an absence of industry-standard methods for handling of program data. "C" language helps alleviate much of this problem, although it does not eliminate it.

The database aspect of TPF is probably the most vexing issue. Installations that hard code database access routines in the application greatly increase the overall system complexity, slow development time, and increase risk. The use of a database manager to remove the programmer from the physical aspects of the database makes excellent sense. Those who have implemented TPFDF, for example, have seen substantial increases in programmer productivity. Unfortunately, with this product they have also experienced an old, poorly documented product with few features, requiring a non-standard API, and is known to miss data on READs and lose records during RECOUP.

The most notable problem with TPF from a user perspective is its user interface. Most companies continue to use commands to enter and query data. These commands are usually difficult to learn and remember, and make less and less sense as the years progress and new features are added. Other companies chose to use 3270 mapped screens to permit a "fill in the blanks" paradigm. This was a really good solution twenty years ago. Still other developed proprietary application programmer interfaces (APIs) to permit communication between TPF and other computer systems. This has worked well, except that the communications method is proprietary and a "closed" architecture.

A viable solution to these problems is the implementation of a client/server model using TPF as its database backbone and servers to provide applications and to support a graphical user interface. This scenario provides the desired flexibility from the business user perspective, but assures the required processing throughput while leveraging much of the existing TPF software. The implementation of a database management system, such Greyhound RDBMS, can also provide value by simplifying the programming tasks on TPF and providing a flexible and dynamic database.

So when the business user starts grumbling, all is not lost. But you must develop a technological strategy which is coherent, satisfies the business needs, and makes good sense to the overall business.


Thom Kolton is the President of Mid-Atlantic Systems Design Corp. and developer of the Greyhound RDBMS.