e-Business Value Added Hub

[DimPrawn]

This universal business translator.

Does it work in Europe?



www-3.ibm.com/software/ebusiness/jstart/pdfs/universal_translater_concept.pdf

[Martin Underwood]

Phew! best of luck!

I'm still unsure what you are intending to build.
Is it a totally flexible document translation facility?
If so, you can't get away from quite rigid standards.

If a company transmits an invoice using OAG XML version 8, how will you be able to pass that to a buying organization that only supports OAG XML version 7.2, and another that only supports RosettaNet PIPs, etc, etc, without having some very complicated understanding of each of these message standards?

It is for this reason that the adaptors for products such as BEA's Weblogic Integration are incredibly expensive, because they have taken companies like BEA many months to develop each adaptor.

Now, when you start to get to non-standard interfaces, such as those provided by SAP and Oracle Applications (have you see their open interface specs? they make a grown man cry!), then it gets really messy. Luckily, the ERP manufacturers are starting to see sense, and use OAG standards, etc.

For a really interesting example of how difficult full B2B really is, have a look at how different banks communicate financial transactions with each other over swift. One bank will use a sort code, the other a fedwire address, the other a swift code, the other a name and address. How do you translate these?

[DimPrawn]

Re: Phew! best of luck!

Martin,

I bet you're great at parties...:|

[Simerian]

Re: Phew! best of luck!

Firstly, do not confuse translation with conversion. When you write of Banking sort-codes, fedwire addresses, names and addresses you are inferring data conversion. Translation is of course concerned with the mapping of a structure from one form to another.

There is always an issue with backward compatibility, and sure enough, you cannot fit a quart into the pint pot. Shared data entities translate directly or with some element of re-encapsulation. Those entities that do not "fit" have to be resolved from a business necessity point of view. If the receiving system has no ability to receive such data, there is very little point in it being sent; let common sense prevail here - I have experienced many occasions where extraneous data is identified and ignored under a contractual trading agreement.

I'd like to iterate the initial gambit of the envisaged VAS: To open up the electronic trading arena between SMEs and ERP hubs. This is very different from an electronic market place where documents *tend* to be pre-contractual. Orders and Invoices, for example, are (generally) post-contractual within the B2B arena, however, difficulty arises when the ERP hub provides the sole impetus for electronic trade because of anomalies between standards - that is to say, if the SME wishes to trade with a different ERP supplier/customer then they are usually, I think the technical term is, stuffed.

Yes, they can buy a set-up that will provide translation on the desktop. How many SMEs want to get mixed up with a discipline that (frankly) perplexes most professional IT people.

As I mentioned before, I'm not a neophyte in this matter, I have many years of experience in EDI, document translation (and data conversion) and the issues you mention are largely contextual: BEA weblogic integration is (essentially) developed once for *everyone*. VAS-Hubs have to deal with a finite number of ERPs (the SMEs can be dealt with according to the VAS requirements filtered from the ERPs) that tend to deal in *limited* forms of document definition.

I would also mention that having been closely involved with many "bigname" IT organisations, I'm not mightily impressed with the market approach to EDI/e-Business and certainly not document definition. I have seen EDIFACT-2-XML maps that quadruple the size of the original message. Normalised? No, not at all. Don't be too quick assume that an IT industry run by marketing graduates is necessarily steeped in data processing methodology.

Also, the approach to the inception of such a service has to be based on specific electronic trading groups. It is no good opening it up to every man and his electronic dog (K9?) from the off. i.e. it achieves presence and status by supporting an existing arrangment or providing a new method for an ERP hub to trade with SMEs.

[bakersdozen]

this still being mulled over?

Haven't been on the boards for a while but this seems interesting. Currently doing some work with Biztalk and other technologies in an authentication portal environment so am happy to provide input or take further.

[Simerian]

Re: this still being mulled over?

Are you still asking?

[bakersdozen]

Re: this still being mulled over?

Simerian,

Sorry for the delay, I don't view the boards that often. Yes, I'm interested so let me know how I can contact you.