Application Integration can often feel like a difficult subject to grasp. You can interact with a website, and you can see the data stored in a database, but how do you get the measure of an integration solution?
This article will demystify the subject by presenting the problems a business encounters when it doesn’t have an adequate application integration solution. We will then explore how an integration solution can solve these problems and afford a range of additional benefits along the way.
Finally, we will see how a business that fully commits to a managed application integration solution can unlock the full potential of existing systems, and achieve the high efficiency and adaptability required to stay at the cutting edge of changing market conditions.
WHAT HAPPENS WITHOUT ANY MANAGED APPLICATION INTEGRATION?
At first, application integration can seem like a waste of time and money. After all, your corporate systems are where the work gets done. They are what your customers interact with, and if there’s any spare resource, surely it should be allocated there.
The problem is that because corporate systems are specialised, no single system is a perfect fit for meeting all of a customer’s needs. Sooner or later, it will need to share the functionality of another system. Let’s explore what happens when this occurs:
- A developer working on system A requires some functionality from system B. For example, a web application for an online shop needs to look up if an item is in stock in an inventory management system.
- They ask a developer at system B to write an endpoint, which will return the number of items in stock when called with an item ID.
- They then write a process in system A which calls the endpoint when needed.
The resulting architecture looks like this:
So far so good, but over time this process repeats again and again, with different developers, different requirements, and between different systems. Developers come and go, and gradually knowledge of what’s connected to what disappears. Eventually, the dependencies between systems build up until they start to look something like this:
In this situation, all systems have become tightly coupled to one another. If a system goes down, any system it’s connected to will also be affected. If an upgrade causes a significant change to a system, links may also need to be updated, requiring not just development on the upgraded system, but those which link to it as well.
What’s more, when things do go wrong, it’s not always clear which system is responsible, and issues can be batted back and forth between teams for some time before the root cause is identified. Lacking visibility of the whole system can also lead to developers replicating existing functionality simply because they have no idea it already exists.
Slowly but surely, we have waded into a quagmire of difficulties, simply by following the principle that systems should manage their own integration solutions with each other.
WHAT IS THE INTEGRATION SOLUTION?
What has been described above is called the point-to-point model in integration architecture. Each system must maintain many connections to various other systems. It’s extremely costly to maintain and difficult to wrap your head around the complexity. An alternative is to use the hub-and-spoke model:
In the hub-and-spoke model, instead of systems connecting directly, they each connect via a mediating hub which handles passing the traffic from the sending system to the receiving system.
Say an endpoint in system B returns how many items are in stock for a given item ID, and this functionality is accessed by all other systems. The hub is now responsible for passing the relevant item ID to the endpoint and returning the result to the correct calling system. Now if system B is updated, instead of all systems having to make changes, only the connection to the hub needs to change, greatly reducing the impact of upgrades.
Additionally, if there is a failure or a system is unavailable, the hub will be able to determine exactly where the problem lies, and its logs can be used to trace complex messaging routes involving many different systems. When receiving systems require data in different formats, instead of having to surface multiple endpoints, the hub can transform data sourced from a single endpoint in the source system, saving developers time.
But that’s not all. Once you have this architecture in place, you may find people in your company coming to the hub to learn about what functionality is available across the business’s systems. Developers who work on the hub may become integral to implementing new complex business processes, by providing greater visibility and facilitating communication between disparate teams.
TAKING APPLICATION INTEGRATION TO THE NEXT LEVEL
We could stop here, but these are hints of what is possible if we take investment in application integration to the next level. Let’s explore how we can do that and what it would mean:
- A Canonical Data Model – we could convert all incoming data to a model which closely resembles our business objects, allowing different systems to communicate more easily in a shared language that aligns with the needs of the business.
- Microservice APIs – we could abstract away the internal workings of individual systems and expose this functionality through a standard format, such as REST web services, allowing services to automatically discover each other’s functionality.
- Messaging – we could asynchronously handle communication between systems in the form of persistent messages, decoupling systems and providing strong fault tolerance.
These improvements lead us to the Enterprise Service Bus architecture. At this point, the lines between individual systems start to blur, and applications begin to exist as high-level message flows which involve calls to a range of systems. As requirements change, applications can adapt quickly and easily without being dependent on costly low-level changes.
Where traditionally it would have been expensive to divide a task up between many separate systems, the Service Bus makes it possible to build processes which make use of the full range of functionality provided across the business. This encourages more specialised systems that are easier to optimise, and less duplicated functionality frees up developer time to focus on tasks which are a better match for their skillset.
The result is a level of efficiency and adaptability which can truly unlock the full potential of all your corporate systems, and it all depends on committing to a long-term, fully-managed application integration solution.
CONCLUSION
Application integration can seem mysterious, but all businesses are familiar with the problems that emerge when it isn’t properly managed. This article shows how full commitment to a managed application integration solution has benefits far beyond just mitigating these problems. It allows the business to unlock the full capability of its existing systems.
Examples of tools on the market which enable building such a solution include Microsoft Biztalk and more recently Azure Integration Services, both of which provide the capability to expose system functionality through APIs and then leverage a powerful messaging engine to perform high-level business logic.
As the software ecosystem continues to move towards cloud-based microservices, the costs of integrating corporate systems will continue to drop and a fully managed application integration system will become an indispensable asset to stay at the cutting edge of what your business can achieve.
