Main idea

The two technical divisions of a piece of software do not carry the same business value, and confusing them costs a whole project.

The modules — invoicing, purchasing, access rights — were drawn by developers, but they roughly correspond to areas of the business. That is a partial description, free, validated by years of use: a starting point it would be a mistake to refuse on the grounds that it comes from the code.

The tables, no. A table is not a business object: many exist only to connect two other tables, to keep a technical trace, to store login tokens or temporary results. Making one card per table amounts to copying the technical structure as it is and describing, on the same footing, what matters and what means nothing to anyone talking about the product.

The third possible division — folders, walked through in order — has no relation to business importance and produces a mass of cards with no way of knowing which ones count.

Why it matters

It settles the first decision of a description project: where to advance. Leaning on the modules costs nothing and gives an order that has already been validated; leaning on the tables forces you to redo by hand, object by object, the sorting the database does not do.

It holds more broadly: an inherited division is neither to be adopted nor rejected wholesale, it is judged on what it cost to produce and on what it encodes of the business.

Nuances and limits

The approximation the modules give remains an approximation: objects exposed externally may be scattered across several modules, and therefore invisible as long as you advance area by area. That is why progressing module by module has to be doubled with other angles of enumeration.

And the tables keep a value, but as a check angle — they surface stored objects no description mentions — never as a work plan.

Open questions

• On software whose modules no longer match the business because the organization has changed, which inherited division takes over?