Re: double-entry bookkeeping unneeded?
- From: "Nick Malik [Microsoft]" <nickmalik@xxxxxxxxxxxxxxxxxx>
- Date: Sun, 31 Dec 2006 10:38:43 -0800
"Doc O'Leary" <droleary.usenet@xxxxxxxxxxxxxxxxxx> wrote in message
news:droleary.usenet-86AA62.06525231122006@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
In article <45OdnbJbR9hUOAvYnZ2dnUVZ_v-tnZ2d@xxxxxxxxxxx>,
"Nick Malik [Microsoft]" <nickmalik@xxxxxxxxxxxxxxxxxx> wrote:
"Doc O'Leary" <droleary.usenet@xxxxxxxxxxxxxxxxxx> wrote in message
news:droleary.usenet-548CFE.07022430122006@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
In article <nYCdnXTcTrYAtwvYnZ2dnUVZ_s2vnZ2d@xxxxxxxxxxx>,
"Nick Malik [Microsoft]" <nickmalik@xxxxxxxxxxxxxxxxxx> wrote:
The problem with this system is that you will end up with arbitrary
parts
of
transactions that don't make any sense.
No, the problem is that your system has already discarded too much
information from the start.
Example:
transaction 12345
debit $10,000 from cash receipts
debit $2,000 from credit-memo
debit $1,000 from marketing program
credit $900 shipping
credit $1200 sales incentive
credit $9,800 inventory
credit $1,100 revenue
What a terrible example. Look, yes, that low level of detail might
have
made sense before we had computers but the fact is we have systems that
can deal with billions of objects and cross reference them with ease.
this is a typical example. Without changing the business, show me how
you
would represent it.
I'm not about to design an entirely new accounting system from the
ground up for a Usenet post. The burden still remains on you to prove
that the existing way is more expressive than any other. An accounting
Turing Completeness, if you will. When you bother to actually address
the general issues I've already raised, then we'll have something to
talk about.
My apologies, Doc. I'm not asking you to design a system. I'm not asking
for anything more involved than the example 'solution' I posted in my prior
post. I'm asking you to show me the records that you would place, in a db
table, that would represent the business transaction that I described above.
I would store the records pretty much as described above, without
translating them to "take $4 from account 1 and place it in account 2" as
you suggested.
The reason, one that I demonstrated rather completely, is that your
suggestion would create an artificial representation of facts not in
evidence for the sake of your own 'digital correctness' without regard to
the additional COST that this 'correctness' would inevitably incur when the
information is audited or mined.
You ask me to prove that one is more flexible than the other. I ask you to
consider that flexibility is one measure of software quality, but when given
two designs with equal flexibility, then the other variables must also be
considered: performance, security, modifiability, reliability, and
usability.
The mechanism I describe, where rows are grouped by a complete transaction
is just as flexible as storing each record as though it were a smaller,
complete, transaction. There is no data manipulation that you can perform
that I cannot also perform... no report that I can describe that you cannot
also describe. In fact, there are reports that you can describe that I
cannot (as mentioned in my prior post) by looking only at sub-parts of a
single transaction. I posit that this description is actually errant and
misleading and that was my reason for disagreeing with it. That effect
aside, flexibility is not the only attribute that we should consider. Let's
look at some others:
A system designed to store data in the way I suggest would have higher
performance, because there is no need for the arbitrary allocation of parts
of a transaction that I described in my prior post. Not only can I place
data into the persistence store more quickly, but I can extract raw (useful)
data without the need for transformation. Systems designed like the one you
described will have to transform the data on the way out to overcome the
usability problem described below. Without further detail, I'd suggest that
my design is more likely to be a higher performance design than yours.
Our two designs would have the same security strengths and weaknesses.
We would have roughly equal modifiability, because your system has some
simplicity with respect to the ability of each transaction to stand alone,
while mine demonstrates simplicity of being able to trace the transaction
amounts through the various stages of workflow.
While I think you are trying to make the case that your mechanism is more
reliable, I beg to differ. If you consider the design that the OP and I
were discussing in a seperate thread, called the Semantic Persistence Store,
you'd see that we were discussing a design that insures that a layer of code
surrounds the database tables. This layer forms the interface to the
database and insures semantic 'correctness'. The data tables and this layer
together were the SPS. So I accomplished the same reliability as you did,
but not in the db tables. Given the native support for this kind of
mechanism (SPS), and the ubiquitious nature of their use (I've named
something that already exists), I would suggest that these two alternatives
are equal in their reliability.
Usability is an issue with your design, as I pointed out in my prior post.
It is fairly typical for analysts and auditors to take "extracts" of the
data from an accounting system, often along fairly arbitrary lines, and ask
questions about that data as a 'statistical sample' of the entire system.
You can discover a great deal about the applicability of practices, the
expenditure of funds, and whether good governance is being consistently
applied, by doing these things. These activities are not optional. They
are business requirements in every enterprise large enough to afford them
(tens of thousands of corporations in the USA alone perform this kind of
financial analysis every year). The data MUST be usable for this
requirement.
Data in the 'record-balanced format' that you suggest is misleading and
allows too much freedom to create an errant sub-transaction. By storing the
data is a simple yet expressive format, like I did, the analyst is less
likely to reach false conclusions through naieve queries. If they need
business intelligence data, that can be provided through a star schema that
is built off of the accounting database, allowing roll-up by the different
dimensions that are important to the business. Our designs are equivalent
in their ability to feed the star schema. However, as long as the data is
in the financial transaction db, it must not be stored in a way that
prevents or distracts from the core usability needs of the business,
including the need to extract raw, useful, data.
In other words, you are trying to accomplish the quality attribute of data
reliability in the tables, with a tradeoff of usability, while I am
accomplishing it in code with a tradeup in performance. Net: Your design
is less performant and has a major problem with usability. In a design
review, I would not select your suggested design.
This kind of review of a design using software quality attributes is typical
of a methodology called ATAM. For more information on SQA, see
http://www.sei.cmu.edu/architecture/reasoning_about.html
Please do not take this post in a personal manner. I am not criticizing
you. I am, however, evaluating your design with the same critical eye that
I evaluate the design of dozens of systems every year. As an Enterprise
Architect in Microsoft's internal IT division, I oversee the design of about
a dozen large projects every year (there are over 40 of us). In order to do
this, I have to follow an approach that is tough, fair, and standard. I have
to be familiar with the technologies, and intensely familiar with business
requirements, both in general and in the specifics of each system. I find
the ATAM method to be very useful for this. Read up on SQA if you want to
understand more.
--
--- Nick Malik [Microsoft]
MCSD, CFPS, Certified Scrummaster
http://blogs.msdn.com/nickmalik
Disclaimer: Opinions expressed in this forum are my own, and not
representative of my employer.
I do not answer questions on behalf of my employer. I'm just a
programmer helping programmers.
--
.
- Follow-Ups:
- Re: double-entry bookkeeping unneeded?
- From: topmind
- Re: double-entry bookkeeping unneeded?
- Next by Date: Re: looking for a predicate hierarchy
- Next by thread: Re: double-entry bookkeeping unneeded?
- Index(es):
Relevant Pages
|
