>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" ?

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

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).

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.