Previous < Software Architect's basic qualities > tells you what the basic conditions should be for a qualified architect. When we have these conditions, we can choose to become architects. At this point we should know what the software architect should do and what not to do, that is, the scope of the Software Architect's responsibilities.
Because of the huge differences in software soil at home and abroad, some theories suitable for foreign countries do not necessarily go through the domestic, and some of the domestic information is often based on foreign data directly moved to use, which also directly led to foreign software architects in the domestic become acclimatized. Today's essay is based on a number of training materials, coupled with their own thinking, summed up in the appropriate conditions of the Software Architect's scope of responsibility.
1, demand collation analysis
Some people think that the architect is involved after the requirement specification is complete, but I think the architect should be involved from the very beginning of the project. There are a lot of reasons: first, the least amount of information loss, the architect can better grasp the demand, second, the analyst in the communication with customers, often do not dig deeper requirements, because there are many hidden needs of customers themselves are not aware of, and architects can rely on sensitive software smell to discover these needs, reduce future variables; Third, analysts often leave the development team to blindly accept customer needs, and architects can clearly grasp what the existing research and development team can do, what not to do, anticipate risks ahead of time, and reduce the chances of project failure.
2, System decomposition
After gathering information, architects need to translate user requirements into software requirements, while complementing non-business requirements such as robustness, extensibility, and so on. How to distinguish and dissolve user requirements and software requirements, how to effectively grasp the difference between user requirements and software requirements, is the core of system decomposition. This is where the architect is most tested, and only the architect is involved in the work.
3, Technology selection
This step depends on what architecture, development model, and dependency options the project uses to determine the software requirements. Whether to use a multi-tier architecture or a distributed architecture, a waterfall model or RUP, whether to use MySQL or SQL Server, the need for an enterprise library, or the use of ORM. However, the architect provides a variety of different scenarios for the technical selection of the project, and provides detailed documentation for each of the different scenarios to illustrate the advantages, disadvantages, and feasibility of each scenario. These documents are for the project manager or leader to decide the final technology selection.
4, System design
In accordance with software requirements and technology selection, architects need to work with software engineers to implement software requirements into detailed software design manuals. The architect is responsible for decomposing the software requirements into sub-projects, subsystems, components, and modules, as well as the logical relationships between them, to form different logical components, and finally to identify the interfaces between subsystems and components. These are the basis for further division of the team. As with system decomposition, system design is an important duty to test the architect's ability.
5, training and guidance
After the detailed design of the software is completed, the architect needs technical training for the entire team to understand the scope of their responsibilities, what to do and what not to do, to ensure that the project is carried out smoothly. During the implementation of the project, the architect needs to be involved in the specific development process, giving each developer effective guidance to avoid project delays caused by team members ' misunderstanding of the system design. In my opinion, this is especially important for more novice teams. Because the domestic novice is a common problem is above his business, just learned a little bit of what they think they will, when they get the real design is often overwhelmed, timid.
6, maintain communication
Communication is an effective guarantee to ensure the smooth development of the project. The architect will track the progress of the project from many aspects, timely report the progress of the project with the project manager or the immediate leader, communicate with the technical developer, and, if it is iterative development, need to communicate with the user to change the requirements.
These are the main responsibilities that architects need to take during the development of a project, and I think that architects need to be more involved in the project than some of the training guides.
(turn) The scope of the Software Architect's responsibilities
