EIDX Home  
  About EIDX  
  Benefits of Membership  
  Business Process  
  Education  
  Guidelines & Standards  
  Technology  
Current Projects
The Basics of eBusiness Implementation
Implementation Options
Internet Commerce Model
Technical Architecture
  Reference Materials  
  Meetings & Events  
  Discussion Forums  
  Community  
  Presentations  
  Work Groups  

LOGIN
PASSWORD
remember my login
forgot my password

Factors to Consider when Choosing Implementation Options

Basic Factors

Discovery and Negotiation Decisions

  • Do any of my target trading partners already have some or all of the business process implemented with some of their partners, using the same standards or guidelines?
  • Are there trading partners (other than target trading partners) who have already implemented the business process in the target standard who I could do an initial implementation with or easily add to my program?
Discovery and Negotiation Model portion of ICM

Business Content Decisions
  • How will the business process will be implemented?
    • Will the components for an entire scenario be implemented at once or will the implementation be done business process component by business process component-by-component, or will only some components of a scenario be implemented but never the entire scenario?
  • What standard or guideline is being used to specify the business process activities?
  • Will the same standard or guideline be used to specify the contents of business documents and data files?
  • For the business process to execute correctly, are there requirements for the exchange methods?  Options:
    • Batch
    • Event-Driven
    • Real-time or Interactive
  • Do the business process activities need to be synchronous(2) or asynchronous(2) or a combination?
Business Content Model portion of ICM

The business content model is used at design time to create the trading partner agreement, to specify business processes and to specify business document or data file contents, and maps for transforming data to/from a proprietary format, or to/from another standards format.

At run time, the business process specification and maps created at design time are invoked. Data may be validated against a data dictionary to test for compliance to the standard.

Information Exchange Timing Options
  • For the business process to execute correctly, are there requirements for the exchange methods?  Options:
    • Batch
    • Event-Driven
    • Real-time or Interactive
  • Do the business process activities need to be synchronous(2) or asynchronous(2) or a combination?
Business Integration Decisions
  • What are the requirements of our gateway/message broker?
  • Is back-end integration planned? Both partners or just one?
  • What about documents/processes that require data be extracted from or posted to more than one back-end application? 
  • Is a PC front-end application being used by the trading partner?
  • Is a web application being used by one partner, or a shared web application? 
    • Is it a seller-owned web site or a buyer-owned web site?
    • In whose extranet or virtual private network does the web application reside (buyer's, seller's, third party's?
  • What are the requirements for the user interface?
Business Integration Model portion of ICM

Messaging and Communications Decisions
  • Is a VAN being used by one or both partners, or an Internet connection through a VAN, or a point-to-point connection between partners?
  • What are the security requirements? Need to consider:
    • Privacy
    • Authentication
    • Integrity
    • Non-repudiation
  • What are the requirements for enveloping files that are to be transmitted?
    • Does the standard being used for the business document or file contents have specific requirements for messaging?
  • If digital certificates are being used, is there a process in place to proactively track certificate expiration - before a transmission fails due to an expired certificate?
  • Are dynamic or static IP addresses being used and what is the impact on each partner, and potential future partners?
Messaging Portion of ICM

Communication Options

In general, there is a relationship between the communications methods and the business content standards, messaging standard and/or business integration standards. The choice of exchange method may drive the decision to use a particular messaging and/or communication option. The choice of communications method may dictate or limit messaging options. Or, the data content standard chosen may dictate or limit messaging options. Changes in the various standards are overcoming some of these types of limitations. Additionally, just as VANs provided protocol translations for traditional EDI in the past, such services are now being provided for internet connections, so that partners can focus on business process and business content, and allow service providers to worry about the technical communications.

Communications Options include:

  • Direct, point-to-point connections between trading partners
  • Point-to-point connection via one partner's private network
  • Communications via a network service provider such as a VAN or ISP

The communications options above use one or more of these connection options include:

  • Dial-up
  • ISDN
  • T1 or T3 line (owned)
  • T1 or T3 Leased line
  • DSL

Whats's the difference between a regular telephone connection and an internet connection?

  • Telephone Network
    • Circuit switched. The user pays to rent a circuit for a period of time, so the connection is private. There is a single local service provider.
  • Internet (TCP/IP Network)
    • Packet switched. The user pays to transfer packets over a circuit shared with others, so the connection is not private.  There may be multiple local service providers.

Cost Factors

These are things to be taken into consideration when determining what the most cost-effective implementation option may be in a given environment.

  • Are there internal resources to support the technology (build vs. outsource)
  • Do programming changes need to be made and cost-justified (ROI)?
  • What is the ramification of the change (impact)?
  • Is it mission critical data?
  • Can this be solution leveraged (internal or external)?
  • Externally driven cost of doing business (market forces)
  • Compelling competitive reason (internal)
  • Batch driven vs. real time
  • What are you trying to achieve - what business need are you trying to fulfill
  • Need for response (receipt acknowledge signal and response transaction/message)
  • How assured is the business that the trading partner receives the data and is acting on it?
  • What other initiatives are going on (combination of leverage and internal reasons)
  • How soon do you want it?
  • Fully automated vs. partially integrated vs. not integrated
  • Migration path
  • What is it going to cost the partner?
  • How many partners will this be used with?
  • What are potential transaction volumes?

Project Delay Factors

This is based on a Pareto analysis of several actual implementation projects.  These are some things that have actually happened:

Most Frequent

  • Key player (either trading partner) goes on vacation or on a business trip, or is out ill for extended period of time and has no backup for the project.
  • Key player (user expert, buyer, sales contact, IT contact, whatever) changed jobs and new player had to be brought up to speed (happens frequently).
  • Partner doesn't have resources available at the same time that you have resources available; by the time partner has resources freed up, your resources are tied up in another implementation or project.
  • Supplier or division has other priorities that impede getting to project tasks.
  • Supplier in the middle of installing new gateway and/or translator.
  • Supplier in the middle of installing new order management system.
  • Supplier in the middle of integrating systems.
  • Your own business group in the middle of migrating to next-generation systems like SAP, Oracle, Baan, etc.
  • The left hand doesn't talk to the right hand.
  • Supplier's gateway not correctly configured.
    • Partner doesn't have software correctly installed.
    • Partner doesn't have correct version of standard installed.
    • Partner doesn't have system configured to accept the transaction/message type from you.
Somewhat Frequent:
  • Setup step left out (#1:  forgetting to set the EDI/EC flag to 'Y' in the backend application).
  • Install step left out (like registering a file type for one of the hops in the internal network).
  • Partner needs to setup special sender/receiver IDs for new business process (different sender/receiver ID than currently used with already implemented business processes).
  • Partner splits into two companies.
  • Partner merges with another company.
  • Partner needs to modify current back-end application for the business process.
  • Partner needs to acquire or develop a new application for the business process.
  • Project is dependent on another group or party to complete part of the setup/configuration and have to wait on them.  (e.g. waiting on ASP, ISP, VAN, exchange, or other 3rd party to do their setup).
  • Your internal business group changes their mind about setting up the partner you've been working on and wants to start on another partner.
  • Partner didn't map according to your specs and had to fix mapping.
  • Partner doesn't actually test map until they get first integration test file from you.
  • Supplier not familiar with the standards (previous implementations, if any, were with simple, transactions/messages).
  • Partner has to do re-coding/re-testing of application interface, from bug-fixes to major overhauls.
 Least Frequent:
  • Change made incorrectly in back-end application that caused incorrect partner number to be used (and therefore incorrect Partnership ID in file which could not be matched to gateway's registry).
  • Gateway configuration typo.
  • Partner's eBusiness software cannot read the data; dependent on their third party software vendor to fix and send out new software.
  • Partner's third party software provider introduces new bugs when fixing supplier's software.
  • Partner has no way to configure gateway or back-end to receive two different document types that both use a single transaction/message standard, e.g. can't accept both a discrete purchase orders (850/ORDERS/3A4 etc.) and blanket orders (also 850/ORDERS/3A4 etc. but with different content and different mapping and business rules).
  • Partner changes partner identification number and/or name.
  • Partner gets eBusiness software from one provider, and network from the other provider, and neither knows how the other works and they give conflicting instructions to the partner.
  • Response document (use ASN as example) mismatching because partner's production ASNs aren't compatible with your requirements (can't always catch these in test).
  • Problems with customer's MRP run.
  • Power failure when MRP was running

home | about CompTIA | events | press room | members only | certification | initiatives | contact us

© 2004 The Computing Technology Industry Association, Inc.
All rights reserved.