An AT&T EDI technology seminar I attended in 1994 turned into quite a confrontation; AT&T, which had launched one of the most economical and versatile value-added networks for EDI data transport, had brought together a number of us from the third-party software pool to get acquainted with the features of its network. What I remember most clearly is how ludicrous the idea of sharing business data over the Internet was to us. It was a running joke: "How are we gonna get this to work?" "Well, you know, there's always the Internet. Ha."
A decade later, nobody's laughing, and the value-added networks are more than a little nervous. The Internet is far more secure, and virtually every company you're likely to do business with can be accessed through it. If the time has come to begin developing those connections more thoroughly, you can take comfort in the fact that you have a full spectrum of options. But where do you begin?
Explore Web services
There's an abundance of information on Web services, how they work, and how you can tap into them. Here's what you should know:
- Web services permit and facilitate, in principle, any data transfer application that you are using today in more primitive form.
- The core protocol SOAP is friendly to whatever you already have in place, so you're facing an adaptation, rather than a complete overhaul, in moving an existing application to a Web service.
- Your data-mapping options in a Web service app are sophisticated and growing more so all the time.
- There are numerous development suites available to you specific to J2EE and other development packages you may already have invested in.
- When you build one, the bridge remains. This is also somewhat true of EDI (though interconnects often differ), but once you have a Web service app in place, you have enabled a great many.
- The cost is almost certainly a fraction of what the alternatives will run you.
How do you get started in using Web services for B2B apps? You need do little more than have access to the Internet. Beyond that, there are a few good preemptive moves:
- Consult your application development people. Your Web service apps can probably be accommodated by extending your existing development environment (Java, etc.). If so, you can easily make the most economical choice up front, in terms of the cost of development software you must acquire and your anticipated maintenance.
- Survey both your existing data transfer apps and those you're thinking of adding. What are your partners doing? If some are already into Web service apps, your battle is half won. You can not only acquire lots of know-how, they can probably share components with you (another beauty of Web service apps).
- Do the research. It's the cheapest, most accessible research you've ever had to do in data transfer app development. Existing Web services are, by definition, right there on the Web, and you can learn all about them as you sit in front of your computer. They're dying to bring you up to speed.
How far can XML take you?
The whole point of electronic data interchange is to create a system whereby Company A's business documents (which have a unique format that is important to Company A) may be shared with Company B, which has its own formats, in such a way that nothing is lost in the translation. The ANSI X-12 EDI standard (along with EDIFACT, UCS, and other variations and subsets) provides a framework that is simultaneously flexible in application and rigid in execution. The advent of Extensible Markup Language (XML) represented a giant evolutionary step forward in this kind of thinking.
With XML, you can create complex objects as intermediate versions of business documents using agreed-on labels that unambiguously define all data contained in the object without all the structural complexities of EDI. On the other hand, you lose EDI's most important feature: big, fat books full of translation standards that everyone agrees on. Any XML translation system you put in place between your company and your partner companies is going to be proprietary, and proprietary systems are expensive and a nuisance to maintain.
But there's hope all the same for custom XML-based systems. Consider that with XML, you have a host of development options that unleash for you the power of object-oriented design. That is, you can create classes and types that make your XML-based translation scheme extremely portable to your partner companies (they can share it all with you, meaning minimal fuss for them) and eminently maintainable and extensible—not exactly trivial considerations. If you already have a Web presence that requires you to maintain XML skill in-house, you may wish to go this direction in ramping up for B2B.
Consider opening your databases to partner companies
Here's something important to consider if your company is in an ERP environment: are you a SAP or an Oracle house? If so, you have a data-tabling system available to you that will export parsed objects according to security protocols that can be customer-specific. That is, you can open the data tables containing product-specific inventory data to partner companies (it's assumed that you have ftp capability; if not, you better do something about it). Either of these ERP platforms permits you to establish client-specific security that will lock out data that isn't relevant to the particular client accessing the data. In effect, you can offer your inventory database as a resource to your customers, and painlessly secure each customer so that they only see what matters to them.
There's a knee-jerk resistance from CIOs to let outside parties, customer or no, into your databases. But it's easier than you think to make such an arrangement completely secure, and you have the benefit of dual use: The same mechanisms that secure the interface are the mechanisms that parse the information for your visitor.
And consider the business advantages. You can not only replace existing data transfer apps with an arrangement like this, you can open up new opportunities. Consider that it becomes possible for customers to plan their ordering of your products in accordance with your inventory data (as an example). This pre-order synchronization of data between you can enable a far more efficient product ordering cycle, eliminating the inconvenience of making the customer aware of shortages after the fact, and availing the customer of knowledge of abundant product availability (especially useful as strategic marketing data if you're selling to retailers or distributors). Consult your ERP gurus and explore the possibilities. It may give you not only a technological edge, but numerous business advantages.
EDI systems—integrating the old and the new
Do you already have EDI systems in place? If so, they've probably been there awhile, and you undoubtedly have a great deal invested in them. Moreover, you have data-trading partnerships with outside companies that represent a deep investment on their part. How do these systems figure in your thinking?
It probably costs you quite a bit to keep those systems in place (in fact, XML-based systems and Web services are supplanting electronic data interchange largely because they're so much less expensive), and now you face the prospect of propping up the old, expensive EDI while implementing the cheaper and more versatile Web-based alternatives—not a happy proposition.
You can do many things, but the most important are these:
- Renegotiate your relationship with your EDI value-added network. Get a better deal; they don't own this market anymore, and they're more flexible than they used to be. The fact that you are motivated to go with other platforms is a signal to them that you may not need them anymore.
- Make the reasonable investment in adapting your EDI database import/export facility to whatever import/export you're using for other systems (that is, for those data transfer applications that use the same type of data as your EDI apps). Odds are that your original EDI database extraction software was a customized effort, done some time ago. Since your EDI translation software probably provides the necessary mapping utility, you can make this change with few headaches. Why have several database import/export routines when one will do?
Further cost reductions
The only piece of your EDI legacy systems that is truly costly on a month-to-month basis is the data transport itself—and you can reduce that considerably. Your other big investment—the EDI translator software—is already made, and doesn't need to go away. Everything else is yours to change. Apply some creativity and bring your old EDI systems forward with your new B2B development.
Scott Robinson is a 20-year IT veteran with extensive experience in business intelligence and systems integration. An enterprise architect with a background in social psychology, he frequently consults and lectures on analytics, business intelligence and social informatics, primarily in the health care and HR industries.