We are living in the era of "Bridge" services and platform business models. The importance of the integration domain of software development is on it is pick. Hybrid and multi-cloud models, new partnerships with other technology companies are only spicing the situation.

Mid to large-size companies are typically comprised of many applications. Usually, it is a mix of 3rd party and custom-built software (whether it is new products or legacy). It is natural progress from the need to cover particular business needs with the best software packages which are developed by the experts in specific fields. It could be internal expert teams or external in case of partnerships. And that is okay because it is nearly impossible to cover the whole business with one solution.

All that creates a complex ecosystem where many applications should interact. Interact by exchanging information that adheres to specific rules (contracts) and is delivered according to time and integrity constraints. That is where a tremendous complexity starts to kick in.

Of course, most of the time we underestimate that complexity and try to cover all integration problems with a "silver bullet" of today's reality which is REST. But what unrealized value and business potential we are digging in by doing that?

• What is the impact on the business if you are sharing an API to a partner who needs to make thousands of web-service calls every day in order to get required data, and still without the possibility to fully leverage the potential of your API product?
  

• How does it impact business metrics, including conversions when you expose stale data?
  

• How many costs could be saved by substituting your legacy APIs, which you expose to several development teams internally or to a couple of external partners/clients? It takes weeks to configure them and figure out how to integrate correctly.
  

• How much money could be saved along with credibility from your clients if integration security will be handled properly? It significantly decreases the risks of being hacked and becoming bankrupt.
  

• How would the operational performance of your business rise if stakeholders don't need to spend hours cleaning out duplicate data or looking for pieces that for some reason were not saved properly due to integration process failure?

• To what extent do you decrease time to value by building more loosely coupled applications where change travels faster and without so much friction?
  
  

We could continue extending this list infinitely, but it should be enough to provide a feeling of how important integration architecture is for almost every technology business.

Luckily, almost all integration approaches and patterns have been known for a while and are nothing new. Of course, new standards like REST, pop up. But details are still built around strongly established good-old ideas from the past.

An industry-wide core is based on the ideas provided by Gregor Hohpe and Bobby Woolf in their research of Enterprise Integration Patterns, which teaches us about 65 patterns for the use of EAI and message-oriented middleware in the form of a pattern language. They're organized around six categories that are related to particular integrations styles: Channel Patterns, Message Construction Patterns, Routing Patterns, Transformation Patterns, Endpoint Patterns and System Management Patterns.

What has happened nowadays is that those patterns are incarnated in new tools provided by separate companies and cloud providers, which are adjusted to the ecosystems they reside in. Fully separate platforms e.g. MuleSoft, cloud implementations on Azure (Service Bus, Queues, Event Grid, Logic Apps), AWS SQS, MQ, EventBridge) and many others.

Industry access to travel data is facilitated by global distribution systems. They take care of hotel booking, flight search, fares and bookings, car rental bookings, public transportation bookings, reviews and rating, tours, attractions, and experiences, railways, cruise and ferries. This niche is filled by leaders like Amadeus, Travelport and Sabre, which has been streamlining travel agencies and other travel businesses connections to the biggest first-tier sellers in the world. This is very beneficial if you are a small travel business and need to access aggregated data.

Despite all the benefits GDS businesses created a monopoly that dictates its rules. If you have more specific requirements on data retrieval, competing in a business of low-fare search, you can't do it effectively. Also, in today's world of AI and BigData having no ability to analyze customer data on bookings(as they all are happening on the GDS side), decreases your ability to succeed as a business. First-tier providers also can't control distribution channels. Even a lot of big companies (RyanAir who stopped working with Amadeus in 2017) are dropping support for GDS.

To some extent, GDSs restrain industry growth. For example, we don't have standardized data models and data exchange guidelines. Big players are not interested, because this is their bread. Attempts of alliances like OpenTravel are still not widely adopted. NDC (New Distribution Capability) is also slowly coming under the control of GDSs.

One of the rules to remember regarding the APIs layer: "REST is not a silver bullet!" We should always try to look beyond. Let us provide a real-world example of the case we've encountered recently by working with one of our clients. The need was to integrate travel experiences from a major provider. They had a REST API and several endpoints. In order to get the required data, we needed to implement a background job that runs on a daily basis, does hundreds and sometimes even thousands of API calls in order to get what is needed. And this was fully the provider's fault. If they had GraphQL implemented it would be simpler, cause in one paginated call we would be able to choose which particular data segments were needed and grab them efficiently. GraphQL by its nature is a database querying standard that improves client-server interactions. Of course, it also has its complexities, but it is always nice to understand what is happening in the world beyond REST APIs.

If you are running infrastructure on a major cloud provider and have specific integration needs. It could be connection of on-prem to cloud, implementation of resilience in messages/events delivery. It is always worth remembering that there are very nice instruments both in AWS and Azure for doing that. They don't consume as many costs as they had a couple of years ago. This is because serverless computing became mainstream and gave the possibility to cut costs significantly without the need of running message brokers and other middleware with complex configurations on bare metal and virtual machines.

Where to look if you want to get a feeling of the integration offerings that both Azure and AWS provide? Azure provides a very nice first-time guide to their integration capability.

All the details can be found in the linked article, but in few words this design allows doing load-leveling, reliable infrastructure for sending messages, tracking the progress of long-running jobs, decoupling applications and reacting to different events that are happening across the whole platform. This is a navigation article from which there is a possibility to go to details on particular offerings.

AWS also has a very nice site section dedicated to their integration capability which also serves as a map from which you could navigate to particular offering details. They don't have a reference architecture for integrations that shows how all components play together, but in the materials section, there is a possibility to find practical references on the usage of particular technologies. Vertical Integration Strategy Powered by Amazon EventBridge.

As we can see, EventBridge serves the role of an event bus. Overall this is an example of event-driven architecture, built on top of it.

Of course, usage of the services provided as examples above require detailed software architecture planning and discovery of Quality Attributes of the system. You should be careful when planning their adoption in order to not overengineer a system.

If you need help in your integration journey, we in TageSpot will be more than willing to help, by sharing our similar experiences and expertise with you. Feel free to contact us.