Work Product Descriptor (Artifact): Technical Perspective
The Technical Perspective describes the system in terms of technical entities, technical functions and processes, technical locations, and technical actors/roles. It serves as a minor abstraction of how these aspects need to be related and how they collaborate in the business, defining a technical view of the system.
Purpose

The purpose of the Technical Perspective is to describe, at the technical level, how the system operates (i.e., activities and processes), what is involved in these processes (i.e., entities), where the business has a presence (i.e., locations), and who interacts with the business processes (i.e., actors/roles). It introduces specific technical characteristics such as server makes/model, network equipment make/model, storage solution make/model and desktops make/model.  

The Technical Perspective describes process structures and interactions including prescribing technology choices. The human interaction, that is, the technical roles defined and their interaction with activities is associated with specific sets of people having specific positions within the enterprise. Security solutions, such as Role-Based Access Control, are defined based upon these technical roles.

The Technical Perspective is used by stakeholders and system/process designers to understand how the systems currently work (if in an as-is form) including the technology used, and to analyze the effect of changes to the technical level of the business (if in a to-be form). The IT architect is responsible for the structure and integrity of the model, while system designers and other technical domain experts may assist detailing technical elements within the model.

Also see: Activity: Enterprise Planning and Milestone: Gate 4

Relationships
Contained Artifacts
RolesResponsible: Modified By:
Main Description

The Technical Perspective has the following parts or aspects:

  • Technical Entity Model - model of entities consumed and produced by Activities;
  • Technical Process Model - model of the structure of Activities (which produce and consume entities), forming processes;
  • Technical Locations Model - model of the Locations where the "system" has a presence;
  • Technical Roles Model - model of the Actors/Roles.

Each of these viewpoints is actually a collection of models that (typically hierarchically) define the aspect. See: Concept: Architecture Perspectives and Viewpoints.

Properties
Optional
Planned
Illustrations
Templates
Reports
Tailoring
Representation Options

The Technical Perspective describes the system in terms of technical entities, technical functions and processes, technical locations, and technical actors/roles. It serves as a minor abstraction of how these aspects need to be related and how they collaborate in the business, defining a technical view of the system.

UML Representation: «stereotype» TPL_Perspective

Extends: «metaclass» Package

A Technical Perspective has the following parts:

  • Introduction: A textual description that serves as a brief introduction to the model. 
  • Aspects: The packages and subsystems in the model, representing a hierarchy, with four top level peer packages:
    • Technical Entity Model - model of technical entities consumed and produced by technical functions
    • Technical Process Model - model of the structure of technical functions (which produce and consume technical entities), forming processes
    • Technical System Model - model of the technical layout of systems (including their technical location)
    • Technical Roles Model - model of the user interface components used by various technical roles  

It is likely that the key portions of the model will be the process model and the locations model, which respectively define the processes and systems that they ride upon. The deployment of the technical entities (to systems) is also important to show; therefore this information may be added to the locations model(s). 

Decide on the following:

  • The package structure for the four sub-models: function-based structure or coherence/coupling based;
  • Properties to include;
  • Whether or not any extensions to the Unified Modeling Language (UML) are needed; additional stereotypes for example;
  • The level of formality and detail in the model (see Guideline: Technical Perspective);
  • Tailoring applicable to individual sub-work products;
  • Whether a single model or multiple models will be used (see Concept: Complex IT Architectures).
More Information
Checklists
Concepts
Guidelines
Supporting Materials
© David W. Enstrom, 2025. All rights reserved.