Principles Viewpoint:ArchiMate

Purpose: The Principles Viewpoint in ArchiMate is used to define and model the principles that guide an enterprise’s decisions and actions. It enables architects to capture and communicate the fundamental values and beliefs that shape an organization’s strategy, culture, and behavior. By doing so, the Principles Viewpoint helps to ensure that all stakeholders have a common understanding of the principles and can make informed decisions based on them.

Core Concerns: The core concerns of the Principles Viewpoint include defining and documenting the principles, their relationships to other architectural elements, and their impact on the enterprise. The Principles Viewpoint helps to ensure that the principles are aligned with the enterprise’s goals and objectives, and that they are consistent with its vision, mission, and values. Additionally, it helps to ensure that the principles are integrated into the enterprise’s architecture and that they are applied consistently across all areas of the organization.

Example:

Overview: The Principles Viewpoint is a perspective in the ArchiMate enterprise architecture modeling language that focuses on the principles that guide an organization’s decisions and actions. Principles are high-level statements that capture an organization’s values, beliefs, and goals, and they provide a framework for decision-making and action. In the Principles Viewpoint, principles are represented as rectangular shapes with labels that describe their meaning and purpose. Relationships between principles are shown as lines connecting the principles, with labels that describe the nature of the relationship.

The Principles Viewpoint includes several concepts for modeling different aspects of principles, including:

  • Principles: A principle is a high-level statement that captures an organization’s values, beliefs, and goals. Principles can be modeled to show their meaning, purpose, and impact on the enterprise.
  • Relationships: Relationships between principles can be modeled to show the dependencies, conflicts, and synergies between them. This helps to ensure that the principles are consistent and aligned with the enterprise’s goals and objectives.
  • Impacts: The impact of principles on the enterprise can be modeled to show how they influence decision-making and action. This helps to ensure that the principles are integrated into the enterprise’s architecture and that they are applied consistently across all areas of the organization.

Overall, the Principles Viewpoint is useful for defining and modeling the principles that guide an enterprise’s decisions and actions. It provides a common understanding of the principles and ensures that they are aligned with the enterprise’s goals and objectives. By doing so, it helps to ensure that the enterprise operates in a consistent and coherent manner and achieves its strategic objectives.

Goal Contribution Viewpoint:ArchiMate

Purpose: The Goal Contribution Viewpoint in ArchiMate is used to model how business goals are related to each other and how they contribute to the overall business strategy of an enterprise. The purpose of this viewpoint is to provide a clear understanding of the relationships between goals and how they align with the enterprise’s overall objectives. This can help organizations prioritize their goals and ensure that they are working towards their strategic objectives.

Core Concerns: The core concerns of the Goal Contribution Viewpoint include modeling the relationships between business goals, the contributions that each goal makes towards the overall strategy, and the measures used to assess progress towards the goals. By focusing on these core concerns, the Goal Contribution Viewpoint can help organizations identify opportunities for improving their strategy and ensuring that their goals are aligned with their overall business objectives.

Example:

The Goal Contribution Viewpoint is a perspective in the ArchiMate enterprise architecture modeling language that focuses on the relationships between business goals and how they contribute to the overall strategy of an enterprise. In this viewpoint, goals are represented as ovals with labels that describe their purpose and significance. Relationships between goals are shown as lines connecting the goals, with labels that describe the nature of the relationship.

The Goal Contribution Viewpoint includes several concepts for modeling different aspects of goal contribution, including:

  • Goal Dependencies: Goal dependencies are used to show how one goal contributes to another goal. This can help organizations understand how achieving one goal may impact the achievement of another goal.
  • Goal Decomposition: Goal decomposition is used to break down high-level goals into more specific, measurable objectives. This can help organizations track progress towards their goals and assess whether they are on track to achieve their strategic objectives.
  • Goal Measures: Goal measures are used to assess progress towards goals. This can help organizations determine whether they are making progress towards their goals and whether any adjustments need to be made to their strategy.

Overall, the Goal Contribution Viewpoint is useful for modeling the relationships between business goals and ensuring that they are aligned with the overall strategy of an enterprise. By providing a clear understanding of how goals contribute to the enterprise’s strategic objectives, organizations can prioritize their goals and ensure that they are working towards their strategic objectives.

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.

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.

OntologyDiagram:OWL

An ontology diagram shows classes, object properties and datatype properties, as well as rules (especially set rules). 

Symbols (Classes, Set Rules, Datatypes and Instances) are dragged from the palette into the drawing canvas. 

Connections (subClassOf, SetRelation, ObjectProperty, DatatypeProperty and Instantiation) connect the appropriate symbols.

The ontology diagram symbols palette provides the set of symbols and links which are used to graphically represent the ontology:

  • Class (symbol for a Class which may be automatically colored based on the Class characteristics)
  • Union, Intersection, Disjioint and Complement (symbols for set Rules)
  • owlDataType (symbol for defining the data type of a data Property defining a Class)
  • Instance (symbol for instances of a given Class)
  • subClassOf (connector linking a Class as subClass to its superClass Class)
  • SetRelation (connector linking a Class or a set Rule to a set Rule; composite rules can be formalized)
  • ObjectProperty (connector linking a Class or Set Rule to a Class or a set Rule defining the entertained relationship)
  • DatatypeProperty (connector linking a Class oa setRule to a Datatype)

owlInstanciation (connector linking a Class or a setRule to corresponding Instances)

As in any QualiWare diagram, connecting 2 symbols is achieved by selecting the connector, then the source symbol, then the target symbol, then giving it a name.

The coloring of the Class symbol is achieved based on the Class characteristics.

A class can be:

  • A Thing
  • A standard owl Class defined in the current ontology edited in the currentontology diagram
  • External to the concerned ontology (the one edited in the diagram)
  • A rdfs Class
  • A Resource
  • A deprecated Class

Since it is contextual to the edited diagram, defining a Class as being external to an ontology is achieved by selecting the classes which are external to the ontology depicted in the diagram copying them and pasting them in the “External Classes” field of the definition template of the diagram.

 

The same can be achieved for ObjectProperties which are external to the edited ontology.

 

A same Class (unique in the repository) can be a standard owl Class in the ontology defining it (and appearing pale blue in the diagram depicting this ontology) and dark blue (since external) in possibly many other diagrams depicting other ontologies referencing to this Class.

Same for ObjectProperties.

 

When closing a diagram, the corresponding Ontology instance (the one which refers to the diagram) is updated. Its contained Classes and Object Properties fields are updated.

The instances of Class, ObjectProperty, DatatypeProperty and set Rules instances edited in the diagram are also updated (see corresponding paragraphs)

MilkyWayEnterpriseMap:EDGY

Purpose: The purpose of the MilkyWayEnterpriseMap diagram is to map the different elements into one diagram, creating a view of the enterprise

Core concerns: The MilkyWay enables you to collect objects of the different facets in the EDGY language in one diagram.

 

From the center and outwards, the milkyway shows:

  • the identity elements (Purpose and Story)
  • the Organization
  • the architecture elements (Capability and Process)
  • the Product
  • the experience elements (Task and Journey)
  • the Brand