Tiered Architecture And APIs Government Version

Today’s Government entities are under increasing pressure to provide services in multiple ways, and time is of the essence. With this, they are forced to find new ways to develop and change their service offerings as fast as possible. In response we have seen the emergence of Multi-Tiered Application Architecture and Microservices.

Gartner identified that traditional models of IT, which are largely concerned around availability and accuracy, do not provide organisations with the speed and agility to meet their business requirements, leading to a gap between the demand for IT resource and the ability of IT to satisfy that demand. This Gap was termed by Gartner as Bimodal IT.  

A Bimodal approach identifies an organisations capacity to quickly respond to and drive business goals depending upon the way that it has organised the IT resources within its organisation.  Differing approaches are required depending on how close or how far the IT requirement is from the End user. 

An effective solution to this issue comes in the form of an Integration architecture that uses multiple tiers, in which presentation, application processing, and data management functions are physically separated, thus making it easier to handle differing speed-of-change modes.  

In the diagram below, the value range in each tier is a typical frequency of change in weeks (see MuleSoft’s paper on API-led Connectivity [1]
By the implementation of an architecture of loosely coupled services, organisations are able to adopt a Bimodal IT approach. 

Bimodal IT is supported through loosely-coupled services that are accessed using APIs, which interoperate within a tier and across tiers. 

An API encapsulates a component or service behind a façade, which defines a contract to provide a well-defined response to a given set of input values. The loosely-coupled nature of APIs is often described as being out of process, meaning that the invoking process has no knowledge as to where the invoked API resides. 
The above diagram has added a number of API/Service icons to illustrate this.  

The Aggregation and Services tiers are shown as invoking APIs within the same tier and between tiers. For example, one API in the Aggregation tier could be orchestrating the invocation of other APIs in the same tier, and possibly, others in the Services tier. 

In the Delivery tier, each API is shown as being one-to-one with a single type of Client. This is to illustrate the fact that each kind of client will have different capabilities and volumes of data per API call. 

The term “Microservice Architecture” has sprung up over the last few years to describe a particular way of designing software applications as suites of independently deployable services. While there is no precise definition of this architectural style, there are certain common characteristics around  business capability, automated deployment, intelligence in the endpoints, and decentralised control of languages and data. 

A concise description that can be found in (Seven Microservices Anti-patterns [2]), provides a very interesting description using hindsight to describe mistakes made during its author’s time on early Microservices projects. It reminds us that the following points have always been the most common business reasons for any architecture – use of Microservices being no exception: 

  • Improved Agility: the ability to respond to the business needs in a timely fashion so that the business can grow 
  • Improved Customer Experience: improve the customer experience so that customer churn is reduced
  • Decreased Cost: reduce the cost to add more products, customers or business solutions 

This article is an edited abstract from the full article by John Ormerod which can be found at www.w3partnership.com/blogs 


  1. https://www.mulesoft.com/lp/whitepaper/api/api-led-connectivity 
  2. https://www.infoq.com/articles/seven-uservices-antipatterns