The Global Decision Support System (GDSS) is a Military Command and Control System (MCCS) built for the United States Air Force, Military Airlift Command (MAC). It was built on a very short schedule and limited budget. It was a matter of very serious urgency that the MAC have a state-of-the-art MCCS for the tracking and control of all of its assets around the world. The basic estimate for such a sys- tem was a cost of $200 million and a schedule of 7 years, which was not acceptable to HQ/MAC. So, the development schedule was set at 21 months, and the budget capped at $16.5 million. The question before the Air Force and JPL was whether it was possible to build a system of this complexity under such a short schedule. We decided to give it a try and to build it as a prototype for the all the uniformed ser- vices.
Software Development Standard: DOD-STD-2167A, waived by USAF due to schedule restrictions, and replaced by the Rapid Development Methodology devel- oped by S. Mike de Gyurky.
Documentation: GDSS FRD, TIP, Concept of Operations, GDSS Design Book, and GDSS User Guide, one of each per application subsystem. The GDSS Techni- cal Bulletin, Design Book User Guide, GDSS Interface Control Document, GDSS System Message Manual, GDSS Test Plans, all documented in 5,000 pages.
14.2.1 GDSS System Size
At Final Operational Capability: 7 October 1987. 492,000 source lines of new code.
Total cost:$16.4 million.
Note:The customer was so pleased with the GDSS product that they requested one more year of additional requirements to be added to the baseline.8
At End of Project: 30 September 1988. 971,600 source lines of new code.
8See Figure 12, the official GDSS memo of recognition.
CASE STUDY TWO: THE GLOBAL DECISION SUPPORT SYSTEM (GDSS) 211
Final Cost:$27.0 million.
Languages:GDSS was programmed in Ada, C, and Fortran.
Cost/Line of Code: $27.80 per commented line of code.
14.2.2 The History and Background of GDSS
This is a brief encapsulation of the Global Decision Support System (GDSS) built for the U.S. Air Force’s Military Airlift Command, between December 1986 and October 1988. GDSS was an extremely interesting puzzle to solve, the solution to which was at least partially rooted in the Allied Command Europe (ACE) CCIS.
I had just returned from delivering the Joint Theater Level Simulation to one of our customers when I was informed that we were stuck with this project, and what the circumstances surrounding it were.
Our section and division had inherited the responsibility of building a command and control system for the U.S. Air Force (USAF), specifically for Military Airlift Command (MAC). There were several important functional and technical factors that made it nearly impossible.
The schedule from start to completion was to be 21 months. There were to be three software deliveries, the first was to be in nine months, and the other two in six-month increments.
GDSS was to be a large, geographically distributed, near real-time system that would enable the Numbered Air Force bases of MAC to control its resources efficiently and reduce the cost of operations. (MAC is the largest airline in the world, transporting cargo and personnel around the world under all political and climatic conditions.) The network was to link the following Air Force bases:
HQ/MAC at Scott AFB, Illinois 23rd NAF at Hurlburt AFB, Florida
The ANG at Andrews AFB, Washington, DC The 22nd NAF at Travis AFB, California The 21st NAF at Maguire AFB, New Jersey The 834th ALD at Hickam AFB, Hawaii The 322nd ALD at Ramstein AFB, Germany
For the duration of the development I would add JPL as an NAF-like node. Each node would need to contain the identical functional task groups:
Operations, which is responsible for flight scheduling.
Transportation, with personnel ticketing, is responsible for cargo handling, loading, and unloading.
Command and Control, which is responsible for flight following.
Logistics, which ensures that en route mechanical failures are serviced promptly.
Crisis Action, which is responsible for the management of threats and emergencies.
GDSS was to be designed to accommodate 400 sorties on a daily basis. In the event of war, with the addition of civilian cargo and passenger aircraft, it must accommodate up to 1,600 airlift sorties per day.9
GDSS had to link to the World Wide Military Command and Control System (WWMCCS), which was based on Honeywell 6060 computers, and from there to AutoDIN. We were going to use TransLAN (DDN/PSN) for development, with a development bandwidth available at 7.6 KBS. At the operational stage, the network would be provided a two-way bandwidth of 28.8 KB between NAF nodes and 19.2 KB to the two ALDs (Air Lift Divisions).
A state-of-the-art user interface with both graphical and alphanumeric displays was to be provided. There was an additional large-scale situation display at the HQ/MAC Operations Center using two Visulux Laser Projectors, projecting a 3215-foot-high resolution display onto a motion picture quality screen.
Funding was set at an upper limit of $16.5 million for software development, with the Air Force providing computer hardware (DEC VAX 8600s, disk drives, terminals, MicroVAX-II and IV minicomputers, and the operating systems).
The system was to provide all office automation services possible to reduce the workload of the staff required to run MAC manually (36 Officers and NCOs per shift, three 8-hour shifts per site). GDSS had to be ‘‘survivable’’ and operational in case of a worldwide conflict with the USSR.
14.2.3 Expediting the System
To expedite development, the system was to be implemented with ‘‘vanilla’’ Digital Equipment Corporation hardware and software if it would help to get the system completed on budget.
There was a reason for expediting the development. The tremendous pressure to get this MAC CCIS done was caused by a failure in our military command and control system. During the 1983 Grenada operation, an Air Force Colonel on the ground in Grenada had to use a public telephone to call Pope AFB in North Carolina, get patched through to Ft. Bragg in California, and then had a patch put through to the airlift commander of the U.S. Airborne Task Force with the paratroops of an 82nd Airborne Division to provide the latest tactical infor- mation on the drop zone. With all the funds spent by the Department of Defense on command and control systems, we did not have an integrated command and control network between the services and joint tactical commands. Thus, JPL
9During Operation Desert Storm, the Force Generation and Staging Phase, the addition of allied transport aircraft pushed the sortie generation to 6,400 per 24 hours. GDSS was able to handle the load without problem. Also during this period, an additional ad hoc node was added to GDSS, a mobile one stationed in Kuwait. Again the automatic systems software accommodated the addition without a hitch. We received compliments for this technical feat, unprecedented in its day.
CASE STUDY TWO: THE GLOBAL DECISION SUPPORT SYSTEM (GDSS) 213
had the privilege to do the job, within 21 months, and under the cost ceiling of
$16.5 million.
The basic requirements presented a number of implied requirements that were not stated. A system such as the one the Air Force wanted could not be accom- plished at the time, in 1986, without a few completely new technology thrusts.
14.2.4 The Euler Sphere
A uniquely new way of looking at a systems architecture was called variously the
‘‘Euler sphere’’ or the ‘‘GDSS donut.’’ This was in reality nothing new, as it had been first used by the mathematician Euler. This is a representation in the form of spheres as opposed to boxes and was of enormous help to me to express what I wanted, and what was needed to get underway.10 But, its successful application and use depended on the level of intelligence of the team members, in particular in the area of translating abstract concepts into practical and programmable soft- ware entities, which they would then be able to put into code. The visualization of the technical manager as architect is very important, but of equal importance is the intelligence of the team. I was very fortunate—by sheer luck I had a team of unequalled ability, vision, and skill. This was essential in creating the Globally Distributed Mini/Super-Minicomputer System (GDMSMCS), based on Digital Equipment Corporation (DEC) VAX 8550, 8600 and MicroVAX-II computers and peripherals, using at that time the best operating system available, VMS, and other DEC software as a design baseline.
14.2.5 Beyond State of the Art
GDSS was the beginning of the termMethodology for Rapid Development. At the time, it was absolutely state-of-the-art technology, using a new approach to archi- tecture articulation, as well as a new approach to development methodology and process, which is still valid today. Keep in mind that DEC computer hardware and software at the time of the GDSS development period were the best in the industry.
What follows are some of the technological highlights and innovations that made GDSS such an unprecedented feat of engineering in its day.
14.2.6 A Replicated, Survivable, Synchronous Database Management System
No such thing as a replicated, survivable, synchronous database management system existed at this time. This was a most unique approach to database design.
The GDSS DBMS, instead of having one master database that updated the others, had all master databases that continually maintained each other in a current state.
10Arthur Schopenhauer.Die Welt als Wille und Vorstellung (The World as Will and Imagination), Hoffmans Verlag AG, Zurich 1988. also Deutscher Taschenbuch Verlag, Munchen 1998 pages 76–83.
When one or two local databases had a problem of any sort, the user still would transparently have access to the remote replicated and synchronized surviving data- base of any of the other sites.
14.2.7 The Ultra Large Screen Display System
The Ultra Large Screen Display system (ULSD) provided the MAC decision makers with a worldwide view of all MAC assets, their location, and status. The ULSD utilized two Visulux 1050 laser projectors driven by a MicroVAX II through a 32-bit graphics frame buffer. The image was 3215 feet of high-resolution graphics rear-projected onto a semitransparent motion picture screen. The ULSD was backed up by a new invention by Dr. Don Wedding: large monochrome plasma displays.
14.2.8 The Local Area Networks
GDSS is composed of eight LANs. The GDSS Wide Area Network Configuration figure (Figure 10) shows one LAN at each of the GDSS sites, including the JPL development LAN. The LANs used DEC Ethernet hardware and DECnet-based communications software.
14.2.9 The Wide Area Network
The wide area network used TransLAN hardware that functioned as a datagram repeater, passing all datagrams through the WAN unchanged. Ultimately, when the interface was developed during FY 1988, we switched to the Defense Data Net- work, DDN (Figure 10).
14.2.10 Distributed Client/Server Technology
The system team came up with a novel distributed hierarchical client/server model of communicating between GDSS elements, locally and remotely. This allows any GDSS application to act as sender or receiver to/from a GDSS server process. The servers then communicate to the destination, thus extending a local node’s ‘‘reach’’
to any of the nodes connected at the time. In this way, each node is made aware of the other GDSS nodes that are online, enabling them to synchronize databases auto- matically among themselves.
14.2.11 Message Bus
GDSS also is noted for its origination of the message bus or middleware paradigm, which allows an application to communicate to any other through standardized high-level function calls, thereby hiding the communications-specific protocols from the applications programmers. Automatic message queuing and ‘‘store and forward’’ technologies allow messages sent to offline destinations to be retained (archived), and delivered when they come back online. And, due to the restricted
CASE STUDY TWO: THE GLOBAL DECISION SUPPORT SYSTEM (GDSS) 215
Figure 10. The GDSS wide area network topology.
network bandwidth, GDSS employs a run-length compression scheme for all message packets sent remotely.
14.2.12 The GDSS Software Architecture
The GDSS system software design allows users, after the appropriate authentication procedure has been completed, to use any terminal to gain access to the desired GDSS function. The GDSS Integrated Software Functional Diagram, Figure 11, known as the ‘‘GDSS donut,’’ shows the system-level software architecture of GDSS. I’d like to note here that I found it easier to describe to my team how the system-level architecture should look like using Euler’s approach rather than agonize over block diagrams. Fortunately my team understood, while upper management didn’t. But then, upper management did not have to build the system, I did.
At the center of the GDSS donut (Euler sphere) is the VAX/VMS operating sys- tem, which provides process connections between all GDSS system and application support software.
Surrounding the VMS core is a circled layer of COTS packages, commercially available off-the-shelf layered software products. Contained within this level of software is a variety of compilers,11 the Configuration Management System (CMS), the relational database (DEC/RDB), the All-In-One office automation soft- ware, the DECnet message protocol software, and a variety of other software pro- ductivity tools and packages.
The next circle outward is called the GDSS System Software. This common software services layer provides the software connectivity between the inner circles and the next outward circle, which contain the system servers (the first-ever large- scale distributed client/server technology) and the replicable, survivable, and syn- chronous DBMS (built as a team effort between JPL and DEC).
Outside the GDSS System Software layer is the GDSS System Server layer. In this layer are the server processes that control the underlying operation of GDSS, acting as bridges between the GDSS software applications and the inner layers, the DBMS, and the network.
The GDSS software applications surround the GDSS system server layer. In this way, all applications can access the DBMS and the servers needed to perform their assigned tasks. The users are connected to their local systems via a LAN, and to remote systems via the GDSS Node Network Connectivity (GDSS WAN) and the External Systems Network Connectivity. GDSS also ensures that all system hardware and network addresses are accessed by logical or virtual addresses rather than by hard-coded physical addresses.
11Note re: compilers for Ada, C, and Fortran. Approximately 50% of the GDSS software was written in Ada, a wonderfully stable language, especially ideal for spacecraft onboard computers using the RAD 6000 series 1750A architecture. The balance of the GDSS software was written in C and Fortran, augmented by a variety of software preprocessors. This was not my usual approach to development, but on a very tight schedule, all usable, mature COTS packages had to be exploited.
CASE STUDY TWO: THE GLOBAL DECISION SUPPORT SYSTEM (GDSS) 217
Figure11.TheGDSSsoftwarefunctional
218
Figure 12. Official GDSS recognition from General Duane Cassidy.
CASE STUDY TWO: THE GLOBAL DECISION SUPPORT SYSTEM (GDSS) 219
14.2.13 Accepting the Challenge
When I was asked whether a serious command and control system with military imperatives could be built within 21 months for under $20 million, I was taken off-guard. I had never thought about such a short schedule, limited level of funding, and global scale. However, I did think about solving the problem of developing the ACE CCIS at SHAPE in Belgium, which was huge and very costly. I told my sec- tion and my division that it could be done, but that I was not going to apply for the job. I had just delivered the Joint Theater Level Simulation to the Army, and it had not been a picnic. I really love the Army, it was my teacher, it paid for my education and taught me everything imaginable, but my fellow combat arms officers are not known for their creativity (with a few notable exceptions, of course). It took extreme patience to explain theoretical concepts to them. I was worn out after three years of hard, grinding work.
I told them that if I were to do it, they would have toorderme to do it. And if they did that, there would have to be waived rules, and lots of trust on their part.
Then I would do it out of duty and out of friendship. I knew some of the big pro- blems already. At SHAPE, my boss, teacher, and mentor Col. Joseph Bullers (who had been Gen. Curtis LeMay’s command and control officer at SAC) and I were fought at every turn. We were in Operations Division, Command and Control Branch. The Information Systems Division did not want the users to be involved in determining what we needed to do our jobs. Then there was the big power of WWMCCS with their Honeywell 6060 machines, while we came to the conclusion after the completion of the requirements, that the DEC PDP-11, in 1977, was the best for the task. Naturally, I was shot out of the water; we got H-6060s.
As it turned out, I was told that like it or not, I wouldhaveto do GDSS. JPL’s reputation was on the line, and without a responsive, fast, trouble-free CCIS, Military Airlift Command would not be able to respond effectively to a worldwide crisis. So, I agreed.
14.2.14 Initial Conditions
The first thing I did was to fly up to Scott AFB, HQ/MAC, and talk with the Chief of Staff. He was curious. ‘‘Can it be done?’’ he asked.
I told him that it could be done, but the Air Force would need to waive my favor- ite standard, DOD-STD-2167A, and I’d follow the ‘‘Joint Logistics Commanders Guidance, For the Use of an Evolutionary Acquisition Strategy in Acquiring Com- mand and Control Systems,’’ which was just about to be published, and about which I had talked to a Brigadier General at Ft. Belvoir, Virginia.
This meant that there would be no ‘‘throwing over the wall’’ a system unfamiliar to the user. If we were going to build this in 21 months, then all users of the system would need to work with my JPL development team on a daily basis, as needed.
This condition also applied to DEC. GDSS would be a vanilla DEC system, with DEC benefiting from the development of the products. DEC was to be the sus- taining engineering contractor, so they would have to work with us as the third
member of the team. The COS agreed, we shook hands, and the GDSS Design Team JPL-MAC-DEC came into being. This shows right off the starting line that when a customer is serious about wanting a product, it will support the developer wholeheartedly. It also shows that it takes a team of serious people to get the job done. Without the Chief of Staff behind the system, it would have taken the original Air Force estimate of $200 million and 7 years. I fully believe that this is a true and honest estimate.
A group of very talented DEC engineers was assigned to work under my control.
At first, they felt that they would be the ‘‘go between’’ for the project manager (me) and DEC. For the sake of unity of command, it was made clear that for the duration, they would work for me. It was okay; this idea worked fine.
The next issue to be solved was the architecture. The design team had to have a systems structure to focus on and get to understand. This was not a trivial task. My old friends who were experienced in DEC VAX/VMS first of all felt that it was their prerogative to take charge of the system, and to let me count beans, travel, and go to meetings. This too is understandable, because these are the things managers typi- cally do. (By the way, travel and meetings are the by far the largest consumers of time on a project. In Chapter 8, on cost estimates, I go into detail about this.) So for a manager on a very tight schedule, there has to be a creative approach to the issue of meetings and reviews as well as travel, with the objective of getting the maxi- mum benefit out of them.
14.2.15 Rapid Development: A Totally Different Approach
A totally different methodology is required in a rapid development environment than in a traditional one. The methodology is unique; it is not ‘‘prototyping’’ as some people who do not understand the difference like to call it. A prototype system may be the end result of the effort, such as GDSS became for the DOD, but it is not a ‘‘methodology.’’
I spent an inordinate amount of time trying to explain to a few highly placed managers the difference between the rapid development methodology and a tradi- tional one; it was useless, because the Kantian ‘‘wells of experience’’12were not there. Without the experience on part of the listener, there is no understanding:
‘‘You have eyes, but you cannot see. You have ears, but you cannot hear.’’ If there is no experience factor in the listener, and no analytical ability of abstract con- cepts, he will subjectively interpret what you are trying to explain. Your transmis- sion is simply dumped into the mental trash bin by the reasoning of ‘‘I don’t know, and I don’t understand.’’
As an analogy, the difference between traditional development and rapid devel- opment is like the difference between the military command and control measures and operational rules of an Armored Division versus the role of a Cavalry Regimen- tal Combat Group in its Corps Covering Force Mission. The armored division is large and cumbersome. Even when led by a very talented commander like Rommel
12Immanuel Kant,Critique der Praktischer Vernunft(Quellen der Erfahrung).
CASE STUDY TWO: THE GLOBAL DECISION SUPPORT SYSTEM (GDSS) 221