Solution Architects | QualiWare Center of Excellence

Firewall

Purpose: The purpose of the Firewall template is to document network zones designated by firewalls.

Core concerns: The Firewall template enables you to model Zones, Computers, Networks and Firewall Policies to create a model of a firewall. A firewall is used to control the communication between different networks, typically for security reasons.

Graphical representation of objects:

A Firewall diagram will typically show the Zones of the firewall and the communication policies/rules (Firewall Policies) that exist between the zones. Below, you can see an example of a Firewall diagram containing Zones and Servers (represented by the Computer object):

Relation to other templates: The Firewall template is a technology template and related to the Infrastructure Diagram.

Properties and metadata: The Firewall template can for example retain the following information:

A description of the diagram
Link to Vendor and Hardware
Link to servers
Contract information
Details about resources, costs and benefits
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 Firewall template, where you can view and edit the diagram’s properties in QualiWare Lifecycle Manager.

Deployment Diagram

Purpose: The purpose of the Deployment Diagram is to document the configuration of run-time processing nodes and the components they contain.

Core concerns: The Deployment Diagram template is structural UML diagram that enables you to model Packages, Components, Artifacts, Instance Specifications, Properties, Nodes, Devices, Execution Environments, Deployment Specifications, Objects, Classes, Interfaces, and Annotations. They can then be connected through Association, Dependency, Generalization, Deployment or Manifestation.

The Deployment Diagram models how the different hardware component and software components are connected. Below you can see an example of a Deployment Diagram for a booking service:

In the next example, you can see how Packages and Components would be included in a Deployment Diagram:

Relation to other templates: The Deployment Diagram is, as a component model, part of the application domain on the operational level. As such, it offers a complimentary view to those of the Application Architecture Diagram, Class Diagram, Component Diagram, Data Flow Diagram, Data Mapping Diagram, Data Replication Diagram, Sequence Diagram, State Event Diagram, Structure Chart, and Use Case Diagram.

Properties and metadata: The Deployment 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
Links to extensions such as Stereotypes and Constraints
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 Deployment Diagram where you can view and edit the diagram’s properties in QualiWare Lifecycle Manager.

Class Diagram

Purpose: The purpose of the Class Diagram template is to document the structural aspects of a system using the UML. Below, an example of a simple Class Diagram is shown:

Core concerns: The class diagram shows the system’s classes, attributes, operations and the relationships between classes and other objects such as packages. Below you can se an example of a Class Diagram where the relationship between the Classes “Customer” and “Internet user” with the packages “WEB-API”, “Reservation Control”, “GUI” and “Database” is shown:

Relation to other templates: The Class Diagram presents a detailed structural view of information. It can for example be a decomposition of an Information System which typically is presented in an Application Architecture Diagram. If a Class Diagram becomes too complex or large, a Package Diagram, where the classes are grouped into Packages, could be modelled instead.

Properties and metadata: The Class 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 regarding 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

In the picture below you can see the Class Diagrams properties dialogue window, where the information can be viewed and edited:

Application Usage Viewpoint

Purpose: Designing, deciding

Concerns: Consistency and completeness, reduction of complexity

Scope: Multiple layer/Multiple aspect

The application usage viewpoint describes how applications are used to support one or more business processes, and how they are used by other applications. It can be used in designing an application by identifying the services needed by business processes and other applications, or in designing business processes by describing the services that are available. Furthermore, since it identifies the dependencies of business processes upon applications, it may be useful to operational managers responsible for these processes.

Abstraction Level
Coherence

Layer
Business and application layers

Aspects
Behavior, active structure, passive structure

Application Platform Viewpoint

Scope: Multiple layer/Multiple aspect

Shows structure of a typical application platform and how it relates to supporting technology.

Application Functionality Context

Purpose: The purpose of the Application Functionality Context template is to document the in which Activities and/or Business Processes a given Application Functionality is used.

Core concerns: The Application Functionality Context template can be used to create graphical views showing where Application Functionalities are used. The template enables you to model Application Functionalities, Activities and Business Processes. The Business Processes and Activities are connected to Application Functionalities using Functionality Usage.

Below, you can see an example of an Application functionality contest diagram, where the context for the DocCom – Create and Store Document functionality is shown:

The diagram shows which Business Processes use the Application Functionality as well as which Information System delivers it.

Relation to other templates: To map applications hardware, the Application Architecture Diagram or Infrastructure Diagram template should be used. The Application Functionality Context template graphically connects functionalities of Information Systems to the Processes and Activities in which they are used. It offers an additional view to Application Architecture Diagrams, Workflow Diagrams, Business Process Diagrams and Business Process Networks.

Properties and metadata: The Application Functionality Context template can for example retain the following information:

A description of 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 Application Functionality Context template where you can view and edit the diagram’s properties in QualiWare Lifecycle Manager.

Implement Deployment Viewpoint :ArchiMate

Concerns: Structure of application platforms and how they relate to supporting technology
Purpose: Designing, deciding
Scope: Multiple layer/Multiple aspect

The implementation and deployment viewpoint shows how one or more applications are realized on the infrastructure. This comprises the mapping of applications and components onto artifacts, and the mapping of the information used by these applications and components onto the underlying storage infrastructure.

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.

Migration Viewpoint : Archimate

Concerns: History of models
Purpose: Designing, deciding, informing
Scope: Implementation and Migration

The migration viewpoint entails models and concepts that can be used for specifying the transition from an existing architecture to a desired architecture.

Project Viewpoint : Archimate

Concerns: Architecture vision and policies, motivation
Purpose: Deciding, informing
Scope: Implementation and Migration

A project viewpoint is primarily used to model the management of architecture change. The “architecture” of the migration process from an old situation (current state Enterprise Architecture) to a new desired situation (target state Enterprise Architecture) has significant consequences on the medium and long-term growth strategy and the subsequent decision-making process. Some of the issues that should be taken into account by the models designed in this viewpoint are:

Developing a fully-fledged organization-wide Enterprise Architecture is a task that may require several years.
All systems and services must remain operational regardless of the presumed modifications and changes of the Enterprise Architecture during the change process.
The change process may have to deal with immature technology standards (e.g., messaging, security, data, etc.).
The change has serious consequences for the personnel, culture, way of working, and organization.

Furthermore, there are several other governance aspects that might constrain the transformation process, such as internal and external cooperation, project portfolio management, project management (deliverables, goals, etc.), plateau planning, financial and legal aspects, etc.