maanantai 11. toukokuuta 2020

Software architecture principles

Architectural design principles

If you want to get into software architecture there are so many concepts that it will make your head spin. It's all about having certain core philosophies while designing the architecture. After some time breaking things down in my mind, creating analogies and writing things down i understand it. Hopefully this article will help you to understand it as well.

Multitude of stakeholders


Software projects have multiple stakeholders. Business managers, owners, users, operators, etc. Anyone who can potentially profit from a successful project is included in this group. You need to figure out a solution which makes everyone happy. If you are building a housing complex you need to keep the building company and house owners happy. You also need to keep the government happy by following building regulations. Everyone has to come to an agreement. This doesn't always include the developers. If a developer is hired to perform develop a certain part and receives no additional rewards if the software performs well, then he is not considered a stakeholder.

Separation of concerns

The way humans make sense of the world is by breaking it down into understandable chunks. Whenever i see a wall of text i immediately lose the interest to read it. Text needs to be separated into smaller focused chapters which makes it easy to read. In software architecture this can be perceived with micro services. Complexity is reduced by breaking monolithic web services into smaller parts. When i first started drawing i thought pieces like the Sistine chapel is impossible to create. Then i learned about mannequinization, construction lines, figure and composition. You learn a couple of fundamentals and start understanding how a piece like that is possible to create.

Quality driven

In software development this includes all of the relevant -ilities (security, availability, usability, maintainability, etc.) Whenever you are thinking if you should use java or python or how to prevent security issues you are thinking with this principle. When building a house you want all the materials to be high quality. This same principle should be used for software development.

Recurring styles


If you are building a hotel you will want to use similar elements for the entire building. Every room should have similar bathrooms, kitchens and beds. This makes it easy to order furniture and build the rooms because everything is similar. In software development you want to use the same or similar frameworks and languages for a single project. Using recurring styles allows other people to more easily understand the project. Kinda like if you know one programming language you will easily learn another one.

Conceptual integrity

You need a clear vision of what kind of problem you want to solve and how you will do it. You can call this 'the big picture', if you start developing a project without a clear vision you might end up developing unnecessary functionalities.

Cognitive constraints

Melvin Conway once made an observation that became known as Conway's law. When a group of people create system they will only create a design based on their own experiences. Let's say a group of people are designing a web page. They will not add functionality for disabled people unless one of the team members has built or heard about that feature before. This is why team diversity is important when building projects. This doesn't mean you should build a team where every race (asian, black, white, etc.) are represented. You need to look at the experience and knowledge, not the color of their skin.

These are universal principles

If you understand these universal principles it will help you with other aspects as well. Architects, builders and software engineers use the same principles. If you are ever building something you will find these helpful. I believe that using these universal principles you can predict which software development trends will become popular in the future. Here is the wikipedia article i used as a reference.

Ei kommentteja:

Lähetä kommentti