I have said before, and I will undoubtedly say it many times again – every application uses data. Most business applications use very formal data structures usually via a relational database.

There are a number of ways of looking at applications. The two most common approaches, at least in years gone by, are UI centric and data centric. The UI centric view looks at the application from the point of view of the User Interface. The data centric model considers the data to be the most important part of the application and builds around it.

Neither of these approaches is intrinsically wrong, but too great an emphasis on one over the other can lead to problems in the design of the whole application.
By concentrating on the User Interface there is the danger of designing the database to fit in with what the User wants to do. Conversely, by concentrating on the the database the user may be experience difficulties in what they wish to accomplish because of the constraints of the database.

This is, probably, rather obvious. The user has certain goals which they need to meet. For example, the user may wish to create and send an invoice. But the data needed to create the invoice is likely to be contained in a number of tables: a Customer table, an Invoice table, an Orders table, and so on. The problem for the application designer is not how to build a User-centric interface and a data-centric data layer, for that is not really a problem at all, but rather how to build the transport layer between the two.

In the object oriented world this is usually accomplished by building a business layer which sits between the UI and the data, a typical 3-tier system. And, again, this problem has essentially been solved, and solved in many ways.