MDG Technology patterns for common EA use cases

Your MDG Technology is the contract your metamodel enforces. It decides what your model is allowed to represent, how elements relate to one another, and which quality rules hold the whole thing together. Get that contract right and the model becomes navigable, reportable, and governable at scale. Get it loose and every downstream view inherits the ambiguity.

The short version: this is a reference guide to five MDG patterns we reach for again and again — capability maps, application portfolios, integration maps, process decomposition, and technology lifecycle. Each one gives you the element types to define, the tagged values that matter (with exact names and data types), the relationships to enforce, and the Quick Linker configuration that makes the pattern usable day to day. Copy them, adapt them to your standards, and ship them.

None of this is academic. A precise metamodel is the difference between an architecture anyone can query and a pile of diagrams only their author understands. The patterns below have been pressure-tested on real Sparx EA repositories — see why we build on Sparx EA for the platform reasoning behind them.

1. Capability Map (TOGAF-aligned)

What it does: represents a capability hierarchy with decomposition, linked to the business processes, applications, and organizational units that realize and own each capability. A standard TOGAF approach, structured so the graph reads cleanly for both stakeholder reporting and automated traversal.

Element types

• Capability (stereotyped Business Function or custom)
• BusinessProcess (stereotyped Activity)
• ApplicationComponent (realizes capabilities)
• OrganizationalUnit (owns capabilities)

Key tagged values

Name	Type	Purpose
strategic_importance	Enumeration: Strategic, Important, Operational, Legacy	Prioritizes capabilities for investment
maturity_level	Enumeration: Nascent, Repeatable, Defined, Managed, Optimized	Maturity model alignment
owner_name	String	Direct ownership reference (queryable)
owner_unit	Reference (to OrganizationalUnit)	Organizational context
value_driver	String	Links to business outcomes
annual_investment	String	Budget context (free-form; exact figures optional)

Relationships

• Capability decomposes to Capability (stereotype: decomposed_by)
• Capability realizes BusinessProcess (stereotype: realised_by_process)
• ApplicationComponent realizes Capability (stereotype: realises_capability)
• OrganizationalUnit owns Capability (stereotype: capability_owner)

Quick Linker config

• Source: Capability
• Target: ApplicationComponent, BusinessProcess, OrganizationalUnit
• Direction: Outbound (shows realizing apps, processes, owners)
• Display: Show tagged values for strategic_importance and maturity_level in tooltips

Why this works: stakeholders grasp it on sight, and the explicit relationships let a reader — or a reporting query — traverse the capability graph to answer "what apps support this capability?" and "who owns this?" without guessing. Because the tagged values carry the strategic and maturity signal directly, the same structure feeds gap analysis and stakeholder reporting straight from the model.

2. Application Portfolio (with lifecycle attributes)

What it does: captures the application landscape with vendor, version, lifecycle stage, and business criticality, linked to the infrastructure it runs on, the capabilities it realizes, and the data it touches. This is the backbone of any serious application portfolio management effort.

Element types

• ApplicationComponent (stereotype: Application)
• Node (infrastructure; stereotype: HostingEnvironment)
• DataObject (consumed/produced data)
• Capability (realized by application)

Key tagged values

Name	Type	Purpose
vendor_name	String	Application vendor
vendor_product	String	Product name or SKU
current_version	String	Current deployed version
lifecycle_stage	Enumeration: Strategic, Stable, Sunset, Retired	End-of-life planning
end_of_life_date	Date (YYYY-MM-DD)	Support cutoff date
business_criticality	Enumeration: Critical, High, Medium, Low	Downtime impact
owner_team	String	Support/operations owner
annual_cost	String	TCV or annual run-rate
data_classification	String	PII, Sensitive, Internal, Public

Relationships

• ApplicationComponent hosted_on Node
• ApplicationComponent realises Capability
• ApplicationComponent consumes DataObject
• ApplicationComponent produces DataObject
• ApplicationComponent interfaces_with ApplicationComponent (stereotype: api_interface or batch_interface)

Quick Linker config

• Source: ApplicationComponent
• Target: Node, Capability, DataObject, ApplicationComponent
• Filters: Show only applications with business_criticality of Critical or High for the executive dashboard
• Display: Lifecycle stage as icon; end-of-life date as alert if within 18 months

Why this works: portfolio planning is a standing conversation, and this structure puts every retirement, consolidation, and capability-gap question in one queryable place. Retirement roadmaps and vendor-consolidation cases fall straight out of the lifecycle and criticality tags, while the data_classification tag does double duty for integration governance and data-residency checks.

3. System Integration Map

What it does: documents the interfaces, protocols, data contracts, and message flows between applications — the closest thing most organizations have to an integration blueprint that is actually maintained.

Element types

• ApplicationComponent (source and target)
• InterfaceSpecification (the contract)
• DataObject (payloads)
• TechnologyService (protocols and standards)

Key tagged values

Name	Type	Purpose
protocol_type	Enumeration: HTTP/REST, SOAP/XML, Message Queue, Database, File Transfer, FTP, Direct	Integration method
data_format	Enumeration: JSON, XML, CSV, Binary, Protobuf, Avro, EDI, Proprietary	Payload structure
call_frequency	Enumeration: Real-time, Near-real-time, Batch Hourly, Batch Daily, Batch Weekly, On-demand, Event-driven	Synchronization pattern
sla_response_time	String	e.g., "< 1 second", "< 5 minutes", "24 hour batch"
sla_availability	String	e.g., "99.9%", "Business hours only"
owner_name	String	Integration owner (usually the application owner on the source side)
is_deprecated	Boolean	Flag for sunset integrations
replacement_interface	Reference (to InterfaceSpecification)	Forward reference for decommissioning

Relationships

• ApplicationComponent integrates_with ApplicationComponent via InterfaceSpecification
• InterfaceSpecification uses TechnologyService (protocol definition)
• InterfaceSpecification carries DataObject (payload definition)
• InterfaceSpecification implemented_by ApplicationComponent (the middleware that enables it)

Quick Linker config

• Source: ApplicationComponent
• Target: ApplicationComponent (showing all integrations)
• Filters: Option to show only is_deprecated = true for integration-rationalization views
• Display: Protocol as edge label; SLA as tooltip; color-code by frequency

Why this works: integration debt stays invisible until someone maps it. Once the interfaces, protocols, and SLAs live as structured data rather than tribal knowledge, the brittle chains and soon-to-be-cut interfaces surface on their own, and questions like "show me all batch integrations" or "which apps call this service?" become an instant query instead of an afternoon of archaeology.

4. Business Process Decomposition (BPMN with organizational overlay)

What it does: a BPMN subprocess hierarchy linked to roles, systems, and data — who does what, with which systems, on what data.

Element types

• Activity (stereotyped BPMNProcess for top-level; BPMNSubProcess for children)
• Role (org unit representing a job function)
• ApplicationComponent (systems used in a process step)
• DataObject (created, modified, used)
• Lane (swimlane; use to associate role with process)

Key tagged values

Name	Type	Purpose
process_stage	Enumeration: Design, Active, Deprecated, Archived	Process lifecycle
owner_role	Reference (to Role)	Accountable party
cycle_time_target	String	e.g., "5 business days", "4 hours"
sla_definition	String	Service level expectation
manual_effort_hours	Decimal	Est. human effort per instance
exception_rate	String	e.g., "2%", "< 1%" (typical exception frequency)
is_automated	Boolean	True if RPA or full system automation
automation_tool	String	e.g., "RPA UiPath", "Workflow Engine"

Relationships

• BPMNProcess decomposes to BPMNSubProcess
• BPMNSubProcess assigned_to Role (via Lane stereotype)
• BPMNSubProcess uses ApplicationComponent
• BPMNSubProcess reads DataObject
• BPMNSubProcess writes DataObject
• BPMNSubProcess modifies DataObject

Quick Linker config

• Source: BPMNProcess
• Target: All child processes, roles, applications, data objects
• Filters: Show only deprecated processes for sunset planning
• Display: Manual effort as process label; automation status as visual indicator

Why this works: most process modeling work ends up siloed in a separate tool, cut off from the application and organizational context that gives it meaning. Anchoring it in EA connects process design to the application landscape and the org structure, so the effort and exception tags expose exactly where the manual load and automation candidates sit.

5. Technology Lifecycle (standards categories)

What it does: a technology standards register showing adoption status across the organization — what is strategic, what is merely accepted, and what you are actively retiring.

Element types

• Technology (generic; stereotyped by category)
• TechnologyService (if you are registering platforms as services)
• ApplicationComponent (that uses the technology)

Stereotypes by category

• Language (Java, C#, Python, etc.)
• Framework (Spring, .NET, Django, etc.)
• Database (Oracle, PostgreSQL, MongoDB, etc.)
• Middleware (Kafka, RabbitMQ, etc.)
• CloudPlatform (AWS, Azure, GCP)
• DevTool (IDEs, CI/CD platforms, monitoring)

Key tagged values

Name	Type	Purpose
adoption_status	Enumeration: Strategic, Accepted, Tolerated, Retiring, Retired	TOGAF standards alignment
standard_category	String	e.g., "Database Platform", "API Framework", "Monitoring Tool"
review_date	Date (YYYY-MM-DD)	When status was last assessed
next_review_date	Date (YYYY-MM-DD)	When status should be reviewed again
replacement_technology	Reference (to Technology)	What to migrate to (if retiring)
vendor_or_community	String	e.g., "Oracle", "Apache", "Linux Foundation"
version_range	String	e.g., "8.x – 12.x", "Any" (to allow flexibility)
approval_date	Date (YYYY-MM-DD)	When the technology was approved
rationale	String	Why this technology is strategic/accepted/tolerated

Relationships

• ApplicationComponent uses Technology
• Technology replaced_by Technology (if retiring/retired)
• ApplicationComponent should_migrate_to Technology (target technology for decommissioning)

Quick Linker config

• Source: Technology
• Target: ApplicationComponent (shows which apps use each technology)
• Filters: Display only adoption_status = Retiring to identify migration targets
• Display: Show adoption status as color; review date as alert if overdue

Why this works: technology standards are a governance asset, yet they usually live in a spreadsheet nobody trusts, severed from the model they are meant to govern. Pull them into EA and "which applications still run tolerated frameworks?" becomes an instant answer, with each deviation carrying its own business context — app, status, criticality, and migration priority, side by side.

Implementation notes

Getting started

1. Choose the pattern that matches your highest-value use case.
2. Create the stereotypes and tagged value definitions in your MDG Technology.
3. Define the relationships — both the validation constraints and the Quick Linkers.
4. Populate a pilot set of elements: one capability hierarchy, one application portfolio section, one process.
5. Validate against your standards, then iterate on the tagged value definitions.

Quality checks

• Run a model validation rule to confirm every element of a type has its required tagged values populated.
• Use Quick Linker to spot missing relationships — an application that sits in the portfolio with no realises link to a capability is an integrity gap, not a stylistic one.
• Check that tagged value enumerations match your governance definitions. If you say "Strategic", make sure "Strategic" means the same thing everywhere it appears.

Why the metamodel carries the weight

All five patterns share one trait: clarity at the metamodel level. Explicit element types, specific tagged values, named relationships, and governance-aligned enumerations are what let a query — human or automated — read the model without guessing. A loose metamodel produces ambiguous answers no matter how good the question is; a precise one produces answers you can act on. That principle is exactly why disciplined enterprise architecture treats the metamodel as a first-class deliverable rather than a configuration afterthought.

These patterns are not gospel. Adapt them — your standards may use different terminology, and your industry may demand additional attributes. The structure is what travels: clear element types, specific tagged values, explicit relationships, and governance-aligned enumerations. Your metamodel is the foundation everything else rests on. Get it right and your architecture becomes navigable, reportable to stakeholders, and governable at scale.

Start with one pattern. Master it. Then add the others.