Resources

MDG Technology Pattern Library: 12 Proven Patterns for Governing Your EA Repository

Talk to us

A architect reference for Sparx EA architects and architecture managers.

Introduction

MDG Technology: Sparx EA’s metamodel definition framework: is the most powerful governance mechanism in the Sparx EA platform and, in most organizations, the most underused. It determines what kinds of elements can be created, what properties they carry, what relationships are valid between them, and how validation rules are enforced. When MDG is well-configured, the repository has clear, consistent semantics that make it reliable for both human architects and AI tools. When it is poorly configured or absent, every architect works from a different mental model of what elements mean and the repository accumulates inconsistency at scale.

This pattern library collects 12 reusable governance patterns for MDG configuration. Each pattern is a design template, not a step-by-step recipe: the specific implementation details will vary depending on your architecture framework, organisational standards, and Sparx EA version. The patterns are designed to be applied selectively: not every organization needs every pattern immediately. Start with the patterns that address your most significant governance gaps.

How to use this library:

Read the Problem and Pattern Description first. If the problem resonates, read the Implementation Notes and Anti-Patterns before configuring anything. The AI Readiness Note at the end of each pattern explains why this pattern matters specifically for AI augmentation: for organizations on the path to EA GraphLink integration, this note indicates how much each pattern contributes to query reliability.

Pattern 1: Element Naming Convention Pattern

Pattern Name: Element Naming Convention Pattern

Problem it solves: Element names in the repository are inconsistent: the same application appears as “CRM,” “Salesforce CRM,” “SF-CRM,” and “Customer Relationship Management System” in different packages. AI queries that aggregate by name fail to recognize these as the same thing. Reporting across domains is unreliable. Architects waste time resolving duplicates.

Pattern Description: Define a mandatory name format for each major element stereotype, enforced through MDG-level tagged value validation and onboarding standards. The name format encodes enough semantic information to be unambiguous without being so verbose that it is impractical to use.

Examples of defined name formats:

Implementation Notes: In MDG Technology, define a tagged value on each stereotype called NamingConvention with a read-only value documenting the expected format. This acts as in-tool documentation. Supplement with a validation script (using Sparx EA’s built-in validation framework or a JScript add-in) that flags elements whose names do not match the expected pattern. For enumerated domains (e.g., a controlled list of business domain prefixes), implement the prefix as a drop-down tagged value that must be completed before the element name is finalized.

Anti-patterns to avoid:

AI Readiness Note: High impact. Naming consistency is the single most important factor in AI query accuracy for aggregation queries: “show me all applications in the Finance domain” depends on the domain being identifiable from element names or package membership. Inconsistent naming causes AI tools to miss elements or return partial, unreliable results.

Pattern 2: Ownership Assignment Pattern

Pattern Name: Ownership Assignment Pattern

Problem it solves: No one knows who is accountable for any given element in the repository. When an application is approaching end of life, there is no clear owner to notify. When an AI query returns information about an element, it cannot identify who to route the insight to. Repository elements accumulate without accountability.

Pattern Description: Define an Owner tagged value on every major element stereotype, with a structured format (name + team or email) and mandatory completion enforced through validation. Supplement with a OwnerLastReviewedDate tagged value to track whether ownership has been recently confirmed.

Implementation Notes: Add Owner as a tagged value to each stereotype in your MDG profiles. Set the completion status to indicate it is mandatory. In organizations with a person directory API, consider scripting owner validation against an external directory (so the owner field must match a known person identifier). Configure validation rules to flag elements where Owner is empty or where OwnerLastReviewedDate is more than 12 months in the past. Generate periodic ownership review reports from the validation output.

Anti-patterns to avoid:

AI Readiness Note: Medium-high impact. AI tools that surface architecture insights to executives need to be able to answer “who owns this?” when that question is part of the response. Ownership data in a tagged value is directly queryable through EA GraphLink.

Pattern 3: Lifecycle Status Pattern

Pattern Name: Lifecycle Status Pattern

Problem it solves: The repository contains a mix of current-state elements, decommissioned elements, and planned future-state elements: but nothing distinguishes them reliably. An AI query for the current application portfolio returns decommissioned applications. A roadmap query returns elements that are already live. The repository has no clear temporal semantics.

Pattern Description: Define a LifecycleStatus enumerated tagged value on every major element stereotype, with a controlled set of valid values representing the element’s position in its lifecycle. Valid values should cover the full lifecycle: Draft → Under Review → Approved → Live → Phasing Out → Retired. Supplement with PlannedLiveDate and PlannedRetirementDate tagged values where relevant.

Implementation Notes: In the MDG profile for each major stereotype, define LifecycleStatus as a drop-down (enumeration) tagged value with the permitted values listed explicitly. Set Live as the default value to prevent elements being created without a status. Supplement with a LifecycleStatusLastUpdated date field to track recency. Configure validation rules that flag elements in Retired status as candidates for archival, and elements in Phasing Out status with no PlannedRetirementDate.

Anti-patterns to avoid:

AI Readiness Note: High impact. This is one of the most queried properties for AI tools: “which applications are currently live?” is a fundamental question for portfolio analytics. Without a reliable, consistent status tag, AI tools cannot filter accurately.

Pattern 4: Domain Boundary Pattern

Pattern Name: Domain Boundary Pattern

Problem it solves: Architecture content is spread across the repository without clear domain ownership. Application elements live in project folders, technology elements in domain folders, and business elements in diagrams that are not in any structured package. Cross-domain queries are unreliable because element location does not predict element type.

Pattern Description: Define a mandatory top-level package structure representing your architecture domains, with explicit ownership and access control per domain. Every element belongs to exactly one domain package. Cross-domain references are implemented through relationships, not by placing elements in multiple packages.

Implementation Notes: Create the top-level package structure in the Sparx EA repository before any content migration. Define a DomainOwner tagged value on each domain package (mapped to a named individual). Configure package-level access control so that only the domain owner and their team have write access to that domain’s package tree. Add a PrimaryDomain tagged value to stereotypes for element types that span domains (e.g., Integration Points are typically Technology elements with Business and Application domain references) to allow domain filtering without requiring package placement in multiple locations.

Anti-patterns to avoid:

AI Readiness Note: High impact. Package hierarchy is the primary navigation structure for AI traversal queries. A clear, enforced domain structure makes domain-scoped queries fast and reliable.

Pattern 5: Relationship Type Discipline Pattern

Pattern Name: Relationship Type Discipline Pattern

Problem it solves: Architects use generic “association” or “dependency” relationships for everything: because they are easy to create: rather than using the semantically specific relationship types available in ArchiMate or the organization’s relationship taxonomy. AI tools traversing relationships cannot distinguish between a realisation link, a dependency, a data flow, and an organisational assignment when all four are modeled as generic associations.

Pattern Description: Define a permitted relationship matrix for each combination of element stereotypes: specifying which connector types are valid between which element types: and enforce it through validation. Provide architects with clear guidance (embedded in MDG and in onboarding) on which relationship to use in which situation.

Implementation Notes: In MDG Technology, use the Relationship Rules configuration to restrict which connector types are valid between specific stereotypes. For example: Application stereotype → Application stereotype permits CompositionRelationship, AssociationRelationship (for peer relationships), and RealisationRelationship (for capability realisation), but not DependencyRelationship (which should be used for functional dependency only). Configure validation rules that flag relationship types which fall outside the permitted matrix. Maintain a relationship glossary as part of your MDG documentation.

Anti-patterns to avoid:

AI Readiness Note: high impact. Relationship type discipline is what makes AI traversal queries semantically meaningful. “Show me which applications realize the Payments capability” requires that realisation relationships are typed consistently. Without this pattern, AI tools cannot distinguish between different types of inter-element connection.

Pattern 6: Description Completeness Pattern

Pattern Name: Description Completeness Pattern

Problem it solves: Most elements in the repository have no description. An architect can look at a diagram and understand what an element represents from context. An AI tool: or a new team member: cannot. Queries that ask “what does this system do?” return nothing, or return the element name repeated, because no description exists.

Pattern Description: Define a mandatory Description field requirement for all elements above a defined complexity threshold (typically all elements that are not purely structural: leaf nodes in the package hierarchy, for example, rather than container packages). Enforce through validation, and define a minimum quality standard for descriptions (not just “not blank”).

Implementation Notes: In MDG Technology, mark the Notes field (Sparx EA’s native description field) as required for the stereotypes where description is mandatory. Supplement with a validation rule that flags elements where the Notes field contains fewer than 30 characters (to prevent architects entering “TBC” or a single word to satisfy the mandatory field check). For high-value element types: Applications, Capabilities, Technology Components: consider adding a structured description tagged value with explicit fields (Purpose, Key Functions, Consumers, Dependencies) in addition to the free-text Notes field.

Anti-patterns to avoid:

AI Readiness Note: High impact. Descriptions are the primary source of rich, queryable context for AI tools. An AI asked “which applications support international payments?” needs descriptions to find the answer if the element name does not contain the term “payments.”

Pattern 7: Element Classification Pattern

Pattern Name: Element Classification Pattern

Problem it solves: All elements in the repository are treated equally regardless of their business significance. A mission-critical core banking platform receives the same governance attention as a small departmental utility application. Governance resources are spread uniformly rather than concentrated on the elements that matter most.

Pattern Description: Define a tiered classification system: Strategic / Operational / Technical, or Mission Critical / Business Enabling / Supporting: with different governance requirements per tier. Strategic/Mission Critical elements require stricter property completion, more frequent review, and more complete relationship coverage than Supporting elements.

Implementation Notes: Add a Classification enumerated tagged value to major element stereotypes with the tier values as options. Define the governance requirements for each tier in your MDG documentation and in validation rules: Strategic elements must have an Owner, a LifecycleStatus, a Description, a PlannedRetirementDate (if Phasing Out), and at least two significant relationship connections. Operational elements must have Owner and LifecycleStatus. Supporting elements require only LifecycleStatus. Validation flags non-compliance per tier rather than applying a uniform standard.

Anti-patterns to avoid:

AI Readiness Note: Medium impact. Classification enables AI tools to answer prioritisation questions: “which of our applications are mission-critical?”: directly from repository data. It also improves the relevance of AI query results by allowing queries to be scoped to a classification tier.

Pattern 8: Technology Stack Tag Pattern

Pattern Name: Technology Stack Tag Pattern

Problem it solves: Technology attributes: vendor, product name, version, cloud-native status, and end-of-support date: are either absent from the repository or captured inconsistently in free-text fields that AI tools and BI dashboards cannot aggregate reliably. Technology lifecycle reporting requires manual data extraction and reconciliation.

Pattern Description: Define a standard set of technology-specific tagged values for all Technology-domain element stereotypes, covering the key attributes required for lifecycle management and AI-augmented portfolio analytics.

Implementation Notes: For Technology Component and Application stereotypes (where technology attributes are relevant), add the following tagged values to the MDG profile:

Configure validation rules that flag Technology elements where EndOfSupportDate is within 12 months (requiring a lifecycle decision) and elements where LastVersionReviewDate is more than 12 months in the past.

Anti-patterns to avoid:

AI Readiness Note: High impact. Technology lifecycle queries are among the most common executive-facing questions that AI augmentation enables. This pattern is the prerequisite for AI answers to “which applications are approaching end of life?” and “what percentage of our technology estate is cloud-native?”

Pattern 9: Integration Point Pattern

Pattern Name: Integration Point Pattern

Problem it solves: Integration points: the interfaces through which systems exchange data: are modeled inconsistently or not at all. Some architects draw them as lines, some as components, some as tagged values. AI queries about system interdependencies and data flows return incomplete or misleading results because the integration layer is not consistently represented.

Pattern Description: Define a dedicated IntegrationPoint stereotype (or equivalent in your architecture framework) for modeling the interfaces between systems. Every significant data exchange between applications or between applications and external parties is represented as an Integration Point element with standardized properties.

Implementation Notes: Define an IntegrationPoint stereotype in your Application Architecture MDG profile with the following tagged values:

Require that Integration Point elements be connected to both the upstream and downstream application elements via directed association relationships (indicating data flow direction).

Anti-patterns to avoid:

AI Readiness Note: high impact. Integration point modeling is the foundation for AI answers to dependency and impact analysis questions: “what systems would be affected if Application X was decommissioned?” requires consistently modeled integration points to answer accurately.

Pattern 10: Capability-to-Application Traceability Pattern

Pattern Name: Capability-to-Application Traceability Pattern

Problem it solves: The repository has a capability model and an application portfolio, but they are not connected. The architecture team cannot answer “which applications support the Payments capability?” without manual analysis. AI tools cannot traverse from business capability to application estate. The strategic value of the repository: connecting business intent to technology delivery: is not realized.

Pattern Description: Enforce mandatory realisation relationships from Application (and Technology) elements to the Business Capabilities they support. Implement validation rules that flag applications without capability realisation links as governance exceptions. Define the capability model as the primary navigational anchor for cross-domain queries.

Implementation Notes: Define capability realisation as a required relationship: every Application element must have at least one outgoing RealisationRelationship to a Business Capability element (or an explicit tagged value exemption for supporting applications with no direct capability alignment). Add a CapabilityAlignment tagged value to Application stereotypes that accepts a free-text capability reference for cases where the capability model does not yet include the relevant capability.

Configure a validation rule that flags: (1) Applications with no capability realisation link and no CapabilityAlignment tagged value; (2) Capabilities with no realizing application (potential model gap or decommissioned capability).

Anti-patterns to avoid:

AI Readiness Note: high impact. Capability-to-application traceability is the most commonly queried cross-domain relationship in EA analytics. Without this pattern, AI tools cannot answer any question that spans business and technology domains: which is most of the questions executives actually want to ask.

Pattern 11: Requirements Traceability Pattern

Pattern Name: Requirements Traceability Pattern

Problem it solves: Requirements exist in the EA repository but are not connected to the architecture elements that realize them. Alternatively, requirements are not in the EA repository at all. When a project decision is reviewed, there is no traceable link from the requirement that drove the decision to the architecture element that implements it. Regulatory compliance mapping is manual and fragile.

Pattern Description: Define a structured Requirements stereotype with mandatory traceability tagged values, and enforce bidirectional traceability between Requirements and the architecture elements that realize them. Connect requirements to their source (business unit, regulation, project) and their realizing elements (capabilities, applications, technology components).

Implementation Notes: Define a Requirement stereotype with the following tagged values:

Enforce realisation links: every Requirement in Implemented status must have at least one outgoing realisation link to an architecture element. Configure validation to flag implemented requirements with no realisation link, and to flag architecture elements that are realisation targets of requirements (indicating they carry regulatory or compliance significance).

Anti-patterns to avoid:

AI Readiness Note: Medium-high impact. Requirements traceability enables AI tools to answer compliance-related questions: “which applications are implicated in our DORA compliance scope?”: accurately and from first principles rather than from potentially stale compliance registers.

Pattern 12: Automated Validation Pattern

Pattern Name: Automated Validation Pattern

Problem it solves: Governance patterns 1 through 11 are effective only if they are actually applied. Manual governance processes: peer review, periodic audits: catch problems slowly and incompletely. Without automated validation, governance debt accumulates between review cycles and the cost of remediation grows.

Pattern Description: Build a comprehensive automated validation configuration in Sparx EA that checks all governance patterns on demand, produces a compliance report, and integrates with Kernaro Assist (in-EA, Beta) for AI-assisted governance review. Automated validation is the enforcement mechanism that makes the entire pattern library sustainable.

Implementation Notes: Sparx EA’s built-in validation framework supports custom validation rules defined through script or configuration. Implement validation rules for each of the preceding 11 patterns, organized into a validation suite that can be run on demand or on a schedule.

Structure the validation suite as: (1) Critical rules: violations that indicate fundamental governance failure (missing owner, missing lifecycle status, relationship type violations on core elements); (2) Warning rules: violations that should be addressed but are not critical (descriptions below minimum length, review dates overdue); (3) Advisory rules: patterns flagging elements for review (classifications not refreshed in 12 months, integration points with missing protocol tags).

Use the validation output to generate a governance health score for each architecture domain: a simple percentage of elements passing all critical and warning rules. Track this score over time to show governance improvement.

Kernaro Assist integration: Kernaro Assist (currently in Beta) supports AI-augmented governance review within Sparx EA. Once available, configure Assist to use your MDG configuration and validation output as context for governance advisory queries: enabling architects to ask “what are the governance gaps in the Application Architecture package?” and receive a structured, current response without manually running the validation suite.

Anti-patterns to avoid:

AI Readiness Note: Foundational across all dimensions. Automated validation is the mechanism that keeps every other pattern working. Without it, governance patterns degrade over time as the practice evolves and the enforcement mechanism is absent. With it, AI query reliability is systematically maintained rather than dependent on individual architect discipline.

Closing Note

This pattern library is a starting point. No organization deploys all 12 patterns simultaneously: the right approach is to prioritize the patterns that address your most significant governance gaps and implement them in sequence, with validation and measurement at each stage.

If you are unsure which patterns to prioritize, the AI Readiness Self-Assessment (available at sparxservices.com) gives you a structured score across five dimensions that maps directly to the patterns in this library.

Sparx Services’ Amplify offering delivers MDG governance uplift as a structured engagement: covering pattern selection, MDG configuration, validation setup, and team enablement. If your organization needs expert support to implement these patterns at scale, that is the right starting point.

Learn more at sparxservices.com/amplify

Sparx Services: Enterprise Architecture Platform Specialists

Ready to make your EA investment work harder?

Talk to a Sparx Services architect about where your organization is on the journey and what the next stage looks like.

Talk to us See the journey