Elevating Integration: Steps to Improving Supply-Chain Communication

Linking, sharing and synchronizing data from diverse technology sources, also known as systems integration, is a critical aspect of supply chain management and is almost always “the long pole in the tent.”

In a world of rapidly changing technology integrating business systems, trading partners, service providers, applications, devices and processes can be a highly technical undertaking, making even seasoned managers and executives feel powerless. The resolution is simple: elevate systems integration to a business discussion.

Information technology initiatives start with a business need, are justified with a business case, and approved by an accountable business resource. These steps are typically followed by iterations of design and implementation planning, a hand-off to the team that will deliver the solution. A typical first step in planning is the creation of a data flow diagram, a (sometimes complex) collection of circles, boxes and connecting lines that represent information to be passed between systems and processes. This defines how the solution fits into a broad architecture including other systems. There are risks that the architecture will contain superfluous interfaces or interfaces built with sub-optimal strategies or underlying technologies, the latter being a particular danger due to the speed of technology advances and innovation. Defining the overall solution and how it fits into a broad architecture combined with the risk of over-engineering or the utilization of the wrong supporting technologies may add scope, time and/or cost to the project. This is the step which makes systems integration a long pole.

Interface design can be very technical with many aspects to consider. Some of the underlying strategies and technologies that are required for systems integration have existed for many years, while others are new, with even more being developed. The challenge this creates is that the spoken language will be one in which no one is completely fluent. Still, decisions must be made, including:

• Media – physical network including LAN/WAN, telecom, broadband, cabling and WIFI within the context of bandwidth, queues and response-time.
• Protocol – the way files are transferred including FTP, SFTP, HTTPS, SOAP and AS2. Compression and encryption may be considered as well.
• Application interfaces – the way applications (especially cloud) access features and functions of other applications. API, webhooks and web services may be discussed.
• Files and objects – structure of the data being transferred, including CSV, XML, EDI, JSON, PDF and others.
• Data – fields within the file may include text, dates, currency, links and attachments, among others.
• Data transformation – converting data from one format to another. Subjects such as cleansing, refining, mapping, parsing, formats, layouts, schemas and others may be considered.
• Processing – reason for the integration at the functional level. Frequency or event-based, a file transfer is triggered, and the receiving system performs some action. This is often the point where one or both systems require configuration and/or development.

This partial list constantly changes and keeping up with it is challenging. In the future, artificial intelligence, blockchain, web services, universal integration and integration-as-a-service — to name a few — will make systems communicate more seamlessly. Until then, business resources must elevate systems integration to a business discussion.

The Outlook

Focus on the following to preserve the business context:

• Get involved with design; it will have long-lasting impact(s).
• Tie decisions to the business case.
  • Explain decisions in business terms.
  • Require economic justification.
• Avoid over-engineering.
  • Is an interface required?
  • Can interfaces be eliminated/postponed?
  • What are alternatives? 
  • Will manual processes work?
• Are we using the best supporting technologies?
• Is the architecture flexible to take advantage of innovations?
• Does the design create technical debt, switching costs, or maintenance costs?
• Can we reduce time-to-value?

Jeff Godwin is senior vice president of product development and deployment, and Stephen Bullard is vice president of product development and deployment for MonarchFx.