Technology Viewpoint : Archimate

Concerns: Stability, security, dependencies, costs of the infrastructure
Purpose: Designing
Scope: Single layer/Multiple aspect

The technology viewpoint contains the software and hardware technology elements supporting the Application Layer, such as physical devices, networks, or system software (e.g., operating systems, databases, and middleware).

Implement Migration Viewpoint : Archimate

Concerns: Architecture vision and policies, motivation
Purpose: Deciding, informing
Scope: Multiple layer/Multiple aspect

The implementation and migration viewpoint is used to relate programs and projects to the parts of the architecture that they implement. This view allows modeling of the scope of programs, projects, project activities in terms of the plateaus that are realized or the individual architecture elements that are affected. In addition, the way the elements are affected may be indicated by annotating the relationships.

Furthermore, this viewpoint can be used in combination with the programs and projects viewpoint to support portfolio management:

  • The programs and projects viewpoint is suited to relate business goals to programs and projects. For example, this makes it possible to analyze at a high level whether all business goals are covered sufficiently by the current portfolio(s).
  • The implementation and migration viewpoint is suited to relate business goals (and requirements) via programs and projects to (parts of) the architecture. For example, this makes it possible to analyze potential overlap between project activities or to analyze the consistency between project dependencies and dependencies among plateaus or architecture elements.

 

Account Context Diagram

Purpose: The purpose of the Account Context Diagram is to enable financial risk management by illustrating which processes create transactions on a given account, and which risks are related to this transaction.

Core concerns: The Account Context Diagram enables you to model Accounts, Business Processes and link them with influences.

Below, you can see an example of an Account Context Diagram for the account ‘Other Payables’:

The risks are linked to the influencers and shown on the diagram. For example, in the above diagram, both risks are: ‘Goods received not invoiced, not recognized as a liability at period end’.

It is possible to link multiple risks to each influence. In the following diagram, you can see a similar Account Context Diagram, where several risks are connected to a single influence:

Relation to other templates: The Account Context diagram is for financial risk management. It is related to the Control Coverage Map and the Heat Map templates, which can be generated based on the information in the Account Context Diagram.

Properties and metadata: The Account Context Diagram ­­­­can for example retain the following information:

  • A description of the diagram
  • Link to the owner of the diagram
  • Link to the one responsible for the diagram
  • Link to the Account shown in the diagram
  • Audits (auto generated information regarding its current state and access rights)
  • Associated documents, diagrams and other objects
  • Inherent Risk detailing risk considerations
  • Governance information detailing information about the published diagram and who has been involved in the approval of the diagram

The above picture shows the properties dialogue window for the Account Context Diagram where you can view and edit the diagram’s properties in QualiWare Lifecycle Manager.

Activity Diagram

Purpose: The purpose of the Activity Diagram is to show the overall flow of control through workflows for computational and organizational processes using the UML standard.

Core concerns: The Activity Diagram enables you to document stepwise activities and actions with support for choice, iteration and concurrency. The template allows you to connect the following objects using either Control Flows, Object Flows or Exception Handlers:

Below, you can see two different examples of an Activity Diagram. The first illustrates a structure for an ideation process, the second shows the process for Booking an order – divided into two different Activity Partitions:

ActivityDiagram_2

ActivityDiagram_1

Relation to other templates: The Activity Diagram can be used instead of a Workflow Diagram or a Business Process Diagram, though the different languages have their own pros and cons. The Activity Diagram is part of the UML templates QualiWare supports along with the Communication Diagram, Deployment Diagram, Class Diagram, Composite Structure Diagram, State Diagram, Package Diagram, Component Diagram, Sequence Diagram, Use case diagram and Timing Diagram.

Properties and metadata: The Activity Diagram ­­­­can for example retain the following information:

  • A description of the diagram
  • Link to the owner of the diagram
  • Link to the one responsible for the diagram
  • Audits (auto generated information regarding its current state and access rights)
  • Extensions: Stereotypes, constraints and tagged values
  • Associated documents, diagrams and other objects
  • Inherent Risk detailing risk considerations
  • Governance information detailing information about the published diagram and who has been involved in the approval of the diagram

The above picture shows the properties dialogue window for the Activity Diagram where you can view and edit the diagram’s properties in QualiWare Lifecycle Manager.

For more information: about the UML and Activity Diagram, please visit the Object Management Group’s Website, where you can find the complete specification.