Enterprise System Implementation Strategies and Challenges

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.

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.

Service Oriented architecture

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.