Accounting has only CRUD APIs
numeric.substack.com
Accounting has only CRUD APIs
1–4 of 4 posts
Re: Accounting has only CRUD APIs
#2Accounting is downstream of business processes that have been mismodelled for decades. The antipattern is overloading the successive lifecycle stages of a business object onto a single database table, and distinguishing them with a status code or by whether or not certain "optional" columns have been populated.
I hope it is immediately obvious why that gives accounting bad inputs.
The crisis that accounting is facing is the impending failure of their ability to shift blame for bad inputs.
Re: Accounting has only CRUD APIs
#3Accounting is downstream of business processes that have been mismodelled for decades. The antipattern is overloading the successive lifecycle stages of a business object onto a single database table, and distinguishing them with a status code or by whether or not certain "optional" columns have been populated. I hope it is immediately obvious why that gives accounting bad inputs. The crisis that accounting is facing…
I agree with your first statement, but a little lost on the last one—I would think of the first idea as a question of data modeling, whereas the last (bad inputs) is one of enforcement and ownership.
Both present challenges, but better inputs don't help without a better model for business objects (as I see it)?
Re: Accounting has only CRUD APIs
#4Accounting is downstream of business processes that have been mismodelled for decades. The antipattern is overloading the successive lifecycle stages of a business object onto a single database table, and distinguishing them with a status code or by whether or not certain "optional" columns have been populated. I hope it is immediately obvious why that gives accounting bad inputs. The crisis that accounting is facing…
I agree with your first statement, but a little lost on the last one—I would think of the first idea as a question of data modeling, whereas the last (bad inputs) is one of enforcement and ownership. Both present challenges, but better inputs don't help without a better model for business objects (as I see it)?
The practical purpose of information modelling is to prevent the bent coins from propagating. The end users will always create them -- to this day, they were trained on typewriters, and they think '1' and 'l' are the same. The point is to stop the malformed data before it gets where they can cause harm, either by blocking a data-transmission path or by being exploited by bad actors. The status quo is that each point of contact has its own validation rules and its own notion of how severe each kind of syntax error is. A worthwhile model unifies that end-to-end.