Programming considered harmful for application development (and reuse)

Jan R. Schultz and Jeff Sutherland
© 1999 Jan R. Schultz and Jeff Sutherland
IDX faces a challenge similar to most vertical market application vendors. We get 90% of our revenues from legacy systems that need to be updated. Within the past five years, we have spent millions of dollars and many person-years of effort building new systems to the latest "market driven" standards only to find the standards changing as we develop. It is very difficult to build with the new technology because it is unstable and incomplete. The end results of the development efforts are not scalable in terms of any of the "ilities" to the size of the old "outdated" systems, all of which results in our inability to meet market expectations for our new systems.

We are moving towards a Web based component technology architecture that will support both ActiveX and JavaBeans/CORBA environments. The architecture encapsulates much of the new technology behind facades that we control. The facades define the architectural elements that we use to build our applications. We can then build our applications within this framework and take advantage of new technology, which is encapsulated "in one place" within our architecture instead of being spread throughout all of our applications’ code. Reuse also requires a stable, well-defined architecture and, given the rapid evolution of the current technology, an architecture that encapsulates the new technology behind facades that we control is essential.

Because of the unique nature of large medical systems, we need to support configuration management of large combined legacy and new systems that have multiple versions in different sites that are constantly being modified without necessarily upgrading the whole system. The key to this approach is taking advantage of techniques that are widely used within parts of the medical vendor marketplace for many years. The techniques are the result of "early" developments with what is now considered legacy technology. There are at least three medical information systems vendors: IDX / PHAMIS, Eclipsis / TDS and Vencor / PROMIS who have hundreds of systems installed in some of the largest medical organizations in this country using "table-driven" technology.

The basis for the technology centers on a "table-driven" application construction methodology (which includes the UI) and is based upon Marvin Minsky’s [4] frame technology. Knowledge can be captured within a frame that represents some aspect of an application that can have a variety of specific instances. The instances can have properties removed as well as added. The frame can be a GUI screen definition, an interface to the Business Objects layer or even a Business Object layer instance definition. As Bassett says [3] page 88: "A frame is both an adaptable component and a bill of materials".

Another commercially available example is Magic, (http://www.magic-sw.com/) a product with a "table-driven" engine-based technology. It stores business rules and logic in tables that are interpreted by the Magic engine that contains all of the built-in functionality used to create sophisticated applications. Magic consistently wins RAD contests and builds significantly more application within a fixed time than any other RAD technology.

Netron’s Frames (http://www.netron.com/index.html) is a commercial version of a frame technology. Netron’s products are typically used to connect Visual Basic, PowerBuilder or Java clients to COBOL servers. The combination of the Netron development environment with a set of Netron/user defined components results in applications with very high reuse numbers. Bassett reports reuse percentages between 70 and 90 with some examples in the high 90%. This technology is a construction-time tool that table-drives code generation. An example from Bassett’s book [3] of a Netron customer is an IS shop for a $10 billion revenue multi-national company that handles 28,000 requests per year with 40 staff members. Clearly, they are not programming in the usual sense; there IS shop has achieved "cultural-reuse maturity level 4".

What does all of this mean for where we need to go? There is something missing from our current development environments and tools. Dealing with complexity only at run-time is inadequate. All of the systems mentioned above have mechanisms that allow construction-time specification of applications. Construction-time specification of applications allows programmers to develop applications very rapidly without having to do lots of programming.

The problem at a very high level is that knowledge has to be separated from operations. Both of the most highly recommended books on object modeling [1,2] separate the knowledge level from the operational level within an object model. Fowler says, "Instantiating the knowledge level is effectively configuring the system, which is a constrained, and thus simpler, form of programming." This is the table-driven part of the application. The domain expert (read non-programmer) can fill tables and let the operational level of the system take over at run-time by interpreting the tables.

Many data modelers consider the knowledge level data the specification of the meta-model. Alan Kay has again stirred the computer science community with the new version of Smalltalk – Squeak – that is written in Smalltalk and is extensible. The class hierarchy and the virtual machine can be changed and the language can evolve. This is a great example of the power of a construction-time meta-model (i.e., the meta-object protocol) and is the type of system that needs to be built for rapid construction of large, complex, rapidly changing applications. See http://jeffsutherland.org/oopsla97/mop.html for more information.

Why is it that some of the early medical systems were table-driven? What comes to mind is Stafford Beer’s notion that the controlling system needs as much variety as the controlled system or else it won’t serve its intended function. Early developers of medical systems could not be successful without allowing the content folks – physicians, radiologists, nurses, patient’s accounts managers, etc. - to be developers. This is developer with a small "d" in that what they do in enter medical knowledge using various forms of "table" editors or by going through what are now called "wizards" that define the run-time operations of the applications. For some of the very large systems, there would have been no way to "program" all of the knowldege required for the applications, if a programmer had to write code to program all of the medical content (rules and knowledge) into the system. The PROMIS system that Schultz developed had over 40,000 frames of medical knowledge within it [5].

The unique nature of large medical systems is driving us towards overlaying the component architecture with frame based technology that allow user customization and multiple version support. We think that compositional architectures may have something to say about how we should implement these systems. Adding the frame-based technology to the component architecture may allow compositional architectures to be applied throughout the total life cycle of a system.

[1] Martin Fowler, Analysis Patterns: Reusable Object Models Menlo Park, CA: Addison-Wesley, 1997

[2] David C. Hay, Data Model Patterns: Conventions of Thought New York: Dorset House Publishing, 1995

[3] Paul G. Bassett, Framing Software Reuse: Lessons From the Real World, New Jersey: Yourdon Press, Prentice Hall, 1996.

[4] Marvin Minsky, "A Framework for representing knowledge," in The Psychology of Computer Vision, P. Winston, ed. New York: McGraw-Hill, 1975, pp. 211-277.

[5] Schultz, Jan, "A History of the PROMIS Technology: An Effective Human Interface," in A History of Personal Workstations, Adele Goldberg, ed. New York: ACM Press, 1988, pp. 439-488.