A meticulous, business-focussed approach to application structure...

an image of an italicised letter i, depicting information

Taking our jointly developed specification for your project, we craft a conceptual system design of the back-end data store, the business rules, business logic and the front-end or user interface. An end-to-end solution is usually built in 'layers' describing distinct sections and functions of the solution and is usually known as a multi-tier or, more usually, an n-tier design.

The n-tier design method allows us to completely separate, but loosely couple, the components of the application. This enables maintainability, the re-use of code and much easier updating/upgrading. It also means that it is possible (sometimes even desirable), to locate the different components in separate physical locations. These components, or tiers of the application are described below and, in general, lay out best practice whether for desktop or web-based solutions, although there are differences in some of the technologies, methodologies and tools utilised across these scenarios.

1. The Data Storage Schema...

We start the physical work with the design of the schema, or definition, of the store for your business data. It determines how the data related to your various business 'entities' (customers and orders, as a simple example), will be managed and related to each other.

an image of a human hand drawing a software flow diagram

It also manages how (and which) data is inserted, updated and deleted. It is the source of most, if not all, of the application output. This, of course, is the database definition. Before any development work is undertaken on what the user will actually see and use (the user interface), it is crucial that the data schema definition is designed first and based wholly on the detailed information gathered via the business analysis process.

At this stage we would also look at assigning permissions and authorisation for various groups of users at the database level; for example a user given 'administrator' privileges would have access to areas of the database (through the user interface) that no other user type would have.

2. The Data Access code layer...

Once it has been established that the data schema is correct, we move up a layer to write code that will access this data in its raw form. This layer will ultimately be accessed, via another layer of code (the Business Rules/Logic layer), by user activity occurring through the user interface. The Data Access layer is responsible for directly reading and writing from and to the underlying database, retrieving the requested information for ultimate presentation to the user and saving changes made to that information.

3. The Business Rules/Logic code layer...

This is the layer of code which enforces your business logic and rules on the data before it is passed to the Data Access layer for storage. As an example, consider a customer order. Without any clear method of enforcement, a user could input an invoicing date that was earlier than a delivery date. Without a rule, this data would be passed to the store unnoticed. This is just a very simple example: many rules of vaying complexity need to be enforced, each of them gathered as part of the analysis process. This layer is also that which receives its input via actions occurring through the user interface.

4. The User Interface...

Finally, we design that part of the system your users will directly interact with. If the Business Logic layer with wich the UI interacts has been designed correctly, then the flow of data between the two should be natural and seamless. Focussing purely on the clean, logical and uncluttered input and viewing of your essential data, an easy to navigate, productive UI is essential to the smooth running of your business processes and the satisfaction of your users.