Architecting Great Websites, The Site Engine

Contents

The site engine is the application (software) that sits behind the scenes processing any data as needed. It may be as simple as a contact form that captures a request for information and sends you and email, right through to complex database functionality.

A standard 3-tier architecture approach to designing web applications is the most common, separating data, presentation and application layers. This ensures greater reliability and easier maintainability of the system but also requires more forethought in order to structure the website (application) so that the engine where all the hard work is performed runs separately from the actual layout (presentation). The application then “talks” to the database (the data layer) where all the variable data is stored. So, a typical request for a page looks something like this:

• Visitor browses to page on the site
• Page runs application (engine) behind the scenes
• Application communicates with the database to get necessary information
• Application formats data for use in the page
• Page lays the data out correctly
• Page is displayed to the visitor

There are also template engines which allow you to separate the design and the application completely (such as Smarty), although good software engineering principles should be applied to web development and a web application be as close to the 3-tier model as possible where relevant.

The more complex the engine, and the more complex the data structures, the more testing is required to make sure everything fits together properly. In the example of an eCommerce site, there is a complex series of events that all relate to products. Firstly, people can browse the catalogue, so we need a “display” engine. People can also add them to their basket, so we need a “basket” engine. People can purchase items, so we need a “payment” engine plus a “customer account” engine so we can track who bought what. We also need a “shipping” engine to calculate shipping costs, a “tax” engine to calculate VAT, and also a “stock” engine if we want to manage stock online. We also need a “fulfilment” engine so that orders can be marked as paid, and subsequently shipped (and marked as shipped) by the warehouse. There is a “notifications” engine so that the system can send out messages to customers about order status, and a “customer account” engine so that customers can log in and check the status of their orders. And all of these need to talk to the database in the same way to ensure the application (the ecommerce site) works. That’s 10 engines – and this is just a quick overview of a “standard” ecommerce site. There are numerous other engines (modules) that make up more complex sites, such as “special offers”, “related items”, “marketing updates”, “news”, “accounting”, etc, etc.

The most important aspect in determining the complexity of the site engine is knowing what the site should do, both now and in the future. The clearer these two pictures, the easier it is to scope, build and deliver the application required to do the job. The future picture is important because things like “we’d like to be able to have multiple languages in the future” can have a significant impact in the underlying database structure and the way the engine talks to it. Knowing this in advance allows us to adapt the initial architecture in preparation for the future additions, instead of having to throw away large amounts of the engine to add in the new functionality. Some people call this future-proofing, and it’s an important part of approaching the build of a professional, effective web presence.

In the next episode we’ll look at hosting …