|Subject:||Dynamic Range in Webledgers|
|<< previous · next >>|
The concept of dynamic range in webledgers. Think this a minute, ok.
Accounting or transaction systems are usually optimized for a particular "point" along the following dimensions:
(also known as Large Systems vs. Small Systems)
For example, a consumer General Ledger is hard-coded to send you the entire contents of an account or query, in a browsable table. A high- end system will send the user screens full of data with a limited number of rows.
Consumer G/Ls will let you edit or delete previously created transactions. The market has spoken. This has become a universal feature in small GLs. Midrange GLs often hard-code this decision by enabling NO revision of prior transactions.
This emerges as a key variable for webledgers. The software platform and operating policies of the ASP may be optimized for corporate clients interested in great authentication, ensuring strong audit trail, etc. identifying every user, vendor, item, customer, etc. associated with a transaction. ASPs may "Know their Customer", like a bank, or alternatively, allow nymous or anonymous commerce and settlement on the host. A webledger design or ASP operating policy may implement extreme privacy by maintaining layers of abstraction between any data field and its authentic value, or running a totally encrypted webledger whose keys are held only by the subscriber.
Consumer ledgers for example can operate with flexible account or reference codes, or enable code-less operation where the user literally establishes new customers by typing their names. Ledgers for larger organizations usually require codes, or support extremes of code structure such as segmented account codes.
The concept I am trying to introduce is that designers of internet hosted accounting systems must strive to achieve dynamic range rather than reflecting a "point variable" along any of these dimensions. In other words a webledger should never be hardcoded with design tradeoffs, "optimized" for anything.
These are the criteria that should be used to judge a webledger:
Webledgers should be conceived from the beginning, to accommodate a wide dynamic range of subscriber preferences and needs. This capability to accommodate diverse configurations is one of the things that the Internet requires. The diversity of accounting models and requirements is too great, and the market for webledgers will explode too fast. You cannot expect the number of diverse webledgers to emerge, as we have presently got in the LAN accounting software market. Instead of fifty products optimized in fifty ways, you will instead, see 3 to 5 dominant webledger ASPs capable of configuring like chameleons.
In other words, it would be NUTS to design a webledger that is optimized for a particular size of business like Quickbooks. Why? Because it's not necessary, for one thing. But more importantly the market will not put up with it.
Dynamic range cannot be achieved with a single, monolithic table strucuture and user interface. For example, a core GL without sales, purchases, etc. must be competitive on speed. This can only be acheived by creating tables and indexes within the webledger customized to some degree, for subscriber needs. The webledger client, screens and reporting technology will also be optimized within different modules than what you sell to large organizations' subscribers.
The future accounting and settlement architecture for the global economy will be comprised of e-commerce portals, trading communities, and components such as timesheet, payroll, travel expense, purchasing websites, web storefronts, etc. which I call BSPs. (bus. svc. providers) Ordinary businesses won't buy these software, they will pay ASPs to use them. Accordingly, the General Ledger for future integration of these diverse components will be characterized by a need for rapid configuration and optimization along wide ranges of the above dimensions.
Accordingly, webledger hosts will converge around an XML definition for the General Ledger itself. The XML definition for a webledger instance will be transmitted from the BSPs to a competitive market of webledger providers, to establish webledger infrastructure for accounting for the transactions generated by the BSPs, and start ramming transactions into it. All of this will happen within seconds. See my outline "Egoless general ledgers" which conform to user requirements, on http://www.aspnews.com Jan. 10th or so.
The General Ledger table and configuration XML metadata will greatly simplify the construction of consolidation solutions which enable webledgers to interoperate with each other, or run alongside entrenched legacy accounting systems. Ultimately it is likely the consolidation will happen on the webledger rather than the LAN Ledger, Comshare, Hyperion etc.
Legacy systems are designed for Lock-in and their programmers are inbred, clueless about interoperability. You can upload a Quickbooks or Peachtree today, and import your transactions to webledgers. But you cannot import anything to Quickbooks. It has disqualified itself as the integration point for internet transactions. It does not conceive of integrating an open market of BSPs because Intuit expects to run the entire global economy, I guess. The same is true of most midrange ledgers.
et.c etc. by brain runnin' out of glucose and caffeine at this point...
Todd Boyle CPA webledgers. http://www.gldialtone.com
Sent via Deja.com http://www.deja.com/
Before you buy.