Be a person, do things, and be an architect-Analysis of the architect's capability model

Introduction

What exactly makes you in the same position -- for exampleProgramEmployee or technical director-who has been working for three, five, or longer, but still has no development space? You feel that you have become a master in the technical circle and are confident to win the xxx prize to be awarded tomorrow. However, you are still stuck in the same technical position, what is the price increase from last year to this year? As a result, you began to be dissatisfied with your boss, your employees, and your colleagues who were promoted yesterday ...... You plan to run your ticket tomorrow, or you are planning to raise your salary, but you are worried.

If a technician has a development track, he can either "see through the essence of the tool and transfer the focus to the 'team' circle" or "followCodeThe road has become a good master ". In terms of technology, you can probably be an architect, chief architect, or even chief architect. But the problem is: you are still a programmer. So how can we embark on the path to architects? This article analyzes the capability model of an architect.

Can you be a good architect?

An architect does not define a title that is technically competitive, but a title. The so-called title includes the title-position, service-work. The former determines the resources you have, the scope of the impact, and the target organization. The latter is simply a list of jobs you need to complete.

Therefore, I say "architect" is not "a person who can do the architecture ". The former serves as an architect, and the latter serves as a worker. Being able to make a task in the job list is not equal to becoming a person in the corresponding position. In the management system, your personal characteristics determine where you are, and technical skills are only necessary for implementation. The role of architect also requires a high level of personal qualities and technical skills. Therefore, its enterprising path is to be a person, to do things, and to be an architect.

Therefore, the "model" consists of "personal characteristics" and "technical skills". In the first figure, I particularly note that "personal characteristics" include both interpersonal skills, it also includes (specific) business capabilities and "technical skills. Therefore, personal characteristics are mainly related to "being a person" and partly include the elements of "doing things.

Figure 1 architect Capability Model

"Effective communication" and "negotiation" are not related to specific tasks. They are public aspects of personal competence. The former is a process, and the latter knows how to set the goal and obtain the result. "Risk and precaution" is the key to controlling the process of doing things, and the two items above constitute a complete system with the basic ability to do things. Basically, these three personal features are not available to a "common programmer", and even in most cases, common programmers do not want to possess such individual features, because in the opinion of many technical developers, communication always makes things more troublesome, and negotiation is time-consuming and useless. However, in fact, throughout the architecture decision-making process, architects need to constantly communicate and negotiate. The process of turning "architecture" into "decision-making" is actually a process of compatibility with various technical roles (and their ideas). You need to constantly coordinate various problems between requirements and implementations, we also need to negotiate with various investors (time, capital, talent, and other decision makers) to determine the scale of the project. If there is no scale, there is no scope. How can we design a project without scope?

Some developers will think that the above process is a "Project Manager" thing, but is it true? You don't feel this way when you become a higher-level architect and want to influence decisions on multiple projects. In this case, your decision is prior to the start of the project, or you are not just a technical role.

Design is part of the architecture capability, but architects are not designers. You can see the differences between the two before you take the first step in the architect's career.

Abstract is the thinking ability, modeling is the expression ability

Another important aspect of personal characteristics is "abstract thinking", which is a capability directly related to the architect role. This ability is both vocational skill characteristics and universal ability.

The so-called universal ability refers to the "abstraction" that is everywhere in our lives, as an individual such as a person. For example, we talk about flowers, grass, tables, chairs ...... We use language to refer to any existing thing that can naturally exist without our language. When talking about a table, neither the specific form of the table nor its specifications are described. But when we use this term, everyone knows what the table is ". Therefore, the term concept is the subject of the entire Abstract Logic System. If we lose these terms and definitions, we can't talk or describe anything-it's just like we can't say anything.

When you describe your system in an existing mature vocabulary, most people will understand what you mean. For example, we say "this system is designed as a three-tier structure ". However, the systems faced by architects are not necessarily described in mature words in many details. Therefore, they must build an abstract system by themselves, this requires conceptual abstraction, conceptual expression, and conceptual logical expression.

Conceptual abstraction is a kind of thinking ability. To put it simply, it is to "break down or generalize the target clearly": You can either simply say "What is it" or explain in detail "what it includes ". A large number of words must be used to describe what is a complete system in the ideological process. The common method is "ing the system ". For example, you can use the "number axis" in mathematics to map "Real Number Fields ". After the target system is formally defined as a conceptual and discussed structure system, your abstract process is basically over.

Figure 2 personal characteristics in the Capability Model

However, this "abstract system" may only be built in your mind and must be depicted. Because the system can not be designed simply by yourself. This "profiling" relies on the next two types of expressive power. One is to depict conceptual entities and the other is to depict the logic of entities. What is interesting is that, this seems to return to "program = structure +Algorithm".

Now let's look at UML, or more types of ML (Modeling Language). They are used to express these two aspects: it is either a conceptual entity (for example, a box Indicating the system boundary) or a logic on the entity (for example, an arrow indicating the logical sequence ).

Therefore, we should be clear about how we praise UML, which is just a "expressive ability" for modeling systems. You can only use it as an auxiliary expression tool, it cannot help or serve as a reference in an abstract process or an abstract thinking environment.

Any good architect has his own unique way of thinking, which determines how he abstracts the system and how he "creatively" designs and constructs the system. This "unique way of thinking" carries out the whole process from the child's growth until he forms an independent social view, outlook on life and world outlook. His ability to recognize and accept the world depends on how he thinks and reflects the uniqueness of his way of thinking ". But this does not mean that he has a maverick behavior feature (we only talk about his way of thinking). We should not mind whether he uses a language (such as UML or formalization ).Programming Language) To express his thinking results.

Push: design is bigger and implementation is smaller

The architect first sets the true goal of the problem and then turns it into system design, platform design, or architecture design. After that, there will be two development directions for the design output, one being faithfully implemented, and the other being deformed. There is a fatal danger in both directions: whether the architecture can be fully implemented. For the former, it may be that the architecture is over-designed, or the design itself is wrong; the latter is a direct harm to the architecture.

Therefore, architects must participate in the entire implementation process, especially in the early stage when the architecture is mapped to the target system. In this phase, the architect's task is to promote the implementation of the architecture to ensure the consistency of the design, architecture, and system throughout the project. In addition to communicating directly with designers or design teams to ensure that their designs are within your control, architects must also have the ability to implement phased design. This capability is used to turn an originally large-scale architecture design into a small, easy-to-implement, controllable key point for the development team. For example, in the planning of the system level, the design may be an independent, heterogeneous, and migratable storage framework to implement the data layer. However, in the (preliminary) implementation, it may be expressed as a local database and requires front-end developers to access the database through a clear data interaction layer, such as a set of data access interfaces or an independent data service component. Developers may encounter obstacles here: it is redundant to access the local database through these intermediate layers. However, this "redundant work" provides system flexibility, creates a period for concurrent teams to develop public storage services, and provides the possibility of flexible deployment and data migration in the future.

The key here is that no matter how big the original system is, the implementation is always "small ". Each partial implementation block is controllable and leaves a location and interface for it in the whole system space, so that it can be expanded from a "small part. Architects of a large system may consider the architectures of multiple projects in different locations and understand the final overall scale of these projects. This is the domain involved by platform architects and system architects.

Figure 3 implementation capability in the architect model Diagram"

Is the architecture really "good? Just like my understanding of the project, the root of the Architecture problem is not whether it is perfect or beautiful, but whether it is used together. Therefore, architects must have a full understanding of the implementation architecture team and the implementation process, their ability defects, the resources consumed during the implementation process, and the possible faults and precursor of each link. Only in this way can the architect design an architecture that can be implemented by the Team and controlled during the implementation process.

You know, you have been invited as an architect, instead of drawing a few drawings and handing them over to the project manager. You can do it, but you won't do it. Even if you can practice it and teach and train everyone in this team, what about the company's expenses? What is the risk? Aren't these things taken into consideration? When the project cycle cannot be controlled due to the complexity of implementation, the project will die. So, is it the architect's problem? Yes. Why did you build an "unsuitable" architecture? -- You don't know how to develop a project, who implements it, how to manage it, and so on. How can you design the architecture in the face of these actual environments?

Therefore, this part of capabilities should be found in your development experience, team experience, and human experience. Refer to the "design capabilities" under "implementation capabilities" in the model diagram to learn about your main communication objects "," Architecture implementation ", and other branches. There are some available tips for you.

Local and global

The architecture is a process from the global to the local, while the implementation is the opposite, from the local to the global. This is exactly the meaning of another layer of "bigger design, smaller implementation. Only when the design is big can we see the global effect on the global one; when the implementation is small, we can focus on the details before talking about quality and control.

In fact, in most cases, the architecture is considered outside the current project, which can be considered as an integral part of global attention. Therefore, we need to define the scope of the so-called "Global": beyond the scope of the company or the entire product series, product lines or planning is redundant.

Therefore, when talking about "Global" in architecture decision-making, the goal is not necessarily "guaranteeing the current project", but must be completed by the current project.

A frequently used example is: if it is only for the current project, it only needs to be made into a DLL module; if it is for the product line, it may be in the structure of "pipeline + plug-in. The "pipeline + plug-in" format is obviously more time-consuming than making a DLL module. This time cost (and other costs) becomes the unnecessary overhead of the current project.

The impact of this global strategy on local planning is intolerable to most companies and is also affected by many teams. However, this is the "almost inevitable" Impact of the architect role on the System-if you try to reference the architect role in the system. In some cases, the system can accommodate this impact. For example, the "Technical architect" tries to promote a plug-in framework, while developers are interested in this technology, then let's take some time to implement it. However, if this is not the case, when implementers or implementation teams do not see the value of "excess" to them, local conflicts will arise.

In this case, balancing these conflicts has become one of the practices implemented by the architecture. In my opinion, "balance" is a global art and a local technology. That is to say, on the one hand, architects should learn to lobby, and on the other hand, they should also seek more concise and less cost implementation technologies. Only when the entire system is aware of the importance of (what you implement) the architecture and the implementation cost is within their acceptable range will they take positive actions.

Therefore, the so-called balance is actually a compromise process. Architects only know what trade-offs can be done and what they cannot. The so-called design evaluation (implementation capability in the model diagram-> design capability-> Design Evaluation Branch) is not to analyze a design result that is good or bad, but to see the original requirements, see the overall intention of the system, and then know what trade-offs can be made when the design becomes more "appropriate. For the same reason, architects must know the impact of their decisions to control them in order to prevent them from being team disasters. In some cases, architects may even need to discard some features so that the project can continue. Because the product's phased output is only one part of the entire strategy, not all.

Others

The question "how to be an architect" is divided into two parts. One is "done" and the other is "done ". Because the architect is only a technical position, it is natural to get it when the time is ripe. But the problem is, one day you were put in this position. Can you do well?

I have browsed several tutorials on architects from so-called training institutions and some architecture-related books. I found that they generally use architecture as a "professional technology", just like training programmers or skilled workers. However, as far as my experience is concerned, architecture is not a job that simply expresses technical capabilities. Therefore, it is not necessary to translate a few books to learn several methods to put them into practice. The deeper problem is that architects are not actually fighting. I discussed this topic with my colleagues yesterday. He summed up some of our thoughts over the past few years in three sentences: From nothing to nothing, architecture, from table, is abstract; from coarse to fine, is design.

So what is architecture? From the above summary, you cannot see the answer. What is the architecture? You cannot see the answer from this article. However, I said that the root cause of "you cannot see the answer" is your vision and mind-the word "Next" is modern vernacular, that is, "thinking ". What really hinders you from becoming a good architect is perhaps the beginning of your knowledge and ideas, throwing them away, and accepting some totally different information.

Maybe you are angry now: This articleArticleHow is it empty? -- I can even imagine the expressions of some readers. However, please stop before the question and do not rush to give the answer. Just as you would "?" A little lower, it becomes "!" The question itself is the answer.