TestModelUAKI Knowledge Graph Q&A Test Suite
This document contains a curated benchmark of realistic Power-User Q&As based on the diagrams and model entities in the local Neo4j database imported from repository TestModelUAKI.
These questions represent how Enterprise Architects, Solution Architects, Business Process Owners, Compliance Officers, and DevOps Engineers query the model without referencing graph-specific jargon.
Table of Contents
- Business Process Management & Workflows
- Enterprise Architecture & Legal Compliance
- Application & Information Architecture
- Software Architecture & Technical Design
- Deployment, Infrastructure & DevOps
- Organization & Stakeholder Management
1. Business Process Management (BPM) & Workflows
Q1.1: What are the main steps and decision gates in the Model QA workflow?
- Persona: Quality Assurance Lead / Process Manager
- Source Diagram:
Model QA Process(inno-6670,ProcessDiagram_Analytic) - Question: "What are the sequential steps in the Model QA process, and who formulates and approves work orders?"
- Ground Truth Answer: The Model QA process follows an analytical BPMN workflow consisting of three primary activities:
- Formulate Work Order: The QA workflow initiates with defining the task parameters and requirements.
- Perform QA: The model changes or deliverables are reviewed against quality standards.
- Accept Plan / Decision Gate: An evaluation gate that approves the execution plan before final release.
- Key Entities:
Formulate Work Order,Perform QA,Accept Plan.
Q1.2: How are internal and external business processes linked to business services?
- Persona: Business Architect
- Source Diagram:
Geschäftsfunktionsübersicht(inno-6173,DiagramEAEnterpriseArchitecture) - Question: "Which business functions realize our customer-facing services, and how are internal versus external processes structured?"
- Ground Truth Answer: In the Business Function Overview:
- Business Services (
Dienstleistung) are realized directly by core Business Functions (Geschäftsfunktion). - Core Business Functions are composed of Internal Business Processes (
"interner" Geschäftsprozess) for backend handling and coordinated with External Business Processes ("externer" Geschäftsprozess) triggered by external organizational roles. - Key Entities:
Dienstleistung_GFÜ,Geschäftsfunktion_GFÜ,"interner" Geschäftsprozess_GFÜ,"externer" Geschäftsprozess_GFÜ.
2. Enterprise Architecture & Legal Compliance (EA / Governance)
Q2.1: How are legal regulations mapped to architecture requirements and business processes?
- Persona: Compliance & Legal Governance Officer
- Source Diagram:
Rechtsgrundlagenverzeichnis(inno-3908,DiagramEAEnterpriseArchitecture) - Question: "How does the system ensure that enterprise requirements trace back to specific laws, and which analytical processes implement them?"
- Ground Truth Answer: The Legal Directory maps compliance from statutory laws to execution:
- Laws (
Gesetz_RGV, e.g. based on federal regulations like RVOG / RVOV) are associated with Enterprise Requirements (Enterprise Requirement_RGV). - These Enterprise Requirements are realized by executable Analytical BPMN Processes (
BPMN Process (analytic)_RGV), establishing end-to-end traceability from law $\rightarrow$ requirement $\rightarrow$ process. - Key Entities:
Gesetz_RGV,Enterprise Requirement_RGV,BPMN Process (analytic)_RGV.
Q2.2: How are business capabilities structured and derived from goals and standards?
- Persona: Chief Enterprise Architect
- Source Diagram:
Fähigkeitslandkarte(inno-2984,DiagramEAEnterpriseArchitecture) - Question: "How are our strategic capabilities broken down, and what is the difference between standard capabilities and legally mandated capabilities?"
- Ground Truth Answer: The Capability Map structures capabilities into a 2-level hierarchy:
- Capability Domains (
Fähigkeitsdomäne) aggregate Refined Capability Domains (präzisierte Fähigkeitsdomäne). - Refined domains aggregate specific capabilities split into:
- Statutory Capabilities (
Geschäftsfähigkeit aus Gesetz) driven by legal requirements. - Standard Capabilities (
Geschäftsfähigkeit aus Standard) driven by industry and IT standards.
- Statutory Capabilities (
- Strategic goals (
Ziel/präzisiertes Ziel) influence and justify the existence of these capabilities. - Key Entities:
Fähigkeitsdomäne_FLK,präzisierte Fähigkeitsdomäne_FLK,Geschäftsfähigkeit aus Gesetz_FLK,Geschäftsfähigkeit aus Standard_FLK.
3. Application & Information Architecture
Q3.1: How are information systems (IS Services) structured and exposed to business functions?
- Persona: Application Portfolio Manager
- Source Diagram:
IS-Servicelandkarte(inno-8708,DiagramEAEnterpriseArchitecture) - Question: "Which application modules expose IS Services, and how do they serve business functions?"
- Ground Truth Answer: In the IS Service Landscape:
- Fachanwendungen (core business applications) realize concrete IS-Services.
- IS-Services are composed hierarchically and expose technical Interfaces.
- These IS-Services serve (
ServingBusiness_ToFunction) specific Business Functions (Geschäftsfunktion_ISSL), allowing applications to exchange data flows across boundaries. - Key Entities:
Fachanwendungs_ISSL,IS-Service_ISSL,Geschäftsfunktion_ISSL,Interface_ISSL.
Q3.2: Which business processes have Read and Write access to our business objects?
- Persona: Data Governance Lead
- Source Diagram:
Informationsverwendungsmatrix(inno-8575,DiagramEAEnterpriseArchitecture) - Question: "Where can I find the CRUD access rights showing which business processes create or read business information objects?"
- Ground Truth Answer: The Information Usage Matrix defines:
- Information groups (
Gruppe Geschäftsinformationen) and discrete objects (Geschäftsinformation). - Granular access relationships:
AccessBusiness_ToBusinessObjectWriteFromBusiness: Identifies processes that generate/write data.AccessBusiness_ToBusinessObjectReadWrite: Identifies processes that query and mutate existing business entities during execution.
- Key Entities:
Geschäftsinformation_IVM,Geschäftsprozess A_IVM,Gruppe Geschäftsinformationen_IVM.
Q3.3: How are Domain-Driven Design (DDD) Bounded Contexts decomposed?
- Persona: Lead Software Architect
- Source Diagram:
Konzeptionelle Bounded Context Landkarte(inno-11034,DiagramEAEnterpriseArchitecture) - Question: "What is the structural hierarchy of our conceptual Bounded Contexts and which root IS-Services belong to them?"
- Ground Truth Answer: The Conceptual Bounded Context Map defines:
- Nested and specialized Bounded Contexts (
Bounded Context_KBCLK). - Direct composition of IS Functions (
IS Function_KBCLK) and Root IS-Services (IS-Service (root)_KBCLK) encapsulated within each bounded context. - Key Entities:
Bounded Context_KBCLK,IS-Service (root)_KBCLK,IS Function_KBCLK.
4. Software Architecture & Technical Design
Q4.1: How does the application isolate external reference data access?
- Persona: Senior Backend Engineer
- Source Diagram:
Komponentendiagramm Detail(inno-2418,StructureDiagramblackBoxLandscape) - Question: "How does our persistence layer communicate with external reference data, and what proxy interfaces are in place?"
- Ground Truth Answer: In the Detailed Component Diagram:
- Application persistence (
Application-related Persistence) accesses reference data through a dedicated Reference Data Proxy (RefData Proxy_KDD). - The proxy realizes the read-only interface
SSt-01 Referenzdaten lesendand exposesSSt-03 Referenzdaten Proxyto decouple internal business logic from external data providers. - Key Entities:
Application-related Persistance_KDD,RefData Proxy_KDD,SSt-01 Referenzdaten lesend_KDD,Sst-03 Referenzdaten Proxy_KDD.
5. Deployment, Infrastructure & DevOps
Q5.1: How is the containerized microservices stack deployed on Kubernetes?
- Persona: DevOps / Cloud Infrastructure Architect
- Source Diagram:
Logisches Deploymentdiagramm(inno-420,DiagramEAEnterpriseArchitecture) - Question: "What is the deployment topology for our Docker containers, and how do they connect to logical networks, ingress, and data storage?"
- Ground Truth Answer:
In the Logical Deployment Diagram (
inno-420): - Kubernetes Cluster aggregates dedicated Kubernetes Namespaces.
- Docker Containers running Business Services are deployed inside these namespaces behind an Ingress Controller.
- Containers connect to:
- Logical Networks linked to specific Availability Zones / Datacenters (
Rechenzentrum/Availability Zone). - Technical Standard Services: Message brokers and search clusters (e.g. Apache Kafka, Elasticsearch).
- Shared Services: Identity & SSO portal (
Eingekaufte Standardkomponente). - Database Schemas aggregated inside Virtual Databases (
Virtuelle Datenbank).
- Logical Networks linked to specific Availability Zones / Datacenters (
- Key Entities:
Kubernetes Cluster_LDD,Kubernetes Namespace_LDD,Docker Container_LDD,Business Service_LDD,Ingress Controller_LDD,Technische Standardkomponente (z.B. Kafka, Elasticsearch)_LDD.
Q5.2: How is network segmentation and firewall isolation structured between physical and virtual tiers?
- Persona: Network & Security Architect
- Source Diagram:
Netzwerkdiagramm(inno-3767,DiagramEAEnterpriseArchitecture) - Question: "How do our physical firewalls interface with virtual firewalls and logical network devices?"
- Ground Truth Answer:
The Network Diagram (
inno-3767) specifies: - Physical Firewalls connected directly to physical networks.
- Logical Firewalls aggregating Virtual Firewalls to provide micro-segmentation for software-defined networks.
- Logical Network Devices aggregating Virtual Network Devices to route inter-tier traffic.
- Key Entities:
Physical Firewall_ND,Virtual Firewall_ND,Logical Firewall_ND,Logical Network Device_ND,Virtual Network Device_ND.
6. Organization & Stakeholder Management
Q6.1: Who are the accountable stakeholders and IT architects for our architecture domains?
- Persona: Project Portfolio Manager / Enterprise Architect
- Source Diagram:
Domänenlandkarte(inno-8675,DiagramEAEnterpriseArchitecture) - Question: "Who is designated as Accountable Sponsor versus Consulted Reviewer for the architecture domains?"
- Ground Truth Answer:
The Domain Landscape (
inno-8675) models RACI governance: - Project Sponsors (
Auftraggeber (Accountable)) have primary accountability. - IT Architects (
IT Architekt) and Enterprise Architects (UA Architekt) act as technical leads and reviewers (Reviewer (Consulted)). - Key Entities:
Auftraggeber (Accountable)_DomLK,IT Architekt_DomLK,UA Architekt_DomLK,Reviewer (Consulted)_DomLK.
Q6.2: How are process roles and deputies assigned within organizational units?
- Persona: HR & Operations Lead
- Source Diagram:
Aufbauorganisationslandkarte(inno-2809,DiagramEAEnterpriseArchitecture) - Question: "How are process roles mapped to organizational units, and who acts as designated deputy for each role?"
- Ground Truth Answer:
The Organizational Structure Map (
inno-2809) defines: - Organizational Units (
Organisationseinheit) composed within the parent organization. - Process Roles (
Prozessrolle) serving specific units. - Deputy Assignments (
Person (Stellvertreter)) linking specific individuals to roles as backup representatives. - Key Entities:
Organisationseinheit_AOL,Organisation_AOL,Prozessrolle_AOL,Person (Stellvertreter)_AOL.