To get a better understanding of how Cincom ObjectStudio was developed and it’s pivotal role early in its infancy, we have provided this historical narrative. It is rather lengthy, but may be of some interest to current developers or others who enjoy historical events.
In October of 1989, the predecessor of ObjectStudio, called SCOPE (Signaal Command Oriented Programming Environment), and a number of test applications named M3I, were released in Brussels. Today, however, this event is rather unknown. The main reason for it is that ObjectStudio saw a number of owners during its lifecycle. After the release, a contract was made between HSA (Hollandse Signaalapparaten, the military division of Philips) and a software company called ENFIN, to distribute the market. For HSA, they owned the rights to the military market and Philips. ENFIN could sell the product everywhere else. Eventually, several mergers would give Cincom Systems, Inc. the rights for development and marketing of ObjectStudio, preceded by ENFIN, EASEL and VMARK. Throughout its infancy, the name of the product itself was cause for confusion. Names like SCOPE, Enfin/2, EASY and ObjectStudio saw the light. But eventually, SCOPE became ObjectStudio.
HSA was developing complex decision support systems for the navies around the world. The general name for that kind of systems was C3I (Command Control Communications Intelligence). C3I supported decision-making for the usage of weapons like missiles, guns and torpedoes, based on information achieved and filtered from radar and sonar sensors, as well as optical devices. These systems were huge and complex, the software was tailor-made and all the components were assembled on one platform like frigates and corvettes. Around 1985, HSA decided to consider the possibility to also develop C3I-systems for the army.
The Way to the Test Site
In contrast to the navy, the army had a great number of platforms. An artillery observer and radio telegrapher formed one platform. With a military map, binoculars and a measurement device, the observer would make crucial decisions and send that information to other groups. Jeeps, tanks and other vehicles in a command center were considered another platform.
It was clear that in order to support the decision-makers, three things had to be realized:
The decision support systems had to be implemented into portable PC’s.
Communication had to be integrated.
Military maps had to be digitized, virtually stored and presented in the PC self.
HSA was already experienced in digitizing and presenting maps for the navy. This experience came from the transition of synchronized radar screen pictures (the so-called, Plan Position Indication screens) to the raster scans of the conventional color screens. In addition, the radar information had to be converted from polar coordinates to Cartesian coordinates. Around 1985, color screens had the possibility of presenting a picture of 1280 x 1024 pixels. The investigation was a trade-off between the disadvantages of radar information and extra memory and the advantages of naval maps in color (with much more information as text, labels and symbols). It seems that the advantages were more essential than the disadvantages.
For the test site, a Philips PC was used, configured as a CAD workstation. Next to a small computer screen, a larger color screen with separate memory, capable of 1280 x 1024 pixels, was connected. Although the CPU was relatively slow, a military map appeared on the large color screen within ten seconds. Thus, the first prototype application (an elementary map handling system) was created, capable of digitizinged maps, loading, shifting and adding texts and symbols on each computer.
With this successful test, a number of basic problems were removed:
Scanning military paper maps without ‘flickering’.
A fluently virtual transfer of UTM (Universal Transverse Mercator) coordinates in overlapping areas to a two dimensional surface. Contrary to a paper map, every coordinate could be chosen as the center.
Comprimation of digitazed maps by assuming that sequences of the same pixels must be available.
The usage of symbols. The supplied CAD application system had plenty available.
The next challenge was the realization of a prototype decision support application. The basis was the notion that a spreadsheet was a logical coordinate system. The input and output were based on the idea that texts and formulas and their connections were using logical coordinates as A1, C3, and W22. By changing these logical coordinates to UTM-coordinates of the topographical or military maps, it was possible to use the available functions of the spreadsheet and functions of the connected available add-ins and add-ons. As a spreadsheet Lotus 1-2-3 and as add-in Decision Support One where the choices. Based on the already realized elementary map handling system, the spreadsheet and functions of Decision Support One, especially Linear Optimization a transport optimization application was developed. Data like starting points, road segments, and number of vehicles, delivery points and loads were the components. They were data fixed by the user in the map handling function, transferred to the spreadsheet then executed by the coupled linear optimization function. The results were transferred from the spreadsheet to the map handling system and displayed to the user
Due to the limited amount of memory, it was not possible to load the two applications (the map handling system and the transport application) at the same time. Besides this, MS-DOS did not allow two programs to run at the same time. Consequently, the two applications were joined by a small transient program that took care of coordinating when each application had to be loaded alternatively. As it turned out, there was no disadvantage with this process because the CAD workstation had its own memory.
By the end of 1987 ,the prototype (see picture) was presented to the Board of Directors and the CEO of Philips, who happened to be the chairman at the time. The presentation was a success and the CEO of HSA gave orders to investigate the possibilities of converting this prototype into a real decision support development system.
The Realization of SCOPE and M3I
The army had, until now, very little experience with computerized decision support systems. Of course there were written procedures to coordinate the actions of the manoeuvres (tanks, infantry), the support (artillery, low level air defence), communication and services, like military engineering and transport. However, to achieve this type of procedure on a computer, a development system was needed which made interactive prototyping possible. This would ultimately allow an efficient decision support system to become a reality. The development system must be created with the newest generation of PCs having sufficient speed and memory and an operating system that supports multi-programming with a generally accepted graphical user interface (GUI).
In 1987, there was an announcement by Microsoft and IBM of a multi-programming operating system (OS/2) that included a GUI called Presentation Manager. This seemed to conform with the required preconditions. The development system itself must contain object-oriented bricks (Smalltalk-oriented) in the field of:
Modelling for data and formulae (the kernel of a spreadsheet; the model editor).
ENFIN already had a working knowledge of these types of requirements. A trial demonstrating an Artillery Planning System proved the possibilities of their existing software. Instead of the calculated 4000 man-hours, the trial only took 1000 man-hours. This led to a joint-venture between HSA and ENFIN, aiming to transform all the software within the OS/2 and Presentation Environment to Smalltalk. As a control, the whole development requirements were defined for four decision support prototypes. The aim of these applications were threefold:
To test the usability of the working of the basic Smalltalk classes.
To get experience with interactive prototyping.
To have some kernel applications immediately available for marketing purposes.
These prototypes were multi-window systems built to handle military maps, a frequency management system to support a computerized telecommunication network, a transport optimization system and an artillery planning system. Near the end of 1989 at a computer exhibition in Vienna, the first Smalltalk-based prototype application was shown. This prototype was not yet based on OS/2 and the Presentation Manager. Similarly, a frequency management system was presented in Berne Switzerland a few days later.
In October of 1989, SCOPE (Signaal’s Command Oriented Programming Environment) was demonstrated at the AFCEA Conference in Brussels. This new development system, based on OS/2 and the Presentation Manager, included a number of prototypes. Based in Smalltalk and oriented with OS/2 and Presentation Manager, SCOPE was a 4GL object-oriented development system offering a large number of services for the specification, realization and maintenance of Management Information Systems in particular.
The SCOPE System Architecture was divided into three levels. The first level “The Object Oriented Development Environment” contained the basic tools and services needed for the creation of information systems in general. The second level “The 4GL System Classes” contained additional building blocks to develop, in a quick and secure way, Management Information Systems. The third level “The 4GL Specification Features” enables the specifying of forms, models and databases without the need for editing the specification in a programming language later. The prototypes were part of the M3I (Managing, Monitoring, Mapping, Inferring) concept. These four concepts showed how the tasks of the military decision maker C4I (Command, Control, Communication and Intelligence) could be supported.
The prototypes were:
Map handling and overlay (MO). The Map handling and Overlay application supports the Mapping function in the M3I applications by offering geographical mapping facilities. This application may in itself again be described as being a layer on top of which the other applications run.
System control and management (SYSCOM). SYSCOM was a M3I application that supported commanding officers in communication networks by dealing with all complex operational problems in the field. SYSCOM provided the user with frequency management information (information about frequencies that should be used to establish communication lines in specific areas), resource management information (information about the quality of specific communication links) and situation information (the projection of the network on its real environment).
Fire Support Resource Planning (FSRP). FSRP is a M3I application that supports the planning of the deployment of artillery resources. FSRP provided the user with resource management information (usage of type ammunition, that should be used to achieve a certain damage to a specified target) and impact analysis information (information about the impact of target characteristics and artillery means characteristics on the damage to be achieved).
Transport Resource Management (TRANSPORT). TRANSPORT is a M3I application realised both for civil as in military purposes that supports the managing of transportation means. It provided the user with environmental information (information about routes that should be followed), time management information (information about the schedule that should be used for loading and delivering), resource management information (information about the use of transportation means, like cars and divers) and situation information (the projection of the transport routes on its real environment).
Planning and Control of effectors and sensors (PACES). – PACES was a M3I application for the determination of the coverage of the separate sensors, weapons and radio’s and the determination of the quality of connections between the nodes of a communication network belonging to it.
By introducing this development system in October of 1989, SCOPE and M3I acheived the following:
It was the first object-oriented development system on a PC.
It became the first GIS (Geographical Information System) on a PC.
The positive effects of EPM (Evolutionary Prototyping Method) combined with the EPIS (Evolutionary Procurement of Information Systems) methodology was proven (EPIS ’90 symposium in The Hague).
The combination of Smalltalk and EPM was superior in relation to the traditional way of programming (as was usual in the military sector with a language like Ada).
The notion that the military could use civil components indicated what the term COTS (Commercial off-the-shelf) would become.
However, the tremendous opportunities of M3I and SCOPE were overshadowed by an enormous political event a month later. On November 9, 1989, the obligations of NATO to defend its allies against communism ended with the Berlin Wall crumbling to the ground. Because of this, the Dutch army was no longer interested in M3I and SCOPE. It would be several years before there would be interest in a command control system again.
In 1992, ENFIN released their product ENFIN/2 based on OS/2 and Windows. The marketing in Germany was strongly supported by IBM after testing and analyzing the value of the product in the United Kingdom. One of the results was that IBM came with its own object-oriented development system called Visual Age. The system had a number of various language versions like Java, Smalltalk and Pascal, but all the versions were written in Smalltalk. An object-oriented development system is optimal for extension of new classes and objects. GEBIT, a company from Berlin, released a multimedia package called MediaBuilder which was used by the ‘Haus der Geschichte’ in Bonn. During this time, a revision of ENFIN/2 was developed adding various functions which supported the whole development process from user specifications to programming. It was during this time that the whole system was renamed ObjectStudio and sold to Cincom Systems, Inc.