What do architects do, do you know?

Happy New Year to you guys!

Thank you for supporting the original article of “IT veteran brother”, ❤️❤️❤️! It is my original intention and motivation to share valuable knowledge or experience with more people and enhance my personal value in the process of sharing. I will work harder in the New Year and hope to continue to get support from all of you! Adhere to the original is not easy, if the article is valuable, do remember to manually click a “👍” oh, ^_^

I wish you all New Year in family, career and life have new progress, let’s work hard together! ⛽ ️ ⛽ ️ ⛽ ️

A year ago we talked about why a programmer should know architecture, what architecture is and what types of architecture there are. Today we are going to look at how an architect does his or her job, which roles he or she needs to work with, what input he or she uses as work input, and what output he or she ultimately produces. These contents not only help us to better cooperate with colleagues in the architect position, but also serve as a reference for whether to transition to the architecture. Next, let’s unveil the mysterious veil of the architect!

1. What are the architectural design inputs?

What software systems are ultimately built into is determined by the various requirements of the project stakeholders. Typically, we gather these requirements in a product requirements document, which is the input to the architectural design. We can divide these requirements into:

• Function requirements: Perform functions required by a service. For example, the shared bike client software supports bike location, code scanning, and unlock.
• Quality requirements: the quality requirements to be met for each functional operation, such as ease of use, reliability, security, performance, etc.
• Business requirements: what kind of cost and iteration speed should the software system be brought to market, how to improve the competitiveness of the product in the market, etc.

2. What roles does the architect interact with?

These requirements come from different dimensions of project stakeholders, business management, business competition, laws and regulations, technical environment, political constraints and life cycle. The architecture design is to distinguish the priority weight of these requirements, and then find the relatively optimal solution to balance and meet the demands of all aspects. Finally, based on this architecture design scheme, a corresponding software system will be developed and introduced to the market, and market feedback will be collected and input into the next iteration of evolution.

Therefore, the architecture needs to connect with the boss, product, project, development, testing, security and operation, etc. They are all internal customers that the architecture needs to pay attention to and serve, and their pain points are the driving factors of the architecture.

3. Output of architectural design

• Key Scenarios: Analyze product requirements and extract Key business Scenarios that must be validated for architecture design, such as user registration and login, payment account binding, rental and return of bike.
• Logical View: How many subsystems the entire software system logically needs to be divided into in order to implement critical business scenarios. If the critical business scenario is likened to a play, the logical view is the main actor in the play, it is end-user oriented and accountable to functional requirements.
• Process View: The Process View is based on the logical View, which is the static structure of the system, and the Process View is the dynamic flow of the system. If the key scene is compared to a story script, the logical view is the role of the characters, and the process view is to let these characters rehearsed the story script. In this view, the division of labor positioning and interaction relationship of each character will be clearly defined, according to which the integrator can verify the system.
• Development View: the division and responsibility positioning of subsystems are determined through logical View and process View. Development View is to clarify what kind of technology stack is used to realize each subsystem, including programming language, Development framework, hierarchical structure, project engineering, etc. The development view is mainly output to the programmer, and the programmer can start coding implementation related work based on this, so the architectural design is to bridge the requirements and implementation.
• Physical View: After the subsystems that constitute the whole system are developed, we need to deploy these subsystems to the real physical environment. The physical view is to determine what specifications of software and hardware environment each subsystem needs, which network area it is deployed to, and whether firewalls should be opened in different network areas. And how many instances of each subsystem need to be deployed to meet business requirements.

4. Workflow of architecture design

• The first step is to analyze product requirements and sort out key business scenarios.
• The second step is to divide subsystems based on key scenarios and output logical views.
• The third step is to determine the business interaction process based on the key scene and logical view and output the process view.
• Step 4, determine subsystem technology stack based on logical view and process view, output development view;
• Step 5: Determine the deployment scheme based on the logical view, process view and development view, and output the physical view.

Today, we will share here for the time being. Next, we will continue to talk about architecture. Please pay attention. Adhere to the original is not easy, if you feel valuable, please move your hands to guide the “👍” button below, so that more partners can see, veteran brother will be more motivated to adhere to sharing. In addition, I will share my experience in career planning, job interviews, skills improvement and influence building in the future. Please follow this column or “IT veteran brother”!