Archives: Templates

Templates and model types in the QualiWare platform.

Link:EDGY

Link is a fundamental concept denoting a meaningful structural association between two elements. Far from being a mere connection, a link elucidates the relationship between these elements, illuminating its relevance within the broader scope of the enterprise.

Types and Facets of Core Links: EDGY modeling boasts a rich lexicon with twenty-four pre-defined types of links. This variety allows for a nuanced expression of relationships between design elements, ensuring both clarity and specificity. These links have been categorized into several facets:

  1. Identity:
    • Story contextualizes purpose.
    • Content expresses purpose.
    • Content conveys story.
  2. Experience:
    • Task is part of journey.
    • Task utilizes channel.
    • Journey traverses channel.
  3. Architecture:
    • Capability requires asset.
    • Process realizes capability.
    • Process requires asset.

… and so on, for each facet.

By utilizing these core links, co-designers from diverse disciplines can engage in a richer dialogue, enabling them to integrate their specialized designs more effectively across their respective fields.

The Link is a part of the EDGY language created by the Intersection Group.

Value Chain Model

Purpose: The purpose of a Value Chain Model is to model a value chain and show relationships to essential elements of an organization, such as capabilities, policies, regulations, information concepts and systems.

Core concerns: The Value Chain Model template enables you to model Business Processes, Capabilities, Information Concepts, Information Systems, Organizations Units, Goals, KeyPerformanceIndicators, Policies, Regulations, Risks and Opportunities.

 

Value chain models can help businesses by:
  • Highlighting weak points in core functions and processes
  • Breaking down all the activities that go into producing a good or service and understanding areas of cost savings and differentiation
  • Optimizing efforts, eliminating waste, and improving profitability
  • Visualising relationships between processes and capabilities

Technology Component

The Technology Component template is used to describe a technology domain in an InfrastructureDiagram.

A technology component can be realized by a product (derived).

Its lifecycle can be described in terms of when it is used in the organization.

And its product lifecycle.

Package Merge

PackageMerge is a template in a Class Diagram that represents a relationship between two packages, indicating that one package (the receiving package) is merging with another package (the merged package). PackageMerge is used to combine or merge the contents of the two packages, integrating their elements in a way that creates a more coherent or simplified model. The receiving package effectively absorbs the contents of the merged package, including its classes, interfaces, datatypes, and other elements.

The PackageMerge relationship helps to manage complexity and maintainability by allowing you to refactor or reorganize the model as it evolves. By merging related packages, you can simplify the structure and reduce potential redundancies or inconsistencies.

Example: In a Class Diagram for a system that manages a hotel booking platform, you might initially have two separate packages: “GuestManagement” and “ReservationManagement”. The “GuestManagement” package contains classes like “Guest” and “GuestPreferences”, while the “ReservationManagement” package includes classes like “Reservation”, “Room”, and “Booking”. As the system evolves, you may decide to consolidate these related packages into a single, cohesive package called “BookingManagement”. You can use a PackageMerge relationship to merge the contents of the “GuestManagement” and “ReservationManagement” packages into the “BookingManagement” package. This simplifies the model and makes it easier to understand and maintain.

Package Import

PackageImport is a template in a Class Diagram that represents a relationship between two packages or namespaces, indicating that one package is importing or including elements from another package. PackageImport enables modularity and reusability by allowing a package to use the elements (such as classes, interfaces, or datatypes) defined in another package without the need to duplicate their definitions.

By using PackageImport, you can create modular and organized designs, where related elements are grouped together into separate packages. These packages can then be reused and shared across different parts of the system or even among different projects.

Example: In a Class Diagram for a system that manages an online store, you might have two packages: “ProductManagement” and “OrderManagement”. The “ProductManagement” package contains classes like “Product”, “Category”, and “Inventory”, while the “OrderManagement” package has classes like “Order”, “OrderItem”, and “ShippingInfo”. To create a relationship between an “OrderItem” and a “Product” in the system, you can use a PackageImport relationship to import the “ProductManagement” package into the “OrderManagement” package. This way, the “OrderItem” class can reference the “Product” class without duplicating its definition, and the two packages can evolve independently while maintaining their connections.

Enumeration

Enumeration is a template in a Class Diagram that represents a distinct set of named values, also known as enumeration literals. Enumerations are used when an attribute or parameter has a limited number of possible values, and each value can be uniquely identified by a name. Enumerations help to make the model more expressive and easier to understand, as they allow you to use meaningful names instead of arbitrary numeric or string values.

Example: In a Class Diagram for a system that manages event bookings, you might define an enumeration called “EventType” to represent the different types of events that can be booked. The EventType enumeration could have the following literals: “Conference”, “Workshop”, “Seminar”, and “Webinar”. Then, you can use this enumeration as the type for the “eventType” attribute in the “Event” class, indicating that only the values defined in the EventType enumeration are valid for this attribute.

Resource

In a Business Process Notation (BPN), a “Resource” connection typically refers to a link between a task or activity in a process and the resource (e.g. person, equipment, material) required to complete the task.

Let’s say we have a process for creating a new product, and one of the tasks in the process is to design the packaging for the product. To complete this task, we need a graphic designer who has experience in packaging design. We can represent this resource requirement using the “Resource” connection in the BPN diagram.

The “Resource” connection links a business object to the specific resources needed to carry out a business process, while the “guide” connection links a business object to instructions or procedures that guide the execution of that process.

HTML Desktop

The HTMLdesktop-template is used to configure the content shown on a desktop on the collaboration platform on the web.

THe HTMLDesktops are inserted in the HTMLPublisher on the Personal Page tab to create a collection of available desktops in the platform.

Desktop with HTMLTiles

The content on a desktop is composed of HTMLTiles, and it is possible to specify filters for role and configuration.

The HTMLdesktop(s) are published to the web via the HTMLPublisher when they are included on the “Personal Page” tab (see below).  It is also in the publisher where it is possible to set filters for role and configuration for the desktops.

Dashboard-UI for Desktop (version 10.10)

The HTMLDesktop is also used in version 10.10 to configure the Journey based Desktops.  To achieve this the HTMLDesktop should only contain HTMLDashboards (you can insert one or more dashboards on a desktop, to enable multiple layouts, e.g. made different dashboards for different roles)

Note that to enable the desktop functionality, introduced in QualiWare 10.10, the HTMLDesktop must only contain HTMLDashboard(s). If HTMLTiles are included in a HTMLDesktop, the behaviour of the desktop will change and the desktop will not be included in the list of available desktops.

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.