Software architecture .. Once upon a time on Computerico

The ultimate debate

One of the greatest debates I have ever worked with is the definition of the software architecture, and even when we are working with a very simple software development, sometimes it will be necessary to define software architecture for the product.

Sometimes however, a person would not be able to explain what the architecture is and what is the activity of the software architect. Usually, in some companies, a software architecture is a niche document stored in a very high secure storage media, usually used to explain to the client or the customer that the company has software architecture for its product. When the engineers open this document, they discover it is of no use. Even with no relation at all to the current software version, and was only created for the aim to define well the software from flying bird at the high sky view.

However, having good understanding for the software architecture will not be only useful for a day to day development but also for the innovation and production of new ideas. In my humble opinion, it is an essential part of the software development cycle starting from customer needs awareness to the marketing for a new innovative idea. This includes customer requirements capturing, software design, and validation. Even the verification of the software code against some standard would require the interaction of the architecture to be able to correctly do the verification.

In Computerico

To understand my point of view, I encourage all of you to visit with me for a while the planet Computerico. It is a very advanced planet where the machines have taken over the lead to control everything in the planet, even the humans. In Computerico, the master is the intelligent computer, and it is the one who is responsible to define the tasks, on the other hand humans are no more than intelligent slaves who would do everything their masters want, but with some little bit intelligence.

With this model of parallel universe, the computers are thinking in terms of software, this means that the production of their thinking is software. The computers will need to transform their thinking into concrete ideas and hence instructions to be done by humans. As we all know, humans can understand only code instructions, documented and explained such that it is readable. So master computers have to transform these software pieces into understandable instructions and explained in the humans readable language, as we know, not all humans are software engineers!

Here, a human software engineer will be able to play the intermediate link between computer and human by explaining the software in a way that could be easily understood by any non-experienced human. This translator should not only understand the software, but be able to reverse it into natural language. So let us say a master computer will need to create a new table which is going to be used as a throne for the computer king. The software which is the thinking of the master computer represents a software to make a table! If the engineer reversed that software to natural language we will find that it holds the steps to define table dimensions, colors, and materials necessary to make it. Then other activities include the blueprint to create the table along with every step necessary to bring table to life. If there is not that software engineer, normal humans will take a very long time to get what the master computer want to say! They may be killed because of misunderstanding or doing incorrect instruction. So, a software engineer role is very important as a translator and mediator between the computer and other humans.

Now consider a more complex need, the product to be created is not just a single table but product to be used by every computer, then there will be focus on standardization, and optimization to reach maximum production rate with minimum resources as well as usual production steps. The software engineer has to understand all of these activities and translate all of them to other humans such that they are able to achieve their tasks well, otherwise master computer will be disappointed and may kill of them, including the software engineer!

And the question is "What is the role of that facilitator or mediator software engineer?" In my simple opinion, this man / woman is the real architect for the table. They know everything about every step, facilitate and support every other member, and give all guidance based on their full understanding for the master computer needs and expectations. This translator may or may not play a role in the creation of the table, but for sure he or she will have a major impact on the development of the table.

Back on earth

If we are back on earth, in my humble opinion, what we have just discussed before about the software engineer is in fact the role of the software architect in a software development project. The architect role is mainly to understand well the needs of the customer which are talisman and hard to solve symbols according to other engineers, and translate them in a well defined understandable language. In this case, the software architecture is not just a simple document, it is a complete process activity coming in parallel with the software life cycle to explain and facilitate to other engineers how to do their job correctly according to the customer requirements and needs.

In Agile/SCRUM methods

The best way to describe a software architect, still according to my point of view, is the Agile/SCRUM Master role. This one should be in direct contact with the product owner, and have full understandability and awareness of what is the product mainly is going to do, and how in details it could be made or at least, has the ability to use the clues available to head towards several possible optimum solutions.

In the Agile/SCRUM methods, the SCRUM Master is more like a facilitator and team leader rather than a manager, he / she is a person who is playing with their team in the match, not a manager sitting outside the field, leading them to the success. To be able to do so, it is not possible to document the match plan on paper and share it across the team members, this will not be enough. The plan is an activity that should be done by all members together, and needs someone within the team to lead the members to do the plan by being the first one to apply it, and guide them through each step.

Architecture here is then playing role in each part of the software development phases starting from requirements specification and till the final validation for the final delivery. Because Agile methods depend more on collaboration and team understanding, a specific document for the architecture should not be a very heavy document, it is enough to develop ongoing during the software cycle, and with each step, to store the necessary information only which needs to be documented. Since the evolution process of the project, the sprints and releases in SCRUM methods, stops when the project is terminated and delivered to the product owner, then the activity of architecture will stop at this point and so is the document evolution.

In traditional process

People in traditional process however, like strict V-Cycle and Waterfall, with traditional techniques and heavy documentation activities, will find this point of view strange or not precise. I can understand their point of view and accept it, but I would like to share my experience, which could explain why I can see the software architecture like this. In fact, according to my work experience as software architect in several projects, the software architect never finishes his / her work at a certain point during the project. He / She are always interacting all the time because they are the people with most highly understanding for the requirements and the top vision. The architect is one who always responsible to perform code reviews for modifications, solving complex bugs with major changes in software, accepting / rejecting software modifications according to the overall behavior of the project, and defining the necessary software testing techniques and methods to be able to cover all the use cases and requirements in a correct ad right way.

In a real-time embedded software for example, a small change in main clock value may seem a very minor change, however, an architect may see it as a major change due to the huge impact on timings of the systems, and so, this is an architecture task to accept or reject the software modification, and evaluate the updates to done on other parts of the software based on the change of the clock.

If we can take software architecture into account from this point of view, as the above example, we could understand why a software architecture is a everlasting activity which stops by the end of the project.

In conclusion

In my point of view, software architecture is not a niche work product, it should not be even seen as a software project artifact. Software architecture is an activity tightly coupled with the life cycle of the project, and should be done on every necessary step. The software architect is not a manager, he / she is a software project leader as well as very strong technical reference point in the project, their role never ends in the project, until the project is completely closed.

I hope you may find my article to be useful to you, and I am opened to any comments, discussions, feedback, questions, and even ideas to discuss together about computer science and engineering.

Thanks for reading ;)