Continuous architecture plugs the gap between planning and delivery. The new agile way of working has led to everything
being ‘continuous’, which in turn is driven by digital transformation and now at the speed of COVID – where architectures are being created on an ongoing basis.
General requirements of any continuous architecture project are split into two areas − functional and non-functional requirements – the latter are also known as quality attribute requirements (QARs).
Focusing on QARs and not on functional requirements is the second principle of continuous architecture. QARs are often poorly documented
and require the following:
- The system must operate 24/7
- The system must be extremely user-friendly
- The system must be very fast
Functional requirements define what a system must do and are often also poorly defined. Stakeholders are frequently incapable of describing what they want until they see it. QARs define how it does it, so clarifying QARs is important as they drive the architecture design.
Also bear in mind that QARs may change, and as such, you would be wise to beware of modifiability. Basically, I endorse an approach of thinking minimum viable architecture and avoiding what is known as the big architecture up-front syndrome.
Delay design decisions
The third principle of continuous architecture aims to encourage companies to delay design decisions until they are necessary to keep the architecture manageable, or in other words, until after all the facts are known. Keep things as simple as possible. Make a small number of design decisions based on the few facts known at the beginning of the project and avoid design guesses.
Use ‘the power of small’ if you are to architect for change, and of course, note the latter is inevitable.
I endorse an approach of thinking minimum viable architecture and avoiding what is known as the big architecture up-front syndrome.
The following are simple rules to help create architectures that are resilient to change:
- Base the architecture on smaller, loosely-coupled components
- The goal is to replace not modify as new requirements emerge
- Beware of tight coupling in unexpected places
- Databases
- Rules engines
Leverage the robustness principle − Postel’s Law
This advises to “be conservative in what you do and be liberal in what you accept from others”. This is also often reworded to “be conservative in what you send, be liberal in what you accept”.
Design with micro-services – they are not about code base size, they increase velocity and complexity − they are about functional decomposition, domain-driven design, robustness and graceful degradation.
Do micro-services provide
a new perspective on reuse from service-oriented architecture (SOA) days? SOA architectures were based on relatively ill-advised services and lots of orchestration – what is required here is a more creative choreographed approach. Using small, loosely-coupled components and even micro-services if possible, facilitates the replacement of components where necessary, instead of attempting to enhance and perhaps even introducing new defects.Architect for build, test and deploy to deliver capabilities continuously: This is the fifth principle and is the first one of all the foregoing that is specific to continuous delivery.
The architecture needs to be optimised for the entire software development lifecycle and not just for the design and build phase of the process.
The architect needs to consider the following requirements:
- Integration
- Testing
- Deployment
- Production support
Techniques that can also be very useful include small design, API testable services and service virtualisation.
If wishing to architect for build, test and deploy to deliver capabilities continuously, focus on the software deployment process and think automation.
The architect elects to use a container approach to facilitate deployment of the application. Using this approach, the application and its dependencies are packaged in a container which allows applications and associated components to be rapidly deployed in multiple environments, including cloud environments, both internal and external to the enterprise.
Model the organisation of teams on the design of the system to promote interoperability.
Moving on to principle six: Thus far, we have dealt with process and technology but what about people? Moreover, could the organisation of teams have an impact on system designs?
The answer is yes! Organising teams in layers does not promote collaboration, it creates communication issues. Model the organisation of teams after the design of the system if you are to promote interoperability.
To achieve this, let’s invoke Conway’s Law (Melvin Conway – 1968) which stated: “Organisations that design systems… are constrained to produce designs which are copies of the communication structures of these organisations.”
Architectures affect the organisation, but Conway’s Law can also be used in reverse. It can either work in favour of modelling teams after the design we wish to create and implement, or against it, if a legacy team negatively impacts the design because of interoperability issues between the teams. This would eventually result in multiple defects and associated rework.
This can be negated by organising teams around the following capabilities that will be delivered by, for example, a new ‘mobile shopping’ application where the team would:
- Obtain quotes for a product – including competitors’ quotes
- Place an order
- Examine order fulfilment
Combined with pairing, this approach results in better knowledge of the system being delivered, better ownership and better productivity.
Why does continuous architecture work?
Leveraging the principles of continuous architecture assists architects to address and eliminate the bottlenecks that may be created by traditional architecture when attempting to support Agile projects.
Additionally, it speeds up software development and delivery processes by systematically applying an architecture perspective and discipline.
Moreover, and probably most importantly, it supports today’s business goal of delivering software at an ever-increasing speed to create competitive differentiators.
