BOO!!! ARE WE ALL HISTORY???
This message is in two parts,
in the first part I argue why DISA is about to become history, hit by a truck marked 'Microsoft - Internet EC', just another piece of road kill along the path of computing history. Therefore we should just switch tacks and pack our bags and figure out how to go and build EC based systems.
OK - first lets look at some recent press from the 10th DISA conference:
"EDI Expansion"
"The EDI industry is currently growing at over 40 percent annually," says Harvey Seegers, president and chief operating officer of Rockville, Md.-based GE Information Services. Seegers is a keynote speaker at the conference. Seegers' message is "EDI has a future -- particularly if it embraces Internet technology -- to extend its capabilities." An important component of a successful future for EDI is Web technologies such as TCP/IP, which enable data to be moved across diverse computing environments: from desktops to mainframes, from Windows to UNIX. Browser interfaces are another innovation that can breathe new life into EDI by giving the Internet "a much friendlier interface to EDI," Seegers says.
Other industry leaders are seeing examples of EDI growth as well. For instance, Stamford, Conn.-based Frontec is growing at a rate of 40 percent annually, says Peter Stiles, Frontec's senior vice president of consulting, whose presentation at EC/EDI `97 is about using EDI in transportation planning and supply chain management. Wilton, Conn.-based APL Group reports "a tremendous" growth spurt in the past six months, especially in its consulting business. A software and services provider, APL specializes in personal computer- based EDI translation software and is preparing to move into offering Internet and Web-based EDI systems. APL is one of the exhibitors at the DISA show, where it plans to announce a new electronic commerce initiative with Washington-based telecommunications giant, MCI.
Wake up and smell the Roses!
This says to me that all the big players couldn't give a fig about old EDI. New EC based stuff is going to use HTML, CGI and even more importantly the upcoming XML, extendable next generation HTML, along with perhaps some Java objects to exchange business data, business facts, and processes.
(XML - eXtenible Markup Language : )
This will make DISA style traditional EDI obsolete within a year. Especially as the delivery mechanism between trading partners now becomes an NT box running a Web Server and a hook to your friendly local ISP for $20 a month. Add in Microsofts 'Normandy' MCIS product and now you can click, drag-drop out of Access or VB into your Web Browser and your data is delivered. Total integration of MS Office and the backend delivery channels. (Full details at , search on MCIS).
Where does traditional EDI fit into this picture?
It DOES NOT!
It just gets in the way. It's faster to put a Web page and some HTML together to capture the information that you need, and get people to interface that way EVEN if they are using a BATCH process to generate HTML from their database, instead of an expensive translate into EDI format.
So, OK, there is message overhead this way, but who cares? Bandwidth is cheap these days. When EDI was first done 2400 bps was state of the art. Now ISDN costs less than 2400 did 10 years ago. 115200 bps can take alot of HTML overhead.
Better still even new programmers straight out of college know HTML inside and out and there are great GUI tools for slapping fields onto forms and creating the programs to drive them so easily.
Plus, when you send someone your sample HTML form they can bring it up in their FREE browser and understand it instantly. (Try that with your proprietary format EDI Implementation Guideline and EDI message format that only works with the EDI tool you have purchased).
OK - so lets read some more news - smell some more Roses
Like many companies, Mobil Corp. was tantalized by the idea of using electronic data interchange to swap information with business partners. But because of the pitfalls--high costs, burdensome software maintenance and lack of real-time information--Mobil is eschewing traditional hard-wired EDI and using an intranet for electronic commerce in what analysts call a "leading-edge approach" to an area of EDI that's now under intense scrutiny. After a successful pilot, Mobil this month began rolling out the new system to its more than 300 lube distributors, the independent businesspeople who handle Mobil's "heavy products"--packaged or bulk industrial oils and greases. The intranet integrates Mobil's mainframe data with an Oracle Corp. database that holds product information.
Can I call them or what? There's more:
Previously, Mobil had implemented two different EDI systems--one DOS-based and the other Windows-based--that transmitted business documents over a VAN (value-added network). Mobil encountered many of the problems that have stymied the growth of EDI. VAN charges for using the hard-wired networks topped $100,000 a year. Maintenance was burdensome: Every time Mobil changed a business rule, new software had to be sent to each dealer and installed on their desktops. Inventory information was updated only once a week. Because of this, dealers communicated with Mobil through a hodgepodge of EDI, phone calls and faxes: a system of redundant data input that led to many time-consuming errors. Mobil began looking for a new system when its lube group made improving communications with dealers a top priority. The Internet was an obvious solution.
An intranet approach for EDI didn't require a hard-wired network, so VAN charges disappeared. When business rules are altered, Mobil only has to make changes once, test the new rules and put them on the server--they become immediately available. "Our customer support people are excited because distributors can look up the information and make the transaction electronically, so the support people's phones won't be ringing off the hook with questions," said Hawkins.
Mobil's business rules are embedded in the system's Java applets. The system immediately alerts a distributor if he or she is entering an incorrect order--say, asking for a product in an unavailable package size or making an order that is too large for a truck shipment.
Just what I've been saying. This last piece is key. The Java is the transport layer that links business rules and data handling into the whole. OK, but the NAY sayers can still point to some holes.
"Mobil's approach is a leading-edge way to do this kind of application," agreed Rick Drummond, a consultant in Forth Worth, Texas, who has been helping develop security standards for EDI over the Internet. Yet he still has reservations. Said Drummond: "The impact outside this limited application is pretty low because it's not clear if it's dealing with the interoperative issues" raised by EDI systems that are not as closed as Mobil's.
Yep, but guess what, this is just a matter of time, NOT technology.
XML is with us,
and it will provide that missing piece, along with use of Java, to be able to link components of one system to another. So - I can embed rules in XML or Java into my LOCAL data processing system, and have Mobil et al send me those when they update them. Thus allowing this thing to move to the next level in a way that EDI was never able to.
In fact it gets even worse. The new XML provides all that missing Object Orientated transport layer that DISA has been haggling over, built right into your Web Browser and Web server. (As an aside DCOM and or CORBA? Who cares? As an end user, there is no need to worry about such MIDDLEWARE issues, since the browser companies will always have to provide a layer that can transport your objects at the Web server end. DCOM, CORBA? You never see this! Your JAVA or XML toolkit and execution environment handle all this 'bits and bytes' stuff).
Microsoft and Netscape
have had to address these issues for their new V4browsers, not because of EC or EDI but for distributed programming and client/server deployment reasons. Just so happens they nailed the EC and EDI side too.
So where does DISA fit into this model?
It does not!
If I'm Mobil and I'm implementing the next application, I just create my HTML, XML, Java and do it. Then my trading partners collect those components off my Web server and use them to exchange the information we need. I can even generate all this stuff straight off the SQL database definitions I already have loaded up in my CASE tools and database dictionaries.
DISA, who him??
The Second Part of this story: 4 Tier EDI to the Rescue!
From DISA's 10th conference I see alot of haggling over who is right. (Kind a like Nero fiddling while Rome burns around them?)
Let's roll the video tape: >>>>>>>>>>>>>
Modelling a Better EDI
Many in the EDI standards community hope the creation of a new type of EDI standard will open up big new markets for the standardized technology among the nation's estimated 4 million small and medium- sized businesses. The new EDI would have to be simple to implement at little cost. An important aspect of that future EDI standard will be that it must also maintain backwards compatibility with the existing versions of EDI standards, including the standards of ASC X12 and the United Nations.
Standards discussions at the DISA show include one by Klaus-Deiter Naujok, standards manager at Concord, Calif.-based Premenos Corp. His subject is Object Oriented EDI, a new proposal for future EDI developed under the auspices of the United Nations EDIFACT's CEFACT. The proposal, made public for the first time at the conference, makes use of object-oriented techniques to model business scenarios into business objects. Naujok says object-oriented modeling holds the possibility of making EDI easier to use and less costly.
More Than One Way
Dan Codman, co-founder of the Wilton, Conn.-based APL Group and chairman of X12C, the communications and controls subcommittee of ASC X12, says he is not confident object-oriented techniques are relevant to EDI standards. However, ASC X12's Strategic Implementation Task Group, formed to represent U.S. positions on EDI to the CEFACT, will look at modeling techniques to aid the development of a new EDI standard. It will have to be able to be used around the world, cheaply implemented, and understood by anyone who uses it, Codman says.
David Files, the leader of ASC X12's Business Information Modeling Group, says Object Oriented EDI fails to address the needs of large companies doing high-volume EDI. Such companies, the majority of those already EDI-enabled, will find that OOEDI is less efficient for large volumes, he warns.
Estimates put EDI usage in the United States at only 5 percent of the potential. Reaching the hundreds of thousands of small and mid-sized companies not yet doing EDI is a crucial factor in future growth, industry experts say, and a new EDI model is one of the key linchpins in that endeavor. And, of course, different alternatives will benefit different segments of the industry.
So we have at least three camps!
Well, what if all three can live together under the one roof? And the fourth 'grizzly bear' called Internet EC can also be made a player too?
Enter 4 Tier EDI.
Here's a picture of this, and here's how it works.
Layer 1 - Traditional EDI
Layer 2 - Rule Based EDI/EC
Layer 3 - Process Based EDI
Layer 4 - Object Based EDI
Now, what this means is that your total EDI message can consist of some or all of these components AS YOUR BUSINESS NEEDS require.
Layer 2 is absolutely the KEY LAYER. (Layer 3 and Layer 4 are in fact implemented and done with the tools in Layer 2). Layer 2 supports both XML and Java as the means to define your complete EDI message, including the data. You can either embed an EDI message itself using the standard HTML comment token, i.e. :
This is just some text
ST*323*712990413
V1*7039610*NEW ZEALAND QUEEN*D*104N*SCAC***L
LS*0100
R4*D*D*JAX*JACKSONVILLE FL****
V9*EAD**920819**JACKSONVILLE FL***A26
LE*0100
SE*25*712990413
/!>
Or, you can use the newer HTML/XML methods of identifying data fields and their content within your business forms. What is more, HTML already has a convenient 'Process' level mechanism - the URL to the next, or previous linked form, and the POST/SEND mechanism as a way of telling you where the message came from, plus status information. XML of course allows you to roll your own more extensive features. XML also allows you to transport binary information, and is also fully multi-lingual compliant.
OK - so you get the picture. The ability to define your own message sets, structure, rules, objects, whatever grabs your fancy. And then send this to your nearest neighbour via Web Server technology.
Also, LAYERS, so that if an Object Orientated approach is meaningless for your business needs you DO NOT need to use it, or burden your messaging with any overhead or complexity associated with OO needs.
By defining Layers 3 and 4 using Layer 2, you allow people to choose to what level they wish to use each messaging component.
So - how does DISA get into the middle of all this?
Two ways. First XML is a virgin territory, therefore DISA can step in and define XML components and standards for enclosing EDI fields, and mapping Traditional EDI to XML/HTML.
Then DISA can define process components in XML that facilitate EDI, that for example an applet or object called: date_format(), or entity_characteristics(), and so on, that reference the existing EDI data entity rules that have been loving crafted over the last twenty years.
This means DISA can publish a CDROM of XML/Java components that describe and reference existing EDI entities. This will make everyones life easier, and speed implementation of EC.
How?
Because right now, programmers are using Sun's Java library as the next best thing, plus whatever they can grab off the Java/JavaScript language sites of 'canned' code. I.e. I need to check two dates are valid in my Web form, and so I hook in either an Applet, or JavaScript module that does this, pass the applets dates as parameters, and presto, my dates are OK. Well, instead, on the CDROM is a nice set of routines called Java_valid_EDI_date(), and XML_valid_EDI_date(), that do this for me, but now I know my dates are also fully EDI compliant. And so on.
Tool vendors can build plug-ins to Web Browsers that automatically associate these kinds of properties to EDI compliant fields.
Also the Web Servers provide services such as Transaction Logging (alot of them can do that now) and of course message routing to different backend servers based off content and addressing, security, database interfacing. In short everything one would expect from a mature communications server platform.
The second piece is then obvious for DISA
Having stepped into the middle of the EC process by extending XML, and migrating EDI standards over to this transport layer, DISA then has an on going role. Providing both support for this, and also maintaining products such as the Universal Entity Dictionary, and also defining new methods, processes, and objects that are specific to EDI for use with XML/Java.
OK, I hope this is fairly clear. 4 Tier EDI, founded on merging EDI formatting and transport methods with EC Web based methods, where DISA provides the lead in this, and then maintains the standards and certifies vendors products as being compliant, et al. A migration to Web EC based messaging standards as the foundation for future EDI.
Understandably there is a section of the existing DISA membership that has to be resistant to this, because their entrenched commercial position is exposed to newer Web vendors and a completely different business and trading model.
A brief consideration of the alternatives however should bring everyone into focus. This is not really a choice! If Microsoft and Netscape saw a role for DISA in the future of EC they would already be very active members of this forum.
As they are NOT, I can only conclude that DISA needs to quickly make itself part of the mainstream EC agenda, before it vanishes into the mists of time.
Otherwise I foresee that Microsoft will shortly be hosting its on Electronic Commerce Symposium for EC Business Partners, and signing up vendors to support its MMSP (Microsoft Messaging Standards Protocol) that it built-in to the Microsoft Web Server engines and Browsers.
Certainly one EDI stalwart has already made the move,
two months ago "EDI World" magazine was renamed "Electronic Commerce International".
David Webber.