4th module: Architecture as a placeholder for something hard

Architecture can be a hard word to define, especially for a student who has had close to zero experience working with industrial or real life projects. While the article works hard to try and describe it based on the experience of several people. Each one has his/her own opinion and “guesses” the answer based on they think is important (or not) about this mysterious part of software creation. In this post, I will try to do the same from a unique and rather ignorant point of view.

Up until the last semester, I had never really been concerned with decisions concerning the grand scheme of projects, whether because all of the work that I had been working on has been relatively simple (less than 3,000 lines of total code) or because said projects never needed to be seen by the perspective of someone like an architect or devops engineer. I just needed to make sure the program met the requirements of the class I was in and that was it. Going by that kind of experience, all I knew about architecture was more or less the same as the analogy presented in the article: The architect is the person who takes most, if not all, the decisions related to requirements, making sure they are as clear and correct as possible so as to make the job easier for everyone.

This responsibility is quite similar in terms of ambiguity to the one in the article and may result in different interpretations depending on the person reading it. While the author tries its best to attain a certain level of abstraction and unify all of the definitions, I still think it is left uncertain just what an architect is. I clearly don´t have the answer to that, and I am not sure that I will ever have it. I think that it will be answered with time, as this industry is still very young compared to most others. Perhaps, when the art of programming is as old as the art of building nowadays, we will be able to answer this mystic question.