RE: Xtreme Ease-of-Implementation

[Stefano POGLIANI <stefano.pogliani@sun.com>]

Todd,

	thanks for the encouragement!
Now, as usual, I am not sure I can follow all of your comments. I will try. 
Here follow my comments.

Best regards

/Stefano

> -----Original Message-----
> From: Todd Boyle [mailto:tboyle@rosehill.net]
> Sent: Tuesday, December 12, 2000 5:55 PM
> To: Bob Haugen; 'ebXML-BP@llists.ebxml.org'
> Subject: RE: Xtreme Ease-of-Implementation
> 
> 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.  

	In the EAI space this concept is the one for Adapters. Adapters
	turn a context-less application into a context-full one, roughly.

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

	This is one of the reasons for really doing this job of specifying
	this layer. The better is specified the simpler it will be for
	some brilliant programmer/company to build a rock-solid software
	implementing it.

> 
> So lets assume you build a real, empowered application.  

	The Application (in the sense of the legacy doing the real "business"
	work) already exists. What we need to "build" is something that
	enables the legacy to play the ebXML game with the other ebXML
	children.

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

	Well, this may be true but it is not something we can ever control.
	I mean, what is important is that we "allow" the things to work
	in a secure way. After that, if the user environment is not secure
	then...

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

	For sure I did not fully understand you. If the BCM (plus all the other
	layers...) plays the role of the Adapter, either it sits on the top
	of the application or it communicates with the application via the
	network. In this second case, I feel that the "security" issue you 
	raised before will be rippled a level down the chain.

	BUT... in my mind, from a technical point of view the BCM can work 
	that way. The Legacy simply exposes a "network" interface (in the
	general sense, something that can be accessed from a dinstant computer).


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

	Well, this part is a little unclear to me.
	I think you assert that SMB try to use an "intermediate" step
	before the actual booking, which consists of some "supervision"
	capability. 

	I "think" that this could be done in two ways:

	1.	The first would be, for instance, that the SMB proposes a CPP
		which uses SMTP....
		Behind SMTP they could do whatever they want, even manual 
		processing.

	2.	The second is more interesting from the point of view of what we
		are talking in this thread. If the BCM software (enriched with
		some other functionality in order to become the kind of
		BSI I am thinking of...) would also be able to automatically
		and ** in a standard way ** log all i/o transactions and movements,
		maybe we do not reach the goal you mention here in a single shot
		but at least we provide the use the possibility to trace back
		what happened on his ledger.

	Does this make sense ?


/Stefano
> 
> > <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
> 
>