Architecture Hoisting

All software has software architecture. This is true even when a team has not spent time coming up with it. This architecture is often called Big ball of Mud. A big ball of mud architecture is a software system that lacks a perceivable architecture.

 Every software system has a software architecture is similar to saying not taking a decision is also a decision. 

The big ball of mud term was popularised by Brian Foote and Joseph Yoder in their paper with the same name. According to them this is the most common form of software architecture. In their paper , they wrote

 A Big Ball of Mud is a haphazardly structured, sprawling, sloppy, duct-tape-and-baling-wire, spaghetti-code jungle. These systems show unmistakable signs of unregulated growth, and repeated, expedient repair. Information is shared promiscuously among distant elements of the system, often to the point where nearly all the important information becomes global or duplicated.
 The overall structure of the system may never have been well defined.
 If it was, it may have eroded beyond recognition. Programmers with a shred of architectural sensibility shun these quagmires. Only those who are unconcerned about architecture, and, perhaps, are comfortable with the inertia of the day-to-day chore of patching the holes in these failing dikes, are content to work on such systems. 

As software engineers and architects one of our goals is to ensure our system does not have a big ball of mud architecture. To ensure this does not happen I am of the opinion that some upfront software architecture need to be done.

I personally like SEI definition of software architecture. You can read many software architecture definitions here .

 The software architecture of a computing system is the set of structures needed to reason about the system, which comprise software elements, relations among them, and properties of both. 

The main reason software developers and architects spend time in software architecture is to influence quality attributes of the system. The typical software quality attributes are modifiability, scalability, latency, security, extensibility.

For a software system some of these quality attributes are more important than the others. For example, quality attributes for Facebook.com and Outlook Email web client could be different. For Facebook important quality attributes could be low page load time(latency) and scalability. On the other hand for a web email client like Outlook data security could be the most important quality attribute.

The biggest problem that most software architect face is the divergence of software from the design. This is not intentional but it does happen in most software.

Since last couple of weeks I am reading Just Enough Software Architecture book by George Fairbanks. In chapter 2 he covered three approaches to software architecture.

Approach Description Architecture-indifferent design You pay little attention to architecture. This is what is big ball of mud architecture. Architecture-focussed design You deliberately choose your software architecture. You design a architecture that is suitable to achieve your goals, which include functionality and quality attributes Architecture hoisting A kind of architecture-focussed design in which developers design the architecture with the intent of guaranteeing a goal or property of the system.

The third approach to software architecture Architecture hoisting caught my attention. Architecture hoisting can help reduce the gap between design and software.

Architecture hoisting was coined by the Mission Data System (MDS) project at NASA JPL to describe their methodologies originally designed for spacecraft flight control software design.

 Architecture hoisting is a kind of architecture-focussed design in which developers design the architecture with the intent of guaranteeing a goal or property of the system. Once a goal or property has been hoisted into the architecture, developers will not need to write any additional code to achieve it. 

To make it more clear let’s take a few examples to understand architecture hoisting as I think it could be best understood through examples.

• Let’s assume that one of the quality attribute that you want in your system is to maintain audit history of all the changes. You don’t want a developer to forget it. So, you end up hoisting this property in your architecture by making it part of the database design. So, in the database design you also setup triggers that populate the audit history tables. This ensures that audit history invariant is satisfied.
• Another common example is automated garbage collection. You don’t want developers to introduce memory leaks by forgetting to clean up memory. So, you hoist this property in your architecture by using a programming language like Java that does automated memory management.
• Another example of hoisting is the use of centralised log aggregation. You introduce in your architecture the agents that capture the logs written to console and push them to centeralized log aggregation server. This frees developer from the burden of doing it.
• Another example is the use of libraries like Hystrix that can make your system more reliable by encapsulating remote API calls.
• If you are into Kubernetes ecosystem then use of service mesh like Istio is another way to hoist some quality attributes into the system. Istio can be used for secure service to service communication using mutual TLS. Setting Istio in your Kubernetes cluster can hoist security quality attribute into the architecture. This again frees developers and they don’t need to write any additional code to achieve it.

Architecture hoisting is powerful but it comes at a cost. When you add Istio into your architecture then it might make it difficult to achieve low latency and debugability. Similarly, if you want your system to run on low end devices then automated garbage collection could make it difficult to achieve other quality attributes that are important for low end devices.

I will conclude this blog with the final paragraph of George Fairbanks original blog on Architecture Hoisting where he wrote following.

 Architecture hoisting can be seen as a kind of tyranny over developers, burdening them with additional constraints and bureaucracy, or it can be seen as liberation for developers, freeing them to focus on functionality instead of properties and quality attributes. Hoisting is just a mechanism and can be used appropriately or not. It can be most effective when the system design requires properties or quality attributes but achieving them would be a burden to developers. Often developers may be experts in the domain but not on how to ensure a quality like security or performance, so hoisting can enable experts to work within their specialty.