Architecture Description Framework
From FactorityWiki
The TOGAF Architecture description framework established a common set of terms that can be used across projects and even companies. This document describes the actual adaption of TOGAF for the FACTORITY project.
Note that the TOGAF concepts are not repeated here. For more details see References.
Introduction
In order to break down the complexity of the FACTORITY architecture documentation the TOGAF View and Viewpoint concept is used. Certain Viewpoints address certain Stakeholder needs.
TOGAF provides a content meta model that describes the relationship of several viewpoints (Figure 1).
In the context of a FACTORITY integration project, Views based on these Viewpoints are created. Therefore, certain views from the views repository are selected and adapted. Whereas, generalizations of new views will be added to the repository (Figure 2).
The view creation process is as follows:
- Refer to an existing library of viewpoints
- Select the appropriate viewpoints (based on the stakeholder and concerns that need to be covered by views)
- Generate views of the system by using the selected viewpoints as templates
Stakeholders and Concerns
User
The user wants to know how to use the system, and how the performance will be.
Software Engineer
Software Engineers are interested in established guidelines to help minimize the effort required and the risks involved.
Major concerns for these stakeholders are:
- Development approach
- Software modularity and re-use
- Portability
- Migration and interoperability
System Engineer
Security Engineers
Security Engineers are interested in how the system is implemented from the perspective of security, and how security affects the system properties. He/she examines the system to establish what information is stored and processed, how valuable it is, what threats exist, and how they can be addressed.
Their major concerns are understanding how to ensure that the system is available to only those that have permission, and how to protect the system from unauthorized tampering.
Communication Engineer
Database Engineer
System Administrator
Principles and Requirements
Preliminary Viewpoint
Stakeholder:
User, Software Engineer
Artifacts:
(TODO)
Architecture Vision Viewpoint
Stakeholder:
User, Software Engineer
Artifacts:
(TODO)
Architecture Requirements Viewpoint
Stakeholder:
User, Software Engineer
Artifacts:
(TODO)
Business Architecture
Motivation Viewpoint
Stakeholder:
User, Software Engineer
Artifacts:
(TODO)
Organization Viewpoint
Stakeholder:
User, Software Engineer
Artifacts:
(TODO)
Function Viewpoint
Stakeholder:
User, Software Engineer
Artifacts:
(TODO)
Information System Architecture
Data Viewpoint
(TODO)
Application Viewpoint
(TODO)
Technology Architecture Viewpoint
Stakeholder:
Software Engineer
Artifacts:
Architecture Realization
Opportunities, Solutions, and Migration Planing Viewpoint
(TODO)
Implementation Governance Viewpoint
(TODO)
Enterprise Security Viewpoint
(TODO)
Software Engineering Viewpoint
Stakeholder:
Software Engineer
Artifacts:
- Project Dependencies
- (TODO)
System Engineering Viewpoint
(TODO)
Enterprise Managementability Viewpoint
(TODO)
