I had a discussion with my father recently on the development of software applications. He’s an experienced product manager with many successful small and medium sized information systems to his name. Having one of those vocal conversations you can only have with family was surprisingly productive and resulted in the discussion of issues in far more candid manner than would ever be possible with a real business user.

Like many high level managers his principal perception of information systems arises from either the user interface or the database. Something you often observe with technically savvy business users is their passionate views on the consistency of database structures. A worthy and admirable goal to be encouraged in any long term software enterprise. However, even when faced with the fact only maybe a fifth of the development time spent building applications is concerned with the database schema itself, they often refuse to accept that there is value in putting similar levels of effort into the architecture of the business tier. That is to say they ignore the structure of the middle tier simply because they don’t have a mental image of the structure within it.

Business users often understand the database structure, at least at a quite abstract level and the extra expenditure on good design in that area is easier to rationalize because of it. The problem with the business tier is that users have little concept of its structure and this promotes complacency about its role. But the business tier tends to be bar far the most time consuming aspect of a development cycle and the construction of the object model can have huge affects on maintenance and extension costs further down the line.

This problem often evolves into a lack of expenditure in progressing the design and architecture of a product. This is patricianly notable in volatile business areas where focus on design goals are rarely escalated above the level of the humble developer.

The question thus arises: How do you induce the user understanding required to allow them to rationalize the extra expense required for extensible business tier architecture?

This is a subject I intend to address in a future article but if you have any thoughts on the subject feel free to email me.