Information Engineering and CASE Tools: - Are They Compatible with TPF?
by Thom D. Kolton & Carol A. Fogelsong

An information engineering (IE) methodology and CASE tools approach to system software development can be implemented successfully for any type of operating system environment, including TPF. In fact, as information environments become increasingly more complex and interrelated, we believe that an IE approach using CASE tools is becoming necessary to manage complex business environments.

When a recent, well publicized TPF project using CASE tools failed, nay sayers were quick to point a finger to CASE tools as a primary culprit. Our experience in this area, however, has been to the contrary. Instead of as an unknown variable capable of destroying well managed projects, we view IE and CASE tools as integral parts of our application development life cycle.

The project being developed under an Information Engineering methodology using CASE tools is the Amtrak Express project. The Amtrak Express system is a freight and U. S. mail cargo transport system. Amtrak accepts shipments of small packages, pallets and U.S. mail containers, and transports them via regular scheduled train service throughout the country. Currently a manual process, Amtrak expects this system will improve customer satisfaction by providing online tracking capabilities, automatic rate quotations, and an electronic link to the billing system operating under MVS. The TPF portion of this project is made up of seven major software components, and is using a 3270 mapped screen application program interface (API) for its implementation.

The Amtrak Express project was initiated several years ago to provide financial data for billing purposes, and was later expanded to encompass shipment tracking and other ancillary functions. Due to various factors, the project was interrupted at several points during its application development life cycle. It was re-initiated in the summer of 1990.

The results of previous efforts and the document serving as the basis for continuing development was a functional specification in the format typical of TPF applications. While reflective of previous designs and agreements between departments, this document no longer served as a viable document for developmental purposes. For one thing, because of its age, the business had changed in several respects while this document remained static. Also, several functions had been poorly or inadequately defined. Finally, a change in personnel had created a loss of continuity on the project.

Interviews with our internal customers were started again to confirm functionality and to clarify processing needs. These meetings were carefully documented and new agreements forged between departments. However, the Information Systems Department (ISD) proved unable to design portions of the system which the customer would accept. Moreover, the agreements forged during the interview periods and documented in meeting notes proved worthless; the customers had changed their mind on certain aspects, and we were obliged to fulfill their needs. The "review and reject" syndrome seriously hampered our efforts to complete this project. It became clear that a new and radical approach was necessary. We decided to implement the Information Engineering (IE) methodology along with KnowledgeWare's ADW CASE tool.

Information Engineering is defined by James Martin as, "An interlocking set of automated techniques in which enterprise models, data models, and process models are built up in a comprehensive knowledge base and are used to create and maintain data processing systems." This boils down to several basic principles, the first being that designing a system begins by identifying the strategic goals of the corporation and how the system will serve them. No system stands alone, but instead is an integral piece of the larger enterprise. Second, once defined, data is owned by the corporation. Each piece of data that is important to the corporation, or "entity", is considered an asset to be maintained and protected like any other corporate asset. Another important principle of IE is that of "top-down" design. Designing a new system starts with the planning phase, in which strategic goals and business areas are identified. The next phase is analysis, in which data and process models based on the business rules for an individual business are created. Design follows next, with the models being used to create program modules, screen layouts, report layouts, and data structures. After design is the construction phase, in which the individual programs are coded and tested. Using the IE methodology, the bulk of the work will take place in analysis and design. Coding does not begin until all requirements have been identified and all data has been defined. Emphasis is also placed on creating reusable design and code. Another important part of IE is that user interaction is constant throughout the development cycle. The system is designed to serve the business needs of the user, rather than designing the business to serve the needs of the system.

KnowledgeWare's ADW workstation supports the IE methodology by containing all output of all the development phases within an "encyclopedia." The encyclopedia contains, among other things, the critical success factors identified during the planning phase, the data and process models created during the analysis phase, the screen layouts and data structures created as a part of the design phase, and, if the code generator is used, the coded programs. Since the workstation works globally on an encyclopedia, changes made to entities, processes, data flows, etc., are perpetuated throughout the various models and diagrams. This saves time for the analyst as well as allowing dynamic manipulation of data elements. The encyclopedia transcends a data dictionary in that it contains all the associations and relationships of data elements as well as their definitions. An encyclopedia is used by individual analysts and programmers on a project and can be rolled into a corporate encyclopedia that is maintained by a data administration group.

The various tools contained with the ADW workstation allow easy creation and management of the diagrams and models that document the workings of a system. For example, during analysis, one of the tools shows the individual data entities that make up a system and the relationships between them. The project data model is created here, which is eventually placed in the corporate data model. Process models are then created showing the essential processes that must be performed by a system. The resulting data and process models are then put together to show the flow of data in, out, and within processes so that all data needed by a process is accounted for. During the design phase, a structure chart diagramming tool is used to show the control of models and the parameters that pass between them. The screen layout tool is a painless way to "paint" a screen. The designer can easily manipulate fields on the screen to achieve the best possible format. It also documents the fields used during a screen dialogue and from which entities they originated.

The implementation of IE and ADW naturally incurred some start up costs. We started out by installing ADW on an IBM 386 PC. This worked fine, but our productivity was gradually impacted by its slow speed. Once we upgraded to 486 PCs we were able to use the tool much more effectively. We found that proper training was essential. It is extremely difficult, if not impossible, to learn the finer points of IE and systems analysis in general by self-study. Fortunately, there are several vendors that offer training in CASE tools and how it is used for business area analysis and structured design. By providing our team with the proper training at just the time they needed it, we cut down the learning curve considerably. Learning the mechanics of the tool was relatively easy. It was the change in perspective, from a narrow, TPF-centered view to a corporate-wide view that was more difficult.

Since we were creating data objects that would eventually be shared, we found that new procedures were necessary. Changes to shared objects would need to be controlled to minimize impact on other projects. Also, since all team members were working with separate encyclopedias, a method for consolidating encyclopedias was worked out. Amtrak's Database Administration group was brought in to coordinate these procedures.

The support of upper management is absolutely essential when implementing an IE and CASE methodology. This is a long, difficult, and costly endeavor that does not show immediate payback but, rather, over a period of time. Since this would eventually touch most of the department, we needed upper management's blessing to implement this strategy effectively.

It is a common misconception that IE, CASE and TPF are incompatible. Since IE emphasizes the corporate view of systems, it can be used regardless of the operating system or hardware involved. The ADW CASE tool can be used for designing TPF systems from the planning, analysis, and design phases. The code generator is not being used by the TPF team, but instead by our MVS counterparts.

The main focus of the planning and analysis phases is the logical view of the system and the data, not the physical view. In many ways this was the most difficult adjustment to make since, as TPF professionals, we were accustomed to thinking in terms of physical layout and performance efficiency. Once this shift was made, we were able to see clearly what data we needed, how it was to be used, where it came from, and what the data actually represented. The result of our analysis phase was a system design based solely on the business needs of our users and not hampered by any physical limitations.

It is not until the design phase that physical considerations become important. All systems need refinements for performance reasons during this phase, and ours is no exception. Even though we are not using the code generator, we are using the translation utility that creates relational tables from the data model. These tables are being used to document the "dsects" that we will use in coding the programs.

Due to the fact that the Amtrak Express development project had already become somewhat of a "legacy" system even before implementation, we felt it was necessary to modify our approach from a true IE environment. Where one would normally begin documenting user interviews and creating data models, process models, and data flow diagrams in support of user requirements, we instead chose to use the original functional specifications as the basis for our analysis phase. Without direct customer participation, we began with a basic understanding of the functional requirements. Using this information, we then created the logical model of the specified data, followed by the production of screen sketches for input and output and brief process descriptions. This final output was used during the customer interviews to validate and complete the user requirements.

These "interactive design sessions", as they are known, are held approximately three times weekly. The purpose of these sessions is to complete the gathering of functional requirements, to validate the business rules, assure concurrence among the various departments, and to confirm the screen designs. It is in these sessions that we create and review functional specifications. It is also during these sessions that any department may raise concerns or objections over proposed designs. Where new processing or new data is brought into a particular function, ISD applies that information to the base data, adding new entities where appropriate. Through this, we capture functional and data requirements, and then use this information in the physical design of our data base and screen input and output. The department representatives review each portion of the design as we complete a function. Thus, any changes which are deemed necessary through consensus are made immediately and the document reprinted for review. The information gathered also then becomes available to other applications who must share common data. For sake of conformity to our current documentation standards within ISD, we produce functional specifications in a format virtually identical to existing documentation.

On the surface, these sessions appear to be somewhat expensive. Each meeting is attended by no less than three representatives from ISD and one to two members from three different departments. However, IE stresses the analysis and design of a system. Any changes necessary are more likely to occur during the analysis and design phases, where they are easier and less expensive to implement, rather than during coding and testing. The role of all personnel have also changed dramatically. The business community ensures all business rules are precisely defined, and that the system will be "user friendly" for the field. No longer in the role of "order taking," ISD acts as facilitator and technical consultant to our customers. Because each department is actively involved in the design of the system from the start, we are able to bypass the "review and reject" syndrome. Each session participant is equally committed to the successful design and implementation of a quality system and so feel more ownership of the final product. It is more "their" system because they helped to design it.

The level of detailed information gathered during these sessions is also superior to that gathered in more conventional approaches. Functional requirements are put into logic diagrams using pseudo-code. In conjunction with the fully documented database layout, these diagrams permit a programmer wholly unfamiliar with the system to code and test the programs. Everyone has heard of the ideal that you should generate your technical documentation while in requirements and coding phases. By using IE and CASE, we have made this a reality. We have defined and documented all data and their relationships and all essential processes before writing a line of code.

The direct involvement of departments in the detailed design of a system is a costly proposal. Yet, to develop a system which does not meet the customer's needs and requires modification over an extended period of time is also a costly proposal. In the long run, we firmly believe that these sessions will have proven to be cost-effective overall.

A technical benefit of using this approach is that it has allowed us to design a database that is nearly devoid of redundant data. There are no "mystery" fields that nobody knows anything about but everybody is too afraid to remove. By using the secondary indexes that were defined during analysis, the users can access the information stored in the database by a variety of different methods. The system is flexible enough to meet their needs, but efficient from a TPF performance standpoint because related data is stored together.

Using the IE methodology has also allowed us to work closer with our MVS counterparts and with other departments in the corporation. Since our development process is more like the rest of the vast information systems world, we are less and less considered "those oddballs in TPF." We are now sharing and contributing data to the corporate model, rather than existing in a vacuum. Other project teams at Amtrak have since started to use IE and CASE, so it is gratifying to be able to share ideas and experiences with them.

It should be emphasized that there is no one absolutely correct way to implement an IE and CASE strategy. Each organization must customize the methodology to find the right combination that works for them. We were initially unsure as to how we could use IE and CASE to design a TPF system, but with proper training and hard work, we found a way to make it work for us. We weren't always successful, so we made adjustments and are continuously working on further improving our development process.

An important lesson we learned is that our success is due to the IE methodology first and the CASE tools second. It has been suggested that previous attempts by other shops to implement CASE in a TPF environment failed because they focused too heavily on the tool and not enough on the methodology. While it is easy to be dazzled by the powerful graphics of CASE tools, it is by using the IE methodology that we are designing an efficient, user friendly TPF system that meets our user's business needs.

Currently, we are well into the design phase of the Amtrak Express project. While we anticipate a smooth implementation of the system into production, we know that this article is not complete until Amtrak Express is being used by Amtrak agents everyday. We will keep ACP/TPF Today readers posted as to our progress. We also welcome any comments or questions readers might have about IE, CASE and how it can be effectively used in a TPF environment. We can be contacted at the following address:

Carol A. Fogelsong
Thom Daniel Kolton
Amtrak
400 North Capital St, NW
Washington, DC 20001

Carol Fogelsong possesses eleven years in the travel industry with both Piedmont Airlines and Amtrak, six of which have been in Information Systems. She is a TPF programmer, and has been using Information Engineering and CASE tools for one year.

Thom Daniel Kolton has over thirteen tears experience in Information Systems at Pan American World Airways and the Port Authority of New York & New Jersey. As a project manager at Amtrak, he is charged with the implementation of IE and CASE tools in the TPF environment, and has been using them in development for the last two years.