Electronic data interchange (EDI) Solutions



Modern EDI is the result of many years of changes in business-to-business (B2B) trading practices and technologies. B2B changes usually arise organically. A single influential business that mandates trading partner use of a new document standard or communication protocol frequently triggers broader adoption within or even between markets. As a result of many such adoption cycles, businesses are finding that the EDI solutions they put in place years ago are no longer capable of meeting their requirements for trading partner integration. Classic EDI remains essential, but it’s no longer good enough, by itself.

Modern EDI isn’t a new kind of technology or EDI product category. Rather, it’s an integrated set of capabilities that can be delivered in different ways. You can acquire modern EDI capabilities using on-premise middleware, cloud services, Integration-as-a-Service, or a combination. And the benefits of doing so are compelling. Businesses that invest in modern EDI capabilities are more agile, more scalable and efficient, and easier to do business with.

It is possible to realize some modern EDI benefits without wholesale replacement of your current EDI system. But realizing the full benefit of Modern EDI ultimately requires migration of existing EDI infrastructure, implementation assets, and processes. Just as there is no one modern EDI solution approach, there is no singular prescription for EDI modernization project success. But there are proven best practices that can reduce risk and make it easier to achieve your EDI modernization goals.

  Classic EDI Modern EDI
Endpoint Connectivity Limited to external partner integration using VANs and asynchronous direct connections "Any-to-any" integration between partners, apps, data, communication services, and cloud services
Automation Scope Simple inbound and outbound processes End-to-end combinations of partner-facing and internal business processes
Process Latency Asynchronous, batch-oriented processes Mix of asynchronous batch and synchronous, near real-time processes
Document Transformation Standard EDI document syntax and semantics plus flat files Standard EDI plus XML, spreadsheet, and flat file documents
Application and Data Integration Coded integration with applications and data Configured, plug-in integration, aided by intelligent automation
File Transfer and Governance Ungoverned, un-auditable file transfer and access activities Managed transfer and governance of files exchanged with external and internal endpoints
Visibility IT-dependent, "forensic" management and reporting Centralized visibility and management of all integration activities, with alerts, self-serve dashboards, and on-demand reporting



EDI Modernization Planning Phase

Figure 1 depicts the gross staging of an EDI modernization project, consisting of a one-time planning effort, followed by a series of implementation sprints aimed at migrating existing assets to a modern EDI solution

EDI Modernization Planning Phase



The main goals for the Planning phase of an EDI modernization project are to:



The table below shows some of the main Planning phase tasks in a typical EDI modernization project. The actual set of tasks needed for a given project depend on goals, constraints, project scope, modernization strategy, and other situational factors.

Planning Tasks Details and Option
Enumerate goals and constraints New requirements, process improvements, delivery target, budget, change impacts, risks, etc.
Establish project infrastructure and policies Agree on project structure, lifecycle processes, versioning and change management, set up project repository
Inventory legacy system Catalog and populate project repository with trading partner specs, interface specs, sample EDI and application data, etc.
Perform gap analysis based on current and anticipated use cases Middleware capabilities, integration processes and assets, tool functions, life cycle practices, exception-handling, reporting, etc.
Choose an implementation model Self-implement, outsource, or hybrid. Consider strategic value, deadlines, budget, resource and skills availability, etc.
Identify supplemental resource needs Needs for planning, implementation, design reviews, project oversight, etc.
Select modern EDI solution Ensure fit to current and anticipated use cases, deployment preference, personnel needed, support requirements, etc.
Define roles and assign personnel Assign coverage for all essential roles and tasks, whether outsourced or performed in-house
Train planning and migration staff Ensure understanding of solution capabilities, life cycle processes, and best practices
Choose a modernization strategy New development only, phased partner migration, phased integration layer replacement, en masse migration / implementation (for smaller cases)
Define integration architecture Identify process, adapter, and mapping patterns, application interfaces, communications, exception handling strategy, performance considerations, etc.
Establish project schedule Define scope, staging, and delivery estimates, partner implementation priorities, go-live policies, etc



Best Practices for Planning

Use a Project Repository

Using a repository to capture planning documents and migration deliverables is a best practice, for several well acknowledged reasons:



Assign Project Staff According to Clearly Defined Roles

IT organizations generally struggle to staff EDI modernization projects with the right people and skill sets, for multiple reasons, including:

No project staffing situation is ideal. Some adjustment of plans to accommodate available personnel and skill sets is normal and expected. But fundamental staffing errors like overlooking critical skill gaps or leaving important project functions unassigned can put project outcomes at risk.



A best practice to avoid such problems is to assign project staff according to clearly defined roles. Basing your staffing plan on a comprehensive list of project roles and responsibilities ensures that potential staffing issues are identified up-front, so they can be addressed before they put your project in jeopardy.

Some modernization project roles, like Project Lead, Business Analyst / Planner, and Builder, are almost always required, with Builders assigned later. Others, like Architect, Specifications Gatherer, and Trainer, can be important roles in larger projects, but assigned as minor, part-time duties, in smaller ones. Assigning more than one role to the same person is the norm, in most EDI modernization projects.

The precise set of roles and responsibilities needed for a given project depends on project scope, solution characteristics, methodology, and other factors. Ask your solution provider or (for outsourced projects) integration consultancy to recommend a project staffing model, then adjust to suit your project needs.



Conduct a Thorough Inventory of Your Existing EDI System

One of the first and most important tasks in a modernization project is to populate the project repository with an inventory of existing EDI system assets, including:



This best practice lays the foundation for detailed project planning and migration activities, by:



Analyze Change Impacts Before You Choose a Replacement Solution

Replacing a legacy EDI solution affects the way you organize, implement, operate, and maintain EDI integrations. And modern EDI systems can be complex, exerting impacts in unexpected places. So before you choose a replacement solution, examine the differences between your current solution and candidate replacement solutions. Then consider potential change impacts at four levels:

Use a life cycle activity model to analyze the impacts of different candidate solutions. Focus special attention on activities that are complex, time-consuming, or potential sources of errors or exceptions.



EDI Modernization Migration Phase

The main goals for the Migration phase of an EDI modernization project are to:



The Migration phase of an EDI modernization project typically targets a combination of legacy migration and new integration objectives. New integrations that require modern EDI features (such as XML transformations or near real-time response) are frequently modernization drivers, and given top delivery priority. The subsequent migration of assets from the legacy EDI system is usually staged using a series of implementation sprints.

Migration of legacy EDI assets occurs using a combination of metadata-driven conversion, object reuse, and automation-assisted implementation. Direct, one-to-one asset migration is rarely feasible, because of integration model features that are not found in classic EDI systems, vendor-specific implementation differences, and intellectual property protections.