3C Gravity Model.

4 min readSep 5, 2023

Recently, I read a great article written by

. He is an outstanding person who opened the door to the IT Architecture discipline for me, formed a design thinking basis, and showed me the path for further growth. He has a unique mindset, and I enjoy following him on social media.

In the mentioned article, he provided several pieces of advice based on his vast experience and surveys held among engineers and managers. The advice is valuable itself (you can check it out by the link below), but I would rather focus on the model of the relation of architectural styles and three stakeholders' concerns: the cost of build, the cost of change, and the cost of ownership. During the examination of the model, I decided to name it the 3C Gravity Model, and you will see why.

The Purpose of (Software) Architecture

Some people wanted to have more rigorous architecture work, and some people wanted to avoid producing architecture artifacts at all but focus on well-written code in a fully agile way. We have many good books and articles explaining the value of appropriate architecture. But I don’t think it is the same, so I am here in an attempt to cover the gap.

medium.com by Ivan Padabed

Let's quickly review three architectural styles from Ivan’s article and how they deal with costs.

Monolith

Monolith is a well-known architecture that does not care much about cohesion and coupling concerns. In such a way, it is easy to build due to the fact that any system component can freely communicate with each other or share the common functionality. Consequently, it is cheap to develop (low code of build). On the other hand, any change in the system can become a headache. Components have strict dependencies and change in one part can affect other ones (high cost of ownership). The components cannot be scaled independently therefore, you need to create a new instance each time and, in many cases, buy a piece of new equipment or resources that require licenses and continuous maintenance (high cost of ownership).

Distributed

Distributed architecture provides a high level of isolation. Ideally, each component has its bounded context, can work independently on other components, and deals with its own database (even if it is just a new instance of a running component). The bounded context, eventual consistency, and transactional nature of the data became a challenge (high cost of build). Support of such systems requires highly skilled engineers, comprehensive monitoring tools, and well-established processes (high cost of ownership). Hopefully, all of these allow us to build highly scalable and changeable solutions. Thanks to bunded context, changes in one component cannot affect others. We can introduce new components or create new versions of the component to coexist with other versions at the same time, even if they are written in different paradigms or programming languages (low cost of change).

Offloaded

Even though I’m not quite sure that it is an architectural style, we still can offload some functionality to 3rd party services or providers (SaaS, PaaS, FaaS, IaaS). Let’s call it offloaded architecture. In such a way, we transfer some responsibility to managing data centers, maintaining infrastructure, organizing backups, performing operational tasks, etc., to somebody else (low cost of ownership). Although the 3rd party services provide built-in functionality, they focus on the mass market in a way that may require significant effort to build unique products (high cost of build). You cannot introduce a new component freely owing to the fact that you must always consider the framework of the utilized service, limitations, and parts of the systems that cannot be changed at all (high cost of change).

The Model

Now, when we are familiar with different architectural styles and how they deal with cost, we can look at the model.

According to Wikipedia, in physics, gravity is a fundamental interaction that causes mutual attraction between all things that have mass. Gravity is the most significant interaction between objects at the macroscopic scale, and it determines the motion of planets, stars, galaxies, and even light. In our case, we can claim that the cost of change, the cost of build, and the cost of ownership (3C) have a mass that determines the motion of the choice between the architectural styles. Each “C” affects the style as strongly as the style is close to the “C.”

In the case of the monolith, distributed, and offloaded architecture styles, the model may look like it is presented in the picture below. However, you can use it for any architectural style you want. You just need to evaluate the influence of the costs adequately.

In this context, mitigating the impact of a “C” entails opting for an architectural style that stands furthest from it. Nonetheless, it’s crucial to acknowledge that such a choice might accentuate the prominence of two other “C” factors.

The Application of the Model

The model offers a highly convenient approach to explaining the impact of costs on your architectural choices and defending the choices when communicating with stakeholders from the business sphere.

Thank you for reading. I hope you enjoyed this article. Sincerely yours, Alex.