National Academies Press: OpenBook

Integrating Airport Information Systems (2009)

Chapter: Chapter 6 - Architecture, Strategies, Technologies, and Contracts

« Previous: Chapter 5 - Airport Systems
Page 70
Suggested Citation:"Chapter 6 - Architecture, Strategies, Technologies, and Contracts." National Academies of Sciences, Engineering, and Medicine. 2009. Integrating Airport Information Systems. Washington, DC: The National Academies Press. doi: 10.17226/14234.
×
Page 70
Page 71
Suggested Citation:"Chapter 6 - Architecture, Strategies, Technologies, and Contracts." National Academies of Sciences, Engineering, and Medicine. 2009. Integrating Airport Information Systems. Washington, DC: The National Academies Press. doi: 10.17226/14234.
×
Page 71
Page 72
Suggested Citation:"Chapter 6 - Architecture, Strategies, Technologies, and Contracts." National Academies of Sciences, Engineering, and Medicine. 2009. Integrating Airport Information Systems. Washington, DC: The National Academies Press. doi: 10.17226/14234.
×
Page 72
Page 73
Suggested Citation:"Chapter 6 - Architecture, Strategies, Technologies, and Contracts." National Academies of Sciences, Engineering, and Medicine. 2009. Integrating Airport Information Systems. Washington, DC: The National Academies Press. doi: 10.17226/14234.
×
Page 73
Page 74
Suggested Citation:"Chapter 6 - Architecture, Strategies, Technologies, and Contracts." National Academies of Sciences, Engineering, and Medicine. 2009. Integrating Airport Information Systems. Washington, DC: The National Academies Press. doi: 10.17226/14234.
×
Page 74
Page 75
Suggested Citation:"Chapter 6 - Architecture, Strategies, Technologies, and Contracts." National Academies of Sciences, Engineering, and Medicine. 2009. Integrating Airport Information Systems. Washington, DC: The National Academies Press. doi: 10.17226/14234.
×
Page 75
Page 76
Suggested Citation:"Chapter 6 - Architecture, Strategies, Technologies, and Contracts." National Academies of Sciences, Engineering, and Medicine. 2009. Integrating Airport Information Systems. Washington, DC: The National Academies Press. doi: 10.17226/14234.
×
Page 76
Page 77
Suggested Citation:"Chapter 6 - Architecture, Strategies, Technologies, and Contracts." National Academies of Sciences, Engineering, and Medicine. 2009. Integrating Airport Information Systems. Washington, DC: The National Academies Press. doi: 10.17226/14234.
×
Page 77

Below is the uncorrected machine-read text of this chapter, intended to provide our own search engines and external engines with highly rich, chapter-representative searchable text of each book. Because it is UNCORRECTED material, please consider the following text as a useful but insufficient proxy for the authoritative book pages.

70 To determine an appropriate integration strategy, including what technologies to employ, airport management needs to have a basic understanding of current system architecture. This chapter provides discussions of the following: • Systems Architecture, including discussions about open architecture, protocols, and legacy systems; • Integration Strategies and Technologies, including discussions and an assessment of the strengths and weaknesses of various strategies; and • Software Contracts, including descriptions of several standard types of contracts in the context of an airport enterprise, along with some provisions the contracts typically contain. Systems Architecture Open Architecture Systems When a system is said to have an open architecture, it means that the system can be added onto or integrated easily because the inner workings (architecture) of the system are transparent to everyone. System developers can accomplish system transparency in many ways, including the following: • Conform to standards that are approved by various trade organizations, such as the Interna- tional Organization for Standards (ISO) and American National Standards Institute (ANSI); • Create an Application Programming Interface (API) and publish a reference guide that describes how to interact with the system; • Use relational databases to store system data along with documentation of the database schema (how the data are organized into tables and columns); and • Rely on a built-in standard scripting language to customize and enhance the system. A closed architecture system, on the other hand, is one that does not allow for easy modifica- tion or integration, because the inner workings of the system are not transparent. Many times though, closed architecture systems make sense for an airport, such as when the software vendor allows for data to be extracted and easily integrated into other systems. Typically, closed archi- tecture systems have some or all of the following characteristics: • Data storage in a proprietary format that is not documented and cannot be accessed by other software, • Little to no mention of or conformance to standards, • No published APIs, • No scripting capability, and • Proprietary scripting language used to customize and enhance the system. C H A P T E R 6 Architecture, Strategies, Technologies, and Contracts

There can be confusion between the terms open architecture and open source. Open source refers to the legal ownership of the programming language source code used to build the software. An open source system is one where the program source code is freely available to everyone and can be used and modified at will, provided that certain legal conditions are met. Open source systems are, by their very nature, open architecture, because the necessary transparency is more than adequately provided by the public availability of the source code. On the other hand, a system does not have to be open source to be open architecture. A com- pany can develop an open architecture system while still keeping the source code private. Follow- ing are some of the many benefits of using open architecture systems: • It is easier to integrate between open systems. • People can add features as they become necessary in the future. • It is easier to find technical resources to maintain open systems. When procuring software systems, answer the following questions to ensure that the system is based on an open architecture: • Are the data stored in a relational database, and is there documentation on the database schema? • Are there documented APIs for integrating with this system? • What industry standards does this system support? • Are there any built-in mechanisms for customizing or enhancing this product? Do the mech- anisms use a proprietary programming language or a standardized scripting language? • Are there other software systems that integrate with this system out of the box? What technolo- gies are used in that integration? Protocols A significant piece of most system architectures is the protocols the system uses. A protocol is a set of rules that allows multiple systems to exchange information. A protocol is like a diction- ary that helps you communicate in a foreign language when traveling. If you need to find a restaurant, you can use an English-French dictionary to find the French phrase to ask “Where is the nearest restaurant?” But just as these translation dictionaries are limited, most protocols do not allow for every conceivable piece of information to be communicated. As with system architectures, protocols can be open or closed. An open protocol is one that follows a published standard, such as TCP/IP, the set of communications protocols used by the Internet. Open protocols allow multiple vendors to build systems that interact with each other because they speak the same language. A closed protocol is a protocol that is specific to one ven- dor and is not published or standardized. Closed protocols allow multiple systems from the same vendor to communicate, but if you buy a new system from a different vendor, it will not support that protocol. Legacy Systems The term legacy system refers to an old computer system that is still in use well past its origi- nal life expectancy. Many legacy systems in use today were created before the popularity of open architecture computing. Some legacy systems might have been built on an open architecture that was valid when they were built, but the standards used then are so old that newer systems do not support them today. Any legacy system, whether open architecture or not, can hinder integra- tion because of the following: • Lack of resources with knowledge of the system architecture, • Hard to find or non-existent documentation on the system and/or standards, or • Difficulty or impossibility of upgrading. Architecture, Strategies, Technologies, and Contracts 71

With these drawbacks, why are legacy systems still in use? Some reasons not to replace a legacy system are as follows: • The cost of replacing the system is too high. • No one knows exactly how the system works or everything it does, so replacing it is risky. • The system was built to be highly available and cannot be taken down. Integration Strategies and Technologies In this Handbook, strategies refers to a specific software systems integration approach. Each strategy has different strengths and weaknesses and is appropriate for different situations. Under- standing how these strategies work is key to determining the most effective strategy for a partic- ular airport’s situation. Technology refers to the tools used to build and integrate software. Integration technologies include the following: • Standards used to format and store data, such as Structured Query Language (SQL) and XML; • Software techniques such as relational databases and online analytical processing (OLAP); and • RP, such as CUPPS. The use of a specific technology does not imply the use of any particular strategy. For example, XML is a technology that is widely relied on to integrate software systems, and it can be used to implement all of the strategies described in this Handbook. Integration Strategies This section describes popular software systems integration strategies (i.e., data warehousing, enterprise information integration, and enterprise application integration) and compares their strengths and weaknesses. Data Warehousing This strategy gathers data from different software systems and puts the data in a central location called a data warehouse. The warehouse uses software to scrub the data—apply preset business rules and analyze the data—to use the data in preset calculations to provide needed information. Other systems then go to this central location to get the data as input for their calculations, or in the case of a large data warehouse, data is first distributed to departmental data marts, such as a financial data mart or operations data mart. Think of the data in a data warehouse as the items sold by a large retail chain. All of the items (data) are received from the different manufacturers (software systems) in the central warehouse (data warehouse). The employees (data scrubbing routines) of the central warehouse ensure that the items received meet the standards of the retail chain. The items are organized and distributed to the retail stores (data marts) based on which stores need what items. When IT people discuss data warehousing, they often mention an associated strategy called Extract, Transform, and Load (ETL). This strategy typically uses technologies like open databases, flat files, and XML to extract the data from various sources before transforming or scrubbing the data so that it can be loaded into the data warehouse. The data warehouse and data marts are usually made up of one or more databases. These databases identify relationships between data and provide for open communication of data between databases. The data in a data warehouse or data mart are read-only, so they cannot be modified. Therefore, this strategy is used only for viewing and reporting on data; it does not allow software systems to interact with each other. 72 Integrating Airport Information Systems

Figure 6-1 shows how a typical airport’s information process would look using a data warehouse strategy. The strengths and weaknesses of data warehousing are as follows: • Strengths. Good for analyzing historical data, analyzing trends, and finding hidden correla- tions in data. • Weaknesses. To the extent that making real-time decisions is important, this strategy may not be as appropriate. Enterprise Information Integration This strategy leaves data in the various software systems and a central EII software program gets data from those systems when data are needed. The information in these various systems is termed distributed data. The EII software presents a single, unified model of the distributed data so that queries and reports can be written against this central model, regardless of in which system individual data elements reside. Think of an EII system as a multi-restaurant delivery service. The customer (a report or query) calls the delivery service (EII software) and orders Chinese food (accounting data), pizza (main- tenance data), and an apple pie for dessert (flight data). The delivery service picks up the food from three different restaurants (software systems) and delivers it to the customer. In discussing EII software, people often mention technologies like Open Database Connectiv- ity (ODBC), Java Database Connectivity (JDBC), and Web Services. These technologies are used to access data from the various distributed sources. Some of the strengths and weaknesses of EII are as follows: • Strengths – Because data are left in the original software system, reports are always up to date. – Users can access data from multiple systems in an integrated manner. Architecture, Strategies, Technologies, and Contracts 73 Figure 6-1. Schema for data warehousing strategy.

• Weaknesses – Because the data are not stored in a central location, how much and how historic data are cap- tured is up to the original software. Thus, queries and analyzing past data can be a problem. – Performance can be a problem because each system is last accessed in real-time. – Configuration of the EII system (deciding where data comes from, which data to ignore, etc.) can be complicated. Enterprise Application Integration This strategy links various software systems to form a single, integrated system. This type of integration is on the far end of the integration spectrum, integrating not just data but systems and processes. From the viewpoint of a user, systems integrated using EAI can appear to be a single piece of software, although multiple different software systems are behind the scenes. Think of an EAI system as a large Broadway production. A member of the audience (user) sees a coordinated performance of people, props, lights, and sound (various software systems). From the audience point of view, it seems like everything is coordinated perfectly according to plan. Back stage, a director (EAI software) is making sure that the people in charge of the cast, lighting, sound, and props are all coordinated properly. Technologies often associated with EAI software are Web Services and Service Oriented Archi- tecture (SOA). These technologies are used to provide integration, not just at the data level, but at the functional level. For example, business processes might dictate that a specific action in the accounting system (marking an account as delinquent) causes an action in the operations system (marking all work orders for that account as on hold). Web services that allow manipulation of work orders in the operations system might be used to accomplish this kind of integration. Some of the strengths and weaknesses of EAI are as follows: • Strengths. EAI is the strongest form of integration techniques because it leads to what appears to be a single system from the user’s perspective. • Weaknesses. In most cases, EAI is the most complex integration approach and is usually cost prohibitive or impossible with old or proprietary systems; also, because of its ambitious nature, EAI is the most risky integration approach. Integration Technologies This section describes technologies that an airport enterprise can use to implement a chosen systems integration strategy: • Relational Database, • Online Analytical Processing, • Open Database Connectivity and Java Database Connectivity, • Flat Files, • Extensible Markup Language, and • Web Services. Relational Database A relational database is the most common type of database in use today. A relational database is normally built using a Relational Database Management System (RDBMS). Data in a relational database is stored in tables. A table in a relational database is like a spreadsheet, with columns to define the attributes for each data point and each row representing a data point. Another important aspect of relational databases is their ability to enforce constraints on the data (ensures validity of the data) as well as referential integrity (ensuring that tables that refer to each other are consistent). 74 Integrating Airport Information Systems

Online Analytical Processing OLAP is an approach to provide quick answers to queries of multidimensional data (data about more than one facet of an item, such as name, address, city, and state rather than simply a name). To facilitate these queries, OLAP data are organized into multidimensional OLAP cubes that aggregate the facts across the different dimensions of the cube. For example, a sales data cube could be created with dimensions including sales date, region, and product category. The facts contained in this cube could include quantity sold, dollar amount sold, and gross margin. This cube would enable someone to very quickly answer questions like the following, which can take quite a bit of processing power and development time on a relational database: • What were the top selling product categories in the east region in Q4? • What product categories increased in sales from Q3 to Q4? • Did the product categories that increased do so in all regions? The users of OLAP data are typically business people looking for answers on what is going on in their business. Most OLAP software is meant to enable those business people to find the answers themselves, bypassing the need for IT staff to write complex queries. Open Database Connectivity and Java Database Connectivity ODBC and JDBC are standard APIs for accessing data stored in RDBMS. Although ODBC was meant to work with any programming language, JDBC is an API specifically for the Java pro- gramming language. Flat Files A flat file, or text file, is a simple mechanism for storing data that can only be last-accessed sequentially, or from beginning to end. Flat files originated in the early days of software devel- opment, but are still used primarily for importing and exporting data between different systems. Extensible Markup Language XML is a markup language used to describe data. The primary use of XML is to facilitate the sharing of data among software systems. XML has gained wide use on the Internet and is the basis of many other technologies, including Extensible Hypertext Markup Language (XHTML), Really Simple Syndication (RSS), and Extensible Stylesheet Language (XSL). XML schemas are a way to specify validation rules for XML documents. For example, an XML schema can specify that an order document contains at least one order line. U.S. Government standards for XML include the Federal XML Developers Guide and the Federal XML Group Update.2 Web Services Web services are XML APIs that can be accessed over a network, commonly using the World Wide Web Consortium (W3C) standard, Simple Object Access Protocol (SOAP). Web serv- ices differ from traditional APIs in that, due to their use of XML and HyperText Transfer Pro- tocol (HTTP), web services can be used to communicate between software on different operating systems. Architecture, Strategies, Technologies, and Contracts 75 2U.S. Federal Chief Information Office (CIO) Council. Draft XML Developers Guide. Architecture and Infrastruc- ture Committee, XML Working Group, April 2002.

Software Contracts Certain provisions occur frequently in software purchase and maintenance contracts. This section describes several standard types of contracts in the context of an airport enterprise, along with some provisions the contracts typically contain. This information is provided to help iden- tify and understand the basics of such provisions. No legal analysis or opinion is offered or intended; an airport that enters into any software or other technology contract is urged to review the specifics of the offered contract with legal staff experienced in such contracting. This section addresses the following types of software contracts: • End-user object code software license, • Software maintenance, • Software escrow, and • Enterprise software. End-User Object Code Software License Contract In an end-user object code software license, the purchaser is the licensee and is restricted as to the number of users, number of installations, and number of copies. The software company is the licensor and normally retains all source code and rights to the source code. The contract pro- visions normally prohibit an airport as licensee from reverse-engineering the code or trying to copy or disseminate it in any way. All intellectual property rights are retained by the software company. This is normally reflective of a closed architecture software solution, but the solution can have protocols for easily extracting data for integration purposes. Software Maintenance Agreement When an airport enters into a licensing agreement with a software vendor, a software main- tenance agreement accompanies that agreement. This type of agreement should explain how the software will be maintained on an ongoing basis and the cost of that maintenance. Monthly maintenance costs are charged for a set period and sometimes are based on a tiered structure. The agreement also details the process for upgrades or enhancements to the software and updates to fix software glitches. It is important for an airport to understand, as defined in the maintenance agreement, how software upgrades and patches will be deployed and how patches can affect the software and its data. Sometimes the cost of upgrades or enhancements is in addition to monthly maintenance fees, and if the airport does not accept an upgrade, patch, or enhancement, support restrictions can be imposed by the software vendor. Software Escrow Agreement Escrow agreements allow for the software source code and relevant architecture documenta- tion to be escrowed with an objective third party. The software vendor/depositor agrees to deposit the source code and all development documentation in the care of the escrow agent for the benefit of the airport. These agreements can delineate how disputes are resolved and what happens if the software vendor files for bankruptcy. This type of agreement, if structured cor- rectly, can add a level of security during any software acquisition, especially if the data might not reside with the airport or might not be in a usable format. The escrow agreement should contain language to explain the amount and type of knowledge transfer documentation, the source code, and how documentation and code are periodically updated to the escrow agent. Just receiving the source code does not mean that anyone will understand it without the necessary documen- tation for knowledge transfer. 76 Integrating Airport Information Systems

Enterprise Software Agreement In enterprise agreements, the purchaser of the software is the licensee, and if the purchase is based on a large number of users, an airport should have greater leverage to control and negotiate lower rates and more favorable terms for the license agreement. Because these application instal- lations are at an enterprise level, hardware, infrastructure, and an implementation plan are nor- mally included in the agreement. Enterprise software agreements should detail every aspect of the implementation and installation of the software, and these aspects should be negotiated into the contract. Because of the complexity of the solution, a phased approach using phased agreements might be considered. When purchasing enterprise-level software solutions, open architecture or specific data integration extraction technologies should also be negotiated into the agreements. Architecture, Strategies, Technologies, and Contracts 77

Next: Chapter 7 - Manager s Dashboard »
Integrating Airport Information Systems Get This Book
×
MyNAP members save 10% online.
Login or Register to save!
Download Free PDF

TRB’s Airport Cooperative Research Program (ACRP) Report 13: Integrating Airport Information Systems is designed to help airport managers and information technology professionals address issues associated with integrating airport information systems. A summary of the efforts associated with the development of ACRP Report 13 was published online as ACRP Web-Only Document 1: Analysis and Recommendations for Developing Integrated Airport Information Systems.

  1. ×

    Welcome to OpenBook!

    You're looking at OpenBook, NAP.edu's online reading room since 1999. Based on feedback from you, our users, we've made some improvements that make it easier than ever to read thousands of publications on our website.

    Do you want to take a quick tour of the OpenBook's features?

    No Thanks Take a Tour »
  2. ×

    Show this book's table of contents, where you can jump to any chapter by name.

    « Back Next »
  3. ×

    ...or use these buttons to go back to the previous chapter or skip to the next one.

    « Back Next »
  4. ×

    Jump up to the previous page or down to the next one. Also, you can type in a page number and press Enter to go directly to that page in the book.

    « Back Next »
  5. ×

    To search the entire text of this book, type in your search term here and press Enter.

    « Back Next »
  6. ×

    Share a link to this book page on your preferred social network or via email.

    « Back Next »
  7. ×

    View our suggested citation for this chapter.

    « Back Next »
  8. ×

    Ready to take your reading offline? Click here to buy this book in print or download it as a free PDF, if available.

    « Back Next »
Stay Connected!