Soaring to new heights: Building wings @ GTAA
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.