Reply to: e-Business Value Added Hub

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.

Re: this still being mulled over?

Are you still asking?

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.

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.

Re: Phew! best of luck!

Martin,

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

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?

This universal business translator.

Does it work in Europe?



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

Over 12 years worth of supporting trading standards amongst a trading base of thousands has kind of given me some insight into the problems that arise. That is why I know that a "common" trading standard can *never* be achieved.

You have to be a pragmatist - definitive document standards are counter-productive from the inceptive point of view of client take on: produce "this" or forget it? Trading standards should reflect the fact that documents, and so definitions, are only a sum of their parts and it is data components that require the most attention when translating data.

EDIFACT, TRADACOMS, X12, they all display rigid genealogical structures that cannot be remoulded when conforming to a standard. A flat structure that allows referencing between entities gives much greater flexibility - just as any relational model.

Do I intend to build this hub - it may keep me in bread and water when completed so I am actively pursuing it.

Client take on is of course the essence - "no traders" means "no sales". SMEs don't want to know about standards and message protocols - rightly so. They want easy, inexpensive, interfaces either desktop based or via the internet. Some still want Fax2EDI. Larger corps want ERP integration.

I was heavily involved in a scratch-built bespoke EDI project over a decade ago, the product of which I have not seen surpassed in its overall functionality and flexibility - or more importantly, cost!

Re: Sounds great. I'll take ten!

Still think the secret is to find the community that needs the service!

Once you have that then you have something to build. You need to know what needs translating to what. Making it secure is just another service on top.

Sounds great. I'll take ten!

Is this vapourware or do you actually plan to build this mammoth hub?
You state there should be *no* restrictions on document formats, etc, etc, etc.

Have you looked at how complicated trading partner communications actually is? You've only to read the business document models of OAG or Rossettanet to realise it is a massive undertaking. OAG has been trying to establish a common language for EDI for many years. It is backed by many of the top application providers, yet in its seventh OAG release is still far from a real standard.

Then we look at the hubs themselves: BEA Weblogic Integration springs to mind. Have you seen how complicated the adaptors are to connect to SAP, Oracle, Peoplesoft and so on?

I'll answer two questions in one go...

Secure Transactions: Security has to occur at a number of levels, starting with physical access. Can't do much about this with respect to "client" sites. The next step is secure login accounts over networks. Data encryption should be applied at network and business data level.

Whether or not the application data protocol is XML is irrelevant - There should be *no* restrictions in data formats.

Hub services should be provided to allow a range of connection methods, internet & VAN interconnection.

Payments on subscription and "pay-per-use" tariffs.

The key to success is the ability to integrate to ERP systems for maximum hub participation and the "desktop" to generate spoke interaction by SMEs

Re: what do you mean exactly by

Presumably you are thinking about web services that provide a secure translation of message type a (protocol a, standard b, message c) to message type d (protocol e, standard f, message g).

I have assumed there is probably a large market for this, particularly when the development of translators has traditionally been very expensive. Try buy a licence from mecator for example. However, the main issue is who needs what translated by a third party and will pay for the service.

I have not used BizTalk but have assumed it has much of what is required to start a service of this nature.

what do you mean exactly by

"secure electronic document translation" encrypted xml?...?

Anybody else have any thoughts on e-Business that doesn't revolve around "marketing" - i.e. the real work of electronic document interchange?

More XXX than XML then?