Turn: Every architect should study the law of Conway.

Today's share is mainly from my previous work experience and the usual study summary and thinking. My previous background is mainly to do framework, system and platform architecture, before the company EBay, Ctrip, the only product will be platform-based internet company, so today mainly with platform architecture perspective and share experience. Architectural perspective Everyone is different, can say 10,000 kinds of vision, there are business architecture, security architecture, platform architecture, data architecture, are not the same, here is only my opinion, welcome to join the "chat architecture" community to participate in the discussion. The topic of today's conversation mainly includes the following points:

• My understanding of the architecture definition
• The iterative and evolutionary nature of architecture
• Building a closed-loop feedback architecture (architecting for Closed loop feedback)
• Talk about MicroServices architecture and the latest topics
• Structure and organizational culture relationship
• Architect mindset and soft skills
• My views on some of the architects ' controversial themes

　　My understanding of the architecture definition

About 7-8 years ago, I used to have an American counterpart architect, mentor, who told me that architecture was actually discovering stakeholders (stakeholder) and then addressing their concerns (concerns), and then I read a book Software system Architecture: Working with stakeholders using viewpoints and perspectives, the idea is that the goal of the system architecture is to address stakeholder concerns.

This is from the one in the book, I used to share the schema definition is often in this diagram, the architecture is defined as:

• Each system has a schema
• Schemas are composed of schema elements and their relationships to each other
• Systems are built to meet the needs of stakeholders (stakeholder)
• Stakeholders have their own point of concern (concerns)
• Schemas are described by the schema document
• The schema document describes a series of architectural perspectives
• Each perspective is addressed and corresponds to the stakeholder's point of concern.

Before architecting the system, the architect's first priority is to identify all stakeholders, business parties, product managers, customers/users, development managers, engineers, project managers, testers, operations personnel, product operators, and so on, all of which may be stakeholders, and architects should communicate fully with stakeholders, Deep understanding of their concerns and pain points, and out of the architecture to address these concerns. Architects often make mistakes by missing out on important stakeholders, and inadequate communication will result in a lack of architecture that does not meet the needs of stakeholders. Stakeholder concerns are likely to be conflicting, such as management (manageability) vs. Technology (performance), Business (M.F.B. s) vs technology (reliable and stable), which requires architects to be flexible and balanced, and how to balance the architect's level and value.

The 2nd definition of architecture is that architecture focuses on non-functional requirements (non-functional requirements), the so-called-abilities.

This is a picture I shared in my last company.

This is slideshare a PPT in the interception, two graphs are listed in the architecture of the non-functional focus on how to measure the level of the architecture, last year I saw a word that has a great influence on me.

Architecture represents the significant design decisions that shape a system, where significant was measured by cost of cha Nge.

In Chinese, architecture represents a design decision that plays a key role in the shaping of a system, and the system is basically shaped, and the key here can be determined by the cost of change. This sentence is Grady Booch said, he is one of the founders of UML.

Further, the goal of the architecture is to manage complexity, variability, and uncertainty to ensure that part of the architecture changes during long-term system evolution without undue negative impact on other parts of the architecture. This ensures agility in business and research and development, allowing the variable parts of the application to change frequently, with minimal impact on the rest of the application.

When I first entered the software development industry, the architecture was mainly performance, high availability and so on. Now, have seen countless legacy systems, especially the status of domestic enterprise IT, the legacy system of countless coupled systems, poor architecture like handcuffs tightly limited business, upgrade replacement cost is very large, so I pay more attention to understandable, maintainability, scalability, cost. I would add that it is very important for a startup to get a good architect or CTO at the beginning of a startup.

The iterative and evolutionary nature of architecture

I am an architect of the older generation, who took part in the work in 99. Career beginner a lot of RUP, unified the concept of software process. The RUP philosophy has a deep impact on my architecture, and Rup summarizes three features:

• Use cases and risk-driven uses case and risk driven
• Architecture Center Architecture Centric
• Iterations and increments iterative and incremental

RUP is very focused on architecture, advocating architecture and risk-driven, it is necessary to do end-to-end prototype prototype, through the compression test to verify the feasibility of the architecture, and then on a prototype based on continuous iterative and incremental development, development, testing, adjustment architecture, such as development, loop, as shown:

It can be seen that architects are trying to write code as much as possible, doing tests, and then throwing the architecture into the team is very unreliable (unless it's a very clear and mature area). In addition, the technical architecture is a bit of a perfectionist tendency, at first often like to seek big perfection, ignoring the evolution of architecture and iterative, this tendency of easy-to-build products and users can not form effective rapid feedback, products do not meet the needs of end users, continue to see the following two graphs:

The first diagram is about the concept of the smallest available product (Minimum viable product, MVP), making the smallest available product, dropping it to the user as soon as possible, and quickly acquiring customer feedback, based on iterative and evolving architectures and products. The second figure is over-engineering (over Engineering), in fact, it is also said that the product architecture and the user does not form an effective feedback closed loop, the architect to think and the customer is not in one direction, through the smallest available products, fast iterative feedback strategy, can avoid this problem. Note that before the system is really put into production, a good architecture assumes that the later the product is used by the user, the higher the cost and risk of failure, and the smaller the step, through the MVP Rapid experiment, the acquisition of customer feedback, iterative evolution of the product, can effectively reduce the cost and risk of failure.

In addition, many years of experience tells me that architecture, platform is not bought, nor with an open source can be obtained, nor designed, but long-term evolution to take root. Recommend two good articles to everyone:

• 58 Shenjian: A good architecture stems from constant evolution rather than design
• Pleasant Loan System Architecture – the evolutionary path under high concurrency

The two articles are all about the iterative and evolutionary nature of architecture, and it is worthwhile for each architect to learn to assimilate.

　　Building a closed-loop feedback architecture

First, share a link that has had the deepest impact on my architecture over the years. This article is about DevOps, but the same applies to system architecture: The three ways:the principles underpinning DevOps

The first road, the system thinking , the development drive organization organism, its ability is not the production software, but the continuous delivery customer value, the architect needs to have the global view and the system thinking, the thorough understanding entire value delivery chain, from the business demand, the research and development, the test, the integration , to deploy operations, the efficiency of this value chain does not depend on a single or a few links, the results of local optimization is often a global damage, the architect to stand at the system height to optimize the entire value delivery chain, so that enterprises and customers to form a rapid and efficient transfer of value.

The second road, the reinforcement feedback loop, any process improvement goal is strengthens and shortens the feedback loop. The new engineer, also a common problem of Chinese students, is the lack of awareness of production operation and maintenance (monitoring is an important part of system feedback). There are two flowers that say:

• No measurement, no improvement no measurement, no improvement or promotion
• What's your measure is something you get to measure anything and get what

A system without monitoring or monitoring is equivalent to a bare-Ben, high-speed without a dashboard. There is a lot of error on the measurement driven development of the article, on InfoQ, recommend to everyone: metric-driven development.

This article presents the concept of metric-driven development, called MDD, in systems, applications and services, through three-level monitoring, building three feedback loops, continuous improvement of systems and architectures based on monitoring and measurement, and I have recently been referring to this concept to design a technology architecture for an e-commerce platform, see:

This is an e-commerce platform architecture, the entire embodiment of the idea of closed-loop architecture, the right side is the entire platform feedback monitoring link. Specific as follows:

• The system layer monitors the computing network storage and constructs the feedback loop of the system layer.
• Application service tiers to monitor business, applications, services, and even the entire development process to build feedback loops for applications and service tiers
• Customer experience layer, monitor the behavior of end users and analyze site users, build and customer feedback loops

The following diagram shows a general approach to system elevation and improvement:

Closed loop repetition of adjustment, such as measurement----the system, application, process, and customer experience are likely to continue to improve and improve on the basis of measurement data and feedback, otherwise the so-called improvement of no data can only be achieved by taking the head or guessing.

The third path encourages a culture of courage to take responsibility, to risk trial and error, and to continue to ascend. This is the most difficult, and generally related to the density of enterprise talent. Tools, technology, and processes are just a part of a company's iceberg, and the real impact on corporate effectiveness is the underwater part of the iceberg, the people and culture of the enterprise, the architect as a technology and architecture preacher, who has the responsibility to encourage and promote the trial and error culture.

Architects need to understand these three paths, focus on the efficiency of the entire value delivery chain, focus on closed-loop feedback on each link, encourage and drive the company's trial-and-error culture, and create a system-wide closed-loop architecture (architecting for Closed loop feedback) to improve overall system performance. The DevOps and daily delivery is the direction of every Internet system Architect's dream and effort.

　　Talk about Micro service architecture MicroServices

I think we all listen to a lot, I am also very concerned about and promote micro-services, from a technical point of view, I think the micro-services mainly embodies the single responsibility and focus on the separation of ideas, from the single-process module to further expand into the cross-process distributed modular. MicroServices are independent development, test, deployment, and upgrade units, as I mentioned in the 1th architecture definition, where each service in the microservices can evolve independently, its cost of change is relatively small, the overall architecture is flexible and is an evolutionary architecture that supports innovation. Last year, Martin Fowler wrote two articles that threw cold water on micro-services, suggesting that you read them carefully.

• Http://martinfowler.com/bliki/MicroservicePrerequisites.html
• Http://martinfowler.com/bliki/MicroservicePremium.html

This figure tells you when to introduce microservices. Micro-services have additional costs and need to build infrastructure such as frameworks, releases, and monitoring. Start-ups and small-scale teams are not recommended. The main determinants of system complexity and team size, when reaching a point, a single block architecture seriously affects efficiency before consideration. In addition, microservices are more about organizations and teams than technology.

　　Structure and organizational culture relationship

Let's talk about Conway's law:

Conway ' s law:organizations which design systems [...] is constrained to produce designs which is copies of the Communi Cation structures of these organizations.

(The organization of the design system, the resulting design and architecture are equivalent to the communication structure between organizations.) )

From a monolithic architecture to a microservices architecture is the very embodiment of this law.

The team is distributed, the system architecture is monolithic, development, testing, deployment coordination and communication costs, serious impact on efficiency, serious when the team is also prone to conflict conflict.

Decoupling single-block architectures into microservices, each team develops, tests, and publishes its own responsible microservices, with no distractions and improved system efficiency.

It can be seen that there is a mapping between the organization and the system architecture (1 ~ 1 mapping), and there are a variety of problems with misalignment, on the one hand, if your organizational structure and cultural structure are not supported, you will not be able to successfully build efficient system architectures such as centralized and rigorous functions (business, Dev, QA, Deployment, Ops) enterprises, it is difficult to implement tiny services and DEVOPS, the implementation of Docker/paas platform will be more difficult, such organizational functions are inclined to local optimization (local optimization), unable to form effective and cooperative and closed-loop.

In turn, if your system design or architecture is not supported, then you will not be able to successfully establish an effective organization; As a system architect, it is important to understand Conway's Law and Design system architecture before we see the organization structure, but also the organizational culture (Democratic cooperation, centralization, jungle law, talent density), Then adjust the system architecture or organization structure according to the situation.

　　Architect mindset and soft skills

Empty cup, or open mind (open minded) is a mature architect's due mentality, stay hungry,stay foolish, the mentality of how open, the field of view is more open. One sentence from the seven habits of high-performance people ~ Steven ~ Covey is given to each architect:

If a person with considerable ingenuity and I disagree, then the other side of the proposition must have I have not yet realized the mystery, worth to understand. The most important thing to do with people is to pay attention to the different psychology, emotion and intelligence of different individuals, as well as the different worlds seen in the eyes of individuals. Communication with the minded, the benefits are not small, to have a difference to gain.

In addition, we recommend a book, "Software architect 12 Discipline", three points in the book is worth each architect to learn to understand:

• Soft skills is always tough than hard skills, soft skills harder than tough skills
• Choosing relationship over correctness, pay attention to the relationship between who is right and who is wrong
• The political nature of the architecture, in particular in the middle-sized companies of the architects to learn

Politics refers to the art of collaborating with others to get things done, architecture is a social activity, in the technological world, individualism can easily be defeated, even if your goal is good technology is optimal, technical decision-making is a political decision (technical decisions is political decisions), a technical product, a wave of people can do, another wave of people can do, in the end who do good, really bad to say, no matter who do, all to the business set on a pair of handcuffs.

How does the architect improve? Actual combat, actual combat, actual combat! Plan your career, find good teams and projects, summarize share, learn about GitHub open source projects, participate and create your own open source projects and products, and accumulate for a long time.

　　My views on some of the architects ' controversial themes

The main controversy is two topics:

• The relationship between technology and business.
• Does the architect want to write code?

How does the architect answer such questions? A mature architect's mantra: depending on the situation, not necessarily, nor is it depends. Technology and business, architects to understand the business, look at products and customers, if it is a business product, must understand the business, if it is a technical product, it is not necessarily.

The architect wants to write code? Also not necessarily, personal feel as far as possible to write, if you write more than 10 years code, every year not less than 20,000 lines, have played through, can not write. In addition, if the architect writes code, it is important to control, not to drill into the code, to spend a lot of time to solve the details and complexity problems, ignoring the global and systemic problems.

　　At last

I would like to say that the Internet is developing very well in China, and more and more people are joining the architect industry, and the industry is "growing in all things". But we have not Martin Fowler, Adrian Cockcroft Such a structure of cattle, my generation need to continue to work hard, look forward to China 10-20 years after the emergence of more than 10 Martin Fuller, Adrian Cockcroft such as the God-level characters. We must not cease to explore, and the end of all exploration is to return to the starting point, and the beginning of a first-like understanding.

Turn: Every architect should study the law of Conway.