RE: Xtreme Ease-of-Implementation

[Todd Boyle <tboyle@rosehill.net>]

Bob Haugen said: Monday, December 11, 2000 2:10 PM
in thread http://lists.ebxml.org/archives/ebxml-bp/200011/msg00053.html

> I separated the software that handles the business transactions
> and drives the liaison with the MessageServiceHandler (the
> "Business Transaction software") from the software that handles
> more the more complex choreography of Business Collaborations
> (the "Collaboration software").  If we call them the BTM for Business
> Transaction Manager and BCM for Business Collaboration Manager,
> then in my view the layers and flows would go like this:
> 
> APP<>BCM<>BTM<>MSH<>TRP<>MSH<>BTM<>BCM<>APP

Well, regardless of anybody's names for these things, it is inherent 
in the whole ebXML project that there will be some kind of 
collaboration manager.  So the only question is how much it will
cost.  I think your work with Stefano to get this piece of 
software built is simply terrific. SMBs everywhere owe you a 
debt.  

Without your work, there would be no solution that permits SMBs 
to use ebXML except EAI middleware, biztalk server and so forth, which 
will certainly cost $5 figures, including their hidden costs. 
Tim Bray spoke to Seattle XML SIG last night, just a quick point,
he mentioned XML Schemas are so complex there's a risk that
only 5 companies will be able to build the parsers. (guess who.)

> The main reason for the separation is that I think that business
> collaborations have a logical boundary that is much larger than
> some other people in ebXML (seem to) think.  For example,
> in the resource exchange scenarios I have been focusing
> on, a single collaboration typically consists of order, delivery
> and payment and all of the document exchanges in between.
> The collaboration is not complete until all the commitments
> have been fulfilled and all the claims balanced.
>
> All stages of the collaboration may not go through ebXML in all
> situations, but sooner or later I think they will.  There are lots
> of problems, both legal and financial, in the current disconnect
> between order, fulfillment and payment in some consumer
> e-commerce sites.  The same problems exist in B2B.
> 
> Legacy apps are totally clueless about how to conduct
> B2B collaborations, especially using ebXML protocols.
> Therefore ebXML collaboration software will be required,
> that looks a lot like your BSI.
> 
> The reason for separating out the business transaction
> level is that there needs to be a simpler "infrastructure"
> release and that level can stand alone as well as being
> used as a component by the business collaboration
> software.

The above is brilliant.   

I don't know why there isn't more of this common sense wavelength. 
You're like this object, out there in the galaxy radiating this 
coherent wavelength of light that is different from all the other 
wavelengths.   Obviously you will go broke... you're an artist...<G>
Just kidding.

> I am happy to leave the wrapping of the legacy system to you, although
> I fully agree that it needs to be done.... to be at least three 
> logical software layers between the MessageServiceHandler and the 
> non-collaborative legacy app:  the adapter, the collaboration manager, 
> and the transaction manager.

Small business *might* accept a new type of software in their computer 
that lets them actually conduct business, i.e. having the power to 
execute a transaction, sending commitments to other parties that are 
more or less final and non repudiable.  But let's face it, this is a 
*very* ambitious concept which simply has never been successfully 
achieved by any commercial software vendor to date, on a widespread 
basis.  

As soon as you have a piece of software that can actually conduct 
business, there is a presumption that it has got to be able to make a 
payment, or at least, a very binding payable obligation.  Businesses 
don't have time to screw around with computers, generating documents 
and messages that doesn't have this power or authority, and then
redo the same documents in their real payables, receivables, and
cash, and wait for the other guy's "real" documents.

So lets assume you build a real, empowered application.  The moment 
you have any significant number of these software on Windows boxes in 
the SMB's office they are obviously going to be attacked by intruders.  
Right?   There is no way for even an expert to secure a Windows 
computer, other than maybe the top 100 security gurus.

So here are my recommendations: by all means, build your layers of the
software, the BCM, that manages ebXML collaborations all the way down 
to the transactions.  Or at least build the UML stuff so that software 
developers can take it down to the code level.  But for the time being,
plan on two things:

A.  Running on BSPs

These objects running on internet BSPs (business svc. providers) who 
have got a reasonable firewall and management to provide the ebXML BCM
services to small businesses thru a browser, thru an SSL connection.

B.  Unposted transaction batch

Plan, furthermore, on any actual money transactions flowing into other 
web-based accounting and business applications as *unapproved*, 
unposted transaction batches along with the rest of the diverse 
payments, POs, and other transactions being built.

Small business is fairly conservative and does *not* feel comfortable 
with various diverse transactions actually being booked or paid in 
their master accounting system automatically.  That's what people are
telling me.  They want to see it in the inbox, at least in summary
form, before they "POST" it to their real system.  

The good news is, you're going to have greater success in adoption, it's 
just like the postal mail which is not secure but works because there 
is always a human approval someplace.  But your system is not going to 
be able to really conclude deals.  Rather, it is going to have to 
wait for a message from the "master system" whatever that is.

Now, you can always try to build a master business system, but you 
would then have to provide a whole set of user interfaces, workflows, 
solutions for the needs of business where they are today, to either
replace their whole accounting stuff, or to import its data as
sub-ledgers.   The latter is not so implausible. 

Or you could decide on recognizing where small businesses are today, 
on Quickbooks, Peachtree, MYOB, and on down the list.  And figure out 
how to slide into their universe harmoniously, in an integrated way 
that smoothly integrates with their existing customer and vendor list, 
inventory, receivalbe, payables and cash.  That's what I'm trying to 
recommend to you.  *I'm trying to tell you the data formats* to import 
and export to/from small business accounting systems, so you can run 
alongside.

This is somewhat difficult with some of the existing software, and a 
lot of businesses will obviously reject the hassles.  But there is 
*substantial* pent-up demand for being able to conduct business over 
the internet, and frustration with printing paper checks, invoices.  
Or paying $10 to $50 a month for crappy billpaying systems that don't 
even have any data integration.  

If you build something that is even half-way reasonable, that permits 
any reasonable possibility of not wrecking their efficiency of the 
existing software, thousands of SMBs will give it a try.  The rest is 
up to you.

> <Stefano>
> I will be very happy to continue this discussion further. Best regards
> </Stefano>
> 
> Me too,
> Bob Haugen

Me too.

* Todd F. Boyle CPA    http://www.GLDialtone.com/
* tboyle@rosehill.net    Kirkland WA    (425) 827-3107
* XML accounting, webledgers, BSPs, ASPs, whatever it takes
* Got a real job 12/11/00  "Functional Architect", NetAccount.com