Soaring to new heights: Building wings @ GTAA

Soaring to new heights: Building wings @ GTAA

George Irwin
P. Eng, President/Chief Software Engineer Irwin Consulting Services Inc.
200 North Town Centre Blvd, Suite 101 Markham, Ontario CANADA L3R 8G5
Telephone: (905) 940-1038, Fax: (905) 305-0529
E-Mail: george@irwincs.com

Abstract
The Greater Toronto Airports Authority (GTAA) is one of the busiest commercial airports in North America. GTAA is currently undergoing a multi-billion dollar reconstruction and a staggering rate of information change estimated at 10-15 person-years/day. This paper will discuss the approach that GTAA took in implementing a Web-based Information Navigation and GIS System (WINGS) to "serve up" its vast storehouse of technical information to users throughout GTAA. Specifically, this paper will outline the methodology that was used, the significant technologies that were employed and the key issues that need to be addressed when using the web to deploy broad-reaching applications that incorporate spatial data. This paper will build on a presentation entitled "Building An Enterprise-Wide Spatial Information Integration Platform" presented at GITA 2000 which outlined the "platform-building" approach that was used in creating WINGS, a powerful and flexible, yet eminently usable web-based information system.

Background: GTAA, ADP & TDC
The Greater Toronto Airports Authority (GTAA) has been responsible for management, operation and maintenance of Lester B. Pearson International Airport (LBPIA) since 1996. LBPIA is Canada’s busiest airport, handling 29M passengers/year and, in terms of international passengers, it is North America’s 4th busiest airport and is the 15th busiest in the world. The infrastructure at GTAA currently includes 4 runways, 85 bridged gates, 20 aircraft positions and over 10,000 parking spaces.

Airport Development Program
The Toronto airport is currently in the midst of a massive $4.4B Airport Development Program (ADP) to improve airport infrastructure. This program includes: Terminal Development, Airside Development, Infield Development, and Utilities & Airport Support. The new facilities at GTAA are designed to handle 50M passengers per year and will include: a new terminal building (to replace terminals 1 and 2), a new parking garage (12,600 capacity), an airport people mover, new access roads and a new aircraft fueling system.

Technical Data Centre
The Technical Data Centre (TDC) is the group at GTAA that has the responsibility of managing all of the “technical” information that relates to LBPIA. More specifically, the TDC has the following mandate:

"To ensure that the airport data is up-to-date
"To provide a high quality product
"To provide efficient access to technical and graphical data and information
"To ensure that GTAA CAD/data standards are adhered to by both internal project teams and consultants
"To maintain a high level of service and communication

Why Wings?
It’s very difficult to establish “buy-in” for something that doesn’t exist, but that’s exactly what you need to do at the outset when building an enterprise-wise spatial information integration platform. Here are some of the things that we did to build momentum for WINGS.

The Business Case
The basic need for a system to manage and disseminate the vast quantity of information associated with the airport facilities at LBPIA stimulated GTAA to look at implementing GIS technology in the first place. After numerous feasibility studies and just prior to another feasibility study being undertaken, the Manager of the TDC at GTAA made a decision to veto the feasibility study and instead commissioned the implementation of a web-based Geographic Information System in 1999.

This initial need was further magnified by the construction activities associated with current airport terminal development project. It has been estimated that the TDC is currently coping with a rate of information change that is estimated at approximately 10-15 man-years/day by senior airport management. With such a staggering rate of information change, it was absolutely imperative that appropriate mechanisms both organizational and technological be put in place to assist the Technical Data Centre staff in their role as the gatekeeper of facilities information for LBPIA. After an initial pilot implementation of the GIS technology, WINGS was born.

Objectives
The next thing we did to help set WINGS on a firm footing was to define a set of objectives that we wanted to accomplish with WINGS, namely:

To provide a single tool (portal) that will enable a broad class of airport personnel to access (technical) data that is pertinent to their jobs.
To use the geographic (spatial) location of assets as a common denominator (backbone) for all relevant information about airport assets.
To expose errors and omissions in current data sources with a view to defining processes by which these errors and omissions can be corrected.
To provide an accurate inventory of airport assets with the intention of improving upon the current economic viability of airport operations. (I.e. increasing profitability)
To improve the airport personnel’s ability and readiness to respond to emergencies.
To provide relevant information to assist in airport planning and engineering activities.
To streamline airport equipment maintenance activities.
To get everyone to share and maintain his or her own (spatial and attribute) data in a format that is both consistent and appropriate.
To publish an “information catalogue” to make airport personnel aware that (technical) information is or can be made available to them.
To reduce the information maintenance load on the Technical Data Centre.

Vision Statement
Another important facet of establishing “buy-in” was to agree on a vision statement for WINGS. The vision statement for the WINGS initiative was as follows: WINGS is primarily a system that will connect people with facts, without bogging them down in minute detail. Clearly, there is no shortage of information in the world at large, least of all in LBPIA. The challenge that this system will address will be to deliver the right information that users require to make them function more efficiently in their jobs, thus enabling GTAA as a whole, to better fulfill its mission.

A big part of delivering the right information to users is providing them with an effective way to navigate through the reams of data: graphic and non-graphic, database or document-based, local or central that exist at the airport. Implicit in the ability to navigate through information is the ability to group information so that it is:

reduced to a manageable level of complexity, and
organized in a fashion that different types of users can relate to.

Name-Branding
One of the best things we did was name-branding our vision. Somehow, “WINGS” caught hold of peoples’ imaginations, even if it was just to make them hungry for pub grub or Chinese takeout. We even overheard people in the elevators in the GTAA Administration building talking about this cool new system called “WINGS”, long before we even had a working prototype that anyone, least something of all the people on the elevator could have actually seen and touched. We also had people in the IT department at GTAA audit some of our WINGS UI design meetings to ensure that what we were doing would fit in with another initiative that was being undertaken at GTAA. The fact that we had even shown up on their radarscope was testimony to the fact that we were successfully crystallizing our vision. People were taking notice.

Building an Enterprise-Wide Spatial Information Integration Platform
What follows is some theory from a previous paper that we applied in designing WINGS. As with most things theoretical, not everything could be directly applied to our efforts, but these principles help to guide our efforts so I’ve included an abridged version of some of the key points here. You can skip this section if you are bored and get right to the more practical stuff in the next section.

Information vs. Applications: The 80/20 Rule
We’ve all seen them and, to a large extent we covet them. Every year at GITA, we see some of them. Most of us also personally have had a modest role in authoring them: the “killer apps”. Killer apps are the things that make all the wading through endless reams of sporadic software vendor documentation, all the undocumented bugs, all the late nights drinking Jolt Cola, all the hair pulling, nail biting and stomach ulcers worthwhile.

Applications, however, do not exist in isolation. Information is what makes it possible to build neat applications. Just as the verb in a sentence needs a noun, similarly applications need a critical mass of information. Broadly speaking, most of what we do with computers can be classified in one of two ways: basic information manipulation and advanced information analysis (Information vs. Applications). In the GIS field, perhaps more than any other, applications rule! Of course, there is a great need for advanced spatial information analysis applications in the GIS world, and to a large extent this has been what has set the industry apart. But the reality of the situation is that most users don’t really need this level of functionality. What most users really require is easy access to pertinent information that will help them accomplish the immediate task at hand.

The problem is that most GIS systems today tend to cater to the 20% (or less) of the user community made up by users who require advanced information analysis instead of the 80% (or more) of the user community that require basic information manipulation.

Abstraction: Information And Applications
Because, all information, especially spatial information, does not presently fit neatly into rows and columns in a some kind of a “georelational” database, there is a need for some mechanism that will allow information, whether it is textual or graphic, file-based or transaction-based to be easily managed by anyone who is going to (or would like to) encounter that information. This mechanism would handle the entire user interface, business logic and data manipulation issues associated with managing this information in an object-oriented fashion. We call this mechanism an information abstraction layer (IAL), which is analogous to a hardware abstraction layer. A hardware abstraction layer isolates the operating system from the underlying hardware platform on which the O/S will be running. Similarly, an information abstraction layer isolates the user from the underlying details of how the particular information associated with his objects is managed. The IAL will encompass all significant data manipulation operations required to manage both spatial and attribute data including:

information navigation,information retrieval and information input. In addition, the IAL will deal with both file-based and transaction-based data. Information Abstraction Layer Standards Application Abstraction Layer Components As discussed earlier, both information and applications have their respective roles in any successful information systems implementation. Just as building an information abstraction layer can greatly assist in managing basic information navigation, retrieval and input, building an application abstraction layer (AAL) can assist in abstracting the information analysis capabilities of different applications.

The AAL does for applications what the IAL does for information. It provides a generic way to work with the functionality that different classes of applications provide, but in a vendor-neutral fashion. That is to say, you can choose the individual applications you need to fulfill a particular set of functionality without having to standardize on a single vendor to provide all of the functionality required.

Leveraging Internet/Intranet Technology
It’s all well and good to have universal standards for storing and accessing information and an information abstraction layer (IAL) to connect people with facts. Likewise, it’s fantastic, if perhaps a bit optimistic to have applications serving up their functionality in nicely architected software components, all of them accessible through our ubiquitous application abstraction layer (AAL). However, these elements alone cannot achieve the result that we desire. We need connectivity!

We live in a world where information and applications are distributed across an extraordinarily wide area. Fortunately, we also live in an age where the ultimate (so far) wide area network is already in place and is, coincidentally, revolutionizing the way we live and work. Internet (aka intranet/extranet) technology is the plumbing that connects the appliances (applications) with the water (information) that is flowing freely around the world today.

Bringing It All Together: The Platform
How do all of these pieces of the puzzle fit together? Well, it works something like this: the IAL is connected to the information, the AAL is connected to the applications, and the wiring is TCP/IP. When it’s all put together, the result is a platform that is both scalable and flexible and empowers the organizations to choose both information technologies and applications based on their own merits. Moreover, it doesn’t force organizations to choose a homogeneous solution and try to make everyone fit their square pegs into the round holes that we’ve carved out for them in our “solution”. The platform is built around what already exists, not around a vision that a particular GIS vendor has of the world. Users who only want information management functionality get just that and advance analytical users are empowered to accomplish more and increase the overall level of information understanding in an organization.

Wings: System Design Principles
I had to include this heading because that’s technically what I’m trained as: a Systems Design Engineer. Actually, I have a professional obligation to use some variation of that term in any publication on which I collaborate; otherwise, the professors at my alma mater have promised to visit upon me some technological plague of the university’s making (even though I don’t believe they’ll ever produce an artificially-intelligent being). Here are some things to consider as you proceed.

Re-inventing the Wheel
Implicit in our mandate to create WINGS was one “non-requirement”: “Don’t re-invent the wheel”. GTAA has invested a great deal into their existing IT infrastructure, and only a portion of this investment was into hardware and software. As organizations invest in information technology they build up a kind of “technological inertia”, much the same as a large ocean liner builds up a head of steam that carries onwards to its eventual destination. The larger the organization, the more inertia it has. Just as you can’t suddenly turn an ocean liner on a dime, you cannot change an organization’s information technology direction overnight.

This leads to a second implication for WINGS, namely that it needed to leverage the IT infrastructure that was already in place at GTAA. Even if we found a better way to do something we might not necessarily implement it if it meant discarding technology whose roots ran deep throughout the organization. Anyone who has ever tried to uproot a willow tree will know what I mean.

Resiliency
The flip side of this is that, if we do make the effort to build upon the existing IT infrastructure, we can capitalize on this “technorganizational” inertia and use it to propel our initiative forward. The only caution is that organizations do, in fact “change out” technology as it becomes obsolete or as better technology becomes available. That means, if we want our system to survive the relentless pace of technological change, we cannot allow our system to become so intertwined with a particular vendor’s technology that it becomes a “throw the baby out with the bathwater” proposition. In more practical terms, we want to be able to replace the engine that our system uses without having to build a new car. A good question to ask yourself when implementing a system is “If the GIS technology crashes, will our system crash?” If the answer to this question is “Yes”, go back to the drawing board.

Of Purists and Pragmatists
When we set out to create WINGS, we took a hard look at what we could leverage on the existing workstations deployed at GTAA. Since the workstations were all running the same operating system (or a compatible derivative), we chose to take advantage of this fact. As a result, WINGS was not implemented as a “pure” web application (I can hear your collective gasp!). Instead, we actually implemented a system that used operating system features that we knew would be on each workstation running WINGS. At the risk of authoring a paper that is not ostensibly vendorneutral, but for the sake of clarity, I’ll tell you that GTAA is a Microsoft shop and is running Windows NT/2000 on virtually all of their workstations. Don’t get me wrong – WINGS is still a multi-tier system that deploys auto magically onto a client workstation when the user navigates to our site on GTAA’s corporate intranet, but it only runs on Internet Explorer! As sacrilegious as this sounds, it gave us a tremendous amount of freedom as software engineers to ply our trade, the end-result being a system that has a more substantive look and feel than a “pure” web application. Moreover, we were able to leverage off-the-shelf ActiveX controls (Whoops, did I say that out loud?), which meant less re-inventing the wheel; although the particular circular rotating transportation device that we chose to leverage is one that I personally wouldn’t mind reinventing.

Making Lemonade
Sometimes, leveraging existing technology is tantamount to making lemonade. You know the expression: “If you get lemons, make lemonade!” Where WINGS was concerned, making one particular technology work actually required our writing a Windows NT Service resuscitator to restart the services for another vendor’s technology that kept crashing. Although this wasn’t necessarily the most desirable or even productive use of our programming talents, it was the most necessary use of our desirable and productive programming talents. If writing a life-support system for someone else’s software is what we needed to do then that’s what we did.

Some Final Thoughts
As I reflect upon our initial vision for WINGS and what we ultimately achieved (and hope to continue to achieve in the future), I am at once proud and humbled (I don’t know if it’s even possible to be both of these things in one sentence.) I believe WINGS is a remarkable accomplishment, one that couldn’t have happened without a lot of blood, sweat and tears (but then most things of value in this life require all of these things). One of the most rewarding testimonies I have ever heard regarding WINGS (other than the guys I overheard in the elevator) was from a GIS vendor who after seeing a short demo of WINGS, said “Lot’s of people have talked about doing something like this, but you guys actually went out and did it.”

At the same time, I am humbled to have had the opportunity to be part of a tremendously talented team that included a remarkably patient and understanding client who, together, moulded this incredibly sophisticated technology (GIS) into a living, breathing entity that we hope will have a long lifespan indeed.