An often overlooked NFR — Simplicity

I’m going to show my age by admitting that I was a certified Microsoft Solution Developer back in 2001. The core module for this certification was “Analysing Requirements and Defining Solution Architectures”, and one thing from this that has stuck is PASS ME, an acronym for non-functional requirements: Performance, Availability, Security, Scalability, Maintainability, and Extensibility. I’ve used it over the years as a quick ready reckoner. But it’s incomplete. It’s missing a very important S — Simplicity.

KISS (Michael Ochs Archives/Getty Images) — Keep It Simple Stupid

The importance of simplicity was reinforced for me recently as a result of being asked to perform peer reviews of event-driven solution architectures.

Event Driven Architecture (EDA) and Microservices are not new concepts, but as fully managed application hosting services are maturing, (offering opportunities for reduced operating costs, increased resilience, and scalability), the spotlight on these concepts is intensifying. Engineers want to implement them. Delivery managers want to deliver them. And product owners want to own them.

EDA is an architecture paradigm where event producers react to events by emitting event notifications to event channels. Event consumers will then listen for events on one or more event channels and process the events. The producers and consumers are loosely coupled. The producers do not know the consumers of the events, or how the consumers will process the events. Under the EDA paradigm business workflows are completed through choreography rather than orchestration.

The potential benefits of this decoupling are:

  • Scalability of the system — If one of the consumers implements a complex resource intensive process then it is possible to scale out the consumer without need to scale the system as a whole. Thus performance can be optimised.
  • Scalability of the organisation — The decoupling of the system enables the organisation to scale, with separate smaller teams able to work independently and efficiently. This in my opinion is one of the greatest drivers for decoupled systems.
  • Resilience — If a consumer fails when processing an event notification, and possibly terminates, then it can replay the processing of the event notification when it has recovered from the failure. Also, if a consumer is offline the event notifications will be queuing up in the event channel and can be processed when the consumer comes back online. In neither case does the system as a whole fail.
  • Maintainability — By decoupling the producers and consumers it is possible to independently maintain each of the components. If change is required to one of the microservices then this change can be implemented, tested, and deployed without the need to test and deploy the system as a whole. This can result in a significant reduction in time to market for new features.
  • Extensibility — As the producer has no knowledge of the consumers, a new consumer can be added to the system without need to modify the producer. There is a caveat here though, which is the case where a business workflow has a number of steps which must be performed in order. This can still be achieved using EDA and choreography, but each step in the process involves a microservice that is both a consumer and a producer. So inserting a new step into the business workflow will potentially involve modifying the microservice that performs the next step as they will now be consuming a different event type.

But there are also costs and caveats:

  • Complexity — The cost of EDA is that the system is more complex. It is harder to understand what the system as a whole is doing, and in the case of a system that is implementing a business workflow it is harder to understand what this process is. For each workflow instance it is harder to observe the state of the instance. And when there is a failure it is harder to determine where the failure lies. There may be a need to invest in additional tooling to enable this observability.
  • Need for Mature DevOps — A caveat is that mature DevOps practices are required to fully benefit from the decoupling offered by EDA and microservice architectures. If you are only capable of releasing the system as a whole on a 6 month release cycle then may have added a lot of complexity for little to no gain.

I mentioned above that one of the greatest drivers for decoupled systems is the need to scale the organisation. To have separate teams working independently on sub-components of the system, and being able to deliver change with less time to market and less risk. If you do not have a need or ability to scale the organisation in this way, (for example you may only have a a small team of engineers), then you may find that the complexity of EDA is too great a cost. Reconsider why you are advocating EDA and be judicious in when and where you use the EDA paradigm. Implement it for the right reasons, and not just because it is currently trending.

So rather than dogmatically following an architectural pattern we sometimes need take a step back and focus on why we would want to follow a particular pattern and whether the benefits outweigh the costs. And we need to keep simplicity in the forefront of minds when trying to balance the sometimes competing goals of the NFRs.




Learn about the solutions, ideas and stories driving Nationwide Technology.

Recommended from Medium

Spring batch processing: overview

Do you monitor how third-party apps use your SaaS accounts? You should…

Create a Docker application with Python easily — Example

Tag Governance & Tag Audit Cycles compliant with data privacy and security governance — Magic Pixel

Container Stack v2 — an overview of Skycap, Maestro and Pricing

Tezos Smart Contracts Examples

CSS: Day 69

Useful Python Libraries

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Ross Whitehead

Ross Whitehead

Enterprise Architect @ Nationwide

More from Medium

What is Data Engineering?

some pipes and crap

What languages and cloud platforms are trending in today’s ‘Data’ jobs

Natural beauty of organic convergence

What does it take to become a leader in engineering