Are you a Software Dev? Why and How you Should Empower Yourself as an Architect.
If you enjoy what you do, you are going to love this.
I know who you are 🙈
If you are a software developer that likes what you do, then I can tell more about you. You are a problem-solver that sees complexity as an opportunity to demonstrate what you are capable of. You appreciate the freedom to investigate, think, test and create; you dislike repetitive work and tasks with every step defined in detail. Yeap, I know… You prefer to build something to automate that.
If you feel that this description talks about you, then we are similar and hopefully, this article will serve its purpose.
First of all, what do we really mean when we talk about Software Architecture 🧐
According to Wikipedia…
Software architecture refers to the fundamental structures of a software system and the discipline of creating such structures and systems. Each structure comprises software elements, relations among them, and properties of both elements and relations.
With this definition, it is clear that every executable piece of software has its own structure. Furthermore, systems are usually formed by a bunch of clearly separable services that constitute a network that communicates in different ways.
Software architects are big-decision-makers (aka heroes). They analyze the requirements and the organization to determine if and how a system should be divided; the responsibilities of each division; the internal designs; programming languages; and the technologies used in the communication. Moreover, they envision how the system could be changed while scaling or being extended.
In fact, the levels of flexibility of a software project are usually degraded with the pass of time — the amount of effort required to make a change increase exponentially. Because of that, one of the most — if not the most — important goals of this position is to take the necessary actions to prevent that situation as much as possible.
Now, let’s remember some wise words of uncle ben…
In spite of I wouldn’t recommend a software architect to say out loud that (s)he is like Peter Parker, (s)he is indeed responsible for her/his decision and, even though everyone makes mistakes, (s)he must promise to investigate and evaluate different possibilities and have a reasonable justification for each decision.
Specific decisions that you could take as an Architect
Of course… The theory is great but we also need concrete stuff. Let’s go there.
Jim is an architect and he wants to be a good guy. One day, his employer/client comes and asks him to lead a team dedicated to the creation of an articles management system. Writers should be able to publish articles and the software will be in charge of delivering the content to readers, classifying that content and generating recommendations (what a marvelous slice of creativity, right?).
Assuming that the requirements are better specified than that, Jim would have to consider his resources (team size and abilities) and take some of the following decisions:
- In how many business areas (Bounded Contexts) should the domain be divided.
- How many backend services should be created for the first version of the system: one (Monolithic) or more (Microservices).
- If a Serverless solution makes sense for some use cases.
- Take leverage of some NoSQL databases in some services: ElasticSearch, MongoDB, Redis, Cassandra.
- Programming languages, Frameworks.
- Which information should be cached, where and how.
- Types of communication between services and with the outside world: Http, Websockets, Event Sourcing.
- The internal designs of services to keep the system in a modular and loosely-coupled state allowing flexibility and future improvements.
Of course, we could mention other choices to take but let’s skip them for the moment.
Jim, like every architect that praises himself, is always reading about new technologies, standards, and patterns; that help him to form new ideas and imagine ideal scenarios for what was requested. However, he comprehends that he is part of a team with limited resources and abilities, therefore, it is crucial to add that variable as brain-input to make judgments.
Some details are usually done temporarily in some way and planned to be modified when certain conditions are reached.
How would you feel if this task is assigned to you? You could be a little bit nervous. Nonetheless, if you are like Jim and me, I’m sure that excitement would be all over your body. A sense of challenge would be in your mind and you would start thinking about different possibilities immediately. With these augmented responsibilities, those qualities you appreciate of being a software developer would skyrocket. Besides, it’s important to make clear that an architect codes less but doesn’t stop doing it. As a matter of fact, an architect is usually one of the most capable programmers.
How can I become an Architect
There isn’t a clear roadmap to follow before being capable of applying to this position, but, apart from the soft skills (clear communication, empathy, etcetera) that are strongly desirable, we could definitely suggest some technical skills that a candidate should learn.
- [Not a MUST but strongly recommended] Deep knowledge in, at least, one programming language with Object-Oriented Features. Java, C#, Go, you name it. Though every language is different and has its own details, any who conquer the singularities in one of them has faced common problems for software developers and has discovered tools, libraries or classes that usually have a counterpart in other technologies. Even if you work on a system using a language with other characteristics, this experience will certainly help you to design services (or a group of services) with a more flexible and decoupled structure.
- Understanding the main programming paradigms. The purpose of them and how their concepts can be interrelated in a single application.
- Familiarity with the principal Design Patterns. The use cases of Creational, Structural and Behavioral OO patterns but also Functional patterns like Clojure, Currying and Function Composition.
- Awareness of important software principles like Single Responsibility, Open-Closed, Liskov Substitution, Interface Segregation and Dependency Inversion (SOLID). Meaning, benefits, and techniques to achieve them.
- Comprehension of both traditional and trendy architectures. Master-Slave; Client-Server; Microservices; Serverless; Event Sourcing; CQRS; and many others.
- Experience with currently accepted Good Practices. Domain-Driven Design, Test Driven Development, Continuous Integration, Continuous Delivery, etcetera.
- Certain consciousness of new security and communication standards. What are they solving and how much advantage do they represent compared with the previous techniques.
The list can continue. An architect could reach a point that (s)he knows the most important areas but it is evident that (s)he has to keep learning until the end of his life in that role. Believe me, it’s worth it.
Empowerment 💪
Is it not possible to assure that your company is going to put Software Architect as your title if you start this learning path. Nevertheless, if you start this learning path and demonstrate your evolution, some things will undoubtedly happen.
By starting making recommendations and suggestions to improve the development goals, people will start asking you to participate in their software design discussions and you will stop abiding others’ choices.
Your voice will be heard like never before. Furthermore, you could start teaching these things to your colleagues — one of the best ways to affirm your current knowledge 🤓. Once you are on that, you will have the possibility to analyze the problems of other people and learn from them, accelerating your learning curve.
The more skills you prove, the more freedom you will get. Hence, instead of receiving details that simplify the solution of those complex problems, you’ll be defied with challenges of your real size.
Hello World.
This article presents important tasks that can be entrusted to you at the end of this route. Luckily, one day you will be there so I would like to add a bit of personal advice:
While you increment your knowledge, you’ll find things that could be improved and technically ideal possibilities for future developments. Then, don’t rush on taking quick elections and dedicate some time to think about the world that surrounds you: hierarchical structure of your organization, the form of developer teams, number of people that could apply their efforts in your project, among others.
Remember: it is not the primary goal of your organization to make the purest piece of software, so, even knowing that imperfect choices have side effects, it is sometimes wise not to pursue the most ideal case.
Future Content.
In the following weeks, I will be delivering a series of opinionated articles seeking the goal of sharing some details of architectural concepts and demonstrations with real and specific examples.
Thanks for taking the time to read this, see you soon! 😊 🚀
