Anecdote: Transaction
Introduction
You can either choose to watch the movie or read the anecdote explained below.
Two data management consultants of a large bank, asked to discuss with them a matter on redundancy. They said they have the principle that a Logical Data Model should not contain redundant data but that they ran into a situation where they cannot avoid it from happening. They told me about their model, simplified for the purpose of explanation, containing the Business concepts Customer, Current account and Transaction. They explained that when money was transferred from one account to another, both would get a Transaction that would be almost identical: both carrying the two Bank account numbers involved, both having the amount, currency, description and both will have the account holders name of the counterparty.
I stated that I agree on their principle and that a Logical Data Model should not have redundancy. On top of that, I found this case a good observation. Most people only consider redundancy at the Business term level, in a way that one Business term can be derived applying a Business rule using a or multiple other Business terms. Here, duplication of Business concept objects was addressed.
I applied a Business Data Management principle, questioning Transaction to be a Business concept: it is not something out of the real world of the business. The consultants did not agree with me. They said, “Transaction is in our systems, so it is real and should be modelled”. I asked them to explain to me the process. Where does a Transaction come from, who initiates it? They told me that it is the customer using electronic banking or an app, selecting the own account to debit, selecting from a contact-list the account to credit, adding the amount, a description, date of execution, etc. and after validation the customer sends the payment order to the bank. After several checks within the bank, two Transaction objects are created “Because the payment order has to be booked”, they explained.
In the meantime I was drawing a slightly different diagram containing the concepts Customer, Current account and Payment order. The Payment order will have 2 relationships to Current account, one for the debit and one for the credit account. So in response, I asked them about the noun they used: “Payment order”.
I told them that from a business point of view, there is no need to evolve a Payment order into a Transaction. And that “booked” may just be a status in the life cycle of the Payment order . That means that Transaction must be considered as the technical implementation of Payment order. That may be necessary from a technical point of view, but does not belong within a Logical Data Model neither within a Business Data Model. They had a point in telling me that Transaction was also reported back to the customers in terms of daily, weekly or monthly overviews, so they considered it as part of “the real world”. Still I questioned if this is right. Wouldn’t like the initiating customer rather be informed about the Payment order being fully executed as requested, and that the specified amount was credited to the account of the receiving customer? In stead of only getting the confirmation that the amount is taken/debited from his own account?
Conclusion.
What we see here is that Payment orders are subject of extensive processing and only the (rather technical) outcome is stored in an (back office) accounting system. Processing within a channel, front- or mid-office may lead to loss of business data, context and information, not only for cases that reach the end stage but also for cases that do not.
So within Business Data Management, we define and model Payment Order and not Transaction.
