Clickable Business Models eBusiness Education Acronyms Cross References
B2B Content Standards EC Technology Standards Glossary Implementation Guidelines
Implementation Options General Recommendations References Methodology/Legends
 Home | Copyright Notice and Legal Disclaimers | Navigation Help | Tour! | Downloads | Contact Us | Site Index | Search
Implementation Options | Technical Basics | Internet Commerce Model  | Architecture |
Implementation (Technology) Options

Basics of Implementations: Initial eBusiness Implementation

Special Notes:    

    Identify First Trading Partner
    Establish Trading Partner Agreement
    Requirements Definition
    Select Service Provider(s)
    Define User Interface
    Assess Requirements for Back-end Applications
    Implement Gateway Components
    Define Messaging (Transport and Routing) Requirements
    Test Connectivity
    Train Resources
    Implement First Partner and Business Process
    Setup Environment for Ongoing Implementations
Back to Basics of eBusiness Implementations

The following refers to the initial implementation of an eBusiness infrastructure.  Most steps are one-time only tasks that do not need to be repeated when new trading partners or new business process functionality is implemented on top of this infrastructure.

  1. The first step, of course is to identify potential partners.  Identify first trading partner.  Frequently, the first partner is an existing trading partner who has come to you and asked you to implement an eBusiness solution. 
  1. If you have specifications for trading partners posted to a web site, that is a repository.
  2. Third-party registries are an evolving service.  Eventually, companies will register their eBusiness capabilities, and the registry will contain pointers to repositories - either a 3rd party repository or the company's repository - which contains the company's specifications and technical profiles.
  1. A trading partner agreement should be established with each partner.

 

  1. Assess requirements and develop implementation plan.  As you proceed, be sure to capture all hardware and software requirements.
    1. Evaluate cost factors to ensure that you've chosen the optimum technology choice.  Be cognizant of the potential project delay factors.
  1. Identify initial functionality - which business process and associated messages.

 

  1. Identify which business content standard or standards you plan to support.
  1. Review industry documentation, such as EIDX or EDIFICE guidelines, including supporting documentation.  Especially review recommendations that apply to all business processes and messages.
  1. Select network service provider.  This might be a third-party Internet Service Provider (ISP) or Value Added Network (VAN).   For internet communications, there are several possible scenarios.   Decide what services you may want to perform in-house, and which you want outsourced to the VAN or ISP.  There are a variety of service levels available, too, usually with category names like "gold," or "premium", etc.
    1. A large company may develop their own network and be their own service provider for intranet, extranet, and internet communications.
    2. A company may use its own internet service for intranet communications, and connect with third-party ISP used for extranet and internet communications.
    3. A company may use a third-party ISP used for intranet, extranet and intranet communications.
  1. Determine what the user interface will look like - how the data will be presented internally and to the trading partner.

 

  1. Evaluate the back-end application to see if it has the necessary infrastructure functionality for enabling B2B.
  1. Functionality for identifying which partners are enabled for electronic transmissions.
  2. Determine how partners and locations are going to be identified in the transmission files, e.g. by using proprietary identifiers or a standard such as DUNS or a combination.
  3. Functionality for identifying which business processes and documents the partner is enabled for.
  4. Functionality for identifying which products qualify for the enabled business process an documents.
  5. Determine how products are going to be identified in outbound transmission files and recognized in inbound transmission files.
  6. Functionality for assigning an identifier so that when the gateway receives the file, it knows what to do with it.
  7. Functionality for identifying files inbound from the gateway so that the application knows what to do with them.
  8. What else?

 

  1. Evaluate, select and implement gateway components.  This includes hardware and software requirements.  Many of the components may be supplied by the third-party service provider.

 

  1. For XML data mapping, it is important to understand the difference between the XML parsing methods DOM and SAX, and to determine which you need in your mapping solution.
  1. Determine messaging and transport requirements.  Any of the following may dictate or influence the requirements:
  1. The chosen business content standard
  2. The choice of network service provider
  3. The choice of gateway software and hardware components
  4. Level of security to be supported, and whether or not security levels are flexible (can vary depending on partner and business process).
    1. EIDX recommends 128-bit encryption or higher
  1. If you are using an ISP, VAN or other third-party, perform connectivity test.  Ask if sample data can be provided that allows you to send a test file through to ensure that you can connect without any errors.
  1. Ensure that your internal resources are trained:
    1. Training business users on any procedure changes introduced by automation (if the design of the interface and back-end application is good, procedure changes should be minimal.
    2. Train application administrators on how to configure the application for eBusiness.
    3. Ensure that gateway support resources have sufficient understanding of the standard, how to read mapping specifications, etc.
  1. The very first implementation will include all the steps of doing a first implementation with a trading partner and doing the first implementation of a business process and its associated messages.  You may have future implementations that are new business process with new trading partner, but most of the time you will be bringing new partners up on business processes you've already implemented, or implementing new business processes with partners who already have other implementations with you.
  1. If you are going to be doing a lot of new partner implementations, it may be worth your while to implement an instances of your back-end systems especially for testing, so that you don't have to disrupt production flow or store test data in production applications (which the application may not know is test data).

Last updated 02 March 2003