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)