Re: Specifying all biz rules in relational data

From: mAsterdam <mAsterdam_at_vrijdag.org>
Date: Fri, 17 Sep 2004 09:35:11 +0200
Message-ID: <414a93b6$1$37789$e4fe514c@news.xs4all.nl>

Kenneth Downs wrote:
> mAsterdam wrote:

>>Kenneth Downs wrote:
>>
>>>>I have been involved in the developement of
>>>>several largish applications, including a complete
>>>>CRUD-GUI (+ some CRUD scripting system) mostly for
>>>>testing purposes. Maybe 10% of the programming
>>>>budget went into that. When you have the CRUD-stuff
>>>>you aren't anywhere near a serious application -
>>>>in my experience.
>>>
>>>Please elaborate on the other 90%.
>>
>>Tough question, this. My first thinking was:
>>"the application!", but that does not look
>>very nice as an answer.
>>
>>Maybe this helps: Think of a multi-player game.
>>Just two players will do: Chess, tic-tac-toe, or the
>>(computer-)ancient, simple game of 'pong'.
>>Now think of two people playing it over some net,
>>others watching. Imagine the database,
>>imagine the cruds, imagine the userinterface,
>>the protocols, etc...

>
> Hmmm. I will grant without argument that games as a category are more than
> a database, but in same breath I'll argue that the typical business
> application has little in common with games, see below.

The only thing that really matters is the set of interactions, supported by the application. The games are an example.

>>Most interactions are more complicated than this game.
>>The users do *not* think in terms of what is stored in
>>the database - they might not even know that there is one.

>
> As stated above, while this is true for games, it is not true for business
> applications. IMO a well designed biz app will actually bring the users as
> close to the data as possible. In other words, if a business application
> is "CRUD plus", where the "plus" is everything you have to do on top of
> CRUD, then the idea is to have as little "plus" as possible. Keep the
> users very close to the data.

It strikes me as odd, that interactions in games would generally be more complex than interactions in your typical business.

Surely there is a place for database-centric applications. With this type of application, the user is aware of most tables, and actively, conciously maintains data. Before automation you would see a bunch of people operating some filingcabinets with many relatively simple cards with mostly tabular data.

"CRUD plus" nicely characterises the automated version of this type of work, and I do agree here it is good practise to try keeping the "plus" as small as feasible, in order to preserve simplicity, and maintain the necessary table-awareness of the users.

The people with the filingcabinets, however, would typically not be the people doing the real business, but clerks: bookkeepers, administrators; they would provide a service to - games are also nice as a metaphore - the players.

> Here are some examples. One is the simple action of posting cash in an A/R
> application. The basic actions of entering the data are easy, we will call
> that CRUD. But this is a CRUD-plus situation, because in addition to
> entering the cash into AR, we have to cascade some data into the General
> Ledger. In the context of the original post, this is an action that
> follows patterns. It is the same basic pattern as printing checks in AP or
> Payroll, or posting AR invoices in the first place. In all cases you are
> have a user inputing some data, and then you map that data into the GL.
> Looked at in that way, you begin to ask questions like, "How can I design
> all of these operations so that they are instances of the same basic
> thing?" Once I've done that, I've reduced the amount of code I'm writing,
> and with it the amount of bugs, and reduced more operations to simple data
> dictionary entries. When it comes time to explain to the user what is
> going on, you bring him to the HTML page that displays the mapping tables,
> and there is your documentation. Once the user realizes that all posting
> streams are doing the same thing, you have made a friend.

Ah! The second level of automation. Yes, a lot of development results in (developer-shared) tabular data, and the developers may very well be served by administrators maintaining these. I would try to hide those tables from the original clerks, though. Nah - because of automation most of them are now jobless, so let's retrain (a few of) them.
Temporarily. Automate it and you have Meta-CRUD plus, the basic version for CRUD-plus apps being your everyday datadictionary. So ... let's keep the plus minimal, ok?

> Second example. A legacy application has a horribly denormalized set of
> quantity columns in its sales and production tables. So you have qty1,
> qty2, and so forth. To make it worse, in some cases there are cost01,
> cost02, you get the idea. When coding EDI imports and exports, you have to
> constantly transpose columns to rows and vice-versa. Here again the
> transpose can be mappable in a data dictionary. By extension, any lengthy
> import/export that substantially changes the structure of data can be
> specified as a series of a small number of operations.

This would be the Meta-CRUD plus, right?

> The third example I am going to put in another thread, because I have some
> questions about it. It is the Allocation problem that you see in ERP apps.

Nice thread! :-)

> You could sum my whole position as something like this. Customers pay us to
> write database apps. Since 'All Business Rules Resolve to Database
> Specifications', we should spend as much time as possible making extremely
> explicit tables. Once we have done that, the amount of support code (the
> plus in CRUD-plus) tends to drop off dramatically. It also happens when we
> do this that we recognize we are only doing so many things with data, so if
> we can write general handlers for a finite number of operations, we can
> generate some very powerful apps.

I would not formulate this as a position but as a type of automation. Specifically: this typifies automation of secondary (as in *not* the business core) processes. Received on Fri Sep 17 2004 - 02:35:11 CDT