You use connected devices and systems like Alexa, smartwatches and smartphones to perform everyday actions. In the workplace, enterprise systems for accounting, customer relationship management and enterprise resource planning have also become increasingly interconnected.
You rely on dozens of different applications to keep your business running smoothly. Known as enterprise system integration, connecting enterprise systems maximizes the value of each solution to your organization.
In this post, we’ll compare two popular enterprise system integration methods and reveal the best integration tools to ease the process.
What is enterprise system integration?
Enterprise system integration is the process of connecting existing systems to share and communicate information. Integrating applications enables data to flow between systems with ease, simplifying IT processes and increasing agility across your business.
Most large companies use at least several kinds of software and data systems that can benefit from enterprise system integration, including:
- Customer relationship management (CRM)
- Supply chain management (SCM)
- Business intelligence and analytics
- Human resources data
- Internal and marketing communications
- Accounting software
- Enterprise resource planning (ERP)
Connected systems often take on new functionalities. For instance, a CRM system might need to call the accounting system’s application programming interface (API) to access customer account information.
Integrating systems with distinct software and hardware brings a new set of challenges for engineers. New systems integration solutions have emerged for passing flat files between systems, direct database queries, hard-wired API calls, middleware/service bus solutions and others.
Comparing popular enterprise system integration methods
Tightly coupled system integration and service-oriented architecture are two common systems integration approaches. Let’s dive into the distinctions of each:
Tightly coupled system integration
When systems are tightly coupled, an application is developed to allow the requesting system (left side of Figure 1) to directly call the API of the responding system. This application will create the request from data in the requesting system, transport the request and response (typically) and translate the response from the responding system into something the requesting system can use. This is illustrated in Figure 1 below.
This is a common pattern in enterprise system integration. Organizations often approach integration this way because it’s initially less expensive, less complex to set up or they simply don’t know better. However, this integration paradigm will cost your organization exponentially more time, money and peace of mind when you need to upgrade or replace the core system in question (the accounting system in Figure 1.)
When the accounting system API changes due to an upgrade or system replacement, you must redevelop and test each integration point (represented by red lines in Figure 1). This is no small task — and often a major reason organizations tolerate dated or difficult-to-use core systems. It’s simply too complex or too large of a project to replace the system.
Fortunately, a better architectural pattern exists for enterprise system integration — called service-oriented architecture (SOA). The concept of SOA has long been used in general software development and integration frameworks. At its core, SOA promotes loose coupling, flexibility and reusability that tightly coupled architecture cannot provide.
When software developers use the term “loose coupling,” they’re referring to a separation of concerns. This means changes in one system don’t directly impact changes in another system; each system is only concerned with its own function.
In this pattern, a request from one system is translated into an intermediate format called a canonical message. A canonical message (in this context) represents business functionality across the enterprise.
The example in Figure 2 below shows a request to get accounts receivable information. Each requesting system can create a request in the format the vendor developed – whether that’s an XML or JSON message. That external request is then translated into the canonical message.
Once the inbound request is translated into a canonical message, the enterprise integration framework (EIF, pictured in the middle of Figure 2) routes the request to the appropriate system and processes the response message. The response message goes through a similar process – it’s translated into a canonical message to represent the response then translated into a response the requesting system can understand.
Advantages of the SOA IT integration method
At first glance, this service-oriented architecture approach appears to require more work.
For instance, Figure 1 involves 10 message translations (one response and one request translation per system) while Figure 2 requires 12 (one response and one request translation to canonical per system and one response and one request translation from the canonical to the account system.)
Here are two major payoffs of the service-oriented architecture approach:
- Compatibility: The accounting system doesn’t have to be compatible with the message format a requesting system generates. The message the requesting system generates will be translated into a format the EIF can process (the canonical message). The accounting system is completely uninvolved in what happens beyond the EIF. This is extremely helpful when adding new systems that require access to systems that are already part of the EIF.
- Ease of switching systems: The loosely coupled nature of this architecture makes switching accounting systems much simpler and cheaper than if all connections were hardwired to the accounting system. If your company needs to modernize its accounting system and has an architecture similar to Figure 1, you’ll need to redevelop all 10 translations — and migrate the accounting data.
In Figure 2, the connections between the accounting system and the EIF (designated in red) are the only points you must redevelop. This dramatically decreases overall project time and risks associated with system replacement. While setting up an enterprise EIF takes extra planning and effort, it’s a necessary component to provide the flexibility and adaptability your organization needs to thrive in a fast-changing and increasingly connected technical landscape.
IT systems integration tools for the enterprise
Many tools exist for enterprise system integration, but some are more suitable for transaction-based processing. These include:
These systems are great for processing high volumes of real-time transactions. Each has its own benefits and drawbacks that you’ll want to explore for your own organization.
At MXOtech, we use BizTalk Server for this type of integration. BizTalk Server is extremely powerful and has matured over the last decade. It ships with a variety of adapters that enable connectivity to a range of systems. It also includes various schemas and components that handle multiple message types.
This alone saves an integration developer hours of development time. BizTalk Server also provides reliable messaging so nothing is ever “lost” once BizTalk receives the message. This is crucial in enterprise system integration.
Connect your critical enterprise systems with confidence
When critical business systems can communicate freely, your IT team and employees save time and headache.
But like any complex data-sharing project, you don’t want to leave anything to chance. Working with an experienced partner is the safest way to guarantee success.
MXOtech develops world-class enterprise system integration frameworks for healthcare companies, energy and utility companies and logistics companies. Schedule a call today to learn how we can help lead your IT systems integration project and transform the way you work.
Other articles you might find helpful: