System Architect

Definition

System Architect

the role that is played when a person produces the architecture of a system

Classification

As illustrated in the preceding figure, System Architect is part of the following inheritance hierarchy:

• Type: Concrete
• Superclass: Architect
• Subclasses:
  • None

Responsibilities

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:
        • Subsystems
        • Data Components
        • Hardware Components
        • Personnel Components
        • Procedural Components
        • Software 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:
    • Functional Requirements
    • Data Requirements
    • Interface Requirements
    • Quality Requirements (e.g., interoperability, performance, portability, safety, security)
    • Constraints
  • 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.

Personal Profile

To fulfill these responsibilities, a System Architect typically should have the following personal characteristics, expertise, training, and experience:

Personal Characteristics

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.

Expertise

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.

Training

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.

Experience

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.

Tasks

A System Architect typically performs the following role-specific tasks in an iterative, incremental, parallel, and time-boxed manner:

• Requirements Engineering:
  • Requirements Analysis (i.e., requirements prioitization)
• System Architecting:
  • Architecture Reuse
  • Architectural Patterns Selection
  • Architectural Modeling:
    • Architectural Views
    • Architectural Perspectives
  • ArchitecturalAnalysis:
    • Capacity Analysis
    • Operational Availability and Reliability Analysis
    • Performance Analysis
    • Safety Analysis
    • Security Analysis
  • Architectural Mechanism Production
  • Architecture Prototyping
  • Architecture Documentation
  • Architecture Integrity Assurance
• Quality Control:
  • Quality Control - Environments Evaluation
  • Quality Control - Requirements Evaluation
  • Quality Control - Implementation Evaluation

System Architect typically inherits common role tasks from the Role method component.

Teams

A System Architects typically performs these tasks as members of the following teams:

• Requirements Team
• Architecture Team
• Process Team
• Evaluation Teams:
  • Environments Evaluation Team
  • Requirements Evaluation Team
  • Software Evaluation Team

Work Products

As a member of these teams, a System Architect typically produces all or part of the following work products:

• Architectures:
  • Application Architecture
  • Center Architecture
  • Content Management Architecture
  • Database Architecture
  • Distribution Architecture
  • Hardware Architecture
  • Information (Data) Architecture
  • Network Architecture
  • Operational Availability Architecture
  • Organizational Architecture
  • Scalability Architecture
  • Security Architecture
  • Software Architecture
  • User Interface Architecture
• Documentation:
  • Contact Center Architecture Document
  • Data Center Architecture Document
  • Information Architecture Document
  • Software Architecture Document
  • System Architecture Document

Guidelines

• 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.