Gerry,

>>That's just for the software licensing. You are leaving out all the expenses associated with implementation, customization needed for the business, integration with existing systems, training, and ongoing support. When all of this gets added up, it comes into the millions. I suggest you do some research and see what happened at Boeing when they tried to implement one of these systems. I don't remember if it was Baan or SAP.<
>
>That was the whole point of "ASAP" (get it?); SAP realized they needed solutions that would "easier". ASAP is their "User friendly" approach for smaller outfits.
>
>We have "small" local companies (Gienow Windows) that are running SAP painlessly.
>
>The others (ie. Husky) are now using it for B2B; no mention of .NET.
>
>I suggest you do the research; it was Boeing and Baan ... and Boeing is not "small".
>
>I find it interesting that you think that companies will spend "millions" implementing an available, component-based solution ... The implication being that if they do it themselves with ".NET" it will be "cheaper". Where is the economy of scale ? Or will .NET suddenly make everyone "smarter" ... bringing in projects that meet requirements, on time and under budget. That's magic indeed.
>
>>>>No, it doesn't. Look at BizTalk Server. Look at SOAP. Both are about messaging between incompatable formats. Neither assumes that you'll be starting from scratch. What happens when the supplier is using Baan and the customer is using SAP and they want to electronically exchange purchase order information? EDI is big and ugly. BizTalk and SOAP will make this much easier.
>
>EDI is the _established_ standard for exchanging "transactions"; BizTalk and SOAP isn't going to change that.
>
>XML cannot replace EDI. EDI defines the _required_ content and codes to identify the transaction types. XML may have a future in EDI, but only in terms of "format"; EDI defines the "meaning" and "requirements" as to content.
>
>Companies are exchanging EDI transactions "now" and have been for 15+ years; they didn't need BizTalk and SOAP then, and are not going to stop and "retool" now.
>
>You call EDI "ugly", simply, I assume because it uses a format other than XML. Or does sticking an EDI transaction in an XML wrapper (ie. "BizTalk") suddenly make it "pretty" ?

EDI actually is pretty ugly. <g> Not that it isn't the best way to proceed.. Just that the standard is so darn flexible within each document definition as to almost - not quite - render EDI an untenable 'solution' for < Fortune 1000 companies. You know as well as I do just how expensive EDI solutions have been in the past. Let's start at around US$100,000 per document.

Still, for all it's warts - it works.

I also do not think XML will replace EDI - only perhaps extend it a bit.


>
>Have you ever seen an EDI transaction ? I dont't think so.

www.eccompany.com - now www.adx.com. I helped with some of the core technologies where in 1996 we sent, from a real bank, a real transaction from a real bank account over the Internet into a real bank account at another real bank. We also successfully 'married' EDI & ACH - something I haven't seen many others do.


>
>Let's say this for XML: it will add a lot of "bloat" to the current transaction load ... something some companies that have to handle "millions of EDI transactions" per day were trying to avoid (eg. railcar tracking).

I think this is the killer of the deal but the current methods of going "the last mile" aren't always too hot either. <g>

Personally I think something along the lines of Rick Strahl's Web Connection plus (and this is the hard part) a local, desktop ability to 'map' to the local data store is what will eventually extend EDI down to the smaller companies - who really cannot compete on the cost side right now.

>
>Again, I don't think you understand the real target of XML.
>
>>How would you categorize BizTalk? Is it a tool? a solution? IMO, it's both. Keep in mind that .Net is more than just Visual Studio. BizTalk is a .Net server.
>
>BizTalk is a "document manager/router"; it's relevance to .NET is secondary. We're getting a lot of hype but basically all it does is wrap some XML around some other "stuff". In VFP, we call it TEXTMERGE.
>
>>SOAP is a protocol that was initiated by MS (and supported by other companies), but now approved by the W3C. Your point about MS wanting things to be just Windows doesn't hold up here.<
>
>My point was MS dumped JAVA to push VB.NET and C# (ie. MS/Windows), and that horse won't fly. SOAP and XML are small favors.
>
>For most people, FrontPage will do the trick.

Just my opinion...