Relationship to Other Key Roles in Development Organization
The following roles are usually found in large-scale software development. Each role has an associated relationship with the software architect. Note that no organization will necessarily have all these roles, nor will each role be assigned to separate individuals. Often in smaller organizations, two or more of the roles can be combined and assigned to one person. In addition, there will often be more overlap of individuals focused on architecture and those focused on development in smaller projects. On large projects, these kinds of overlap will occur less frequently. The relationships between the role of software architect and other roles in the organization are described below:
Role: project management
Description: This includes the top-level project manager, and the immediate staff associated with that role. This could include program planning, subcontract management, supplier management, software estimation, release management, and operations management.
Relationship to Software Architect: The program management must understand how the software architecture maps to internal development teams, subcontracted development teams, COTS tools, hardware, network architecture, and external organizations/entities with whom the software must interface. In addition, the architect will work with project management in the definition of release content as well as prioritization of features included or omitted from a release.
Role: development team managers
Description: These are the managers for each individual development team. These may be internal or subcontracted teams. These leads may also have a small staff with whom the software architect must communicate.
Relationship to Software Architect: These development team managers should clearly understand the interfaces they provide and consume with respect to other development teams and external entities. This includes the high-level technical aspects, such as COTS tools involved in the interface, as well as the complexity involved in the development or modification of each of these interfaces. In addition, the managers should understand the key interfaces that may be a potential performance problem. Finally, the software architect will need to assist the development team managers in the addition of features or reduction of functionality.
Role: system architect/chief engineer
Description: Many organizations have a top-level technical lead responsible for the overall system design and delivery. This is frequently the case when significant hardware components are to be delivered along with software. The responsibilities associated with this role often include technical leadership of the systems engineering, software development, hardware design, network (LAN andWAN) design, and even test organizations.
Relationship to Software Architect: The software architect must communicate the overall software design to the system architect. This includes interfaces between development teams, external interfaces, requirements-related issues, and dependencies from other organizations that may impact the software development. In addition, the software architect will work closely with the chief engineer to identify and resolve significant technical issues.
Role: chief software engineer
Description: In some organizations, a role of chief software engineer (CSE) is separate from the software architect. In smaller organizations, these roles may be merged. The role of the chief software engineer is usually tied more closely to the development process than the details of the software architecture. This means the CSE should not only play a key role in the definition of the process, but should ensure the process is followed throughout the development lifecycle. The CSE works closely with the technical lead and build manager for each release.
Relationship to Software Architect: The software architect and CSE work closely together not only to make sure the delivered software meets the requirements, but also to ensure that the interface and port definitions match those defined by the software architecture team. In addition, the CSE will consult the software architect on many process definition issues, especially those related to requirements, architecture definition, and design.
Role: hardware architect
Description: The hardware architect is responsible for the selection and configuration of the hardware on which the software must execute. This requires a careful analysis of several types of requirements. These include requirements related to performance, input/output, data storage, COTS products, software sizing, and the user interface.
Relationship to Software Architect: The software architect will provide detailed information on the low-level requirements the software will levy on the hardware. These estimates will often vary widely early in the architecture definition process and less widely as the architecture becomes well understood. The hardware architect will also communicate to the software architect the restrictions that are imposed by the hardware that will be used. Often the selection of hardware is mandated by the customer or prior installations of the system and the software architect must make sure the software architecture is defined within the constraints of this hardware. In addition, the software architect must participate in the hardware selection and the specification of configuration information, making sure all key requirements are considered.
Role: network architect
Description: The network architect is responsible for defining the LAN and WAN design and configuration. In addition, the network architect must make sure the installation of the network hardware is performed to meet the network design. This role is sometimes combined with the hardware architect, primarily because knowledge of the various hardware components and how these components are interconnected are closely related.
Relationship to Software Architect: As with the hardware architect, the software architect must communicate network requirements to the network architect and participate in the selection and configuration of the network. In addition, once the network configuration is defined, the network architect must communicate the constraints implied by the network back to the software architect.
Role: technical leads of each release
Description: One effective approach we have seen is to have a manager and technical lead work together to deliver each major release of the software. Each individual can then focus on what they do best, leaving the release management tasks to the manager and the technical issues to be worked out by the technical lead. This lead is responsible for technical aspects of the interfaces, defects, building, testing, and delivery of the software. These technical leads will often participate in the definition of and modifications to the software architecture.
Relationship to Software Architect: First, the software architect must deliver a set of architecture views to the technical lead that clearly communicates the system under development and test for that release. This will enable the technical lead to quickly detect and remedy issues with the software. In addition, the software architect should work with the technical lead to change representations in the architecture that do not accurately represent the software that was delivered.
Role: data architect
Description: The systems engineering leads are responsible for delivering the system requirements that have been allocated to software, to the development organization.
Relationship to Software Architect: The software architect must review these requirements to make sure they can be developed, given the project constraints, and provide feedback to the systems engineering leads when a mismatch occurs. In addition, the software architect must communicate the software architecture to the systems engineering leads to make sure the requirements have been correctly understood and translated into the architecture.
Role: software systems engineering lead
Description: Many development organizations create a software systems engineering (SSE) group that translates and maps the requirements from the higher-level systems group into lower-level requirements, which can be assigned to individual development teams. This often means that the higher-level ‘shall statements’ which are used at the top level must be translated into use
cases and other artifacts that more clearly communicate the requirements to the software development teams. In addition, the requirements associated with each interface may also be specified by this team.
Relationship to Software Architect: The software architect should participate in many of the use case and interface definition activities with the SSE team. The preliminary software architecture will often be provided to this organization, and the resulting activities of the SSE team will evolve the software architecture as the system is better understood.