Hello, I am Guo Dongbai. Starting from this lesson, we have entered the second link of the architecture activity, which is goal confirmation.
Identifying a correct goal for the architecture activity is the link where the architect can make the greatest contribution to the architecture activity. From my personal experience, most of the goals of architectural activities are not correct and reasonable, and lack basic logical arguments. Once the goals are wrong, the entire architecture exercise has little hope of success. Therefore, if you can inject rational thinking into architectural activities at this node and improve the correctness and rationality of architectural goals, you can contribute huge value to the company.
Most of the time, the architect does not have the power to define the goals, but has the power to verify the correctness and rationality of the goals, and then guide the architecture project to a correct set of goals. However, this very important node is often overlooked by architects who are just entering the industry. So in this lesson, let's take a look at how to take the step of goal confirmation well.
What is Target Validation?
What is goal confirmation? At the node of target confirmation, the architect must not only ensure the correctness and rationality of the target, but also ensure the accessibility of the target. In other words, goal confirmation starts with the end in mind. Architecture activities must begin with a clear goal, and a successful architecture activity must end with this goal.
Right, reasonable, and reachable are three words that are common, but in the context of architectural activities, their meanings are more specific. So let me clarify these three concepts first.
The first is Correct, which refers to the goal that the enterprise should pursue at the moment.
For example, in an e-commerce company, should we pursue GMV, number of orders, DAU, NPS or profit? Although these goals are very important for e-commerce companies, under the different life cycles of enterprise development, the specific positioning of subdivided products and the competition situation, there can only be one most critical goal at present.
Therefore, architects need to understand and verify the top-down decision-making logic to ensure that the goals assigned to your architecture activities are correct and strongly related to the strategic intentions of the enterprise.
The second is the rationality of the goal (Reasonable), which means that the setting of the goal is reasonable: it is challenging enough, but it will not cause large-scale movement deformation. Specifically, justification covers specific target values, delivery times, and quality expectations for architectural activities.
The last is the attainability of the goal (Achievable), which means that the goal can eventually be achieved. Any architectural activity needs to bear certain risks, and "goal attainable" means that when a certain risk actually occurs, the cost of achieving this goal may increase (time, manpower, computing costs, etc.). But the goal still needs to break through the risk until it is achieved, not defeated by the risk.
These three dimensions look very similar, but if you look carefully, you will find that their starting points are completely different:
- The correctness of the goal: Think about the goal from the perspective of the decision-maker of the enterprise, so as to help the decision-maker make the right choice.
- Rationality of the goal: Examine the goal from the perspective of the executor, so as to set a suitable challenge for the team with an optimistic attitude that can bring a sense of accomplishment.
- The accessibility of the goal: Examine the goal from the perspective of the sponsor, so as to ensure that the investment can return even when major risks occur with a pessimistic attitude.
In general, in the process of confirming the goals, we need to see whether the goals are correct from the perspective of decision makers, whether the goals are reasonable from the perspective of executors, and whether the goals are achievable from the perspective of sponsors. This is the way of kingship.
If you do not do these explorations, or if you know that the goal is incorrect, unreasonable and unreachable, but you still forcefully promote the architecture activities, then you are kidnapping the decision-makers of the enterprise, the executors and sponsors of the architecture activities, and it is domineering practice.
Preparations before target confirmation
Before going into goal confirmation, we need to do some preparatory work, which will be an important input for goal confirmation and subsequent decision-making. for example:
- Accurate perception of corporate goals;
- Identification of the core roles (decision makers, sponsors, and executors) of the architecture project;
- Clarify the core value that architecture activities can create for these roles, and how to measure this value.
I'll start by explaining some enterprise-level concepts, because architects must understand the goals from a holistic perspective.
First, examine the correctness of the target from the perspective of the decision maker. Decision makers are generally high-level executives of enterprises or departments. They should clearly know the real intention of architecture activities, the value contributed to the enterprise vision, and the real priority within the enterprise. The role of the decision maker is often higher than other roles in seniority and hierarchy, and has the right to schedule resources. From the perspective of target confirmation, you need to confirm with decision makers whether the target is consistent with the company's mission and vision.
Second, examine target accessibility from the sponsor's perspective. A sponsor must be someone who can actually contribute limited resources to an architectural activity. In other words, he should have control over the core resources you need, such as human resources and bonus incentives. Architecture activities can have more than one sponsor, but should have no more than three. If there are too many sponsors and inconsistent demands, the goals of the structure activities may be involved by multiple stakeholders, which will eventually lead to an imbalance.
You need to understand the position of the sponsor in the business value chain of the enterprise. For example, the growth department acquires users by spending money, the after-sales department reduces loss by serving users, and the legal department reduces losses by reducing risks. Only by understanding the position of sponsors in the enterprise value chain can we understand where their core appeals lie.
Sponsors are sometimes not necessarily beneficiaries. For example, in the e-commerce project mentioned just now, a large business department, as a sponsor, needs to provide R&D resources for migration, but it may be another business department that really benefits. As we mentioned in the second rule, this is a very embarrassing setting that is not in line with human nature. If you encounter this situation, you must confirm his bottom line with the sponsor, this is the limit of his patience.
With the resources and details provided by the sponsor, as well as his real appeal behind it, we can confirm whether the goal he really cares about most can be achieved.
Finally, examine the rationality of the goal from the perspective of the executor. The executor is the leader of the operations, product and technical teams involved in the architecture activities, and can deploy the manpower or operation resources he manages. For a large-scale architecture activity, architects often need to face multiple performers. So the key here is to understand what are the challenges faced by these implementers, such as large projects already in execution, remaining R&D bandwidth, etc. Only by knowing the real bandwidth that the relevant actors are putting into your architectural environment can you judge whether the goals are reasonable.
You may have discovered that the concepts mentioned just now, together with the mission, vision mentioned in the last class, and the business value, returns, and user value we mentioned in Module 1, not only often appear in the course, but also a little similar. In fact, these concepts are closely related to the goal, as shown in the following figure:
There are four core roles in architectural activities: decision makers, sponsors, executors, and users. The first three roles all serve the corporate vision. In addition to this, all architectural activities in the enterprise also ultimately serve the enterprise vision.
Each architecture activity has a correct, reasonable and attainable architecture goal, which can lead the whole architecture activity to create business value. Business value will help corporate decision makers and sponsors realize their corporate vision. At the same time, architectural goals will also lead architectural activities to create user value, and then help enterprise users.
Finally, due to its macro positioning, complete planning and long-term goals, architectural activities will also produce other long-term returns, such as the impact on decision-makers, sponsors and executives' decision-making efficiency, work efficiency and personal growth. promote. Then these roles will eventually be more supportive of architectural activities because of this.
This diagram also explains the need to be king when building a decision-making environment. If architecture activities have their own halo, that is, with long-term returns, then it is naturally reasonable to attract outstanding participants. For example, in the past two years, if you have organized an active-active architecture transformation of private cloud and public cloud hybrid cloud deployment, then the R&D personnel of the transaction or marketing team will be very willing to join it.
One is because they can all learn the latest cutting-edge technology. The second is because after the solution is launched, they can release it in grayscale between the two environments, and make instant cuts when there is a problem. In this way, their own operation and stability pressure will be much less in the future. The third is that although there is no additional incentive, the goal will attract those who are young and willing to accept the challenge to join in. Working with these people can be said to be both relaxing and growing.
Then let's talk about how you should act kingly at this node.
The architect's role in the target identification process
Confirm core role
As mentioned earlier, we want to identify three core roles of architecture activities, namely decision makers, sponsors and executors. These people must meet the corresponding role conditions we just mentioned. For example, decision makers not only need to know the real strategic intention of the enterprise, but also must personally participate in major decisions. Instead of sending a representative without decision-making power to give symbolic support and go through the motions.
If the locked core character does not meet the corresponding character conditions, then you need to find the real core character. for example. Suppose you are in charge of an audit compliance project led by the internal audit department, but the internal audit department does not have any resource scheduling authority. At this time, if you think that the sponsor is the head of internal audit, it means that your judgment is wrong, and you must find a real sponsor, such as the person in charge of the business department. Only he can decide that the audit is a high enough priority and is willing to divert current R&D bandwidth to the audit. The internal audit department is only the demand side of the project.
You might think that a CTO might be a perfect decision maker and sponsor, since a technical or product team would report to him. Actually not.
As a CTO, I don't think I am the controller of technical resources, but just a guardian. You must know that these technical resources must be calculated financially to each business department. In theory, each business unit is the real owner of technical resources, because they have to pay the relevant costs. And I'm just being trusted to help the business better manage the technology team.
So my job is to see technical opportunities for longer-term development, and find places where multiple teams can join forces. In this way, companies can accomplish more with fewer resources while laying a stronger foundation for the future.
Although I have the right to deploy technical personnel, I don't use this power most of the time, but expect to minimize deployment through the correct organizational structure. That's why I generally decline to be a sponsor of line-of-business architecture events.
I will only serve as a sponsor for large-scale technical refactoring projects. For this kind of large-scale technical reconstruction project, my judgment condition is: the project must get back the return on investment within half a year. In other words, if I invest 200 man-days in refactoring, the manpower saved in half a year should be more than 200 man-days. If this condition is not met, I need to review the rationality of this project repeatedly.
So on the whole node, we need to lock the core roles, get their real commitment, and confirm a correct, reasonable, and achievable architectural goal. This process is just like the non-murderer characters in the script. Our goal is to help ourselves gradually approach the truth through repeated dialogue and analysis.
After the target is confirmed, a complete description of the target is required. This description must comply with the SMART principles: Specific, Measurable, Achievable, Relevant, and Time-bound.
As shown below, there are several goals with clear descriptions:
- Within three months, reduce the time for 90% of merchants to release products from an average of 30 minutes per item to less than 1 minute per item on average.
- Within three months, the stability of the core link for shopping guide orders has been increased from three nines to four nines.
- Before December 31, complete all high-priority rectification projects in compliance audits for e-commerce, cloud, and cross-border businesses.
From these three architectural goals, we can roughly infer the core roles behind these goals. But most of the time, the goals of our projects do not meet the SMART principles. If this is the case, then as an architect, you must take the initiative to write a proposal based on your understanding, and then ask different roles to repeatedly confirm it.
All three goals appear to be true in most businesses. However, these goals may also be incorrect, unreasonable or unreachable under special resource and competitive environment.
For example, in the first example, assuming that the products of this category require a large number of pictures, the product upload tool originally has a function of assisting in shooting pictures. With this function, during the shooting process, the staff of the merchant can adjust the camera angle according to the reminder. But in order to achieve the completion goal of 1 minute for each piece, the shooting process has become a process of uploading photos in batches. After uploading, it was found that the photos had a 10% unqualified rate and needed to be reworked.
As a result, an incorrect goal was met. The efficiency of merchants has not only not improved, but has decreased, and the platform has not achieved the ultimate goal of increasing the number of products on the shelves.
This analysis tells us that a complete description of the goal itself does not have correctness, rationality and accessibility. Therefore, as an architect, it is necessary to understand the current priorities of the enterprise, sort out the core roles, and then confirm whether the goals are correct.
This description also fails to see the added value of the architect in the target identification process. In fact, a correct goal is not a simple distribution from top to bottom, but a process of discovery. In the next class, I will give a detailed case to help you realize this.
summary
In this lesson, we introduced some basic links of goal confirmation. I particularly emphasized that goal confirmation needs to be done from different perspectives, among which the three most important perspectives are decision makers, executors and sponsors: from the perspective of decision makers to see whether the goals are correct, from the perspective of executors See if the goal is reasonable and whether it is achievable from the sponsor's point of view.
These three roles are not randomly assigned, but need to have corresponding rights. In other words, only those who have the corresponding rights can be the performers of these roles. In addition, if you want to confirm whether the target is correct, you need to find the correct character first. Be aware that these roles are generally not disclosed in large companies.
Once the role is locked, the goal that meets the SMART principle can be polished through high-quality communication.
thinking questions
Are the architectural goals you encountered earlier correct, reasonable, and attainable? If not, was the problem discovered then? How is the result?
Too often we see a catchphrase goal rather than one that satisfies the SMART principles. Can you share your experience?
In the N projects you have experienced, the goal definition is incorrect, unreasonable or unreachable. What is the approximate proportion of each? Please give a value for N and an approximate overall failure rate. At the same time, in order to make the answers comparable to a certain extent, we limit the size of the project, requiring that the project duration must exceed one month, and the number of participants is at least equivalent to 10 full-time employees.