I have written a blog post titled Developer here, a while ago. The purpose of that post was to answer the question "who is developing the software" after "what is software". It contains my thoughts about junior and senior developers and the company's or the market's understanding of these concepts. This post will be about the master level in that post, which is also called as the architect. I will also try to explain how this is interpreted in the sector as far as my knowledge and experience lets me. I also want to evaluate the question of "what is architecture" and the journey for developers around my age to became an architect.
There are lots of areas of expertise and mindsets in software nowadays. We can summarise these under 5 categories as backend, frontend, DB, devops and security. Let me put a sidenote here, the companies who are mixing these would have a toxic culture. If we take a look at the mobile application world, we have a spectrum from tracking the device news, apple's and Google's developments and requirements there. Due to not respecting these fields of expertise we get an infinite loop like this: Developers getting hands on everything -> bad code -> too many mistakes -> unhappiness -> frequent circulation -> less innovation -> dinosaurization -> "if it works, don't touch it"ism, -> hiring developers who can get hands on everything... And the cycle continues :) The concepts of junior and senior developer wasn't able to fully and correctly grasped due to this weird understanding. The level that i want to talk about, architect, became the pinnacle of nonsense in some places. This is not actually criticism and of course i have nothing to say to the people who calls themselves as architects. Because the trouble is in our definitions rather than what we are doing.
Back when i was in college, (2006 - 2011), they used to say that the architect designs the classes or packages or modules of an object oriented application, decide a design pattern if necessary, decide how to handle the data. There used to be the architecture of coding back then, since most of the software projects were monolithic and other areas of expertise like DB or frontend or devops were not widespread. It was mostly enough to know details about the programming language and the libraries around it to be called as an architect. It was also necessary to know about software development models to be an architect.
Later then, i have witnessed new software tools and technologies have developed like maven, version control, various DB tools, new libraries for backend and etc. Then the term architect got a new meaning. It required knowledge of these subjects and concepts and the ability to draw the big picture. In a way, these people were the ones who were able to keep up with these innovations. Some of these people learned other languages and also advanced to project management. This caused architects to need the management skills too since employers wanted to hunt 2 birds with 1 stone. This phase didn't last very long because the architectural approaches of a software development changed rapidly due to the evolving business needs. Nowadays, there are the word architect have 4 different meanings as i have witnessed. I will list these and analyze them later.
I have some criticism about these 4 understandings. People used the concept of architect as they saw fit and the question of what it actually is and what it should be got lost in the process. There are architects who are carrying out the responsibilities of a project manager or a senior developer in some other company.
According to the category number 1 you can get by easily if you are a smooth talker. Because there are usually no one who understands about these tools in those companies who understands software architecture like this. They would have made these decisions if they had the necessary knowledge. The 2nd category shows that the people who are hiring you could be dangerous. They could have software development knowledge and they might be trying to load their responsibilities onto you. Since they have background in software development, they know what they want. Even though your title is architect, these people will start treating you like a senior developer after some time.
3rd approach doesn't exactly match my opinion of architect but i think it is not easy to come up with a design according to the business and domain and it requires a big amount of knowledge and experience. Since you will have the authority in the project, the developers can carry on and fix things even if you make the wrong decisions. But i would say that planning the project and the technical analyze together is kind of project management rather than usual architecture. The 4th description is the outdated description in my opinion. I agree that you need to spend years on software in order to be an architect but in 15 years, there can be a new language born and dead these days :D Let's suppose you really wanted to fit this description, you would have to have 5-6 engineers of knowledge today, because the software development evolved rapidly during the 2000s. Have you ever seen someone over 40 who has spent their time constantly keeping up with the state of the art in 4-5 different areas of software development and coded at the same time? I think this description requires this kind of background which i believe is impossible and infeasible.
Of course i have a definition for the architect title and it is different than all 4 of these: "Error, definition not found" :) I mean i don't exactly have a 1 sentence explanation for architect. Because the software development area is evolved a lot and it is now impossible to keep up with every aspect of it or dive into them. That is why i think there is not person on the planet to be a fully fledged architect these days. This is a problem that occurs regardless of the intelligence of the developers or the time you spend in this field. It occurs because of the expansion of this field. If you step into the mobile app development world, you must be keeping and eye on the new devices and language updates and compatibilities. If you step into a web application, the development tools would vary according to the nature of the project. It could be a data-heavy application, it could need a high level of security, it might have 10 thousands of users at the same time, you may not be able to tolerate milliseconds of lags, you might need absolute consistency ...etc. We didn't have this much variation and limitation back in the days.
If you insist on asking for a definition for architect, i think i can say this: The person (ideally a backend developer) whose input speed became faster than the output speed is an architect candidate. My definition is some sort of team leader + initiator. This person would conduct Research and Development and bring a new technology into the environment without occupying the senior developers and also without deadlines. This person would understand the project, the domain and the business thoroughly and would decide if the project will be a single language monolithic app or a multilingual microservice app. This person decides the design patterns or modules if it is modular, decides choreography or orchestration if it is a microservice. Researches for the tools and libraries to tries to find the ideal architecture. This person could draw the roadmap for the project when it needs a change or transformation. This person would be the technical authority and the owner of the project when they can carry out these responsibilities. This person must be the direct contact for project manager in the development process.
I think the backend developers would have a faster input rate than their output rate after some time. I would say this would end up being an architect. According to my definition, it looks like the architect's work is done when the project development starts. But as i have mentioned, inside this much variety of the technologies, you would most likely make some mistakes and the project would require innovations. Or the requirements could change in time. The architect must be the one who brings innovations. The architect must have ideas about how to develop it easily or a roadmap to re-write it. You won't need these everyday but you need this for every project. In other words, you would need an architect as long as you have innovations and developments. Besides, it would be inefficient to use an architect dedicated to one project.
If you think about a car and imagine it would have 4 tyres, 1 cage, gas and brake pedals (like a child), does it mean you have designed a car? No, because that is already what we roughly mean by a car. So does it mean we became architects when we know the necessary tools to develop a software from beginning to the end? Again, no. We would come closer to being an architect if we know which of these tools we can use together and efficiently. But in this case, we can't design the ultimate perfect system since we can't have all the information in the software industry. That is why you need a person who has a faster input rate than the output rate, so that they can derive the ideal faster. They can find what is missing and try to come up with the optimal design. This is what architects should do. Idealize and optimize the architecture and ask the right questions to set the direction to the right course of action while optimizing the software.
Every individual company would impose their own meaning on engineering fields in this corporatization madness. I should be looking for ideals instead of judging the companies here. That is why i don't want to criticise those companies eve though they are damaging these concepts, devaluing knowledge and experience and spending workers like pennies. But i don't want to see the expertise of my field to be subjected to disinformation in the hands on unqualified people. Therefore, i have written this post and made some deductions help the knowledge and expertise of software development to be appreciated in the right place in the right way. This is my playground. See you at the next post :)
Leave a comment