PDA

View Full Version : e-Business Value Added Hub



Simerian
31st July 2003, 14:48
What are people's thoughts on the development of an e-Business Value Added Hub providing secure electronic document translation between trading partners?

roger rabbit
31st July 2003, 15:07
I'd rather have my bilingual secretary sitting on my lap with my foreign suppliers invoice in her hand, licking the pencil as she demonstrates her expertise in French - you with me?

That's what I call Value Added.

Simerian
31st July 2003, 15:14
More XXX than XML then?

Simerian
6th August 2003, 09:56
Anybody else have any thoughts on e-Business that doesn't revolve around "marketing" - i.e. the real work of electronic document interchange?

ScotsPine
6th August 2003, 11:30
"secure electronic document translation" encrypted xml?...?

OrangeHopper
6th August 2003, 12:08
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.

Simerian
6th August 2003, 18:18
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

Martin Underwood
7th August 2003, 09:15
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?

OrangeHopper
7th August 2003, 09:37
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.

Simerian
7th August 2003, 11:16
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!

DimPrawn
8th August 2003, 08:14
This universal business translator.

Does it work in Europe?

:p

www-3.ibm.com/software/ebusiness/jstart/pdfs/universal_translater_concept.pdf (http://www-3.ibm.com/software/ebusiness/jstart/pdfs/universal_translater_concept.pdf)

Martin Underwood
8th August 2003, 16:24
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
8th August 2003, 17:46
Martin,

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

Simerian
8th August 2003, 20:24
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
23rd September 2003, 15:12
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
10th October 2003, 13:50
Are you still asking?

bakersdozen
17th October 2003, 18:07
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.