Archives: Templates

A sequence of activities that create an overall result for a customer, stakeholder, or end user.

A value stream describes how an enterprise organizes its activities to create value. A key principle of value streams is that value is always defined from the perspective of the stakeholder – the customer, end user, or recipient of the product, service, or deliverable produced by the work.

Value streams are typically realized by business processes and possibly other core behavior elements. The stages in a value stream provide a framework for organizing and defining business processes, but different parts of the organization may have their own implementations of business processes that realize the same value stream stage. Conversely, one business process may realize multiple stages in a value stream.

It is recommended that the name of a value stream be expressed using a verb-noun construct in the active tense; e.g., “Acquire Insurance Product”.

The role of an individual, team, or organization (or classes thereof) that represents their interests in the effects of the architecture. In order to direct efforts to their interests and concerns, stakeholders change, set, and emphasize goals. Stakeholders may also influence each other. Examples of stakeholders are executives and key managers in an organization, the board of directors, shareholders, customers, business and application architects, and external partners and regulators. The name of a stakeholder should preferably be a noun.

A limitation on aspects of the architecture, its implementation, or its
realization. In contrast to a requirement, a constraint does not prescribe some intended functionality of the system to be realized, but imposes a restriction on the way it operates or may be realized. This may be a restriction on the implementation of the system (e.g., specific technology that is to be used), a restriction on the implementation process (e.g., time or budget constraints), or a restriction on the functioning of the system (e.g., legal constraints). The name of a constraint should be easily understood and is often a short sentence.

An application state change. Application functions and other application behavior may be triggered or interrupted by an application event. Also, application behavior may raise
events that trigger other application behavior. Unlike processes, functions, and interactions, an event is instantaneous; it does not have duration. Events may originate from the environment of the organization (e.g., from an external application), but also internal events may occur generated by, for example, other applications within the organization. The name of an application event should preferably be a verb in the perfect tense; e.g., “claim received”

Introduction to KnowledgeScope

The KnowledgeScope template is an innovative QualiWare tool designed to configure the Generative QualiAI. It is structured to streamline the process of creating intelligent and context-aware response diagrams. By leveraging the KnowledgeScope, businesses can harness the power of AI to generate diagrams that are not only accurate but also tailored to the specific nuances of their operations.

Key Features:

• Configurable Sections: The KnowledgeScope has configurable sections, such as AIKnowledgeScope, Context, Prompting, and Response, which allow you to determine the content of the diagrams created with the AI.
• AI-Driven Diagram Generation: Leverages QualiWare’s AI capabilities to produce diagrams informed by the context and prompting provided.

Section Details

KnowledgeScope

This primary section offers a succinct overview of the template’s purpose, along with a business definition and a selection of example diagrams for reference.

• Short Description: Concisely articulates the purpose of the KnowledgeScope.
• Business Definition: Provides a broad context of the business or a specific business space, if detailed in the definition.
• Example Diagram List: A curated list (recommended to be 1 or 2) of diagrams from your repository which exemplify the desired outcome, aiding the AI in context understanding.

Context

The Context section is the backbone of the template, influencing the AI’s understanding and generation process.

• Context Dropdown Menu: Offers four methods to establish context for content generation:
  • Current Selected Object: Targets the object currently selected in the web-modeler.
  • Current Diagram: Utilizes the open diagram in the current tab.
  • Select from List: Employs the selected context from the “Link Context” function.
  • Context Undefined: Provides flexibility for open context definition via text input or object selection.
• Context Templates Text Field: Lists available templates serving as potential context sources for the KnowledgeScope.
• Knowledge Structure: Comprises two subfields—Ontology and Root Definition
  • Ontology: This field is dedicated to defining the ontology that governs the data to be accessed from the Context Templates. Users should link to a pre-defined ontology, using the template “OntologyDiagram:owl” in QualiWare. This format helps the AI understand what data is relevant and should be considered during the generation process. For example, if using the BusinessProcess template, the Ontology field should point to an ontology diagram that outlines the necessary data to be accessed from the BusinessProcess context.
  • Ontology Example: ‘BusinessProcess’ The accompanying image illustrates an ontology with ‘BusinessProcess’ as the root. Use this as a guide to link your context templates to your ontology. Proper linkage ensures that AI-generated content aligns with your business framework.
  • Root Definition: Root definition is crucial as it marks the starting point for the AI’s data extraction from the ontology. When multiple context templates are used, there must be a corresponding root for each, and all roots should be contained within the same diagram. This ensures that the AI has a clear entry point to begin its contextual data interpretation for each template. The roots collectively form a map of data points that the AI uses to extract information relevant to the generation of the new content.

Prompting

This section allows users to input additional knowledge characteristics and set the randomness level of AI responses.

• Additional Knowledge Characteristics: This section directs the AI in creating diagrams that align with specific organizational standards. For clarity and precision, input concise directives. For example:
  • Diagram Initiation: “Begin and end WorkFlowDiagrams with a Business Event.”
  • Naming Conventions: “Use concise, descriptive naming for all symbols.”

  These instructions shape the AI’s output, ensuring it meets your defined criteria and maintains consistency with your organization’s practices.

• Randomness (Temperature): A dropdown to adjust the AI’s creativity level, with a recommended default of 0.3 for diagram creation.
• Knowledge Prompts: A collection of pre-defined AI query templates, that you have created, used to standardize rules or commands across various KnowledgeScopes.

Template Naming Conventions

Proper naming of templates is critical for ensuring seamless functionality within the KnowledgeScope. Adhering to QualiWare’s naming conventions allows the AI to accurately recognize and apply the correct templates during diagram generation. Here’s what to keep in mind:

• Exact Match Requirement: Name all templates precisely as they appear in QualiWare, with correct capitalization and spacing. For example, use “WorkFlowDiagram,” not “workflow diagram” or “Work Flow Diagram.”
• Consistency Is Key: Uniform naming across all sections of KnowledgeScope ensures that the AI correctly interprets and utilizes the templates.
• Verification: Double-check template names for typos or discrepancies before finalizing the KnowledgeScope configuration.

Accurate template naming enables the AI to understand and execute your instructions effectively, ensuring the generated diagrams meet your exact specifications.

Response

In 10.10, the Response section does more than describe the diagram you want. It can also
orchestrate how the AI structures, creates, and links objects by using a Response Ontology.
This makes AI outputs directly actionable in both the Web-Modeler and outside the Web-Modeler.

Response Basics

• Response Type: The overall format to return (e.g., “Diagram with objects” or “Object edits”).
• Response Diagram Type: The exact diagram template to use (e.g., WorkFlowDiagram). Use QualiWare’s exact template names.
• Response Symbols & Connection Types: Which symbol templates and connection templates are allowed in the response.
• Response Diagram Layout: The preferred presentation/layout rules for the generated diagram.
• Response Template Descriptions: Short descriptions that clarify intent or lesser-known templates.
• Response Ontology

A Response Ontology defines the appearance and structure of the AI output. It tells the AI
what the root object is, which attributes it may populate, which linked objects may be created,
and which connection templates must be used between them. In other words, it is the contract the AI must follow when creating or editing content.

When do I need a Response Ontology?

• Not required for simple, single-object attribute edits
  (e.g., update BusinessProcess.Description).
• Required whenever the response creates or links related objects
  (e.g., “Add a new Owner to BusinessProcess”). The ontology specifies which attributes are linkable,
  the exact connection names, and which templates may be linked.

How to model a Response Ontology

1. Choose the response root. Pick the root class the AI should build around
   (e.g., BusinessProcess).
2. Declare allowed symbols. Add the exact QualiWare templates the AI may create/edit
   (e.g., Position, Capability, Risk, Person).
3. Add labeled connections. Use connection labels to state the attribute/relationship name on the root or child
   (e.g., BusinessProcess — OwnedBy → Position, BusinessProcess — DeliveredBy→ Capability,
   Risk — Concerns → BusinessProcess).
   Include the exact connection template to use.
4. Specify rules. For each Template, define:
   • Required attributes the AI must provide (e.g., Name, Description).
5. Validate naming. All template and connection names must be the exact QualiWare names (capitalization/spacing included).

Tip: The Response Ontology describes the output structure. It is separate from the Context Ontology
(which describes the input data to read). They can mirror each other but don’t have to.

Runtime behavior (10.10)

• Inside the Web-Modeler: When you ask the AI to create or link objects, the Response Ontology
  drives what is created and how it is linked in the generated diagram.
• Outside the Web-Modeler: The same ontology governs edits and new links from the diagram view.
• Spreadsheet preview: Before applying changes, you’ll see a preview listing all objects to be created/edited
  and how they will be linked. This is always shown outside the Web-Modeler, and shown inside when editing/adding links.

Example: Add an Owner to a BusinessProcess

Input: “Add a new Owner to the BusinessProcess ‘Perform Overhaul’ named ‘Process Owner A’.”

• Response Ontology fragment: BusinessProcess — Owner → Position
  Position requires Name;
• Result: AI creates Position: “Process Owner A” and links it to
  BusinessProcess: “Perform Overhaul” via the Owner relationship, following the declared connection template.

Utilization Guide

This template is structured for ease of use, guiding users through a step-by-step configuration for the Generative QualiAI. For precise diagram generation, it is recommended to provide detailed and accurate information in each section, aligning closely with your business’s operational context and requirements.

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 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.