Re: Specifying all biz rules in relational data

"mAsterdam" <mAsterdam_at_vrijdag.org> wrote in message news:414a93b6$1$37789$e4fe514c_at_news.xs4all.nl...

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

There are two distinct layers of interest in games: the mechanical layer, and the strategic layer.

Programming the mechanical layer is challenging but straightforward. Consider "internet chess", between two (supposedly) human players. The program has to be able to depict the board, judge the legality of proposed moves, and relay moves between the players. That's some programming, but ultimately fairly straightforward.

If you want to write a program to play chess, the main focus is strategic: how to pick a better move.

Likewise, in business, there are two very different layers: the operational and the strategic. One could argue that there's a third layer, the tactical one, between them. I'll leave that for another day.

The goal of most businesses is to make their operational level as transparent and simple as possible. But they would like to keep their strategic level as opaque as they can keep it.

Note that simplicity of operations is an ACTIVE goal in business. Not so in games. Chess is arguably more complex than checkers, and is arguably more popular because of its complexity. A business that's hard to sell to or hard to buy from, solely because its interface is complex, is more likely to fail. A website that is too complex, in comparison to the competition, is also more likely to fail.

So simplicity and success are linked in business in a way that they are not necessarily linked in games. I would suggest that those in this discussion who have focussed on CRUD are looking at the operational level rather than the strategic level.

When you get to the strategic level, business is every bit as complex as the most complex games that are widely played. I would suggest that business is the ultimate game.

Consider two stock market applications. One manages puts and calls, and matches them up with each other so that the transactions can be consummated and cleared. It also makes transactions somewhat transparent, in that the price is reflected on the board. Such an application is a major challenge. But ultimitely it will be kept as simple as possible.

Now consider another stock market application, one that generates puts and calls. Simplicity is probably not an acheivable virtue in this application. Received on Fri Sep 17 2004 - 14:51:59 CEST