Starting from the definition of the role of the architect, and then leading to the core value creation of the architect, that is, the ability to design and implement structured software systems.
In terms of maintaining the core value of homogeneity, what is the territory of different architect roles with different capability dimensions.
The first is the programmer/code structure , which is the minimum starting point of software structure, referring to the consistency in design of the code submitted by each programmer. Code is the ultimate carrier of all upper-level software structures, and it is also the way all structured decisions in the real world are finally concretized in the software world. The main value of this consistency lies in the maintainability of the code and the nature of the code being easy to change, iterate, and expand.
Then there are freelance architects/solutions to lateral problems . This is the first level of abstraction, that is, the solution to the same horizontal problem is shared among multiple code modules, so that the solution to the horizontal problem is consistent across multiple modules. This consistency often comes from a simple organizational abstraction, that is, sharing the same part-time architect with horizontal problem solving in multiple code modules. The value of this consistency lies in lower implementation costs and higher quality solutions.
Then there is the cross-domain architect/holistic solution . This is the second level of abstraction and refers to maintaining the structure of the entire solution across multiple domains. This structure reflects the consistency of design concepts, data models, and information interaction, and will eventually promote the structure of the entire field. The value of this structure lies in making the software in the entire field higher quality, better maintainable, and easier to upgrade and iterate.
Next comes the Chief Architect/Decision Principles . This is the third level of abstraction, which refers to the decision-making principles on software architecture-related investments, which are consistent across the enterprise. In other words, the existence of the chief architect is to ensure that the decision-making principles of the enterprise's software investment at different levels and in different fields are homogeneous. This decision-making principle is to maximize the long-term value-added of technology.
Programmer, part-time architect and cross-domain architect, these three roles are all working according to the same assumption. This assumption is that the structural nature of the software system at a higher level will bring about better external adaptability. These three levels, in order from high to low, are cross-domain, horizontal issues, and code-level consistency.
The last is the concept of CTO/corporate survival priority. This is the highest level of abstraction and refers to conceptual consistency. We mentioned in the course that from the perspective of the CTO, the company's decision-making philosophy should be consistent with the CEO's perspective, that is, to maximize the survival of the company. Under this concept, the resource investment of an enterprise, whether in technology, operations, or the market, should be consistent with the goal of maximizing survival. The function of technology has no particularity, it is just one of the means.
Everyone has their own risk tolerance and their favorite things to do. Some people may love being a CTO at heart, but cannot afford the high-stakes environment that can provide this opportunity . So I think the CTO is not so tempting to him, otherwise he will find a way to convince himself. Therefore, from programmer to CTO, there is another implicit necessary condition, which is your willingness to grow, which is also the most important condition.
This article is a study note for Day 1 in June. The content comes from "Guo Dongbai's Architecture Course" in Geek Time . This course is recommended.