This topic so intangible, I am confused about where to start. Looks like understanding Engineering would lay the foundation. So, let us talk about engineering and software architecture first so that we can talk about the analogy the title says

Engineering

If you observe, software engineering is just one branch among the umbrella of engineering streams we have defined so far. So that says there are some principles that constitute the engineering itself.

Apart from this, as far as I understand, the engineering term itself is loosely defined. So, I define it as

“applying defined mathematical/scientific principles to solve evolving human requirements”

Let us take an example. Assume we want to start a restaurant. The basic stuff we need is food to be cooked and a place where customers can eat it. This is the bare minimum we need to start the business. In the initial stage, if you know cooking and preparing food, you can cook and let customers eat on the floor. I know it is silly to ask customers to eat on the floor. So, we need a decent table and a chair on which customers can eat food comfortably.

Good story to start with. You got the first customer, second and third. You served, all good. On the next day, you get 4th and 5th customers simultaneously. You managed to serve them with some delay in serving. Which was not too bad. Your food is so good, you got a group of people to have a birthday party. Now it is clearly a problem. One, you don’t have enough tables and chairs to fit them and two, you alone cannot prepare food alone.

Clearly, getting tables and chairs in the exact quantity to serve this group is not going to work out. You might get more people in the future or even less. So, you should somehow estimate the number of tables and chairs to buy.

The second problem is, clearly, you alone is not enough. You should get a dedicated cook to prepare the food and to cater to the demand. Again, how many cooks you get, what skills they should have is completely a different story.

Long story short, all the process that underwent this business establishment is engineering the business.

Software architecture

Developing software is never just writing a bunch of functions (for that matter, it is not even just adding some endpoints, database, etc. I have how young programmers consider building web servers is the only software development). It is a lot more than that. You have to understand the problem you are solving in and out. You have to design your software such that it supports changes to the code that does not require a lot of time and should not spoil the health of the software. At the same time, it should be in a state where more and more people can easily work on the software without any issues.

To make sure your software satisfies the above two properties, you should architect the project with a good sense, with better engineering concepts.

Analogy

Let us connect the software architecture and engineering so that we can make analogies to build better software. If you are familiar with programming or software development, by now I am pretty sure you can relate the above process to building applications or building software.

The whole idea for explaining my understanding of engineering is to say that the idea behind all the engineering concepts is the same.

Most of the things in the world that are well stabilized, like, the way a motor engine works, the way a factory manufacturing line works, the design of a car, etc. proves the way they built and work actually fail-proof. By fail I mean, they satisfy both the properties that I mentioned in the software architecture section.

So, that says, if we have a sense of relating building software(architecture) to other engineering concepts, the quality of the product would be far better.

Example

In one of the projects that I work, we were having multiple products that we sell. The tricky part is these are not physical products but few financial products. In the first version, we had a flat product layer with some policies. It was working fine initially. But then things started getting complicated. When we needed a new product with policies combination of multiple product policies subsets. So we kept adding many products redundantly. When we looked back after few months, we bloated the products unnecessarily.

So, then our CTO came up with the Baskin and Robins analogy. He says, if you go to the parlor and see the menu, you find the few base flavors, like vanilla, butterscotch, etc. Then you have multiple add-ons you can put on it. You don’t call every combination of base flavor and addons a product. Which does not make sense.

So, we applied the same idea to our products. We understood that we need some base products which are very different from each other and then we had multiple product flavors which you can apply to the products available.

With this change, you can apply any number of flavors with specific policy changes on top of any base product. This actually solved our problem and we are very happy with the new design. Now we are able to add a new product/flavor in just a couple of hours which used to take days earlier and used to bloat our system.

I know, I did not explain what is a product, flavor, policy in deep, but it is not related to this topic.

Another analogy for the same problem we found is the mobile phones(for that matter any electronic gadget mostly). If you see the catalog of Samsung mobile phones, you see sections like S20, S10, etc. On every phone of S20, let’s say, you still find multiple phones, like, 6Gb RAM-12mp Cam, 8Gb RAM-20mp Cam. But they cannot put all combinations under their catalog. So, they have a base S20 mobile skeleton, on top of which they put the customizations. This is what we learned and applied. Analogy helped us.

Summary

Start understanding how things work around you. If you think they are working well, there are really good chances that you can apply the same philosophy in your software development somewhere sometime. Start building the skill of framing analogies.

I hope you like this article. Cheers!