Integrated meta model for enterprise modelling
including strategy, business architecture, risk and
change
Graham McLeod1
1
inspired.org, 4 Richmond Ave, Pinelands, 7405, South Africa & University Duisburg-Essen
Abstract
The paper describes the development of an integrated meta model capable of supporting a variety of
approaches in strategy and business architecture, including TOGAF®, ArchiMate®, Zachman,
MEMO, Inspired and others. It describes the sources of concepts, relationships and properties; the
modelling approach and rationale and the resultant model, which has proven effective in support of
multiple business transformation projects. The model integrates strategy, contextual factors and
business architecture elements as well as interfacing to implementation architectures, enterprise risk
and programme management. It leverages a multi-level meta modelling approach to overcome
challenges of prior meta models. Advantages and challenges related to a large integrated model are
discussed and suggestions made for dealing with these challenges.
Keywords
enterprise modelling, business architecture, strategy, meta model, integrated planning1
1. Introduction
1.1. Industry background
A variety of approaches are used to conduct business architecture, enterprise modelling, digital
transformation and strategy definition projects within enterprises. This work is often guided
by a method (defining what to do) and one or more languages, which include a meta model
(defining what concepts, relationships and properties are relevant to the analysis) and one or
more notations (defining how models are represented). Popular approaches include inter alia
The Open Group Architecture Framework (TOGAF® Standard) [1] and related publications;
ArchiMate® [2] and that of the Business Architecture Guild, viz. The Business Architecture
Body of Knowledge – “BizBoK” [4]. Other approaches include the MEMO set of meta models
and languages from Frank and colleagues [3]; the DEMO/Enterprise Engineering /Ontology
approach [7] and the Inspired Holistic Architecture Language [13].
Companion Proceedings of the 16th IFIP WG 8.1 Working Conference on the Practice of Enterprise Modeling and the
13th Enterprise Design and Engineering Working Conference, November 28 – December 1, 2023, Vienna, Austria
® TOGAF and ArchiMate are registered trademarks of The Open Group
graham@inspired.org
0000-0003-1022-4510
© 2023 Copyright for this paper by its authors. Use permitted under Creative Commons License Attribution 4.0 International (CC BY 4.0).
CEUR
ceur-ws.org
Workshop ISSN 1613-0073
Proceedings
1.2. Study background
The author and colleagues are engaged in research, consulting, training and method and tool
development related to these topics. The work described in this paper takes place in the context
of a commercial practice (Inspired.org, which delivers services and tools to a variety of client
organisations); as well as academic research by the author in the topics of enterprise modelling
and visual language design.
In 2014 [16] and again in 2019, the author and colleagues collected and analysed available
popular meta models as well as the proprietary models available in inspired.org. This resulted
in an integrated EA meta model (2014) and the Holistic Architecture Language (2019) HAL2019
[13].
Figure 1: Holistic Architecture Language (HAL) rich picture
The author is engaged in academic research, with a focus on development of better
enterprise modelling languages, particularly visual modelling languages [8]. ”Better” is
concerned with the Return on Modelling Effort (ROME). as conceived by Erik Proper and
colleagues [11].
The specification of an effective visual modelling language requires a competent meta model
of the domain which the language addresses. Competence here includes being able to express
the concepts, relationships and properties of the domain sufficiently to support all the required
model types and analyses required.
The meta model, in turn, must be expressed within a competent meta meta model to ensure
consistency, integration and integrity. The meta meta model should facilitate the definition of
the domain semantics, the visual languages and other model types, and the management of the
environment, content and user community.
Existing meta meta modelling approaches are often challenged by the complexities of
enterprise modeling, which aims to model a wide variety of aspects of the real, proposed and
imagined world in many different ways and from multiple perspectives. We concluded that a
competent meta meta model should allow us to express the semantics relevant to the domain;
the mapping of these to logical and physical model types and their representation (Concrete
Syntax) as well as facilitating comprehensive modelling while remaining relatively compact,
figure [2].
Figure 2: Meta meta model components
During 2022, the author defined a new meta meta modelling approach which includes roles
and multi-level techniques and which targets property graph implementation of resulting meta
models [17]. This constitutes the foundation component. The next brick in the wall is the
semantic layer i.e. the meta model for the domain of interest, viz. Enterprise Modelling.
During 2022, new versions of three popular approaches were published, including the
TOGAF® Standard 10th Edition, ArchiMate® Version 3.2 and BizBok Version 11. Inspired
introduced the Business Architecture Mastery Programme, a 16 week training programme, in
2019 and this has already been refined several times. Consulting practice using the HAL2019
model has also been ongoing. It has been applied in supporting business architecture,
information architecture, application portfolio management and requirements projects as well
as maturity modelling in banking, property investment, retail, health assurance and life
assurance environments. The current study updates the HAL2019 model to incorporate new
items from the recently published approaches and leverages the more advanced meta modelling
approach, which has also allowed simplification in some areas of the meta model.
Another challenge has been properly integrating adjacent disciplines which have grown in
projects and enterprises and consequently in our meta models and tool support. These include
Enterprise Risk management, Programme and Project Management and a growing focus on
Governance and Security. Inspired has also pioneered the wider use of Maturity Models and
extending these models with guidance on future courses of action [15].
The meta meta model facilitates defining a semantic layer; a visual representation layer; a
stakeholder and domain layer and a model management component. This paper addresses the
use of the semantic layer to define a meta model for enterprise modelling.
1.3. Limitations of popular models
Popular approaches in Business Architecture (mostly derived from earlier IT-Focused
Enterprise Architecture) do provide meta models to define and describe concepts, relationships
and (sometimes) properties which they deem relevant. Unfortunately, the scope of these
approaches is often not broad enough to truly define a future state of and strategy for the
business as well as to properly consider all the contextual factors that impact a sound strategy.
The Inspired models uniquely embody various elements vital for strategic consideration of the
organisational context, including: Legislation and Regulators, Economy, Emerging
Technologies, Opportunities, Threats, Competitors, Ecology, Politics and many other factors.
Considerable effort has also been expended to integrate the various architecture domains and
neighbouring disciplines, see context and business boundary in figure [1].
2. 2 Approach
2.1. Sources of models
Meta models were obtained from published and internal sources. Approaches which we
included in the analysis (and relevant reference) are given below:
• TOGAF® Standard - 10th Edition [1]
• ArchiMate® 3.2 Specification [2]
• The Business Architecture Metamodel Guide Version 2.1 [5]
• Enterprise Ontology - A Human-Centric Approach to Understanding the Essence of
Organisation [7]
• SABSA® Blue Book : Enterprise Security Architecture: A Business-Driven Approach
[14] (this is the risk model adopted in TOGAF®)
• The Inspired HAL2014 and 2019 models and their extensions as used on consulting
projects and with consulting clients were available to us within Inspired.org repositories
• Note that many sources used for the 2014 and 2019 integrated models are not cited again
here. Essential elements from these are already included in the HAL2019 model
2.2. Method
We first analysed the major sources for concepts, relationships and properties. This included
the published models and methods of TOGAF®, ArchiMate®, MEMO [3], DODAF/C4ISr [6],
EE/DEMO [7] and HAL. This activity involved identifying concepts (business objects) within
each method, collating these and looking for common concepts. This was aided by relevant
definitions in the sources, as well as reviewing the properties, relationships and examples.
Where available, example models, artefacts and instances were used to clarify intent and usage
of concepts in each method. This analysis revealed relevant extensions, refinements and
improvements in the respective models, including:
• TOGAF 10th Edition has extended coverage of Risk and Security (based on the SABSA
model [14]. It has also introduced more material specifically for Business Architecture,
including Value Streams and Courses of Action. Digital Transformation and Agile
implementation projects also receive attention. The distinction previously made
between core and extension concepts has been eliminated. The scope of the meta model
has changed little. Overall, it is still confined to the internals of the enterprise with the
exception of value chains. It does not have any concepts (other than Drivers) to
contemplate the context of the Enterprise. This is a major limitation from a strategy and
business architecture / digital transformation perspective. Unfortunately, there are still
inconsistencies between the meta model, method descriptions and definition of artefacts
within TOGAF. We contend that this reflects the document (rather than model) centric
nature of its development and evolution.
TOGAF does, of course, cover the IT domains of Applications, Data and Technology
reasonably well, but even there the concepts are course grained and more suited to a
document / artefact driven approach than actual model elements. An example would be
treatment of process, which is just one concept and therefor inadequate to perform any
modelling beyond identification and cross referencing to other concepts. TOGAF does
define the concepts and their attributes and relationships relatively well. The schema
uses entity relationship concepts and does not make any significant use of object
oriented concepts or abstraction.
• ArchiMate has a much more consistent approach and is heavily service oriented (at
business, application, data and technology layers). In contrast to TOGAF, it makes
extensive use of abstraction and inheritance to provide a subtle and effective modelling
environment. It has finer grained concepts than TOGAF, which permit the development
of more detailed models. It is still not detailed or granular enough to model internals of
processes or data below the level of entities/business objects.
Data modelling is weak, with only provision for Data Objects but no attributes. Data
is largely treated as something operated on or retrieved from Applications. This
orientation does not facilitate the development of enterprise data models which must
serve multiple applications and services. These may include business intelligence,
artificial intelligence and other tools, which may be internal or straddle multiple
locations.
Being designed to support a rich visual language, ArchiMate has a well defined set of
relationships and corresponding representations. The later versions include a ”strategy
layer” above the business layer, but this is fairly limited, including only Resource,
Capability, Value Stream and Course of Action. This is similar to the TOGAF coverage
(which was to some extent derived from ArchiMate). Again, there is no coverage of
contextual factors that would seriously impact strategic planning. The ArchiMate meta
model is well structured and serves its purpose well. Concepts and relationships are
very well defined. The model does not, however, include attributes, although the meta
model provides mechanisms for extension and their definition.
• BizBOK: The BizBOK has a relatively small but well considered meta model. It is
primarily designed to underpin the specific approaches and techniques advocated by the
Business Architecture Guild. It makes use of Value Streams, Orgranisation, Initiatives,
Capabilities, Outcomes, Product, Information Concepts (= Business Object) and
Strategy. These are core elements of a business, but again fall short in terms of modelling
any detail and especially in any contextual analysis in determining strategy. There is
also a dearth of concepts to overlap/integrate with neighbouring domains. The approach
does now cater for Customer Journey mapping. There is a glossary defining the concepts
and relationships are fairly obvious and sensible in the detailed coverage of meta model
fragments. Like ArchiMate, there are no attribute definitions.
• The Inspired HAL2019 meta model is quite large, but has coverage of all the TOGAF
version 9 and ArchiMate version 3.0 concepts, and a lot more besides. It is particularly
strong in covering the contextual aspects that inform strategy as well as addressing
enterprise risk, metrics and financial aspects in an integrated way. The supporting
toolset (Enterprise Value Architect (EVA)) [12] allows easy user extension or adaptation
of the meta model and visual notations and model types without programming,
downtime or deployment issues. This permitted easy expansion, but meta models had
grown inconsistent in some areas in terms of the use of semantics for relationships
(similar relationship concepts named differently when used between different concepts).
The availability of multiple multi-year client repositories enabled very rich analysis of
concepts and relationships that clients actually used and what extensions they typically
made.
Semantic analysis was performed to merge similar concepts under the most commonly used
name. This was done with the aid of meta models (language; meta model concepts, definitions,
relationships and (where available) properties) in a repository for analysis and comparison. This
analysis was performed during development of the HAL2019 meta model as well, so the recent
work was an extension and update of that analysis.
The next step was to identify all the concepts needed to produce a representative collection
of strategy and business architecture artefacts. These include inter alia all the relevant TOGAF
catalogues (lists of objects); matrices and recommenced diagrams. We also included some
widely used in industry, such as the Business Model Canvas [9]. We included those we routinely
use in our consulting, training and the Business Architecture Mastery Programme. These are
shown in table 1.
The analysis ensured that the necessary concepts, relationships and properties were present
to produce the desired artefacts.
We were uniquely assisted by the prior work on HAL2014 and 2019 and the fact that these
models have been used extensively in practice in our consulting projects, training and by a
variety of clients in various industries including banking, telecommunications, assurance,
media, healthcare, government, retail and education. The EVA toolset holds the meta model as
data in the repository and also keeps records of instances, population levels of various concepts
and properties, and ”age” of data since last update. These statistical details were available to us
from several repositories. This data allowed us to validate what is useful in practice and should
be included.
Table 1
Artefacts analysed in addition to TOGAF and ArchiMate viewpoints
2.3. Use of meta meta model
We mentioned a meta meta model prepared by the author in 2022 [17]. This is targeted to be
implemented in a new generation of tools, but this environment is not yet available. We thus
elected to leverage the existing EVA environment to ”bootstrap” and test the meta meta model
by doing our analysis, representation and engineering of the new models in the proposed
structures. We did not implement the full meta meta model, but just the essentials from the
semantic layer necessary for the task at hand. Please consult [17] for the meta meta model.
Having the meta models expressed as models and data in the repository at instance level allowed
for rich analysis, reporting, verification and evolution.
Integration of EVA with PlantUML [10] allows us to capture models, do reporting and
collaborative work at the semantic level, then generate domain specific language (DSL) to
PlantUML for generation of diagrams. This augers well for the new generation tools which
exploit the multi-level nature of the new meta meta model to allow the same tools to operate
over multiple layers of abstraction. To deal with the large meta models created, and to facilitate
publication, we developed tooling to allow generation of fragments of larger models and to
output meta models in a new compact meta model matrix format - see Appendix for matrices
and relationship types (figures 6 & 7). We also developed algorithms to automatically suppress
some details to simplify visual models, e.g. by eliminating inheritance relationships or not
showing relationships to abstract parents.
2.4. The resultant meta model
The integrated model is large, but it covers context, organisation boundary, strategy, business
architecture, risk and the change dimension. The full HAL model covers the other EA domains
as well, viz. Applications, Data, Technology and Security. The full scope is illustrated in Figure
1.
In line with our broader research aims of making models more accessible and valuable to
different stakeholder communities, the HAL models are expressed at three levels:
• Rich Pictures which are useful for executives and senior stakeholders to gain an overall
impression and have useful discussions without being overwhelmed
• Box and line conceptual models at the level of Business Concepts / Business Object
models. These use a similar notation to UML but with extensions for roles and the
addition of visual cues (crows feet) to indicate cardinality where relevant. They typically
do not show attributes. We will use several of these to illustrate parts of the meta model
in the paper.
• Detailed data models suitable for building the meta model in a repository, database or
software. These are fully detailed and use object oriented techniques, again with the
addition of roles. At this level attributes and (where relevant) behaviours may be
present. EVA and the subsequent generation tooling under development make good use
of rich data types which facilitates high level modelling of capabilities such as storing
related documents, models, hyperlinks, enumerated items, computed values, colours,
dates and times, images and code (e.g. XML or other markup). Our attributed models
thus take advantage of these features.
Figure 3: HAL Context meta model fragment
It is a massive challenge to try to create detailed models of the meta model that can be
accommodated in the constraints of small printed pages, so we have chosen a small number of
subsets (which are themselves somewhat simplified) to illustrate some of the more interesting
features (Figures 3,4,5). Full models are available online [18].
2.5. Features of the new model
• Coverage of context is much more extensive than widely used business architecture
approaches
• Integration of motivations across internal and external dimensions. Many different
considerations have been merged under this area, a trend which we also see exhibited
by ArchiMate
• Caters for Products, Services and Packages via Offering
• Caters for Channels, especially important for digital business models
• Enhancement of risk and security coverage in line with the enhanced coverage in
TOGAF/SABSA
• Rationalisation of relationship types and formal addition of relationship behaviours.
This to support the multi-level approach now adopted and to simplify understanding
for users of the model
• Addition of financial aspects which are surprisingly ignored by mainstream EA
approaches. Having these supports cash flow analysis, Sankey diagrams and more
• Caters for Assets (including IP) and Liabilities, which facilitates digital transformation
• Better Integration into initiative management via Initiatives, Programmes, Projects,
Maturity Models and extended governance concepts
• Coverage of customer journeys and touch points
• Coverage of maturity models
• User extensible Metrics using a flexible pattern, which allows users to define and
monitor variables they deem important in a standard way
• Properties and relationships reusable across concepts and relationships, which improves
semantics and has the potential to reduce tools size by allowing tools to work at different
levels of abstraction
• Caters for architecture scenarios (e.g. Baseline, Interim, Future 1, Altenate Future 2)
• Caters for a summary level to determine visibility (e.g. when rendering models) By using
a Package/Scope for breadth and levels for depth, can easily chose what to generate into
a graphical meta model
Figure 4: HAL business and boundary concepts
Figure 5: HAL change meta model fragment
2.6. Learnings from the exercise
• Working with large models requires strategies to automatically segment / generate /
output
• Defining properties independently of presence on domain concepts leads to higher
consistency and reuse
• Defining semantic relationships independently of their use between domain concepts
leads to rationalisation and better reuse
• Having the meta model itself as a model in a repository allows generation of
visualisations and implementations from it. Also permits use of powerful reporting,
analysis and visualisation tools.
2.7. Usage recommendations
We are not expecting, or even recommending, that clients or modellers try to complete all
aspects of the meta model in a major project. We anticipate that the model will be used much
as HAL2014 and 2019 have been. That is, to identify the goals of a project or an iteration, to
determine what information is useful to meet the goals and satisfy stakeholders and to populate
or refresh relevant content only. This may be a small percentage of the total coverage. The key
is that, when the concepts ”next door” to those already done become useful or necessary, the
models, repository and analyses can be rapidly and seamlessly expanded in an integrated way.
Like an organisation which initially purchases an ERP system for operational purposes, say
just billing and collection, but subsequently finds that it can also take care of customer
management, reporting, stock control and general ledger. Each new use unlocks more value in
an incremental way. In the same way, a good strategic planning and business architecture meta
model facilitates a competent repository and toolset to become the ”ERP of change” within an
organisation, serving multiple purposes and audiences over time, while increasing value
delivered and integrity while reducing effort and lead time to benefits.
The ability of a comprehensive model to support multiple methods and perspectives (e.g.
Zachman, TOGAF, DODAF) has already been proven over more than a decade. The EVA toolset,
for example, allows viewing and navigating the same information through the user’s preferred
choice of framework and modelling language. This can facilitate productivity across teams,
geographies and even natural languages. In the business architecture case, it also allows for
different (but integrated and consistent), perspectives between executives, business users,
domain experts and information and technology experts. This eases communications and the
elusive IT to business and strategy to operational alignment. Having integrated models is also
good for agile workflows, which can operate against a background of known baselines and
strategic intent. Digital transformation is also facilitated by considering issues of value through
IP, automation and smart use of information as well as algorithms. The proper consideration of
customer needs, touch points and channels of engagement can also facilitate higher engagement
and better satisfaction and retention.
3. Conclusions and future work
We believe the meta meta model concepts are proving effective. The integrated strategy and
business architecture model has already proven its worth in many consulting and client
environments. The latest revision should enhance the appeal further. We have at this stage only
fully merged the concepts and relationships not yet all attributes. That work is ongoing.
We plan to explore the automated generation of model fragments of interest and value in
much more detail. Because of the multi-level nature of the models, this can span meta meta,
meta and instance models with the same tooling and, when necessary, showing the various
levels in the same models or visualisations.
References
[1] The Open Group: The TOGAF® Standard 10th Edition - Introduction and Core Concepts;
Architecture Content (C220-Part4p); Series Guide - Business Models (G18Ap); Series
Guide-Digital Business Reference Model(DBRM)(G21Hp); Series Guide - Integrating Risk
and Security within a TOGAF® Enterprise Architecture; Series Guide - Business Scenarios
(G176p); Series Guide - Value Streams (G178p); Series Guide - Organization Mapping
(G206p); Series Guide - Business Capabilities, Version 2 (G211p) (2022)
[2] The Open Group: ArchiMate® 3.2 Specification, Open Group, Berkshire, U.K. (2022)
[3] Frank, U.: The MEMO meta modelling language (MML) and language archi- tecture, ICB-
research report 43 (2011)
[4] The Business Architecture Guild: A Guide to the Business Architecture Body of
Knowledge® (BIZBOK Guide) Version 11.0. Business Architecture Guild, USA (2022)
[5] The Business Architecture Metamodel Guide Version 2.1: Business Architecture Guild
(2022)
[6] McDaniel, D.: DoDAF 2.0 Meta Model (DM2) Walkthrough, Dept of Defence EA
Conference 1 June, (2009)
[7] Dietz, J., Mulder, H.: Enterprise Ontology - A Human-Centric Approach to Understanding
the Essence of Organisation, Springer (2020)
[8] McLeod, G.: Facilitating Design and Use of Effective Visual Languages in Enterprise
Modelling and Information Systems. POEM Doctoral Consortium, Vienna (2018)
[9] Osterwalder, A., Pigneur, Y., Clark, T.: Business model generation: A handbook for
visionaries, game changers, and challengers, Wiley Hoboken NJ (2010)
[10] Open Source: Drawing UML with PlantUML - PlantUML Language Reference Guide, 2022.
URL: https://plantuml.com/guide
[11] De Kinderen S, Proper HA. e3RoME: A value-based approach for method bundling. 28th
Annual ACM Symposium on Applied Computing 1469–1471 (2013)
[12] Inspired.org: Enterprise Value Architect, 2022. URL: https://www.inspired.org/eva-home
[13] Inspired.org: The Inspired Holistic Architecture Language, 2020. URL:
https://www.inspired.org/news/2020/1/21/the-inspired-holistic-architecture-language
[14] Sherwood, J., Clark, A., Lyas, D.: SABSA® Blue Book: Enterprise Security Architecture: A
Business-Driven Approach (2005)
[15] McLeod, G.: Extending and Automating Maturity Models for More Value: EMISA
Journal/Models at Work: POEM (2022)
[16] McLeod, G.: A Comprehensive and Integrated Meta Model Supporting Strategy, Business
Architecture and Transformation. PhD working paper (2015)
[17] McLeod, G.: An Advanced Meta-Meta Model for Visual Language Design and Tooling.
EMISA Journal (forthcoming) and Models at Work Stream, POEM, UK (2022)
[18] Inspired.org: HAL2023 meta model, 2023. URL:
https://inspired.evasaas.com/Archi/Documents/P3099x123426x106xHAL%20Busines%20A
rchitecture%202023.pdf
A. Compact
Compact Meta Model Matrix
Meta Model Matrix Generator
HAL Business Architecture 2023
Compact Meta Model for HAL Business Architecture 2023 Relationship Types
Architecturally_Significant_State
Semantic
Ref #
row to col | col to row
Business_Operating_Model
Business_Motivation_Type
Business_Communication
1 exposed_as | exposes
Critical_Success_Factor
Customer_Relationship
Business_Requirement
Category_Observation
Architecture_Scenario
2 participates_in | involves
Architecture_Element
Business_Motivation
Business_Capability
Environment_Factor
Business_Resource
Customer_Segment
Application_Service
Business_Function
Business_Contract
Business_Concept
Business_Initiative
Business_Process
Financial_Element
Business_Offering
3 relevant to | has
Dynamic_Element
Business_Product
Business_Liability
Business_Service
Course_of_Action
Business_Culture
Economic_Factor
CONCEPTS
Business_Policy
Business_Event
Business_Asset
Customer_Type
Business_Rule
Cost_Structure
4 composed of | part_of
Business_Risk
Business_Unit
Client_Need
Assumption
5 contains | held_by
Competitor
Constraint
Category
Channel
6 uses | used by
Control
Brand
Actor
7 produces | produced_by
Gap
8 role_of | role
Actor 26 9 triggers | triggered by
Application_Service 28 10 applies_to | metrics
Architecturally_Significant_State 4 14 11 provides | provided_by
Architecture_Element 15 12 responsibility_of | responsible_for
26 13 owned by | owns
Architecture_Scenario
15 14 delivers | delivered_by
Assumption 26 15 includes | included in
Brand 26 15 16 categorises | included in
Business_Asset 26 17 quantified_by | quantifies
Business_Capability 26 18 recipient | requires
Business_Communication 26 19 expects | expected_by
Business_Concept 26 20 addresses | addressed_by
Business_Contract 26 21 applies to | governed by
Business_Culture 26 22 reduces | reduced by
Business_Event 9 23 realised as | realises
Business_Function 28 1 26 24 influences | influenced_by
26 25 maintains | maintained_by
Business_Initiative
20 26 supertype | subtype
Business_Liability 26 27 binds | bound_by
26 28 supports | supported_by
Business_Motivation
26
Business_Motivation_Type 16
Business_Offering 26 20
Business_Operating_Model 15 15 15 15
Business_Policy 7 7
Business_Process 6 7 26
Business_Product 26
26
Business_Requirement
20
Business_Resource 26
Business_Risk 3 26
21
Business_Rule
26
Business_Service 26 26
Business_Unit 26
16
Category
26
Category_Observation
Channel 26 14 28
Client_Need 26
Competitor 26
Constraint 26 26
Control 3
Cost_Structure 26
Course_of_Action 24
Critical_Success_Factor 26
Customer_Relationship 12
Customer_Segment 26
Customer_Type 26
25
Dynamic_Element 26 7 9
6
Economic_Factor 26
Environment_Factor 26
Financial_Element 26
Gap 3 26
Identity
Intellectual_Property 26
Jurisdiction
Legal_Business_Entity 26
Legislation 26
5
Location
26
Logical_Property
Maturity_Assessment 26
10
Metric
26
Money 26
Observation
Opportunity 26
Party 26 11
Person
Personal_Capability 26
Political_Factor 26
Portfolio 15
Principle 26
Process_Step 8
Programme
Project 14 6
Real_Person
Revenue_Source 26
Risk_Assessment
Risk_Category 16
Risk_Incident
Risk_Mitigation 22
Role_Type
Scalar_Observation
Social_Factor 26
Stakeholder
Stakeholder_Role
Standard 26 26
Strength 26
Subject_Area 16
Technology 26
Technology_Service 28
Threat 26
Time_Period 19
Unique_Selling_Propositiion 20
Value 26
Value_Chain 26
Value_Step
Weakness 26
Work_Package 20
Zone 15
Figure 6: HAL Business Architecture Compact Meta Model Matrix (left hand portion)
Compact Meta Model Matrix Generator
HAL Business Architecture 2023
Compact Meta Model for HAL Business Architecture 2023 Relationship Types
Unique_Selling_Propositiion
Semantic
Ref #
row to col | col to row
Legal_Business_Entity
Maturity_Assessment
1 participates_in | involves
Intellectual_Property
Technology_Service
Personal_Capability
Scalar_Observation
Risk_Assessment
Stakeholder_Role
2 relevant to | has
Revenue_Source
Logical_Property
Political_Factor
Risk_Mitigation
Work_Package
Risk_Category
CONCEPTS 3 composed of | part_of
Process_Step
Social_Factor
Risk_Incident
Subject_Area
Real_Person
Value_Chain
Time_Period
Observation
Stakeholder
Programme
Opportunity
Value_Step
Technology
Jurisdiction
4 plays | played_by
Legislation
Role_Type
Weakness
Standard
Principle
Location
Strength
Portfolio
5 contains | held_by
Identity
Person
Project
Money
Threat
Metric
Value
Party
Zone
6 uses | used by
7 role_of | role
Actor 1 8 applies_to | metrics
Application_Service 9 provides | provided_by
Architecturally_Significant_State 10 responsibility_of | responsible_for
11
Architecture_Element 2 11 owned by | owns
10
12 delivers | delivered_by
Architecture_Scenario
13 includes | included in
Assumption
14 categorises | included in
Brand 11
15 quantified_by | quantifies
Business_Asset
16 expects | expected_by
Business_Capability 12 23
17 recipient | requires
Business_Communication 5 17
18 addresses | addressed_by
Business_Concept 5 11
19 applies to | governed by
Business_Contract 25
20 reduces | reduced by
Business_Culture
21 realised as | realises
Business_Event
22 supertype | subtype
Business_Function
23 supports | supported_by
Business_Initiative
24 value_for | observations
Business_Liability
25 binds | bound_by
Business_Motivation
Business_Motivation_Type
Business_Offering
Business_Operating_Model 13 13 13
Business_Policy
Business_Process 3
Business_Product
Business_Requirement
Business_Resource
Business_Risk 15 21
Business_Rule
Business_Service
Business_Unit
Category
Category_Observation 22
Channel
Client_Need
Competitor
Constraint
Control
Cost_Structure
Course_of_Action
Critical_Success_Factor
Customer_Relationship
Customer_Segment
Customer_Type
Dynamic_Element
Economic_Factor
Environment_Factor
Financial_Element
Gap
Identity 19
Intellectual_Property
Jurisdiction 22
Legal_Business_Entity
Legislation
Location
Logical_Property
Maturity_Assessment
Metric
Money
Observation 24
Opportunity
16
Party
9
Person 22
Personal_Capability
Political_Factor
Portfolio 10
Principle
Process_Step
Programme 13
Project 18
22
Real_Person
22
Revenue_Source
Risk_Assessment
Risk_Category
Risk_Incident
Risk_Mitigation
Role_Type 14
Scalar_Observation 22
Social_Factor
Stakeholder 7 4
Stakeholder_Role
Standard
Strength
Subject_Area
Technology
Technology_Service
Threat
Time_Period
Unique_Selling_Propositiion
Value 12
Value_Chain 3
Value_Step
Weakness
Work_Package
Zone
Figure 7: HAL Business Architecture Compact Meta Model Matrix (right hand portion)