Skip to content
Skip to main content

About this free course

Become an OU student

Download this course

Share this free course

An introduction to web applications architecture
An introduction to web applications architecture

Start this free course now. Just create an account and sign in. Enrol and complete the course for a free statement of participation or digital badge if available.

1 Architecture

‘Architecture’ is a term normally associated with the design of buildings. In the construction industry, architecture is often taken to relate to the style and structure of buildings. In the context of the architecture of web applications we will focus on structure, both in the terms of their physical components, the ‘system architecture’, and software (the programs making up an application), the ‘software architecture’.

Let’s first define what we mean by ‘software architecture’ by considering the following interpretations.

According to Shaw and Garlan in Software Architecture: Perspectives on an Emerging Discipline, (1996):

The architecture of a software system defines that system in terms of computational components and interactions among those components.

The Microsoft Application Architecture Guide (2009) cites Kruchten et al’s definition of architecture based on the work by Shaw and Garlan:

Software architecture encompasses the set of significant decisions about the organization of a software system including the selection of the structural elements and their interfaces by which the system is composed; behaviour as specified in collaboration among those elements; composition of these structural and behavioural elements into larger subsystems; and an architectural style that guides this organization. Software architecture also involves functionality, usability, resilience, performance, reuse, comprehensibility, economic and technology constraints, tradeoffs and aesthetic concerns.

In Patterns of Enterprise Application Architecture, Fowler (2002) states:

‘Architecture’ is a term that lots of people try to define, with little agreement. There are two common elements: One is the highest-level breakdown of a system into its parts; the other, decisions that are hard to change.

In Pattern-Oriented Software Architecture, Volume 4, A Pattern Language for Distributed Computing, Buschmann et al. (2007) cite the following quote from Booch (2007, p. 214) which emphasises that design and architecture cannot be divorced from one another:

All architecture is design but not all design is architecture. Architecture represents the significant design decisions that shape a system, where significant is measured by cost of change.

In Software Architecture for Developers, Brown (2012) describes architecture more widely:

So, we can see that the word ‘architecture’ means many different things to many different people and there are many different definitions floating around the internet. For me, architecture is comprised of four things:

  • Structure – the building blocks (components) and how they relate to and/or interact with one another.
  • Foundations – a stable basis on which to build something.
  • Infrastructure services – the essential services that are an integral part of whatever is being built. With a building, this might be power, water, cooling, etc. With software, this might be security, configuration, error handling, etc.
  • Vision – it is crucial that you understand what it is you are building and how that process will be undertaken. Vision can take the form of blueprints, guidelines, leadership, etc.

There are quite a few other descriptions of architecture which, like those from Shaw and Garlan and Microsoft , focus on components and have similar wording to Achimugu et al. (2010):

The foundation for any software system is its architecture. Software architecture is a view of the system that includes the system’s major components, the behaviour of those components as visible to the rest of the system, and the ways in which the components interact and coordinate to achieve the overall system’s goal. Every efficient software system arises as a result of sound architectural basement. This requires the use of good architecture engineering practices and methods.

In summary, a ‘software architecture’ relates to the arrangement of software components and the interactions between these components. It also relates to the decisions that are taken about the design and composition of the overall system, how it is broken down into components and how these components interact. This type of structuring reflects high-level decisions that are difficult to change later because they determine software-level decisions. It is thus difficult to change the architecture of a system without starting the design from the beginning.

Activity 1 Defining ‘system architecture’

Timing: Allow 15 minutes to complete this activity

Produce your own definition in answer to the question ‘What is system architecture?’ To do this, consider the definitions of a software architecture given above, and briefly research definitions for ‘system architecture’ and ‘design’ yourself using an internet search engine.


A ‘system architecture’ can be defined as the configuration of hardware, network and software components of a computer system which satisfies the requirement for the provision a particular application or service.

As with a ‘software architecture’, it also relates to the decisions that are taken about the design and composition of the overall system, how it is broken down into components and how these components cooperate. A ‘system architecture’ holds the key to success or failure of a system every bit as much as the ‘software architecture’ does for the software.

We will look at ‘client–server’ and ‘multi-tier’ approaches, which represent mainstream common ‘tried and tested’ approaches, and then ‘network type’ approaches, which represent more recent developments that many organisations are using because these developments have been shown to have additional benefits over the established approaches.

By looking at the development of architecture it is possible to understand the potential benefits of adopting one approach to application design over another, and to understand why a specific architecture itself imparts specific qualities that can lead to a better (or worse) solution.