Archives: Templates

Templates and model types in the QualiWare platform.

Value Stream Viewpoint : Archimate

Purpose:
The primary purpose of the ValueStreamViewpoint is to present a coherent visual representation that focuses on how value is created, progressed, and delivered in the context of the enterprise’s strategy. It provides insights into the motivations behind strategic decisions and reveals the capabilities that underpin these value creation activities.

Core Concerns:

Stakeholder Alignment: How do the strategic efforts of the organization align with the needs, desires, and expectations of its key stakeholders? What outcomes are stakeholders expecting, and how does the value stream aim to deliver on these expectations?

Strategic Capabilities: What are the foundational abilities or capacities of the organization that enable the value creation process? How do these capabilities support or interact with the various stages of the value stream?

Value Creation and Flow: How is value produced, enhanced, and delivered across the enterprise? This concerns the sequence of activities that cumulatively produce the desired outcomes for stakeholders.

Organizational Context: Given the composite elements, this viewpoint may also touch upon how the value streams and capabilities are grouped, categorized, or located within the broader organizational context.

 

Example:

the example above shows a ValueStreamViewpoint for an insurance company, where each stage in the value stream is served by a number of capabilities. Between these stages, we see the ValueFlows with associated BusinessObjects & Values, and at the end the Outcome that this value stream realizes for a particular stakeholder.

In summary, the ValueStreamViewpoint provides a strategic lens, offering stakeholders a visual narrative of how value is created, based on the enterprise’s capabilities, and how this creation aligns with the motivations and desired outcomes of its stakeholders. It gives an abstracted yet holistic view, allowing for strategic decisions, analysis, and alignment checks. The composite elements further provide a way to understand the enterprise’s structuring or geographical distribution of these strategic components.

Container:EDGY

Container serves as an essential structure, encapsulating and categorizing various elements. Think of it as a grouping tool, collecting related entities to bring clarity and structure to the broader design landscape.

Function: The Container operates much like a folder or bin, collecting and segmenting different elements, thus simplifying the overall structure and making it more navigable.

Applications:

  • Organizational Clarity: By bundling related entities, it aids in understanding and visualizing relationships within the enterprise.
  • Efficient Navigation: With elements neatly grouped, users can swiftly pinpoint and access what they need.
  • Enhanced Management: Grouping similar elements under the Container umbrella streamlines management tasks.

In a nutshell, the Container is the backbone of organization in EDGY modeling, ensuring elements are systematically categorized, easy to access, and managed efficiently.

 

Tree:EDGY

Tree signifies that an element is a component of another element of the same type. This highlights hierarchical relationships, where a dominant element encompasses others as its constituent parts.

Examples:

  • Organisations manifesting as a tree of roles, teams, and departments.
  • Capabilities branching into various sub-capabilities.
  • Product portfolios dividing into categories, components, and individual products.
  • Brand portfolios distinguishing between corporate, product, and special edition brands.
  • Goals arranged hierarchically from strategic to tactical and operational outcomes.

Applications: The ‘Tree’ structure aids in:

  • Breaking down an element into its nuanced sub-elements.
  • Denoting that a smaller entity forms part of a larger one.

In a nutshell, the ‘Tree’ concept in EDGY represents structured hierarchy and part-whole relationships within an enterprise.

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

Flow:EDGY

Flow signifies how one element influences another by transmitting objects. It’s the backbone of an enterprise, highlighting how interconnected parts collectively produce results unattainable individually.

Examples:

  • Teams relying on information from others.
  • Monetary transactions between businesses.
  • Data shifts between software systems.
  • Movement in supply chains.
  • The energy in team collaborations.
  • Public enterprise goals tied to budgets.

Applications: ‘Flow’ aids in:

  • Facilitating communication.
  • Optimizing processes.
  • Mapping task sequences.
  • Identifying inter-organizational flows.

In essence, ‘Flow’ is the dynamic force driving collaborative efficiency in an enterprise.

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

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.