Business Process Viewpoint:ArchiMate

Purpose: The Business Process Viewpoint in ArchiMate aims to model the end-to-end business processes that an organization performs to achieve its goals and objectives. This helps to provide a clear understanding of the organization’s operations and how they contribute to its overall success.

Core Concerns: The core concerns of the Business Process Viewpoint include modeling the sequence of activities in a business process, the roles and responsibilities of actors involved in the process, the information and functionality exchanged between them, and the resources used to carry out the process. By focusing on these core concerns, the Business Process Viewpoint can help identify opportunities for improving process efficiency, reducing costs, and creating value for the organization. It can also facilitate communication and collaboration among stakeholders, providing a common understanding of the organization’s business processes and their interdependencies.

Example:

The Business Process Viewpoint is a perspective in the ArchiMate enterprise architecture modeling language that focuses on the processes that an organization performs to achieve its goals and objectives. In the Business Process Viewpoint, processes are represented as rounded rectangles with labels that describe the process name and its purpose. Actors involved in the process are represented as rectangular shapes with labels that describe their roles and responsibilities.

The Business Process Viewpoint includes several concepts for modeling different aspects of business processes, including:

  • Process Flow: Process flow is the sequence of activities that make up a business process. Process flows can be modeled to show the activities involved, the order in which they occur, and the actors involved in each activity.
  • Actors: Actors are the people, organizations, or systems that perform activities within a business process. Actors can be modeled to show their roles and responsibilities in the process.
  • Information Flow: Information flow is the exchange of information between actors within a business process. Information flows can be modeled to show the types of information exchanged and the actors involved in each exchange.
  • Resources: Resources are the physical or virtual assets used to carry out a business process. Resources can be modeled to show the resources used in each activity of the process.

Overall, the Business Process Viewpoint is useful for modeling the end-to-end business processes of an organization and for understanding how these processes contribute to its overall success. By modeling the sequence of activities, the roles and responsibilities of actors, and the resources and information exchanged in each process, stakeholders can gain a clearer understanding of the organization’s operations and identify opportunities for improvement.

Business Function Viewpoint:ArchiMate

Purpose: The Business Function Viewpoint in ArchiMate aims to model the capabilities and functionalities of an enterprise, and how they are organized and executed to achieve business goals and objectives. This helps to provide a clear understanding of how the enterprise operates and how different functions and processes are interdependent.

Core Concerns: The core concerns of the Business Function Viewpoint include modeling the business functions and processes, their dependencies, inputs and outputs, and how they are organized to achieve business goals. By focusing on these core concerns, the Business Function Viewpoint can help identify opportunities for improving efficiency, reducing costs, and creating value for the organization. It can also facilitate communication and collaboration among stakeholders, providing a common understanding of the enterprise’s functional architecture and how it supports business objectives.

Example:

Overview: The Business Function Viewpoint is a perspective in the ArchiMate enterprise architecture modeling language that focuses on the business functions and processes of an enterprise. It provides a high-level overview of the enterprise’s functional architecture and how it supports business objectives. In the Business Function Viewpoint, business functions are represented as rectangles with labels that describe their purpose, while processes are represented as rounded rectangles with labels that describe their activities.

The Business Function Viewpoint includes several concepts for modeling different aspects of business functions, including:

  • Business Functions: A business function is a capability or set of capabilities that performs a specific business activity. Business functions can be modeled to show their dependencies, inputs and outputs, and how they are organized to achieve business goals.
  • Processes: A process is a series of activities that transforms inputs into outputs. Processes can be modeled to show their inputs and outputs, and how they are related to other processes and business functions.
  • Dependencies: Dependencies represent the relationships between different business functions and processes. Dependencies can be modeled to show how different functions and processes are interdependent and how changes in one area can affect other areas.
  • Inputs and Outputs: Inputs and outputs represent the data, information, and materials that are exchanged between different business functions and processes. Inputs and outputs can be modeled to show how they are related to different functions and processes and how they support business objectives.

Overall, the Business Function Viewpoint is useful for modeling the functional architecture of an enterprise and understanding how different functions and processes are interdependent and support business objectives. It can also help identify opportunities for improving efficiency, reducing costs, and creating value for the organization.

Application Structure Viewpoint:ArchiMate

Purpose: The Application Structure Viewpoint in ArchiMate is used to model the structure and organization of applications and their components within an enterprise architecture. The viewpoint helps to provide a clear understanding of the relationship between the applications and their components, as well as how they interact with other architecture domains such as business and technology. This enables architects to design and manage the application architecture effectively.

Core Concerns: The core concerns of the Application Structure Viewpoint include modeling the structure and organization of applications and their components, their interactions and dependencies, and the technology infrastructure that supports them. By focusing on these core concerns, the Application Structure Viewpoint can help identify opportunities for improving the architecture’s efficiency, reducing complexity, and creating value for the organization. It also facilitates communication and collaboration among stakeholders, providing a common understanding of the application architecture and its interdependencies with other domains.

Example:

Overview: The Application Structure Viewpoint is a perspective in the ArchiMate enterprise architecture modeling language that focuses on the structure and organization of applications and their components. The viewpoint defines the different elements that make up the application structure and their relationships.

In the Application Structure Viewpoint, applications are represented as rectangular shapes with labels that describe their functions and capabilities. The components of an application are represented as smaller shapes within the application shape, such as modules, libraries, and services. Relationships between applications and their components are shown as lines connecting them, with labels that describe the nature of the relationship.

The Application Structure Viewpoint includes several concepts for modeling different aspects of the application structure, including:

  • Applications: Applications are the primary elements of the application structure, representing the software systems that are used to support business processes. Applications can be modeled to show their functions, capabilities, and relationships with other applications and components.
  • Components: Components are the parts of an application that provide specific functionality. Components can be modeled to show their relationships with other components within the same application, as well as their dependencies on other applications and components in the architecture.
  • Interfaces: Interfaces are the points of interaction between applications and their components. Interfaces can be modeled to show the data and functionality that is exchanged between applications and components, as well as the technology infrastructure that supports them.
  • Dependencies: Dependencies are the relationships between applications and their components that are required for the application to function properly. Dependencies can be modeled to show the relationships between different applications and their components, as well as the technology infrastructure that supports them.

Overall, the Application Structure Viewpoint is useful for modeling the structure and organization of applications and their components, as well as their interactions and dependencies with other architecture domains. It enables architects to design and manage the application architecture effectively, and to identify opportunities for improving its efficiency, reducing complexity, and creating value for the organization.

Application Behavior Viewpoint:ArchiMate

Purpose: The Application Behavior Viewpoint in ArchiMate aims to model the behavior and interactions of applications within an enterprise, providing a high-level view of how applications support business processes and goals. This helps to identify opportunities for optimizing application behavior, improving performance, and reducing costs.

Core Concerns: The core concerns of the Application Behavior Viewpoint include modeling the behavior of applications, the services they provide, and the interactions between applications and other components within the enterprise architecture. By focusing on these core concerns, the Application Behavior Viewpoint can help identify bottlenecks and areas for improvement and provide a clear understanding of how applications contribute to the overall functioning of the enterprise.

Example:

The Application Behavior Viewpoint includes several concepts for modeling different aspects of application behavior, including:

  • Application Component: An application component represents a unit of functionality provided by an application. Application components can be modeled to show the services they provide and the interfaces through which they interact with other components.
  • Application Service: An application service is a unit of functionality provided by an application component. Application services can be modeled to show the behavior and capabilities of an application component.
  • Application Interface: An application interface represents a point of interaction between application components, or between an application component and other components within the enterprise architecture. Application interfaces can be modeled to show the data and functionality exchanged between components.
  • Application Interaction: An application interaction represents the exchange of data and functionality between application components, or between an application component and other components within the enterprise architecture. Application interactions can be modeled to show the sequence and timing of events.

Overall, the Application Behavior Viewpoint is useful for modeling the behavior and interactions of applications within an enterprise, providing a high-level view of how applications support business processes and goals. By focusing on the core concerns of application behavior, the Application Behavior Viewpoint can help identify areas for improvement and optimization and provide a clear understanding of how applications contribute to the overall functioning of the enterprise architecture.

Actor Cooperation Viewpoint:ArchiMate

Purpose: The Actor Cooperation Viewpoint in ArchiMate aims to model how actors collaborate and work together to achieve business goals and objectives, and to capture the social and organizational aspects of an enterprise. This helps to provide a clear understanding of how different actors are connected and how they contribute to the overall goals of the organization.

Core Concerns: The core concerns of the Actor Cooperation Viewpoint include modeling the roles and responsibilities of actors, their collaboration and interaction, the information and functionality exchanged between them, and the interfaces through which they interact. By focusing on these core concerns, the Actor Cooperation Viewpoint can help identify opportunities for improving efficiency, reducing costs, and creating value for the organization. It can also facilitate communication and collaboration among stakeholders, providing a common understanding of the organization’s social and organizational aspects and their interdependencies.

 

Example:

The Actor Cooperation Viewpoint is a perspective in the ArchiMate enterprise architecture modeling language that focuses on the relationships and interactions between actors (people, organizations, or systems) within an enterprise. This viewpoint is used to model how actors collaborate and work together to achieve business goals and objectives.

In the Actor Cooperation Viewpoint, actors are represented as rectangular shapes with labels that describe their roles and responsibilities. Relationships between actors are shown as lines connecting the actors, with labels that describe the nature of the interaction.

The Actor Cooperation Viewpoint includes several concepts for modeling different aspects of actor collaboration, including:

  1. Roles: A role is a specific set of responsibilities and behaviors assigned to an actor. Roles can be modeled to show how different actors collaborate and contribute to business processes.
  2. Collaboration: Collaboration is the act of two or more actors working together to achieve a common goal. Collaboration can be modeled to show the actors involved, the goals they are working towards, and the interactions between them.
  3. Interaction: An interaction is a communication or exchange of information between two or more actors. Interactions can be modeled to show the flow of information and the roles and responsibilities of each actor involved.
  4. Interfaces: An interface is a point of interaction between two actors, such as a user interface between a person and a system, or a service interface between two systems. Interfaces can be modeled to show the information or functionality exchanged between actors.

Overall, the Actor Cooperation Viewpoint is useful for modeling the social and organizational aspects of an enterprise, and for understanding how different actors collaborate and work together to achieve business objectives.

Representation ArchiMate

Representations (for example, messages or documents) are the perceptible carriers of information that are related to business objects. If relevant, representations can be classified in various ways; for example, in terms of medium (electronic, paper, audio, etc.) or format (HTML, ASCII, PDF, RTF, etc.). A single business object can have a number of different representations. Also, a single representation can realize one or more specific business objects.

A meaning can be associated with a representation that carries this meaning. The name of a representation is preferably a noun.

HTML Model Generator Settings

The HTML Model Generator Settings template is used to configure the table to model feature introduced in the web-modeler in QualiWare 10.8.

In the HTML Model Generator Settings you can configure the table-to-model settings and make them available for selected diagrams in the web-modeler.

  • Settings target: default value is “Table-to-Model”
  • Visual name: The text inserted here will be visual in the web-modeler
  • In Diagram type field, you can select between different Diagram types:
  • Use for templates: Here you select in which template(s) the Model Generator Settings should be available under “Import from Table” in the web-model
  • Setting content: Here you define the:
    • Column: Column Headers in the table in the web-modeler,
    • Default template: The template type of the inserted object
    • Change template:
      • false: the template type is locked and cannot be changed by the user
      • true: the template type can be changed, and an additional column is inserted right to the Column, where the user can change between the available template types defined by the underlying metamodel for the diagram type.

Below is an example of where Box in a Box is selected as Diagram type:

Below is an example of how the “Box in a box” settings works in the web-modeler for the Business Capability Model diagram:

In order to be able to access and generate models in the WebModeler, the HTMLModelGeneratorSettings objects needs to added to the HTMLPublisher and/or to the HTMLTemplateDefinition for the specific diagram Template.

The Model Generator Settings is setup through the HTMLPublisher’s Smart Capture Settings tab:

You can insert the HTMLModelGeneratorSettings in the HTMLTemplateDefinition for the specific diagram on the Smart Capture tab (or select the “Inherit default settings” to inherit from the HTMLPublisher.

Cloud Architecture Diagram

The QLM user creates a new “CloudArchitectureDiagram” the same way as for any other diagram he/she is used with. Then by opening this diagram for the first time, the user is asked to associate it to the Cloud Provider as on the figure below.

 

Une image contenant texte Description générée automatiquement

Adding a “CloudGrouping”

As for any symbol, the CloudGrouping Symbol defaults to a base provider’s symbol, then its appearance is aligned with the qualification of this grouping (called “GroupingCategory”).

First the user places a grouping default symbol as on the figure below:

Graphical user interface Description automatically generated

 

Then the user opens the newly placed GloudGrouping and qualifies it to the appropriate Grouping Category, by selecting within the list of Azure Cloud Grouping Categories, as on the figure below:

 

Graphical user interface Description automatically generated

 

Applying the change or saving the changed description of the Cloud Grouping (pressing OK) changes the appearance of the CloudGrouping symbol according to the selected category.

 

Adding a Cloud Service

When adding and qualifying a Cloud Service, hence defining its appearance, the user will be driven by the meta-model to qualify the service.

 

First the user selects the “Cloud Service” symbol in the symbol’s palette and places it in the diagram page and gives it a name, as shown on the figure below:

 

Graphical user interface, application Description automatically generated

 

The user is asked for defining the Cloud Category of this Cloud Service, as shown in the figure below:

 

Une image contenant texte Description générée automatiquement

 

The user selects the appropriate Cloud Category.

Then the user is asked for defining the Instance Type of this Cloud Service based on the selected Cloud Category, as shown in the figure below:

 

Graphical user interface, application Description automatically generated

 

The user selects the appropriate Instance Type.

Then the user is asked for defining the Resource Type (if any for this Instance Type) of this Cloud Service based on the selected Instance Type (if none, the user clicks OK), as shown in the figure below:

Graphical user interface, text, application Description automatically generated

 

The user selects the appropriate Resource Type (if any), then press OK.

The Cloud Service gets its appropriate appearance based on the selected category, instance type and resource type (if any), as shown in the figure below:

Graphical user interface, application Description automatically generated

 

Relating a Cloud Grouping with Enterprise Architecture elements

Cloud Groupings can be related with specific types of elements of the Enterprise Architectures, as shown in the figure below:

  • Location
  • Organization
  • Zone

The selected element will be inserted in the Relates to field of the previously selected CloudGrouping

Graphical user interface, application Description automatically generated

 

Relating a Cloud Service with Enterprise Architecture elements

Cloud Services can be related with specific types of elements of the Enterprise Architecture as shown in the figure below:

  • ComputerService
  • Computer
  • Database
  • DataWarehouse
  • Equipment
  • Firewall
  • InformationSystem
  • Network
  • Software
  • Technology
  • TechnologyComponent

 

Graphical user interface, application Description automatically generated

 

Facilitating analysis and reporting

Diagrams show the relationships between Cloud Services and Cloud Groupings (Services within Groupings and reverse), but it is useful to get this knowledge from the repository without browsing the diagrams and use it within reports.

That’s the reason, the “Cloud Grouping” and the “Cloud Service” templates manage and show these relationships which are computed at close of the diagram combining cloud groupings and cloud services, and at time of opening either a Cloud Grouping instance or a Cloud Service Instance. As these relationships are computed, they are not editable: the user cannot add nor delete such relationships shown in the “Cloud Grouping” and “Cloud Service” templates.

 

Services contained in a Cloud Grouping

 

Graphical user interface, application Description automatically generated

Cloud Services grouped within the “Availability zone” Cloud Grouping.

Cloud Groupings containing a given Cloud Service

 

Graphical user interface, application Description automatically generated

Cloud Groupings containing this Cloud Service instance.