Main Content

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

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

Identify unmet current needs and projected future needs
Select an implementation approach and modernization solution
Assign and train project staf
Establish target system architecture
Begin to populate a project repository with EDI specifications and legacy solution assets

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:

Repositories facilitate information sharing among multiple project participants and constituents. When all or part of the project is outsourced, the repository becomes a critically important coordination mechanism.
Repositories provide versioning and change management services that enable governance of document modifications and access.
Repositories foster continuity and consistency across project phases and activities. This is especially important for ongoing maintenance of EDI assets after the migration project concludes.

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:

Budget constraints that limit hiring and/or outsourcing options
Unfamiliarity with EDI projects in general and / or modernization strategy in particular
Skill gaps and over-allocation of the most experienced and highly skilled staff
Staff (especially senior staff) preferences for and objections to various project responsibilities

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:

Trading partner specifications (contacts, document standards, validation and mapping requirements, communication options and windows, security requirements, etc.)
Sample data (EDI and application)
Interface specifications (internal and external)
Custom code extensions
Change histories
Open onboarding and change requests.

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

Quantifying the number of partners, transaction types, and interfaces to be migrated
Providing a basis for decisions about project structure and migration staging
Identifying partner-specific customizations that will require individualized migration efforts
Organizing baseline documents and assets for implementation sprints during the Migration Phase

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:

Middleware capabilities and services
Partner onboarding and maintenance processes
Runtime monitoring and management
Quality of technical support and services

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:

Build templates for business processes, maps, adapters, and other integration deliverables to facilitate reuse
Agree on priorities, processes, policies, and tempo for incremental migration
Conduct implementation sprints to create, test, and deploy EDI integrations

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.