Due to the change of push rules in the official account, please click “watching” and add “star” to get the wonderful technical sharing for the first time
Click to follow the #Internet Architect public number to get the full set of information of the architect all here
Today we’re going to talk about how to become an architect, and architects go from beginner to abandoned
If your future career goal is architect, it is highly recommended to read and collect it carefully.
“How can I become a software architect?”
This is a question that many friends have asked me, and I recently saw an article by Kai Niclas about architects, and the insights in it resonated strongly with me, especially the non-technical part of the back. Translated (slightly cut) and shared with you. For English articles, please click “Read the original article”.
I showed it to a classmate beforehand, and he said: It’s too difficult to be an architect, but you have to be proficient in technology, and you have to be able to communicate, balance, and market….. I’ll try to be a technologist!
Ask yourself, I, the architect, can’t do enough in many ways, so keep learning! If your future career goal is architect, it is highly recommended to read and collect it carefully.
Before we dive into the details, we need to know exactly what software architects and architects are:
A software architect is a software expert who can make high-level design decisions, prescribe technical standards, including coding standards, tools, and platforms — Wikipedia
Software architecture is the most basic way a system is organized, expressed by its components, the relationship between components, the relationship between components and the environment. It also includes principles that determine design and system evolution. –Handbook of Software Architecture
Architecture can be done at different levels of abstraction, different levels require different skills, there are many classification criteria, and my favorites are these three levels:
Application level: The lowest level of architecture, focused on a single application, with a very specific design, and communication is often limited to the development team
Solution level: The middle layer of the architecture, which needs to focus on several applications to achieve a business need, there are some high-level designs, but most of them are specific designs, and communication needs to span multiple development teams.
Enterprise level: The highest level of architecture, focusing on multiple solutions, this layer is designed to be abstract and requires solution architects and application architects to refine. Communication spans the entire enterprise organization.
To understand what skills a software architect needs, we need to first look at the architect’s day-to-day activities
Identify the platforms and technologies to develop
Determine development standards and specifications: coding standards, tools, review processes, test methods, etc
Design the system according to the requirements and make architectural design decisions
Document architecture design and decisions, and communicate with the team
Turn the high-rise design into the underlying design
Review and review the architecture design and code, such as to see if the identified patterns and code standards are being implemented correctly
Collaborate with other architects and stakeholders
Guide developers
Note: Architecture design is an ongoing activity, so these activities are done over and over again.
Essential skills required by software architects
Based on my experience, the books I read, and the discussions I have participated in, I can list these 10 skills that every architect must have:
Design, Decision-making, Simplification, Coding, Documentation, Communication, Estimation, Balance, Consulting, Marketing
Let’s talk about each of these skills and I’ll list some of my insights and actions you should take in order to continue to improve in this skill area.
What makes a good design? This is probably the most important and challenging problem, so let’s start with theory.
Understand basic design patterns: In order to develop a maintainable system, patterns are definitely one of the most important tools for architects, and with patterns, you can reuse designs to decide those common problems. The Gang of Four’s Design Patterns: Reusable Object-Oriented Software Basics is a must-read for every developer. Despite more than 20 years, patterns are still the basic unit of software architecture.
For example, the MVC pattern described in the book is used in many fields and is the basis for many new models such as MVVM.
Dig deeper into patterns and anti-patterns: Once you understand the basic Gang of Four patterns, you need to expand your knowledge to more software design patterns, or delve deeper into them based on your interests, such as Java concurrency patterns.
In the field of application integration, my favorite is Enterprise Integration Patterns, a book that can be used in a variety of fields where two applications need to exchange data, whether it’s a very old file-based exchange or a modern microservices architecture.
Understand how software quality is measured: We want our systems to be maintainable, reliable, secure, testable, scalable, usable… In order to achieve these goals, the system architecture must be designed well. You can refer to this:
Theory is important, practice is even more important, otherwise you will become an ivory tower architect.
Keep trying and understanding different technology stacks: I think it’s very important to be an architect, it’s hard to learn the real thing from abstract PPTs, you have to try different, new technology stacks and feel the benefits and “pain” it brings for yourself. You can also try technologies that are not in your field, for example, if you are very good at SAP R/3, you should also try JavaScript.
Analyze and understand patterns that work well: If you look at the frameworks you are currently using, such as Angular, you can study many and put them into practice, such as the observer. See how it is used in frameworks and why it is used. If you’re willing to put in more effort, dive into the source code to see how it is implemented.
Stay curious and participate in community events outside of the company: the Java User Group, for example, discusses a lot of topics, from lowest-level coding to high-level architecture, and I like this activity because it makes me think outside of work and strengthens my personal social network.
Architects need to be able to make architectural decisions that guide projects and organizations in the right direction.
Prioritization: Some decisions are critical, and if they are not determined at an early stage, there will be some workaround, making it difficult to remove it later and becoming a maintenance nightmare. Worse yet, the programmer needs to stop working and wait for you to make a decision.
To avoid this, these decisions must be prioritized, and I recommend taking a look at the Weighted Shortest Job First (WSJF) model, which is very popular in agile software development.
Know your abilities: Don’t make decisions outside of your abilities, it’s critical that if you don’t follow along, it could ruin your architect job.
So be sure to be clear with your peers about your responsibilities and your role. As a low-level architect, you can make suggestions for high-level architecture, but don’t take matters into your own hands. I recommend reviewing key architectural decisions with your peers often.
Evaluate multiple options: When it comes to making decisions, list multiple options. In most of the decisions I’ve been involved in, there is more than one possible (good) choice. Just providing an option means that you haven’t done your job and can’t make a decision. The various options need to be compared by facts that can be measured (e.g. license fees, maturity) rather than personal feelings in order to really complete the decision.
Keep in mind the Occam’s razor principle for solving problems: don’t add entities unless necessary.
If you have too many assumptions about a problem, it is likely to go in the wrong direction, leading to an unnecessary, complex solution. Be sure to refine the assumptions to produce a good solution. (Visible architecture work is also an art)
“Shake” your architecture design: To make architecture design simpler, you can look at the solution from multiple angles, not only in a top-down way, but also in a bottom-up way, if you have data flows or business processes, look left to right, and then look right to left.
Always ask yourself, “What would architecture look like in an ideal environment?” “If it were those big companies, what would they do?” These questions will prompt you to reduce your assumptions.
Take a step back: Often long and intensive discussions, usually lead to a highly complex design that you absolutely can’t take as the end result, and take a step back and look at the overall picture from the level of abstraction, does this design still make sense?
Sometimes it helps to stop the discussion and continue the next day, at least my brain needs time to process that information and then come up with better, more elegant, simpler solutions.
Divide and conquer: divide the big problems into small pieces, solve them one by one, and then see if the small solutions can match.
(1) Sufficient automated test cases to ensure that the function of the system is not destroyed
(2) Obtaining stakeholder approval.
Even if you’re an enterprise architect, the architect at the highest level of abstraction, you need to know what programmers do on a day-to-day basis. Otherwise you will encounter two problems:
(1) The developer will not accept your ideas and statements
(2) You won’t understand the real challenges and real needs of developers.
Do a side project: The aim is to try out new technologies and tools to understand current and future ways of development. Reading some tutorials is really good, but just “book” knowledge. Only by trying it yourself and experiencing it again can you gain a real experience: why is it good? Why is it bad? The longer you spend with a technology, the more experiences you’ll have and the more it will help you make good decisions.
Through this classification, you can find the new technology you want to try.
Clean Code: Clean code is the best document, and architects must be able to distinguish between good code and bad code. There is a great book on good code and bad code:
Try to generate documents automatically when possible: For some of the more detailed documents, it is difficult to update them in time due to rapid system changes, so automatically generate documents as much as possible: if you are a Model Driven, you can automatically generate documents from definition files, SWagger and RAML are good starting points.
More is more, less is less: no matter what the document, at the same time should focus on only one thing, contain only the necessary information of the matter, and the additional information should be kept in the appendix, because a large amount of text is difficult to read and understand. Take a closer look at your documentation and ask yourself, “In order to understand the whole thing, isn’t all the information in it?” “What information is necessary and what can be ignored?” ”
In my observation, this is the most underrated skill, and if you’re particularly good at design, but you can’t communicate with others, your ideas have little impact and you’re likely to fail.
Presentations: Speaking to a small group or large group is a common job for architects, if you feel uncomfortable at first, you can start with your best friend and slowly expand more people, this thing can only be learned through continuous practice, it is a process that takes time, and you need to leave your comfort zone, so be patient.
Find the right level of communication: Different people see things differently, so you need to communicate with them at their level. For example, developers are interested in technical details, and managers are more inclined to know which option is more economical.
So before communicating, you want to see if what you want to communicate with is at the right level, including abstraction, content, goals, motivation, etc
Communicate often: If no one knows, a great architecture makes no sense, often communicate your architecture design and the ideas behind it, communicate regularly at each organizational level (group, department, company), schedule and meetings with developers, architects, and managers to present your architectural ideas.
Be transparent: Regular communication only partially alleviates the lack of transparency, and you also have to make sure that the reasons behind decisions are transparent, especially for people who are not involved in the decision-making process, and it is difficult for them to understand why and why.
Always ready to give a presentation: someone will always ask the architect a question, and you want to give the right answer quickly, what should I do? You can pick out the most important PPT, put it together, show it at any time and show it to them, so as not to find it in a pile of materials, which will waste too much time.
Understand basic project management principles: As an architect or chief developer, you are often asked to estimate your design: how long will it take? How many people are needed? What skills are required?
At first, you can provide a rough estimate: days, months. Remember that the estimated time is not just about coding implementations, but also about requirements analysis, testing, and bug correction. So you need to know the steps in the software development process. One way to get a better estimate is to give predictions based on historical data. If you don’t have historical data, try the COCOMO methodology, and if you’re working on an agile project, this book is very helpful:
Evaluating Architecture: As an architect, you should be able to adapt your architecture design in current and future contexts, which is not easy, and you can prepare a set of questions to “challenge” your architecture design, such as:
(1) Design Practices: What patterns does the architecture follow? Was it used correctly? Is there a clear separation of design and focus?
(2) Development Practices: Have you developed code specifications? Was it followed? Is the code versioned
(3) Quality assurance: What is the coverage of automated testing? Is static code analysis in place? Is the Peer Review in place?
(4) Security: What are the security concepts in the architecture design? What about built-in security? Are penetration testing and automated security analysis in place? Do you use it regularly?
Quality comes at a cost: as I talked about system quality and non-functional requirements, if you overdo the architecture design, it will increase overhead and slow down development. You need to balance architectural design and functional requirements, and over-design should be avoided.
Conflict management: Because teams have different backgrounds, conflicts are inevitable, and in order to find a mutually acceptable and balanced solution, architects need to act as glues to resolve these conflicts. Regarding the theory of communication, I started with Schulze von Thun’s Four-Ears Model:
Have a vision: No matter what kind of project you’re in, whether it’s a traditional waterfall model or an agile model, you have to have a vision, which is the short- and long-term goals you want to get, and clearly communicate them to the team members.
Since it’s impossible to achieve everything at once, I usually tend to build a maturity model that gives the team a clear idea of what level we’re currently at. There are many aspects to development that require the use of different maturity models, such as the development practice maturity model and the continuous delivery maturity model. Each level of these models is clearly defined, and teams can easily measure what level they are at.
For continuous delivery, I personally prefer this model
Building a community: For example, organizing JavaScript programmers and architects to discuss once a month on topics that can be how to solve past and present technical challenges, new technologies, and approaches. Architects can share and discuss their visions, programmers can share their experiences, and meetings like these can help build a stronger group that is extremely valuable to both businesses and individuals.
Have an open discussion: The root cause of misunderstandings and ambiguity is a lack of communication, so you can schedule a fixed time period, such as 30 minutes a week, to exchange some hot topics with your peers, and discuss anything without deliberately arranging the agenda for discussion. You can solve some small things on the spot, and for complex topics, arrange follow-up follow-up.
You have great ideas and communicate well with people, but no one wants to do it, and that may be a lack of marketing skills.
Motivate and persuade: How did companies convince you to buy their products? They definitely show value and benefits, but not only that, they also make beautiful packaging to make it as easy to digest as possible
(1) Prototype: The prototype with the interface is very intuitive and will be very attractive. There are a lot of tools for creating software prototypes, and if you like SAP you can build.me facts, using it to create beautiful UI5 applications easily and quickly.
(2) Video: In addition to boring PPT, using a video can better show your ideas. But please don’t over-market, in the long run, content is king, if you run the train with your mouth full, it hurts your reputation.
Defend your idea and persevere: If you’re really convinced of your idea, you should defend it and fight for it, which is necessary because architectural decisions with long-term goals are not easily accepted: developers don’t like it because it’s too hard to develop, managers don’t like it because it’s too expensive in the short term. So it’s your job to persuade relentlessly.
Find allies: It’s almost impossible to build and execute your ideas on your own, and you need the support of allies to convince others. At this time, you need to use your social network, if you don’t have it yet, go build it now!
You can talk to open-minded colleagues about your ideas first, and if they like (or partially like them), when someone asks, they’ll most likely support you: X’s ideas are interesting. If they don’t like your idea, ask why, are you missing something? Your story isn’t appealing enough?
The next step is to find an ally with decision-making power and ask him to have an open discussion, and if you’re afraid of that discussion, you need to reflect on whether it’s time to leave your comfort zone.
Repeat it, believe it: Studies have shown that repeatedly presenting an opinion leads people to believe that it is a universal view, even if the idea comes from only one person. If you’ve sent a message a lot, it’s easier to convince someone. But beware: this strategy should be used wisely, as it can be counterproductive.
4. Basically covers the summary of all core knowledge points of Spring
Finally, pay attention to the public number Internet architect, reply in the background: 2T, you can get the Java series of interview questions and answers I sorted out, very complete.
If this article is helpful to you, or inspired, help scan the QR code to pay attention to it, your support is the biggest motivation for me to keep writing.
Ask for one click and three links: like, forward, watching.