Causality and causal knowledge are key concepts in science that underpin the development of smart, automatic, autonomous and intelligent systems. Causality is an important concept in modern science (Bunge, 2011); it helps to reveal the domain properties hidden to the outside observer. Causal knowledge is a type of knowledge, next to declarative, procedural, and relational knowledge. Causal knowledge is a “description of causal links among a set of factors … which provides a means for organizations … how best to achieve some goal” (Zack, 1999).

Causality as a theoretical concept is discussed in Schurz and Gebharter (2016). According to Glymour (2004), Schurz and Gebharter (2016) causality should be understood as a theoretical concept (in analogy to the concept of force in Newtonian physics). A general theory of causation was developed by Pearl (2000, 2009), which underlies the theory of causal nets (TCN) developed in Spirtes et al. (2000), Pearl (2009). Two notions of causality can be distinguished – type causality (so-called general causality) and actual causality (called specific causality) (Halpern, 2015). Actual causality focuses on particular events, while type causality is looking for common regularity (law). The understanding of causality in system modelling can be quite different according to the nature of the knowledge used.

The awareness of the theory of specific domain causality is the prerequisite for discovering deep knowledge (i.e. regularities, laws) in a given domain. Causation methods are common in statistics, econometrics, cybernetics, computer science, data science and other complexity sciences to study cause-effect relationships and construct causal models in order to predict and control the possible dynamics of the systems. Causal models are tailored to a specific type of domain, describing regularities specific to that area of reality, e.g. such as physical systems (work centres, robots, autonomous devices), enterprises (production and business companies, education systems, etc.), biological systems, economic systems, ecological systems, etc.).

Excellent results have already been achieved in the development of the cyber-physical systems (CPS) such as smart systems, autonomic systems and other types of CPS. CPS engineering uses the intrinsic properties of a domain (i.e. the Physical System) because there is a long-established good theoretical foundation – control theory. In a physical system, causality is a dependency between causes (impacts, events, faults, etc.) and changes of a system (state, transition, parameter values, etc.). In other words, CPS engineering methods are based on the causal knowledge (scientific law, scientific explanation) of the subject domain (Bunge, 2011). It makes sense to look for the causal knowledge (scientific law, regularities) in other types of real world domains. Causality in risk management is to be considered as the direct relation of the event to a risk situation (influence relation) (Sienou et al., 2008).

Our research area is business modelling and enterprise modelling. One of the definitions of causality in this area is as follows: the dependence of enterprise goals on components of the enterprise such as processes, material flow, information flow, services, systems, and so on (Lagerström et al., 2009).

We are dealing with complex systems (organizational systems, enterprises or cyber-social systems) summarized by the term systems of systems in the methodology of EA frameworks. Such a subject domain is referred to as “enterprise” in application software engineering and is related to a wide range of industries, e.g. manufacturing, military, and healthcare, energy, communication enterprises, and others. A captured domain causality is specified as the internal domain model, e.g. the cause–consequence rules, equations, ontology, meta-model or other structures of causal knowledge (Grundspenkis, 1998).

Two levels of enterprise causal knowledge were introduced for software engineering needs in Gudas (2012). The first level is the presentation of the discovered causation using the Management Transaction (MT) framework. At the second level, a deep knowledge structure of MT is revealed in a more detailed framework called the Elementary Management Cycle (EMC). Causal modelling is suitable for discovering causal dependencies in various real-world domains. These are not just organizational systems (i.e. enterprises, cyber-enterprises or cyber-social systems), but also biological systems (organisms), ecological systems, the content of education systems and other complex systems.

The aim of the study is to bridge the gap between causality inherent in the definite real world domain and EA framework structures.

The EA frameworks are currently based on expert knowledge and experience, these are generalized structures derived from the evolution of the EAF. The analysis showed that there is a gap between the capabilities of EA frameworks and the behavioural characteristics of the real world domain (enterprise management activities).

The aim is to improve the existing EA development methods and systems, use casual knowledge of the activity domain in validating the decisions of EA developers, developing intelligent EA development systems. The paper aims to improve the conceptual structure of the existing EA frameworks (MODAF, ArchiMate, etc.) using causal domain knowledge.

The influence of the newly created EAF component type – meta-models – on the EA development process is investigated. This study is linked to previously published work on the structure of the expanded MDA/MDD process (Gudas and Valatavičius, 2020). An extended structure of MDA is described here, where above the CIM layer is the modelling layer of the reality domain, called the “domain knowledge model”.

The relevance of EA frameworks for more accurate (deeper) modelling of business processes is emphasized (Schekkerman, 2004) – it is necessary to “use business behaviour instead of business processes as part of the EA framework”.

Causal modelling seeks to reveal the domain regularity and is consistent with the internal modelling paradigm. If an external modelling paradigm is applied, then the modelling is based on external observation, obtaining empirical information that does not reveal essential (deep) causal dependencies. The external modelling relies on the naming of “specific events” and its input-output analysis, and the true causality is not determined in this way.

From the perspective of internal modelling, an enterprise (organizational system) is a complex system with a self-managing property, the essence of which is the feedback (control) loop – the circular causality of elements (activities, processes or components).

Circular causality between elements is considered as a transaction and is formally defined as a wheel graph in Gudas and Valatavicius (2017, 2020). The transaction is an essential concept in computer science, database management systems, business modelling notation BPMN 2.0, transactional workflows (Medina-Mora et al., 1992), enterprise management modelling using the transaction concept (Dietz, 2006; Gudas, 2012).

Circular causation is an essential feature of these conceptual enterprise models: Action Workflow model (Rusinkiewicz and Sheth, 1994; Medina-Mora et al., 1992), Deming’s PDCA cycle of business management (Deming, 1993), ITIL Framework (Persse, 2012), or the autonomic computing component (Kephart and Chess, 2003).

Therefore, in our view, a transaction is defined as a conceptual model of circular causality – a description of an essential feature of an enterprise as a complex system. Thus, a transaction is a key concept that allows you to discover the deep characteristics (causality) of an enterprise domain.

The rationale for incorporating the causality paradigm into EA modelling language is the need for adequate modelling capability – to establish a circular causality in the enterprise architecture. As discussed above, the circular causality is an essential feature required to properly identify the self-managed enterprise activities and represent it as management transactions.

The problem (research question) is bridging the gap between domain causal knowledge and the content of the EA system by integrating meta-models as part of EA structures. Second, the necessary properties of meta-models need to be ensured – they must cover not only simple process flows, but also capture the causality of the company’s activities. Such a study includes the application of the extended MDA scheme developed (Gudas and Valatavičius, 2020). Meta-models are expected to create a layer of knowledge in the EA development repository, which ensures smart EA development, allows validation of developer decisions.

The basic concepts of causal enterprise modelling are described in more detail (Gudas, 2012, 2016): Management Functional Dependency (MFD), Management Transaction (MT), and Elementary Management Cycle (EMC).

An analysis of the known EA frameworks and business process modelling notations was focused on the key concepts that determine the possibilities of causal knowledge representation. Known EA structures were examined, including MODAF, ArchiMate, and UAF (Morkevicius et al., 2017; MODAF, 2013; ArchiMate, 2017), as well as key concepts of other modelling approaches – OMG standards BPMN, BPDM, BMM, OSM, goal-driven methods KAOS (Dardenne et al., 1993), GBRAM (Anton, 1996), the NFR framework (Mylopoulos et al., 1992). A comparison of the EA frameworks and other modelling standards allows us to identify the MODAF framework as the most comprehensive one. However, it also contains “white spots” as there are no suitable MODAF products to specify several aspects of enterprise management and validate the resulting models. One of the objectives is to extend MODAF using causal knowledge, complementing the strategy modelling and operational views. Upgrading the core EA systems with causal models (using the MODAF example) reveals the structure of intelligent EA development software. This would streamline the EA development process and increase the quality of the software development.

Several graphical notations were used in this work: UPDM notation to present EA constructs (UPDM, 2017), MODAF meta-modelling tagging (MODAF, 2013), DFD notation for conceptual models.

The remainder of the paper structured as follows: Section 2 explains paradigms of system modelling, the concepts of causal modelling, provides an overview of the enterprise architecture frameworks from a causal modelling perspective. Section 3 introduces the internal model of Porter’s value chain and the concepts of causal knowledge: Management Transaction (MT) and Elementary Management Cycle (EMC). The detailed structure of MT and the specific version of EMC for the enterprise management modelling are set out in Section 4. The causal constructs of enterprise architecture modelling are defined in Section 5. The assumptions for the development of causal EA are formulated in Section 6. Section 6 also provides description of the causality-based MDA/MDD process, the architecture of intelligent EA tools, a causal EA development scheme aligned with the MODAF framework, the EA development stages on the causal CIM* layer of MDA, and types of validation based on causal knowledge. Additions to the MODAF Strategic viewpoint (StV) are the causal StV meta-models are presented in Section 7. Section 8 provides an example of causal Strategic Viewpoint StV development, includes rules for (vertical) model’s transformations and (horizontal) validation processes. The conclusions summarize the essence of causal modelling for EA upgrading and the benefits of causal enterprise architecture development.

In a causal enterprise modelling approach, the management functional dependency (MFD) is defined as a primary cause that creates a causal behaviour between some subset of enterprise activities (a closed-loop chain of causal dependencies) (Gudas, 2012; Gudas and Lopata, 2016). MFD is a real-world phenomenon (causation) that is sought to be discovered by managers or domain analysts (or, in the case of incompetence, not realized). MFD predefines causal dependence of some activities (processes, operational capabilities or organizational units) required by particular business needs (i.e. strategic plan or actual business event). Perceived MFD is conceptualized as the Management Transaction (MT) and is described in detail as the Elementary Management Cycle (EMC) (Fig. 3).

Therefore, a two-level granularity of the domain causal knowledge can be achieved:

Level 1: MT framework reveals a higher level content of management activities: a closed-loop chain of information flows and transformations. In this approach, MT explores the first step of causal modelling of domain activities (i.e. this is conceptual representation of perceived MFDs). The conceptual structure of the management transaction is presented in Fig. 4: Pi – basic physical (material) process (i – identifier), Fj – management function (j – identifier), A – Process State Attributes (raw data), V – Controls (impacts to P).

Note that the enterprise goal G is not explicitly stated in the description of MT, only marked with a dotted line in Fig. 3, but it is considered by the analyst and affects the specification of MT.

Level 2: EMC framework reveals the internal structure of the MT framework as it decomposes the content of the management function Fj (G): internal steps of information transformations (functions) and information flows (A, B, … , V) between steps (Fig. 3, Level 2), clearly indicate the management goal (G) and the impact (management information flows S) of G on the EMC components.

MT and EMC frameworks are unified components of causal knowledge (deep knowledge) for an enterprise causal model. EMC is an internal model of the Management Transaction (Gudas, 2012). A similar interpretation of the transaction as a complex component of deep knowledge (“molecule”, a unified building block) is described in the DEMO ontology (Dietz, 2006).

Therefore, a well-known business management model – Value Chain Model (Porter, 1985) is modified from the causal modelling viewpoint and depicted in Fig. 5 as a system of management transactions {MT₁₁, … , MT₄₅}:

The general EMC framework in Fig. 3 (level 2) explicitly specifies the internal components of management transaction: steps (transformations) and interactions (information flows) of management function F. In order to reveal the content of the enterprise management information, a specific version of the EMC framework (Fig. 6) was developed (Gudas, 2012; Gudas and Lopata, 2016). This version of EMC includes components with well-defined semantics as follows: Goal (G), a goal-driven management function Fj (G), enterprise process (Pi(G), and connecting information flows (A, B, C, D, and V). Management function Fj(G) is a complex structure, which consists of the goal-driven procedural components (four types of the information transformation steps IN, DP, DM, and RE) and the management information flows (A, B, C, D, and V denote the types of data/knowledge, and a flow type S denotes the impacts of goal G to other elements of EMC framework). The semantics of the management information flows is as follows: flow A is “process state attributes (raw data)”, flow B is “systematized raw data”, flow C is “processed data”, flow D is “management decisions”, and flow V is the “controls” of Process Pi(G).

The semantics of the procedural components of EMC is as follows:

Process Pi(G) refers to the physical transformations that produce a tangible result of the enterprise. The procedural components (IN, DP, DM, and RE) denote steps of the feedback loop – circular causality between Pi(G) and Fj(G) (Fig. 7). Note, only the information content of the procedural components is considered here. Therefore, the content of IN, DP, DM, and RE refers to the knowledge clusters (Gudas, 2012, 2016): –

Interpretation (IN) is a cluster of knowledge (rules) for the collection, identification, and systematization of raw data;

An important part of domain causality modelling is to specify the impact of the goal G on other EMC components (procedural and information components). The detailed classification of the G impact on other EMC components is given in Fig. 8.

The causal modelling paradigm is a priority of our approach, as the assumption is made that expert knowledge and decisions should be compared with discovered causal models of enterprise domain.

The analysis carried out suggests that the concept Goal in the context of EMC structure corresponds to co-related MODAF concepts EnterpriseVision, EnterpriseGoal, EnduringTask and Capability of StV viewpoint. The concept Capability is key in the sense that it is EnterpriseVision, EnterpriseGoal, and EnduringTask driven concept and directly links StV products to OV, SV and SoV products and their concepts.

Examining the conceptual structure of EMC (Figs. 7 and 8) and comparing it with the MODAF meta-model, we found that some aspects of Capability dependence relationships and the impacts of enterprise goal are not included in the StV viewpoint. The conceptual structure of the EMC in Fig. 5 defines the following types of impacts of Goal on internal elements of any activity (management function), system or service:

The requirement of taking into consideration the feedback loops between elements of any EA framework (capabilities, nodes or activities) is an essential pre-condition of well-managed enterprise processes. The origin of this requirement is the conceptual structures of the MT (Fig. 4) and EMC (Fig. 6).

Whereas the concept Goal (in the context of EMC) corresponds to the concept Capability (in the context of MODAF), on this basis, we propose more detailed modelling of the goal-related aspects in StV viewpoint (Fig. 8). Causality-based structure of the concept Capability should include a (lower level) predefined types (sub-capabilities): Capability of Information Components and Capability of Information Transformation Components. Both types of Capability (sub-capabilities) are applicable to all other MODAF products, namely OV, SV and SoV viewpoints. This allows us to specify more precisely the strategic view based requirements on elements of EA.

Causal modelling requires predicting the internal organization of processes. Therefore, we suggest predetermining potential causal dependencies in two competing ways: a) causal dependencies between identified capabilities in StV viewpoint and b) causal dependencies between identified operating nodes in OV viewpoint. Note that these techniques are complementary and can be used in parallel, simultaneously.

The definition of Capability has been expanded with new concepts aimed to define causal knowledge (Fig. 9):

The introduced causal modelling concepts (Table 2) and the Capability meta-model in Fig. 10 provide the basis for developing causal meta-models of EA framework starting from StV and OV viewpoints.

The causal meta-model of Capability (Fig. 10) includes capability types Collapsed Capability, Expanded Capability, and Detailed Expanded Capability. The Expanded Capability (DE) includes Capability Roles that correspond to the MT framework. Therefore, Expanded Capability (CE) includes Capability Roles as follows: C(P), C(S), C(A), C(V) and C(FL). Capability role C(FL) must ensure that internal elements (i.e. Capability Roles) of CE are linked by circular causal dependence to form a feedback loop. The Detailed Expanded Capability (CDE) is of finer granularity and includes capability roles that correspond to the EMC framework. Therefore, Detailed Expanded Capability includes the Capability roles C(P), C(G), C(I), C(S), C(A), C(V) and C(FL). The dashed rectangle indicates that some Capability-Step C(S) may vary, depending on the inherent causality (regularity) of the specific domain. Capability role C(FL) must ensure that the internal elements (i.e. Capability Roles) of CDE are linked by circular causal dependence to form a feedback loop.

MODAF methodology provides a logical link between StV and OV viewpoints. The Capabilities identified by the StV viewpoint require the creation elements of Operational Nodes of OV. The identified Capability dependencies are the basis for the Operational Node Internal Relationship.

Causal modelling approach considers Operational Node (i.e. a logical entity that performs operational activities) as a self-managed system relevant to Management Transaction (MT in Figs. 3 and 4). From here, it follows that a higher level Operational Node is considered as a complex component, which satisfies the circular causality requirement: any Operation Node in the next modelling step is decomposed as closed-loop interaction of operational activities. Therefore, any OV node includes at least two lower-level nodes (or activities) with an information feedback loop between them. Note: In some simpler case OV, node could be considered as a transaction in terms of BPMN.

Thus, the new types of causal Operational Nodes are defined as follows (Fig. 11):

New concepts related to causal knowledge have been included in StV’s viewpoint products as follows: Enterprise Vision (StV-1), Capability Taxonomy (StV-2) and Capability Dependence (StV-4). The Enterprise Vision StV-1 of MODAF provides an observation-based list of Capabilities (Enterprise Phase related). This is empirical information whereas MODAF makes no formal or conceptual requirements for the content of the capabilities identified in the development of the enterprise vision. The next stage is mapping the StV-1 to other StV viewpoint products (StV-2, StV-4, etc.), and thereafter, further EA development by mapping the identified set of capabilities to the OV viewpoint.

The causality-based Enterprise Vision StV-1 development is based on the causal meta-model StV-1K (Fig. 14). The causality-based Enterprise Vision meta-model StV-1K includes an observation-based list of concepts (the upper part of Fig. 14) and Domain Knowledge Model-based a structure of causal concepts (the lower part of Fig. 14).

The development of the causal StV-1 model also starts with an initial list of capabilities (empirical information). Let us assume that all identified capabilities are declared as Collapsed Capabilities (by definition in Assumption 2) with a predefined internal structure. The internal structure of identified Collapsed Capabilities needs to be refined in the next step using meta-models StV-2K (Fig. 15) and StV-4K (Fig. 16). There are two options to specify the internal structure of the Collapsed Capability: selecting capability type Expanded Capability or/and Detailed Expanded Capability.

Uncertainty arises in the development of the MODAF causal dependence model StV-4 – what objective evidence confirms the dependencies between the capabilities? Of course, the dependence of StV-4 capabilities is based on expert knowledge, experience, and opinion, but this is not consistent with the MDD methodology, as a transformation from a previously developed model would be required.

The causal Capability Taxonomy meta-model StV-2K depicts the required capability roles (Fig. 14). The Capability Causal Dependence meta-model StV-4K depicts required causal dependencies between capability roles (Fig. 16). The StV-2K is logically linked to StV-4K because the set of all identified in the StV-2K capabilities must be associated with causal dependencies as predefined in the StV-4K. StV-4K includes two (alternative) capability dependence structures of different granularity: MT-based and EMC-based capability dependence.

Let us take the case study “Search and Rescue Enterprise (SAR Enterprise)” (MODAF Strategic Viewpoint, 2019) as a starting point to explain a causality-based approach. In the original example (as well as in Fig. 17), the capability SAR is an aggregate element, it includes three components: capabilities Recovery, Search and Assistance. As well capability SAR is a generalized item: it provides two types of services: Capability Land SAR and Capability Maritime SAR.

The DKM layer distinguishes two main activities: to understand the knowledge discovery method and apply it to the development of the domain knowledge model. The main concepts of the traditional StV viewpoint are depicted on the left side of Fig. 17. Causal modelling concepts (i.e. meta-models of EA) are depicted on the right side and lower part of Fig. 17. Four levels of hierarchy from a Whole Life Enterprise to Collapsed Capability (2) are obtained from observation-based experience. However, this empirical solution needs to be validated. Causal EA modelling starts at the Expanded Capability level as this is where the internal model of Collapsed Capability (2) (i.e. meta-model) is selected for validation in the next stages of EA development. The following are examples of SAR Enterprise causal modelling, focused on the detailing Search capability. Similarly, Rescue and Assistance capabilities causal modelling should be done, creating meaningful causal structures of StV products that match the DKM.

Development of the causal StV solution (see Fig. 12) is a two-dimensional process: •

Vertical direction: transformations of StV models (StV-1, StV-2, and StV-4) in four levels of hierarchy follow to the MODAF methodology and

Basic steps in the development of causal capability taxonomy StV-2 model: •

Capability role validation rules (VR01–VR04) or/and rules (VR03–VR15) used to specify a causal capability taxonomy StV-2 model in Fig. 18. Note, that the original capability taxonomy model StV-2 of SAR Enterprise was developed on an empirical (expert) knowledge basis. The causal EA modelling results in a more reasonable StV-2 due to validation using causal knowledge, fixed in the meta-model StV-2K.

Similarly, Collapsed Capabilities Assistance and Recovery (in the previous stage (rule VT02) were specified as the Detailed Expanded Capability) should be decomposed in this way and validated using the EMC-based capability role validation rules (VR01–VR13).

An example of the capability role validation (3). Suppose that the capabilities Search, Assistance and Recovery are found to be causally related and should be consistent with the MT framework, so their interdependencies correspond to capability type Expanded Capability:

Note. A possible alternative if there is no causal dependency between Search, Assistance, and Recovery (activities occur in parallel), that is, are autonomous activities.

Now let us discuss the peculiarities of causal modelling on the level Enterprise Phases. The two Collapsed Capabilities Land SAR and Maritime SAR are required parts of Whole Life Enterprise UK SAR), and (at the same time) are specialization (sub-types) of the capability SAR depicted at the level Collapsed Capability (1). Suppose the rules (VR01–VR04) were applied for the capabilities Land SAR and Maritime SAR (Fig. 17) on the level Enterprise Phase, this validation revealed a gap, and the new capability “Mountain SAR” was proposed.

Causal modelling of capabilities Land SAR and Maritime SAR can be performed according to the example with capabilities Search, Assistance and Recovery. Land SAR and Maritime SAR activities are tailored to the different real-world domains (land, water or elsewhere) respectively. The specificity of Land SAR and Maritime SAR activities are captured in specifications StV-1, StV-2, and StV-4.

In the next step, the causal dependencies are determined to develop the StV-4 model. The capability dependence model (StV-4) of the case study “SAR Enterprise“ (MODAF Strategic Viewpoint, 2019) has been developed on an observation basis as well. The causal EA approach can result in a more reasonable StV-4 product where the identified capabilities and dependencies between capabilities are verifiable by causal knowledge, fixed in the StV-4K meta-model.

Key steps in the development of causal capability dependence StV-4 model of the SAR Enterprise:

Causal enterprise architecture modelling begins by revealing the subject domain causation (regularities) and building the domain knowledge model (DKM) upon them. In our previous work, the traditional MDA scheme (CIM–PIM–PSM–Code) has been enhanced by adding a new layer “Domain Knowledge Model” for domain causal knowledge discovery (Gudas and Valatavičius, 2020). Thus, the causal modelling approach underpins the consistent EA development that ensures the validation of empirical solutions against captured causal knowledge. This presupposes the development of intelligent EA development tools that have a causal knowledge base. Model transformations and validation can be computer-aided, using causal knowledge repositories of intelligent software tools.

The study shows a way of causal modelling integration to the MODAF framework, starting from the StV viewpoint. Causal modelling is consistent with the paradigm of internal modelling, which reveals the regularity (causality) inherent in the reality domain type. The paradigm of internal modelling seeks to discover the regularities of the subject area (causal knowledge) and to create an internal model of the reality domain. The condition for causal modelling is prior knowledge of the causality of the field.

The contribution of research is bridging the gap between enterprise domain knowledge and EA framework content by the integration of meta-models as part of EA structures. Meta-models that cover not only simple process flows, but also business behaviour, i.e. causality of the activities in the domain, have been developed. In the next step, creating EA development tools, causal meta-models enables to create a layer of knowledge in the EA framework, which ensures smart EA development, allows validation of developer decisions.

The discovered causal knowledge is defined here as Domain Knowledge Model (DKM) and is tailored to the needs of enterprise application software development. The content of the DKM is the source of causal dependencies for determining the causal meta-models of the EA frameworks. The essential thing is the recognition of the defined type of causation – the circular causality, which is characteristic of the enterprise management activity. Two circular causality patterns specific to the enterprise domain – a Management Transaction (MT framework) and a more detailed Elementary Management Cycle (EMC framework) – are unified components of causal knowledge, and are used here to develop MODAF modification, that is, to create causal meta-models for StV view products StV-1, StV-2, and StV-4. The new concepts Collapsed Capability, Capability Type and Capability Role were introduced to specify a causality inherent to an enterprise domain.

Meta-models have enabled a causal knowledge base in the EA repository, which is a key component of intelligent EA tools. Such a smart EA development environment communicates with the EA developer; determines the compatibility of solutions with the business domain causation, validating empirical developer decisions. The case study, which is described in detail, confirms this.

Two types of validation of EA solutions are available due to causal meta-models of EA framework: the first one, assessment of the internal structure of the EA solutions against causal meta-model, and the second one, the discovery of dependencies between identified (observation-based) capabilities. Current EA development tools visualize the created EA models, help check model syntax, but cannot perform validation of EA solution, as it has no domain knowledge models. The SAR Enterprise development example provides important technical details as causal meta-models can be integrated into a specific EA framework. The example provided shows the principled way that causal knowledge base lead to the intelligent EA development, together with the appropriate algorithms, provides a new opportunity to test and validate EA development solution, ensuring the consistency of the EA project.

The next step in the study of causal models integration with EA frameworks is based on the logical relationships of MODAF views as follows. MODAF provides a logical association of StV products and OV products, there is a direct link between the Capability and the Operational node. This led to a definition of causality-based types of Operational Nodes with different granularity: Expanded Operational Node (MT-based) and Detailed Expanded Operational Node (EMC-based).

The presented method provides an opportunity to move the EA development to smart platforms. Upgrading the core EA systems with causal models (using the MODAF example) reveals the structure of intelligent EA development software. This presupposes the development of advanced EA development tool with the ability of computer-aided validation of EA solutions in addition to expert knowledge. This would streamline the EA development process and increase the quality of software development.