Hello, I'm Master Tang~
In the course of our work, we often hear the following statement:
- The product owner said that the current business structure is too complex and needs to be carefully sorted out.
- The technical lead says that the project is complex and needs to do a review of the system architecture solution.
- The R&D manager said that the spike event had a very large number of visitors and required a high concurrency architecture solution.
- The first-line R&D said that the big Internet factories all use microservice architecture, and I want to learn microservice architecture design.
What exactly is meant by the architecture mentioned above? Are these statements right or wrong?
Actually, all of the above is true, just using a different perspective.
Complex systems involve multiple stakeholders such as customers, product managers, R&D, sales, operations, and management. Due to differences in backgrounds and perceptions, everyone views systems from different perspectives and approaches.
To control complexity, we design specific architecture descriptors for different roles. By categorizing and defining each architecture description with its own focus, each stakeholder can quickly access the information they care about most.
To accomplish this, we first need to understand the key concepts of "perspective" and "view".
Architecture Perspective
What is perspective? In plain English, it's where you stand to see.
Let's take the urban system as an example, what can you see when you stand on one of the city's roads?
You can see a few buildings, a few rows of trees, a few large streets, bustling with pedestrians.
But what do you see when you sit in an airplane and look at it?
You can see a piece of property, you can see mountains, you can see rivers and lakes. So what you can see has a lot to do with where you stand to see it, and it also affects the granularity with which you see things.
If you compare a viewpoint to a coordinate point, it requires a set of coordinate systems, which usually have 4 dimensions: breadth, depth, view type, and time.
Breadth refers to the breadth of how things are viewed. In the case of business processes, for example, depending on the starting point, sometimes you need to look at processes within a department, sometimes you need to look at collaborative processes across multiple departments, and sometimes you need to look at end-to-end cross-departmental processes.
Depth refers to the view of things, to reach which level of detail, for example, look at the business process, need to see the organization level, departmental level, or a post of the specific operational steps. Look at the software system, need to see the system level, application level, module level, or a line of code.
Breadth and depth generally interact with each other, if the broader the breadth of view of things, then the level will be more abstract, which is also complementary to the design of the organizational structure, the general top management to look at the problem is very comprehensive, but do not pay attention to the details of the front-line executives, the details of the problem is very well understood, but the perspective is very narrow.
The time dimension is better understood as the point in time at which things are viewed, past, present, or future.
A view type is a collection of concerns tailored to the stakeholder, as described in more detail next.
Architecture View
What is a view? In plain English, it's what you want to see.
A view is a collection of concerns tailored to the stakeholder.
Again taking the city system as an example, the commuter who wants to catch the morning rush hour, his concern is which route to work is the fastest, so he needs a pair of bus and subway roadmaps.
The tenant who wants to rent an apartment, his concern is what neighborhoods are near his company and how much the rent is, so he needs a pair of neighborhood maps near his company.
The worker who wants to unclog a sewer is concerned with how the sewer is lined up, so he needs a map of how the sewer is lined up.
In the same city system, the focus of different roles is completely different, and the information they want to get is also completely different. If you mix all the information together without view segregation, the result is that the information is too complicated, and it is difficult for everyone to get the information they want.
Similarly, different stakeholders look at the focus of the software system is also very different, in order to distinguish the focus of different people, the birth of a lot of software view of the classification method, the more famous "4 +1" view, TOGAF's business architecture, application architecture, data architecture, technical architecture and other view of the classification method.
4 Architectural Views of TOGAF
In 1996, the Clinger Cohen Act was enacted. Cohen Act was enacted, the U.S. federal government legislation, mandatory government agencies to use enterprise architecture theory to build their own IT systems, the most important agencies are the Department of Defense, the Department of the Treasury, the initiative, directly to the level of digitization of government agencies, to rocket-like speed rapid development.
At the same time, the vaunted TOGAF was rapidly evolving, heavily referencing the enterprise architecture theories of government agencies to precipitate a more generalized enterprise architecture methodology.
Currently 80% of the top 50 companies on the Forbes list and 60% of the Fortune 500 companies in the U.S. are using TOGAF theory to improve their IT architecture.
We focus on the 4 TOGAF view types: business architecture, application architecture, data architecture, and technology architecture.
They are the four main parts of the enterprise architecture, which focus on different aspects and functions, but are interrelated and supportive, and together form the overall architecture of the enterprise.
A clear enterprise architecture ensures smooth business processes, reasonable support of information systems, and orderly construction steps. Enterprise architecture is an important basis for project decision-making and the foundation for future development of the enterprise.
- Business Architecture defines that in order to achieve an enterprise's business strategy, an enterprise structurally expresses its business as a comprehensive, multi-dimensional abstract model, including the business model, value streams, business capabilities, business processes, and organizational structure, as well as their relationships to strategy, products, tactics, project execution, and stakeholder relationships.
- Application architecture defines the structure and behavior of application systems in an enterprise, the relationships between these systems, and how they interface with business processes.
- Data architecture defines how an organization collects, stores, manages, and uses data and involves the design and implementation of data models, data management, data integration, and governance.
- Technical architecture defines the structure of IT infrastructure and technical components through which an organization's needs for business, data, and application services can be supported, and they include, but are not limited to, hardware, deployable software packages, networks, technical middleware, communication facilities, computing facilities, and so on.
Through views and perspectives, we can separate concerns and disassemble complex problems so that the complexity of each localization is controlled within an acceptable range. At the same time, the team has a unified architectural cognitive coordinate system, which further contributes to business standardization, and by separating invariant points from change points, we can distill reusable business components and quickly respond to changes in business requirements.
Core Concepts of the Architecture View
Each architecture view contains a set of core concepts through which the entire business system can be dissected layer by layer to systematically understand and manage the overall architecture and ensure coordination and consistency at all levels.
- Business Architecture: Business Model, Value Streams, Business Capabilities, Business Processes, Organizational Structure.
- Application architecture: application services, application structure, application interaction.
- Data architecture: data modeling, database technology.
- Technology architecture: software deployment, technology components, infrastructure.
This article has been featured on, my tech site: Inside there are, algorithm Leetcode detailed explanation, interviews eight stock text, BAT interview questions, resume templates, architecture design, and other experience sharing.