Application Integration Principles Explained: How to Integrate an Airport with a Subway Station
Sustainable application integration has always been a challenge in most organizations. IT professionals have been doing application integrations for decades but still there are misconceptions among IT professionals about application integration principles. A large majority of developers still fail to understand the fundamental principles of application integration. Typically application integration is not planned early in the projects therefore often it is figured out in the last minute; as a result many integrations are achieved by exporting files or making hooks into databases.
The integration is a universal concept that exists everywhere around us. You can see the examples of integration in everyday life for example, how organizations integrate(communicate) with their customers both by a physical visits and by mail, how one organization integrate with another organization i.e. suppliers, vendors, partners, how buildings integrate with other building, how an airport integrates with car rentals, or bus company or a subway station. These are only few examples of integrations from our everyday life. If we look closely into the design of these integrations, we will start noticing the three fundamental principles of integration. Generally people consider these principles as common sense, ironically same common sense principles are completely ignored when we design integrations between applications.
Lets use an example of an airport to understand the fundamental principles of integration. Assume an airplane is a database, passengers are its data and airport is its application. The airport entrances and exits are the interfaces of an airport(application). The people (data) move in and out of these interfaces and is processed by the complex airport processes for on boarding and off barding people (data) in and out of the planes (databases). If you look closely, airport(application) develops some specialized interfaces(APIs) for other applications such as car rentals, parking, hotels, subway station, other terminals etc. These interfaces allow people (data) to move into these other applications directly from the airport in a controlled and sustainable manner.
Now lets assume that the airport in our example above does not has a subway station and the city wants to build a subway station for the airport. Assume subway station is another application, subway is its database and people are its data. People from the subway want to go to the airplanes and people from the airplanes want to go to the subway. lets explore some options how we can design an integration between these two systems. Since the intention of this article is to explain the three fundamental integration principles( i.e. Security & Access, Loose Coupling and Reusability) therefore lets first design this integration using the popular application integration pattern (i.e. direct database connection) and see how it breaks the integration principles and what kind of issues will arise from this design.
Direct Database Connection: We will build the subway station under the gates and airplane parking area. There will be multiple pathways from subway station that will exit right outside the gates near the airplane parking. Lets assume airport has allocated dedicated gates for each airline therefore passengers will use this information to select an exit pathway. Now when passengers arrive next to a plane they can directly board the plane using plane’s ladder (think of this as an ODBC access on a database that all airlines have opened for this integration). Passengers who have luggage can put their luggage into the cargo cabin themselves, the cargo cabin’s will be left open for this integration( think of this as a special access to a secure table in the database). Once passengers arrive inside a plane they can choose an empty seat anywhere in the plane and enjoy their flight.
I am sure you are thinking this solution is a complete non-sense. I completely agree with you but allow me to analyze this little further to highlight the issues that will result from this integration design. If we implement this design you will find a person who has no business on the airplane can just take an exit at airport station from subway and take one of the pathways and board on a plane going to Hawaii and sit on an empty business class seat. This solution will cause so many issues that it will take more than 100 pages to cover all of them but here I will only analyze issues in the context of three fundamental integration principles.
Security and Access: Security and access is always related to a context and it changes when the context is changed. Therefore security and access controls in an application are designed from that particular application’s context. For example security and access context of a subway is very different from the security and access context of an airplane. For taking a subway there is no requirement of a check on passengers if they are criminal or not, there is no restriction on the wait or the contents of the hand carry luggage or of a suit case, there is no requirement of carrying a government ID or passport, there is no requirements of having a destination visa on the subway. On the other hand flying on an airplane has all of these requirements. The processes at the airport ensure that the passenger boarding on airplanes follow these requirements.
When we open a back door entrances directly into the airplanes we break all these requirements. Therefore to make the proposed integration work we will have to implement required checks and controls on passengers coming from trains right at the subway station. We will implement a security and access process on the subway station that will be operated by the subway company. This process will ensure that people entering the airport from subway follow the airplane requirements. This will require a lot of effort and resources to implement this process by subway company. Since the subway company is not an expert in this area therefore their process will never match the airport process. Moreover, these processes will become out of sync as soon as airport makes any changes to their process. Now the airport management will have to invest and implement some new processes to deal with incidents/issues that will result from this integration.
On the other hand if we would have designed the integration in a way that would have taken passengers from the subway station directly to the airport security counters then we would not have to worry about any of the security and access requirements. This way we will be using the standard interface (API) of the airport (application).
Loose Coupling: Other then the security there are several other validations that airlines performs on passengers before they board them to the airplanes. These validations can be compared with an application business logic. For example airline checks if passengers have valid tickets, if passengers are checked-in, validate their identifications, do criminal checks, validate travel authorizations(visas) for travellers going abroad. Airlines also validate passenger’s luggage agains the luggage requirements, oversized luggage is placed in separate cabins, seat numbers are also assigned to passenger. If passenger is a child some extra validations are performed.
In our proposed integration solution unless we implement a separate airline business logic validations process on the subway station, the passengers coming from subway will skip all of these validations. When an integration solution open a back door into the database then the responsibility of validating the business logic falls on to the integration solution. As also discussed in the security discussion above that it is very difficult to replicate the business logic of another application within the integration solution. This requires deep knowledge of the other application and this type of integration tightly couples the two applications. As the business logic changes in the application It becomes very difficult to maintain the business logic in the integration solution.
Therefore it is always recommended to design loosely coupled integrations by using standard application interfaces. For example in our airport subway integration scenario a loosely coupled solution will be to design a pathway from the subway station that will take the passengers directly to the airline check-in counters. This way if an airline makes any changes to its business logic down the road there will be no impact on the subway station application integration.
Reusability: Reusability is another important principle that should be kept in mind when designing the application integrations. In the design above our focus has been the passengers who are taking the departing flights. In-order to facilitate the arriving flights we may have to extend our design a bit and connect another pathway for arrivals. But what about integrating the subway station with other services(applications) at airport e.g. car rentals, taxi stands, food court, currency exchange etc. Lets adjust our design to make it more reusable. In the new design we will interface the subway pathway at a more central location of airport instead of checkin booths or arrivals. This way subway passengers will be able to leverage the existing airport navigation system to access various services at airport by using a single subway interface.
I will appreciate your comments and feedback below. Thank you for reading.