System Architect
- System Architect
- the role that is played when a
person produces the
architecture of a
system
As illustrated in the preceding figure, System Architect is part of the following inheritance hierarchy:
The typical role-specific responsibilities of a System Architect are to:
- Architecturally-Significant Requirements.
Identify and prioritize the architecturally-significant requirements.
- Produce System Architecture.
Produce the components of the system architecture including:
- Styles and Patterns.
Determine and document the styles and major patterns of the system architecture.
- Architecture Model.
Produce the architecture model:
- Views.
Produce and document architectural views including, but not limited to:
- Functional View.
Use the system’s functional requirements to identify the:
- Major functions to be performed by the system.
- Relationships between them.
- Configurational View.
Determine and document the hierarchical decomposition structure of the system in terms of its components:
- Interface View.
Determine and document the hardware, software, and human internal interfaces and protocols
between the components of the system.
- State View.
Produce and document the state models of the system components.
- Data View.
Produce and document the data models (e.g., data dictionary, object model,
logical data schemas, physical data schemas) of the system components.
- Hardware/Network View.
Determine the physical layout and interfaces between the hardware components
(e.g., clients, servers, networks, sensors, actuators).
- Software Module View.
Determine the software packages and major software modules and their interfaces
(e.g., messages and exceptions).
- Software Process View.
Determine the operating system processes, major threads, how they are scheduled, and how they interact.
- Software Allocation View.
Determine and document how the data (e.g., files and databases) and software (e.g., source code,
object code, processes, and threads) are allocated to the hardware.
- Perspectives.
Produce engineering specialty perspectives (i.e., relevant subsets) of architectural views
including, but not limited to:
- Interoperability Perspective.
Determine how the architecture will fulfil its interoperability requirements and
provide one or more corresponding interoperability perspectives of the relevant views.
- Performance Perspective.
Determine how the architecture will fulfil its performance requirements and
provide one or more corresponding performance perspectives of the relevant views.
- Reliability Perspective.
Determine how the architecture will fulfil its reliability requirements and
provide one or more corresponding reliability perspectives of the relevant views
(e.g., showing hardware and software redundancy).
- Safety Perspective.
Determine how the architecture and its components will fulfil their allocated safety requirements and
document one or more corresponding safety perspectives of the relevant views.
- Security Perspective.
Determine how the architecture and its components will fulfil their allocated security requirements and
document one or more corresponding security perspectives of the relevant views such as perspectives of the:
- Data view showing where classified data is stored.
- Hardware view showing the location of network firewalls and security functions
such as access control and encryption.
- Analyze Model.
Analyze the architecture model views and perspectives
to ensure that the architecture and its components meet their allocated
requirements:
- Make “Make vs. Buy” Decision.
Determine and document how the system components will be obtained:
- Acquisition (e.g., via outsourcing, subcontracting)
- Production (e.g., via fabrication, manufacture, software development)
- Reuse (e.g., internal, open-source, purchase)
- Obtain Reusable Components.
Identify, evaluate, and select reusable components.
- Prototype Architecture.
Prototype the architecture by creating executable architectural models.
- Make Strategic Engineering Decisions.
Make and document the strategic engineering decisions (e.g., selection of technology,
design method, and programming language)
that constrain the design and implementation of the system.
- Enforce Architectural Integrity.
Enforce the integrity of the system architecture by collaborating with and mentoring the development staff.
- Support Management.
Help endeavor management to:
- Schedule incremental development and delivery based on optimal development sequencing of the
architectural components (e.g., infrastructure components before components that depend on the infrastructure).
- Staff endeavor development teams based on the allocation of architectural components to teams
(e.g., Conway’s Law).
- Subcontract the development of components based on (for example) required areas of expertise.
System Architect typically inherits the
general role responsibilities from the
role method component.
To fulfill these responsibilities, a System Architect typically should have the following
personal characteristics,
expertise,
training, and
experience:
A System Architect should typically have the following personal characteristics:
- An abstract thinker (i.e., "big-picture" person) who:
- Is comfortable working strategically at high-levels of abstraction.
- Can see the big picture without being caught up in diversionary details.
- Can see beyond the obvious issues to patterns or connections of issues that are not obviously related.
- Can recognize the essential underlying issues in complex situations.
- Able to perform engineering trade-offs between:
- Conflicting architecturally-significant requirements.
- Competing architectural decisions.
- Able to identify architecturally-significant requirements and their ramifications on the various architectures.
- Able to clearly grasp the context of the application and its system architecture.
- Able to comfortably multitask (i.e., perform multiple architecting tasks concurrently).
- Able to make important decisions given incomplete and conflicting knowledge.
- Highly self-directed, being able to both manage and
(re)prioritize the multiple concurrent and competing
challenges, issues, ambiguities, and contradictions that
necessarily occur during the prduction of the system architecture.
- Strong analytical problem solving skills.
- Excellent verbal and written communication skills, and
thus able to explain and document the system architecture for its diverse stakeholders.
- Solid team-building skills.
A System Architect should typically have the following expertise:
- Expert practical knowledge of:
- System architecture tasks, techniques, and tools.
- Object-oriented concepts such as abstraction, encapsulation, inheritance, and polymorphism.
- Component-based development (CBD) concepts such as components, component models, component infrastructures,
and interfaces.
- Networks and network connection devices.
- The major infrastructure and middleware technologies
that are used to implement system architectures, as well as
the associated vendor organizations and their
commercially-available products.
- How to develop architectures of applications that will
be distributed across multiple, heterogenious platforms
(e.g., hardware, operating system, server software, browsers, etc.).
- Object-oriented concepts such as abstraction, encapsulation, inheritance, and polymorphism.
- Component-based development concepts such as components, component models, component infrastructures,
and interfaces.
- Object, use case, and process/functional modeling.
- Application modelling languages (e.g., UML, OML) including the ability to create and read the associated diagrams.
- Application modelling tools.
- Solid practical knowledge of:
- Requirements engineering concepts and techniques.
- Hardware, information, database, and software architecting.
- The theory, practice, and tools of systems engineering.
- The major reusable system mechanisms and patterns.
- How to produce a common architecture for a family of related applications (e.g., a product line).
- Basic practical knowledge of the:
- Application domain
- Business enterprise of the customer's organization.
- Integration and system-level testing theory, practice, and tools.
- Configuration identification, configuration control, and associated configuration management tools.
A System Architect should typically have the following training:
- A bachelor’s degree or better in software or systems engineering, computer science, or the equivalent.
- Practical hands-on training in:
- The project process, especially in terms of relevant tasks, techniques, and work products.
- Object and use case modelling concepts, diagrams, and tools.
- Component models, infrastructures, and interfaces.
A System Architect should typically have the following experience:
- A minimum of 1 year‘s experience successfully producing software and network architectures during similar endeavors.
- A minimum of 3-5 year‘s experience successfully designing and implementing data, hardware, or software components during similar endeavors.
A System Architect typically performs the following role-specific tasks in an iterative,
incremental, parallel, and time-boxed manner:
System Architect typically inherits
common role tasks from the
Role method component.
A System Architects typically performs these tasks as members of the following teams:
As a member of these teams, a System Architect typically produces all or part of the following work products:
- The system architect role typically leads the architecture team.
- On small and medium sized projects, it is not unusual for
the person who plays the system architect role to also play
the technical leader role. This is assumed by the Rational
Unified Process, which assigns many technical leader tasks to the architect.
- This role typically inherits the
common team guidelines from the
Role method component.