The original author: small Fu Ge: mp.weixin.qq.com/s/50574gVPP…

One, foreword

A lot of programmers easel composition headache, do not know what to draw, how to draw!

Sharing, review, reporting, defense, as long as you are in the programmer industry, it is almost inseparable from drawing.

When it comes to drawing, many people want to stand up and shout, “inner volume”, “inner volume”, “PPT engineer”, but the program code itself is a concrete realization of mathematical logic, if there is no chart with the text of the exposition, it is really difficult to let all people can communicate under the common consensus.

This is not like a liberal arts, “eight tables floating clouds clear night, the moon moving spring city” you can think of what it is describing. But partial science code logic or architecture design, can only abstract content in the form of charts, let everyone work together under the same consensus.

The architecture diagram, flow chart, structure diagram, function diagram and logic diagram we draw should be good-looking, easy to understand, easy to use and easy to handle, because:

  • Looking good is to improve communication efficiency,
  • In order to improve communication and consensus,
  • Use is to improve the quality of delivery,
  • Easy to do is to improve the speed of implementation.

This resembles a gentleman to be in pursuit beautiful girl same, good-looking want to take the initiative to hold up, have conduct and common 3 views to let you say I understand you very quickly, next be to deliver quality and carry out speed, that also be the thing that comes naturally.

Okay, calm down, and then we’re going to concentrate on studying the architecture, what it is, how it should be drawn, how it should be done.

What are the types of architecture drawings?

In terms of the technical architecture diagram alone, we generally refer to the system architecture for selecting various technical components to support the overall service construction. However, there are other categories for different groups and scenarios, as shown in Figure 26-1

  • Business Architecture: The results and process descriptions of the initial business requirements are often vague and may come from feedback from a boss, operation, or user.

    The customer said that The Haier washing machine would block up the potatoes, haier immediately designed a special potato washing machine

    A business direction is usually a strategy that sets direction and results, including business planning, business modules and processes, and a list of problem areas.

  • Application architecture: service reuse, across the group synergy, is simple, flexible, integrated application architecture must consider the points, as if you were online a chat, then chat content input method, word recognition, public opinion surveillance, and video services, payment service, etc., they are all in the application architecture product of stratified precipitation to the platform, used by each party.

  • Product architecture: business requirements, product planning, compared with the extensive process of business, product architecture will be more detailed and consider the layers and boundaries of each module.

  • Data architecture: data acquisition, data storage and data use are the three problems to be solved in data architecture, including database storage, big data summary and data analysis.

  • Technical architecture: it is the architecture design closest to programmers. It is not only the architecture diagram design of system construction, but also includes the structure, function, flow, logic and other contents. Its specific description is the whole system how to land the concrete implementation plan.

What is the Zachman framework?

The Zachman Framework is the world’s first enterprise architecture theory established by John Zachman in 1987. His paper “Information System Architecture Framework” is still regarded as the most authoritative theory in enterprise architecture design.

The Zachman Framework is a logical structure that can represent enterprise information according to different categories and perspectives.

The Zachman framework looks at the enterprise from six horizontal perspectives, which can be divided into; What, how, where, who, why (called W5H).

The column of the framework consists of a group of artifacts, categorized as planner, owner, designer (architect), builder, subcontractor, product, or sometimes expressed as viewpoint: scope context, business concept, system logic, technology, physics, component assembly, and operation classes. Figure 26-2 Shows the TOGAF Zachman framework

The horizontal six items in the table represent an aspect of the information system, and it is sufficient to describe any object by cleaning up its explanation in these basic aspects.

  • Data (What) : What is business data, information, or objects?
  • Function (How, i.e. How it works) : How does the business operate, i.e. what is the business process?
  • Network (Where) : Where does the enterprise operate and deploy?
  • People (Who is responsible) : Who? What are lines of business and their hierarchy?
  • When: What is the business plan and workflow? When will it be implemented?
  • Why: Why the solution was chosen? How does this come about?

The vertical six items in the table represent the perspectives used by people involved in the construction of information system when describing information system, including:

  • Scope/Planner: This view describes business objectives and policies, acting as a context in which other views will be derived and managed.
  • Business Model/Owner: This is a description of the organization in which the information system must operate.
  • System Model/Designer: This view Outlines how the system meets the information needs of the organization.
  • Technology model/Builder: This is a representation of how the system is implemented that makes specific solutions and technologies obvious.
  • Sub-contractor: These representations indicate implementation-specific details of certain system elements: parts that require further clarification before production can begin.
  • Functional Systems/Products (Functioning Enterprise) : This line is not included in the 1987 paper (A Framework for Information Systems Architecture), and in fact it is not within the scope of the architecture description. However, this line was eventually added to make the Zachman framework’s description of the architecture more complete.

According to TOGAF, an enterprise is a collection of organizations with a set of common goals, and an architecture is designed to effectively achieve that set of goals.

During the implementation process, a conceptual blueprint (SearchCIO) defines the structure and mode of operation of the enterprise, as well as a comprehensive description (Zachman) of all the key elements that make up the enterprise and their relationships. Process of transforming business vision and strategy into effective enterprise change by creating, communicating, and optimizing key principles and models that describe the future state and evolution of the enterprise (Gartner).

This part can be a bit tricky, but it can be used as an extension of the knowledge of architectural design for learning, understanding and application.

Four, accompany you to draw a structure diagram

To put it simply, an architecture diagram is a demonstration of an implementation for the purpose of communicating a common understanding. It doesn’t have to be a formal one, as long as you can draw it clearly and explain it clearly.

1. Architecture selection diagram

  • Difficulty: ⭐ ⭐ ⭐
  • Role: Usually in the early stage of new project development, some technical selection work should be done. Choose technologies that are appropriate for current development in terms of payload, gateway, architecture, governance, framework, services, data, and environment and supporting services.

2. Microservices Architecture

  • Difficulty: ⭐ ⭐ ⭐ ⭐
  • Role: after the selection of technology, the next is the use of these technologies. The process is a bit like building blocks, filling each area with blocks that fit the location. If the team is being built or the technology is being upgraded, the process is complicated and requires a lot of validation. However, the layering and use of Internet technology has been relatively stable, and it will not take too long to build such a micro service.

3. Technical architecture diagram

  • Difficulty: ⭐ ⭐ ⭐ ⭐
  • Role: The technical architecture diagram is mainly used to guide the technical implementation at the RESEARCH and development level. It can clearly divide the system layer and the implementation structure. In addition, the case engineering structure will also be brought out to explain together, so that team partners can quickly enter the development.

Five, the summary

  • This chapter explains what an architecture diagram is, the classification of an architecture diagram and how to compose an easel. Through such content, we can have a comprehensive understanding of the architecture diagram. In the future, I can also clearly know what user groups I face and what content I want to draw.
  • TOGAF has a well-developed enterprise architecture theory that describes an approach to developing and managing the lifecycle of an enterprise architecture and forms the core of TOGAF. The knowledge involved is so rich that it’s worth looking at.
  • good-lookingIt is very important to be able to do one thing well. It can arouse people’s interest and reduce the cost of communication. I also encourage you to make whatever passes through your hands look as good as possible.