What is Software Architect?
Before going into specific SA is what we see the definition of SA:
A software architect is a software expert who makes high-level design choices and dictates technical standards, including software coding standards, tools, and platforms. The leading expert is referred to as the chief architect. (Source: Wikipedia: Software Architect)
Software Architect (SA) is a professor who is responsible for designing the framework for the system, how to divide and interact between components, write architecture overview papers, coding convention, and direction. Let developers develop detailed designs for each function. So if you work with 1 SA well, when adding new features, the complexity of the software will not increase much.
What is the role of Software Architect?
To the necessary skills of an SA, we must first understand what their job is. It includes the following:
- technology decisions and development platforms
- Generate architectural documents (coding standards, tools, review processes, ...)
- Understand business requirements
- System design based on requirements.
- Follow dev to check / review code and system.
What are the essential skills of Software Architect?
1. Design
- Basic knowledge of design patterns : Design pattern is one of the important things that SA must have to develop and maintain a system. With design patterns you can reuse to solve some of the problems encountered before.
- Dive Into Patterns and Anti-Pattern : Once you know some basic patterns, you should deepen your understanding of the software design pattern. The author has introduced the book Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions .
- Know the quality rating : That's why documentation and coding standards are outlined above to apply. Doing so will lead to a system that is easy to maintain, secure, reliable, ... (which everyone wants).
What is the theory?
- Experience and understand the different technology stack : This is the most important action if you want to become a good SA. Try a new technology experience because each technology will have different design aspects. Nor does it necessarily have to know all the technology but be aware of the important things that your field.
- Analyze and understand the pattern that applies : Take the example that is the Angular framework. When you use it you can learn a variety of patterns such as Observables, Dependency Injection, etc. Try to understand how they apply to the framework. And if you already understand, you can learn more about how the code works.
2. Decide
A SA must be able to make decisions and lead the project or team in the right direction
- Know what is important / necessary : Do not waste time on things that are not important. Learn to appreciate what is important because no book teaches you that. Personally, I usually use two characteristics to evaluate that:
(1) Conceptional Integrity : If you decide to do something in a certain way, focus on doing it that way, although it may be better to do it in a different way. Often this leads to a simple concept, easy to understand and maintain.
(2) Uniformity : If you define and apply a naming convention, it is not just a matter of capital letters, but apply the same way anywhere.
- Priority : Some decisions are made early. If it is not taken into account sooner or later, it will often be difficult to separate it later and be a maintenance nightmare or worse, the dev will have to stop working until the decision is taken. In some cases, making a provisional decision (probably not good) is better than doing nothing. But first consider the priority of the upcoming decisions. There are many ways to do this, I think you should look at the Weighted Shortest Job First (WSJF) model, which is often used in the Agile development model.
- Know your power : Do not make decisions about things that do not belong to you. This is important because it affects your job position if not taken into account. It's a good idea to clarify to everyone about your responsibilities and role. If you are involved in a project with more than 1 SA, you should consider proposing ideas or ideas instead of making a decision.
- Consider multiple choices : Always list more than one option before making a decision. In most cases where I have participated, more than one option is feasible (really good).
3. Simplify
Remember the principles of Occam's Razor. Can explain this principle as follows: If you have too many assumptions about a problem to solve, to solve the problem you may think wrong or lead to other complex solutions. These assumptions should be minimalist (think simple) to be able to work out a good solution.
- Shake the solution To solve the simplest solution, we will usually connect the solutions together and see the problem from different positions. Try to figure out how to deal with top-down or bottom-up. If you have a data flow or a process, first think in the direction from left to right and vice versa.
- Take a step back : After long debates, often a complex solution will be the result. But they are not the end result. So stop and think is it really meaningful? then review the problem and refactor. The debate may be going on the next day, but at least we have time to think about a better and simpler solution.
- Devide and conquer : Simplify the problem by dividing for the rule. Split the problem and solve each one. After validating, match them and have the most overview
- Refactoring is not evil : Accepting problem solving is a bit complicated if there is no better solution at present. We can think about that later. Prior to refactoring, we should have: an automated tests to ensure that system functions work correctly and are agreed by the stackholders.
4. Code
As a SA you should at least know what your dev is doing, do it right, etc. If you do not know then it can lead to 2 situations:
- Your dev does not respect what you say
- You do not understand the difficulties or dev issues that need support
- Have a side project : The purpose of the side project is to experience the new technology. Practice makes perfect. Reading the tutorial or the good and the bad aspects of a particular technology is just a matter of reading books.
- Find the right things to try out : As the past has said above, you do not need to know everything (all technologies). Because that is quite time consuming and seems to be countless. One page I frequently visit is Technology radar . They are divided into the categories of technologies, tools, platforms, languages, and frameworks into 4 categories:
Adopt, Trial, Assess and Hold. With categories so divided it is easy to get the most overview and the reader easily assess the trend to find out.
5. Document
Architectural documentation is sometimes very important, for example, in the case of code guidelined. The original documentation will usually be required before the code starts and should be adjusted regularly, constantly. Some other documents are automatically generated by code such as: UML class diagrams, API doc, ...
- Clean Code : Code can be considered the best document if it is written properly. A SA needs to review and distinguish good / bad code. That reference is the book
Clean code - Generate documentation where possible : The system can change constantly (spec change is a common occurrence) and it is difficult to update doc continuously. For example, the API will often update or add new updates regularly, so updating the doc by the rice is hard. So some tools such as Swagger or RAML is one of the tools to help in this.
6. Communicate
From my observation, this is one of the least appreciated skills. If you are quite good at design but can not express your ideas, your thinking seems to have less effect or even fail.
- Learn how to Communicate Your ideas : A SA you will not only participate in one meeting where you will be operating normally and moderate it. So learning to express your thoughts and ideas is very important
- Give talks to large groups : Expressing ideas in a small team or as a group can help you cultivate this. If you feel this is a bit difficult then start by saying it to your best friend. This can only be done when you leave your comfort zone. Be patient, it takes time to improve.
- Find the right level of communication : Every person shall have the attention and look for a different problem. So, you need to solve the problem of each individual. For example, a dev would usually be interested in a particular solution to a problem, while a manager would usually be interested in the most cost-effective solution.
- There are always questions from people around you that you need to answer right away. Make regular slideshows of Q & A that you can show and explain to people.
7. Estimate and Evaluate
- Know the basic project management principles : As an SA or team leader, you always have to estimate the time spent on workloads: how long it takes, how much work is needed, what skills are needed, and so on. answer the questions "management" on. Remember that time estimation is not just about implementations but also includes activities like tests and fix bugs.
- Evaluate "unknown" architecture : You need to evaluate which architecture is appropriate for each context. This is not easy, so you can prepare it by creating a set of questions that are common to all architectures. Some ideas for these questions:
(1) Design practices : Which architecture systems follow this pattern? Are they often used and used properly? Does the design follow a red line or have any development out of control? Is the structure clear and separate?
(2) Development practices : How do you follow the Code guidelines? How to manage code versions? Deployment practices?
Conclusion
If you intend to become a Software Architect, your career path will usually look like this: Junior Developer -> Developer -> Senior Developer -> Team Leader -> Software Architect. To be a good SA you need to cultivate a lot of things as listed above. Hopefully the article can help people to have a look at the SA location (not leisure, simply drawing the deer way as people usually think).
