Software Architect-reposted from IBM

In terms of film production, software project managers are called producers because they decide what to do. The software architect is the director. He decides whether the things are correct and ensures that the products meet the requirements of investors. The following article describes the software architect.

This article is the second article in the software architecture series (four in total. Last month, the first article in this series defines the architecture. So now we can focus on the architects who create the architecture. The software architect has been proved to be the most challenging role in the software development project process. The software architect is the technical leader of the project, and is technically responsible for the success or failure of the project.

The following is the definition given by the Association of Electrical and Electronic Engineers to the "architect:

The software architect is the technical director

First, the software architect is the technical director, which means that in addition to technical skills, he must have good leadership skills. The leader's leadership plays an important role in the team and project quality control.

In the Team, the constructor is the technical manager of the project. He needs to have a wealth of background knowledge to make technical decisions. Compared with the architecture engineer, the Project Manager manages the resources, time progress, and cost of the project. In the analogy of making a movie, the project manager is the producer (he wants to confirm that the work has been completed), and the architect is the Director (he needs to confirm that the work has been completed correctly ). Because of their position in the project, architects and project managers are public figures. In a team, they are the contact hubs of all the people involved in the project. Architects should invest in building software architectures and clarify the value that software architectures can bring to the Organization.

The architecture engineer should also organize the team around the architecture and actively invest in the planning activities, because the architecture should be transformed into a sequence of tasks to be completed, in this way, we can promptly determine where technologies are needed. One thing to note is that the overall level of the team is closely related to whether the architect is successful. Therefore, the architect should participate in the interview for new team members.

Based on the capabilities of the architect, he can participate in the work of other teams at the same time. The architecture engineer needs to make leadership decisions based on specific instance conditions, and should show enough confidence in the decision process. A successful architect is human-oriented and arranges work hours for his team like a coach. This is good for group members who can get help in a timely manner. This is a huge asset of the entire team.

The architect also needs to focus on the delivery of practical work. He is the driving force of technology. Architects need to make decisions (often under pressure) and ensure that these decisions are made through communication between members and can be implemented.

The architect may have a group to complete the process.

The following describes the differences between a person and a role. A person can assume many roles (for example, Mary is a developer and a tester). At the same time, a role can be played by many people (for example, mary and John are both testers ). The role of the constructor requires a wide range of technologies, which is why the role of the constructor is often assumed by many people at the same time. In this way, technical knowledge can be spread in the group. Everyone brings his or her experience to their work. This technology will spread to the greatest extent, especially when it is understood by both commercial departments and technical groups. The results of the group must be "balanced. The term "constructor" throughout the article refers to a person or a member of the entire group.

[One group] is a collection of people with various technologies. They have a common goal and are responsible for each other. 2
If a group is responsible for the role of a constructor, a person is required to lead the constructor. He must have the overall prospects and adjust the problems between the constructor groups. Without such adjustments, there will be risks between the members of the constructor team. They may not establish a close framework or make decisions that will not be completed successfully.

Now there is a new concept proposed in the architect group: in order to achieve the common purpose and goal among members, the Team has established and released a charter for the architect group. 3

Good architects know where their strengths and weaknesses are. No matter whether the role of the constructor is assumed by a single person or a group, there is a "trusted advisor" behind them. They can work with other architects to make up for their technical shortcomings. The best architecture is usually established by a constructor group, rather than a person. The reason is simple. A group is more powerful than a person's knowledge.

The concept of the constructor group has a defect that is sometimes considered by others in the team to work in the "Ivory Tower" because their products are often wise but not useful. This misunderstanding can be minimized from the beginning: 1) ensure that all stakeholders can actively negotiate, 2) continuously communicate with the architecture and its value, 3) you must be aware of organizational strategies during execution.

Architects should understand the software development process

The architect should have a correct estimation of the software development process, as this process ensures that all members of the group work in the same way. A good process requires defining the responsibilities of each role, product establishment, collaboration among different roles, and so on. As architects need to deal with many group members every day, it is very important for them to understand their responsibilities. During daily work, development teams often need to find architects to understand what to do and how to do it. This is the nuances between software architects and project managers.

Software architects need knowledge in the business field

Despite our rich experience in software development, we also expect (or require) architects to have a certain degree of knowledge in the business field.

[One domain] practitioners who work within a certain scope use a series of specific concepts and terms to express their knowledge in this field. 4
This kind of knowledge will enable the architect to better understand the system requirements and devote his/her energy to ensuring that the system requirements are appropriate-for example, from the perspective of the Architecture Division field, the requirement is to be accurately captured. It is often the case that a specific series of architectural styles can be applied to a specific field associated with it. If the Architect knows this ing relationship, it will be of great help to his work.

Therefore, a good architect will weigh the knowledge of software development and business. If an architect has good software development experience but does not understand the business field, his solution may not solve practical problems, it only reflects how proficient the architect is in his major.

Another reason why architects need to be proficient in the business field is that they need to be able to anticipate changes in the software architecture at any time. Because the software architecture is greatly affected by the configured environment, architects who have a correct understanding of the business field can refer to the software architecture, make more far-sighted decisions on changing situations. For example, if the architect finds that new standards are likely to become mainstream in the future, then he will make his software architecture meet such standards within the life of the service.

Software architects should have technical knowledge

A particular aspect of the software architecture requires a certain degree of professional knowledge. Therefore, an architecture engineer must possess this level of knowledge to be competent for his job. However, the architect does not have to become a technical expert, which reflects the idea of the first part of this article-the macro decision-making of the architect. Therefore, the architect only needs to understand the macro issues, and does not have to care about the details. Because technology changes are too frequent, architects must stay in sync with these changes at any time.

Software architects should have good design skills

Although the software architecture is not just a design, design is undoubtedly an important component. Architects should have good design skills because the software architecture includes key design decisions for the entire software. This decision includes the design decision of the main software structure, the selection of specific parts, and the instruction documents for guidance. To ensure the integrity of the system architecture, the above elements must be specially applied to the design, which plays a major role in the successful completion of the entire system. Therefore, these elements require a fixed person with design skills to take charge of-this person is the architect.

Software architects need good programming skills

Developers are one of the most important teams in the entire project development process. architects should keep in touch with them at any time. After all, they need to ensure that the software can be successfully executed during the final delivery and use. If architects think that the work of developers is very valuable, the communication between them will be very useful. Therefore, software architects need to have certain programming technologies, even if they do not need to write programs.

Most successful architects are core programmers in some occasions, which are usually their career directions. Even if technology develops, new programming languages emerge. A good architect can associate the concepts of design languages that have previously been learned with new languages, to gain a deeper understanding of the new language. Without this knowledge, the software architect cannot make perfect decisions on the important elements of the architecture to be executed, such as the adoption of the implementation organization and program standards. This will cause communication barriers between software architects and developers.

The architect is a good communicator.

Compared with the above mentioned technologies, the communication skills of architects are the most important. Architects need to be proficient in all communication means, especially the ability to speak, write, and speak. Communication is bidirectional, so the architect must be a good listener and observer.

Effective communication between group members is the basic condition for project success. In order to better understand the needs of investors, it is particularly important to communicate with them. At the same time, all investors can reach consensus on the software architecture. Communication with the project team is also important, because the role of the architect is not only to convey information to the Group, but also to motivate them to work. The constructor is also responsible for communicating the ideas of the system to the team members so that they can be understood by the entire group, not just by the constructor.

Architects need to make decisions

Architects cannot make decisions in environments they do not know. However, the development cycle of the project does not give him enough time to explore all the environments, therefore, decisions made under great pressure are unlikely to succeed. This environment is expected, and successful architects are very satisfied with this environment, rather than willing to change it. As a result, the architects need to be cheeky, because they are likely to correct their decisions during the project development process, and return to the original path to find the problem. As Philip Kruchten said: "A software architect's life is a long process of constantly exploring and improving his decisions in the dark ". 5

A bad decision may destroy a project. Other members of the project team will lose confidence in the architect, and the Project Manager will be involved, because the project progress will not be achieved after the framework is improved. The most dangerous situation is that if architects do not document their decisions, other members of the group may make their own decisions, which may be wrong.

Software architects need to be aware of organizational policies

A successful architect will not only focus on technical issues, but also on the power trends of the organization, and always know where the team's decisions are. This ensures that they are discussing project decisions with the right people. Ignoring team power is a naive idea. The reality is that the team often forces the project team to deliver the system at the specified time, which requires the architect to correctly assess the time.

The software architect is a negotiating representative

To understand many standards of the software architecture, the architect needs to communicate with investors at any time. Negotiation skills are often required for such communication. For example, one thing architects need to pay special attention to is to minimize possible risks in the project, because this is directly related to the stability of the system architecture. Because risks are closely related to requirements, you can remove or reduce these needs to reduce risks. Therefore, to cancel such a requirement, the architect and the investor must reach a consensus. This requires the architect to be an effective negotiator to weigh these issues.

Summary

This article introduces some work of the software architect. The next sections in this series will introduce the features of the software architecture process and the benefits of using the software architecture as the foundation for processing IT assets.

Thanks
This article comes from the following book, tentatively titled "Software Architecture building process"; I would like to thank the people who have commented on this article: Grady Booch, Dave Braines, Alan Brown, mark Dickson, Luan Doan-Minh, Holger Heuss, Kelli Houston, Philippe Kruchten, Nick Rozanski, Dave Williams, and Eoin Woods.

Note
1 IEEE Computer Association, practice of describing the software-intensive system architecture recommended by IEEE: IEEE Standard 1471-2000.
2. Wisdom of Teams co-authored by Jon R. Katzenbach and Douglas K. Smith. Harvard Business School Press 1993.
3 Philippe Kruchten, "The privileges ts -- The Software Architecture Team," Proceedings of the First Working IFIP Conference on Software Architecture (WICSA1). Patrick Donohoe (editor). Kluwer Academic Publishing 1999.
4 Grady Booch, James Rumbaugh and Ivar Jacob, The uniied Modeling Language User Guide. Addison Wesley 1999.
5 Philippe Kruchten, Op. cit.