Three-tier architecture is one of the basic paradigms of software development. This design pattern can be beneficially used in web integration projects, as a basis for the overall solution architecture, with benefits.

Also, you should not miss the previous part of the article series about web integration – Roles in integration project. It is a must-read!

In recent projects carried out for Czech financial institutions I frequently encountered problems that snowballed. Web projects that take several years turned into “monsters“, and from the software architecture perspective, this caused many basic problems. Due to the incorrect software architecture, it is very difficult to know which supplier provided what, and to make flexible changes to parts of the solution. Therefore, there is often a complete dependence on the supplier and its knowledge, including in processes that are vitally important in commercial terms.

In this article I will therefore try to outline ways to minimise such difficulties by applying the well-known principles of three-tier architecture.

Three-tier architecture is software architecture that can be separated into the presentation tier, functional/process logic tier, and data storage. Each tier carries out separate tasks; and the layer can be developed, maintained and changed separately, based on the assumption of an unchanging (backwards compatibility) interface between individual layers.

• The presentation tier or user interface tier is responsible for interactions with operations – information gathering, as well as displaying it in a legible and user-friendly format.
• The “business“ logic tier plays the role of transferring information between the website and the data tier, including integration of the required decision logic or transformation of transferred data (calculations, aggregation of information from more data sources and the like).
• The data storage tier implements persistent data storage, with a relational database (RDBMS) or another type of database (NoSQL).

This principle brings a number of basic benefits:

1. Individual tiers can be managed independently

In preserving the integration links, it is possible to carry out basic changes in separate tiers without another layer.

1. The sizing of each layer can be adapted to its performance requirements, regardless of the other tiers.
2. The security setting of each tier can be adapted to its use and requirements.
3. The correct separation of individual tiers enables separation of knowledge important for managing them and allocating appropriate sources to them, without unnecessary overlaps and with consideration of the complexity of individual tiers.
4. Clear separation of competences, if more than one supplier is involved. Individual tiers and the interfaces between them can be beneficially used as a demarcation of competences between suppliers and individual parts of their solutions.

Adapting three-tier architecture to the needs of a web integration project

A web integration project (in most cases a company portal) has its specific properties, to which the overall architecture of such a solution needs to be adapted. The principles of three-tier architecture can be beneficially applied at an abstract level vital for modelling the entire solution.

From the diagram it is evident that in abstract terms we move to a higher level when the basic feature is the system (e.g. CRM and ERP, as shown). It provides the necessary functionality to its environment, and it too can be three-tier.

The diagram also implies the growing complexity of individual tiers “downwards“ and the increasing efficiency demands (in terms of the number of requests dealt with) and flexibility “upwards“.

The typical composition of individual tiers of the architecture as part of the network infrastructure of a project owner is shown.

Presentation tier

In an integration project the presentation tier is extensive and includes both the user interaction in various devices (multichannel access) and tools for managing this tier – Content Management Systems or CMS), an appropriate portal platform, serving as a basis for the developing a specific functionality. This tier is crucial from the perspective of the web integrator’s role.

The presentation tier includes:

• Architecture matching the portal aims.
• A user interface optimised for the specified versions of devices and browsers and their use context, inevitably most often as output HTML/CSS/JavaScript code. It is important in specific cases to consider using other technologies – e.g. a native application for a mobile, touch, desktop or other device.
• Support for user interaction in the form of data insertion and display.
• Interfaces enabling further integration in a structured format – different forms of XML outputs/feeds(RSS, RSS 2.0, Google Sitemap and such like.), web services (SOAP, REST) or application interface (API).
• Tools for measuring user behaviour.
• A platform providing a sufficient function for putting together a solution and development of a specific functionality.
• A tool for easy management of structure and content, bearing in mind the specifics of a concrete project: Content Management System.
• A means for ensuring sufficient performance of the whole solution, in view of the expected number of visitors.
• Security features and measures for ensuring that the project works in the internet environment.
• Specific functionality without an interconnection to the portal owner’s internal system. This means minor independent functional units (modules) as additions to portal features.
• Functionality in terms of SEO and other on-line marketing activities.

All data transformations impacting on the internal systems of the client are naturally linked to the business activity of the portal owner and contain important business logic and know-how. Such data transformations should obviously not be part of the presentation layer, and they should be separated and included with the business logic tier.

The presentation tier is typically implemented based on the design pattern MVC (Model-View-Controller) and its derivatives (MVP), but the difference is that the direct link to the data model is connected to the business tier, which is made accessible using services components, consisting of the service model of the application.

The presentation tier is also very often created externally. It is therefore important to clearly set security rules, responsibilities and especially prevent loss of know-how if an inappropriate leakage of business logic to an external partner occurs, without ensuring the sharing of information or a clear exit plan.

Business logic tier

This tier is crucial in terms of data transformation between the presentation and data tiers. Here a strong platform should be chosen that allows the collection, transformation and subsequent distribution of information in both directions. From the system integrator perspective, this role is crucial.

From the web integration perspective the business tier should contain:

• Screening of the presentation tier from the data tier.
• A clearly defined and documented interface (typically in the form of web services or, in the case of one application technology, interface classes). With such forms (even if it is with a modification for specific use) it is possible to use the interface both for the presentation tier and for other forms of client devices (mobile native application, specialised HW) and communication channels.
• Storage of shared information within individual systems from the data layer and channels from the presentation layer.
• Temporary storage of information necessary for use in the presentation layer, when technically it is not possible to assure accessibility to the information directly from the data tier.

The business logic tier is crucial in terms of retaining internal know-how. It should be carefully recorded in an analysis by the owner, including thorough documentation and substitutability. Leakage of know-how from the firm should be minimalised or thoroughly investigated, and include an exit plan.

Data tier

The layer of core systems, which enable final storage of information and further data processing. This tier tends to be very heterogeneous, with a mutual connection of several parts (systems), which causes problems. To lower the number of integration links, the business tier is used, therefore enabling interconnection of the internal system only to one other node. The data tier is crucial for internal systems, their implementer and system integrators.

The data tier should therefore contain:

• Internal systems with primary data (product catalogues, business parameters, documents and the like.), and in some cases final storage for certain type of entities (user, order form, invoice and such like).
• Specialised internal data storage.
• Selected internal systems connected to basic business activities.
• Specialised reporting tools used as part of or apart from selected data taken from the systems.

Data tiers are beyond the direct competence of a web integrator and they are typically provided by specialised entities.

Benefits for a web integration project

The above division provides several basic benefits for a web integration project:

1. Maintenance of key know-how as part of the business tier with the project owner and its dependence on the presentation tier supplier is reduced.
2. There is clear delineation of competences between each supplier (whether internal or external).
3. It is possible to flexibly react to changing market needs, as part of the various communication channels of the presentation tier. This ensures a minimum impact on the “core“ of the systems in the data tier.
4. In the individual tiers it is possible to choose the appropriate technology and maximise its potential application, including the operational environment.
5. Increasing the security by separating individual tiers with a clear and secured interface.

Personally, I regard the first point as crucial; failing to adhere to it causes the biggest problems and huge risks for the project manager. In practice, it is often the case that the presentation and business tiers are linked in one tier. The result is a leakage of know-how, which is gradually lost, including in key processes, and a high level of dependence on suppliers, and the flexibility of change causes difficulties. Each of these problems merely adds to the snowball effect. The question of what happens if your supplier goes bankrupt cannot be answered. In a company whose turnover is to an increasing extent depends on online channels, finding an answer to this question is key for the company’s survival.

You can now follow to the next part – article called: Relationship of the web integrator and the system integrator.