The Role of the Software Architect

1. The Role of the Software Architect ZHAO Jianhua Dept. of Computer Sci&Tech Nanjing University

2. The approach in this book • Based on four separate, loosely coupled architecture views. • The design approach gives you guidance in • Tracing influencing factors and requirements through the architecture. • Sequencing the design activities • Making design trade-offs. • Supporting system-specific qualities: performance,… • Supporting general qualities like buildability,… • Ensuring that no aspects of the architecture are overlooked. • Producing useful documentation of the architecture.

3. The approach in this book • Global analysis: provide a format for capturing the key information and a sequence of activities for gathering the information. • The software process is also being influenced by what is often called architecture-centered development, in which the software architecture design is used to organize development activities. • Using UML (a common notation) for describing the architecture makes the architect’s job easier.

4. The future • More and more system to have an explicit conceptual view. • Having an explicit conceptual view also opens up the possibility for more systems to use automatic tools: code generators, … • In organizations there is an increasing recognition of software architectures as valuable company assets. • The future will also bring more architecture-level reuse.

5. The future(2) • The importance of software architecture will only increase in the future. • More sophisticated tools, techniques, and technologies will improve the architect’s productivity, but designing software architecture will always be a challenge. • The architect must select the appropriate off-the-shelf components and figure out how to make them work together.

6. Technical aspects is not enough • The technical aspects in this book is essential to being a good architect, but not enough. • An architect interacts with many peoples • managers, system architects, developers, other software architects, marketing personnel, customers, … • Understand, coordinate, listen, communicate. • Has a responsibility beyond the current product.

7. Creating a Vision • An architect must know in advance • what the system will look like • What it will accomplish • How it fits in with the rest of the company’s technology and business objectives.

8. Creating a Vision(2) • An architect should • either knows something about the application domain and targeted product market. • or find other sources for it.

9. Creating a Vision(3) • An architect must understand the global requirement and constraints of the product. • Use them to get a global view of the system • Initially you have a feeling what the components will be • then sketch some preliminary ideas, • consider the implications of the design • get feedback, refine the ideas or try again.

10. Creating a Vision(4) • If the architect an project manager don’t truly believe the vision can be achieved, they’d be better off looking for another project rather than risking involvement in a project that can’t succeed.

11. Creating a Vision(5) • stay in touch with innovations in the field: • stay up-to-date with the new technology in the company and the marketplace. • To get the user’s perspective, you can talk to specialists in application, technical marketing, and customers. • Visit the user site to get first-hand knowledge of what the users expect.

12. Creating a Vision(6) • Once the initial architecture design is sketched, the architect needs to communicate the vision effectively as coach, coordinator, decision maker, and implementer. • Work with the project manager to coach the team during high-level design and throughout product development.

13. Creating a Vision(7) • Need to coordinate and to control key interfaces of the architecture design. • Provide the system architect the requirements and inputs about how the software fits into the overall product, later verify that the agreed system interfaces can be met.

14. Creating a Vision(8) • You can start to think about commercial components or existing software. • You will be the trailblazer in learning new tech. and introducing them to the rest of the team. • Make mid-course whenever you discover defects or holes and communicate any changes to the development team.

15. As a Key Technical Consultant • Software architect is the key technical consultant to the project manager and involved with making major decisions. • For small project, project manager and architect can be the same person. • For large project, there may be a group of architect forming a system review board.

16. Topic Manager Architect Software development Organize, manage resources, budgets schedules Organize team around design; manage dependencies Require-ments Negotiate with marketing Review and negotiate requirements Personnel issues Handle hiring, performance appraisals, salary; motivate employees Interview candidates; provide input on technical capabilities of staff; motivate development team Technology Introduce new tech. per architect’s recommendations Recommend technology, training, tools Quality Ensure quality of product Track quality of design Metrics Measure productivity, size, quality Ensure design goals are met Project manager and software Architect

17. The architect makes decisions • The high level design team: software architect, team leaders, experts. • The architect has to make the early design decisions: balanced demands, make trade-offs. • Architect must have enough domain knowledge to analyze design trade-offs.

18. The architect makes decisions(2) • Must make decisions in time: end unnecessary discussions. • Make global decisions early and identify the risks involved. • Make the decisions according to the scheduling dependencies. • Responsible for global decisions, not for detail ones, and leaving some decisions to experts, teams. Coaching them when necessary.

19. The architect Coaches(1) • Once marketing has established the concept for a new product and the product requirements, the architect works with the project manager to put a design team in place. • Begin with a small high-level design team. Other low-level design and implementation teams introduced later.

20. The architect Coaches(2) • The architecture design is a good starting point to assign components to particular team leaders or individuals. • Identify components of the architecture to prototype early in the development, to minimize risks and to help train new team members.

21. The architect Coaches(3) • You need to make sure everyone understands the design and to convince people it can indeed be implemented. • The architect teaching the team members the important aspects of the design. And communicate with them.

22. The architect Coaches(4) • Team members need to understand the software architecture design well enough to do a detailed design of their subsystem. • You can have them design the decomposition of their subsystem and its interfaces. • Having them estimate the time and complexity of the implementation will provide important feedback to the project manager for the schedule.

23. The architect Coaches(5) • Knowing when to let go: • Provide overall structure but give team members that responsibility and challenge of designing their own piece. • You duties end at appropriate level of design: depends on the novelty of the design, the risks involved, and the skill of the team. • Let them design the decomposition of their subsystem and the interfaces. • Allow them to make small mistakes.

24. The architect Coaches(6) • In the maintenance phase, less involvement on your part are required. However: • A major effort is needed to restructure an architecture. • The architecture needs to be restructured to accommodate new products goals.

25. The architect Coordinates • The architect coordinates the activities of the team members around the design elements of the architecture • The project manager: decomposing tasks, • technical marketing: supporting new features • software engineers: performance, reusability, evolution.

26. The architect Coordinates(2) • Coordinate with the activities of these people that influence and are influenced by the architecture. • You establish and control the key interfaces.

27. The architect Coordinates(3) • keep track of software process, make sure milestones like the architecture design review are met. • Work with the project manager to establish team leader responsibilities for different aspects of the design. Also facilitate how team leaders relate to each other, … • It is your responsibility to maintain the integrity of the design and to ensure that the architecture is followed.

28. The architect Implements • The software architect has a role to play in implementing the system. • it is necessary to go into more detail for high-risk part of the system. An architect may implement a vertical slice of the system to minimize implementation risk. • Prototyping may help. • The architect implements may also be used to instruct team members.

29. The architect Advocates(1) • The architect is an advocate for the software architecture. • Keep track of the existing software architectures in your company to mine for new architecture. • An architect should look beyond the boundaries of the product for reuse opportunities.

30. The architect Advocates(2) • Assess and advocate software architecture technologies. • keep track of research results and experiences of other organizations to help. • Should work to incorporate software architecture into the development process. • The role of architect must be understood and valued.

31. Software Architecture as a Career • Set your sights on becoming an expert in software engineering. • Experience is what matters in becoming a successful software architect. To develop your technical, leadership, communication and people skills. • In the personal career path, you must accept increasing responsibility and more challenging tasks. • Learn from experienced architects.

32. The aspects of architect • Table 12.2, PAGE 355.