Nick Polyak’s Software Blog

Enterprise System Definition

By enterprise software system I mean a system that involves a database that can be accessed by multiple users at the same time.
As shown at the figure below, such system usually consists of three parts:

1. Front End (whether it is a stand alone or a browser based application). Front End is part of the system that the users are aware of: some Graphical interface through which the users can view and/or modify the data.
2. Middle Tier for connecting the Front End application and the Back End. In addition to connecting the database and the Front End, the Middle Tier can also play role in other aspects of the application such as security, load balancing, failover, error handling, etc.
3. Back End for storing, updating and reading the data in the database or in multiple databases. 

In order to create an enterprise application one needs to develop all the above layers (tiers).
Front End is usually built using languages that have packages for developing GUI (Graphical User Interface), e.g. C#, Visual Basic, or Java for stand alone application; Html, JavaScript, Flash, Silverlight for browser based applications.
The Back End database tier is usually written in a superset of SQL language: Transact SQL for Microsoft SQL Server and PL/SQL for oracle.
The Middle Tier, whose main purpose is to connect the database and the Front End application, is usually built in one of the common programming languages: C#, Java, C++ or Visual Basic.

To speed up the development, the Middle Tier and the Back End are often developed together. This was made possible by the code generators (which generate code for calling the database stored procedures from the Middle Tier language) or by frameworks like hibernate (which generate both the database code and its middle tier accessors).

Client Driven Design and Development

When a brand new enterprise product is about to be built, the team or company in charge of its development, faces obvious questions: which tier to start building it from, which tier should be given more importance at the beginning.

In my experience, many times the companies have all three tiers built at the same time by different people. Sometimes, the database and middle tier pieces are given priority since they are the core of the system, and the Front End development is considered to be an icing on the cake.
The point I am trying to make here is that the above approaches are wrong, and actually the Front End development should be given priority while the middle tier and the Back End development should be determined by the Front End needs.
The reasons for such an approach are the following:

1. Front End is closest to the customers, so the Front End developers understand the customer or Product Management requirements the best. While developing the Front End, they can write requests for the Back End and the Middle Tier functionality that they need; those requests being fulfilled by the Back End and the Middle Tier developers.
2. In the same way that the end users or product managers are the customers of the Front End developers, the Front End developers are the customers of the Back End and the Middle Tier developers.
3. When Middle Tier and Back End developers work in a vacuum they are risking spending a lot of time developing functionality unnecessary for the Front End development and skipping what is really important.

This is not to say that no database and Middle Tier work can be done in parallel or even preceding the Front End design and development. Everything that does not have a direct impact on the Front End, everything that the end user does not know about, like security framework, failover, load balancing, error handling, etc, can be developed without existing Front End design. Preferably it should be developed in a way that would have minimal effect on the Front End functionality.

Vertical Development

In the case where the team posesses the right set of skills, I would advocate something I call Vertical Development. This is an ultimate case of the Client Driven Development. Under Vertical Development, the same person creates the Front End, the Back End (up to creating and modifying the database tables) and the Middle Tier functionality for a specific chunk of the Front End application. The great plus of such approach, is that the developer is given more power to change and prototype: the developer does not have to request changes from somebody else for every minor change in the Front End application. Also, the unit testing is simplified: the Back End and Middle Tier changes can be tested via the Front End application.
There are two manageable shortcomings to such approach:

1. There are more opportunities for the developers to “step on each other” if they work across all three tiers. This should be mitigated by more care on the developer’s side and by the developers’ goals being defined in such way as to minimize the collisions.
2. Datables and stored procedures might be developed in completely different styles which would lead to confusion later. This should be taken care of by the setting the rigorous standards for code development and by the architects carefully reviewing the code and asking the developers to re-factor it if necessary.

There are two questions with respect to Vertical Development aproach that can arise

1. If developers A, B and C work at the same time on different screens or different sets of screens of the same application using Vertical Development approach, how easy is it going to be to put their stuff together? The answer is that usually it is much easier to integrate the code developed vertically, than horizontally. The reason for that is that different screens of the same application have much less dependency on each other than the Front End of the same screen on the Back End and the Middle Tier. Still even under Vertical Development, the team needs to have good procedures in place for integrating their work.
2. The second question is about the code reuse. Would not code reuse be weaker under Vertical Development; can it be that multiple developers will be working on similar functionality? In my experience this is not the case. Both in case of Vertical and Horizontal development methods, the code reuse requires good procedures, good communications between the developers, a lot of effort by the architect and the willingness to spend time re-factoring the code.

There is another advantadge to Vertical Development method. Since the developers are less depended on each other, it is much easier figure out who is actually responsible for success or failure.

Please tell me what you think in the comments.