Separation of Modeling Principles and Design Principles in Enterprise Engineering

Summary. An agile enterprise requires evolvable information systems and organizational structures. Some design theories, e.g. Normalized Systems theory, which were originally developed for designing information systems, have been generalized and extended for the design of organizations. In addition to information systems, Normalized Systems theory has recently expanded its applicability into the organizational level, including business process. This resulted in a set of 25 design guidelines for Normalized Systems Business Processes. On the other hand, Enterprise Ontology provides advantages in understanding the essence of organizations for massive abstraction and complexity reduction. Since these two streams of research apparently have similar goals, i.e. designing enterprises, using diﬀerent approaches, some early studies tried to compare or combine them. However, most of them achieved limited success. This research investigates the literature, looking for a new way to connect them. It concludes that it may be possible to sequentially utilize those two artifacts in two diﬀerent phases of enterprise engineering.


Introduction
Enterprise engineering is an emerging sub-discipline of systems engineering that studies enterprises from an engineering perspective. Loosely summarized, enterprise engineering has attempted to view enterprises from the perspective of engineering and then (re)design and (re)implement them. Many researchers and practitioners have been working on this new challenge and have produced a variety of artifacts, such as ArchiMate [1], Enterprise Ontology (EO) [2], 4EM [3], MEMO [4], Normalized Systems theory (NS) [5], S-BPM [6], and so on. On the other hand, some of those artifacts seem to exhibit some overlap in purpose. However, since they have been developed to achieve their own specific goals, they have their own aptitudes by nature. Instead of pursuing the ultimate and apparently arduous goal of unifying them into a single theory, it seems both feasible and valuable to explore a way to combine some of those artifacts in a beneficial manner.
Therefore, this paper tries to find a possible way to combine two artifacts that have recently raised interest, namely EO and NS, rather than unifying them. Indeed, there are several existing studies which tried to compare and potentially find a clue to the unification of the two artifacts in the past. However, most of them achieved limited success, possibly because the two artifacts were compared in the same class of artifacts. In contrast, the authors believe that they should be located in different classes: modeling principles and design principles, respectively. Therefore, this paper investigates the literature, keeping this hypothesis in mind. Stated another way, this study will answer the following research questions: (1) Is EO a modeling principle? (2) Is EO a design principle? (3) Is NS a modeling principle? (4) Is NS a design principle?
The remainder of this article is organized as follows: Section 2 provides brief introductions of the theories of EO and NS, related past works, and the basics of modeling and design principles in the context of model-based systems engineering. Section 3 is the main part of this paper, answering the research questions by collating descriptions of EO and NS with ones of modeling and design principles. After reflection and discussion in Section 4, Section 5 concludes this article with possible future directions for research.

Theoretical Foundation
Enterprise Ontology 1 EO can be loosely described as a well-founded distinctive set of notions, theories, and a methodology for grasping and steering the complexity of enterprises. Here, enterprise is an overall term to identify an intentionally created entity of human endeavor with a certain purpose, e.g. a company, organization, business, governmental agency, and so forth [7, p. 4]. Although EO may accommodate more than one methodology in principle, there exists only one methodology available at this moment, known as "Design & Engineering Methodology for Organizations (DEMO)". The basic assumption of EO is that enterprises are highly complex, as well as highly organized, entities, and thus, a formal theory and methodology are required to achieve the purpose of an enterprise [7, p. 4]. By collating this comprehension against the definition of a system, enterprises are regarded as systems and are now a subject for systems engineering.
The Four Axioms. EO defines its ways of thinking in four axioms 2 . The operation axiom states that "[...] the operation of an enterprise is constituted by the activities of actor roles, which are elementary chunks of authority and responsibility, fulfilled by subjects" [2, p. 81]. It also classifies the activities and facts produced by the activities as either production acts/facts or coordination acts/facts (C-acts/facts). The transaction axiom states that C-acts are performed sequentially following the steps in the universal pattern, called a transaction (Fig. 1a). Some C-acts may be performed implicitly or tacitly. The composition axiom defines how transactions are interrelated: every transaction is enclosed in another transaction, or is triggered by actor roles in the environment, or is self-activated. This provides a well-founded definition of a business process: a collection of causally related transaction kinds. The distinction axiom defines another classification of human activities into original, informational, and documental. Indeed, this axiom asks modelers to ignore informational and documental activities for a substantialreduction of complexity.
The Organization Theorem. In mathematics, a theorem is a statement that is not self-evidently true but is proven to be true as a logical consequence of axioms. Similarly, as derived from the aforementioned four axioms, the organization theorem states that an organization is a heterogeneous system that is constituted as the layered integration of three homogeneous systems: the B-organization for operating original activities, the I-organization for operating informational activities, and the D-organization for documental activities (Fig. 1b).

Fig. 1: Concepts in Enterprise Ontology
Normalized Systems Theory 3 NS theory aims to design systems pursuing evolvability and observability, originally in the field of information systems development. The basic assumption is that information systems must be able to evolve over time while accommodating future changes which defy Lehman's law of increasing complexity, which is a part of his software evolution laws [9]. To accommodate future changes, information systems must exhibit stability against those changes. It means that the impact of a change should only be dependent on the nature of the change itself [5, pp. 106-107]. Otherwise, if the impact of a change-ripple effect-is dependent on the size of the system, thus if it requires more effort as the information system grows, the ripple effect is specifically called a combinatorial effect. High evolvability is achieved by removing combinatorial effects.
NS Theorems. NS gets involved in the process of transforming requirements R i (i.e. functions) into primitives P j (i.e. construction). In order to achieve a good F-to-C transformation that does not produce any combinatorial effects, NS has proposed a set of four NS theorems [10, pp. 88-96] 4 : -SoS; Separation of States When a primitive uses another primitive as it is executed, both primitives should be separated by a state. -SoC; Separation of Concerns A primitive should only contain one concern. -VT; Version Transparency A primitive which is used by other primitives should be version transparent. -IT; Instance Traceability The input received to execute a particular primitive instance, as well as the output delivered by that primitive instance, should be traceable to the particular version and instance of that primitive.
If the transformation is performed along with the theorems, it should look like Fig. 2b, in contrast to a typical transformation like Fig. 2a, which may contain combinatorial effects. These theorems are independent of application domain.
Guideline and Element. From the theorems, a set of guidelines can be derived for a specific application domain, such as information system management, business process reengineering, accounting, enterprise resource planning, etc. The guidelines can be actualized by elements, which are reusable sets of primitives. Guidelines and elements are often dependent on specific application domains, in contrast to theorems. In software engineering as a specific application domain, six NS guidelines are derived from the four NS theorems and are implemented by a set of five elements (which allow the expansion of software which adheres to these principles): data element, action element, workflow element, trigger element, and connector element. In business process engineering, the theorems are re-interpreted to derive guidelines. The theorems produce 25 specific guidelines named Normalized Systems Business Process (NSBP) guidelines. Currently, no elements implemented by NSBP are available.

Related Works
[11] studies an alignment of the construct of EO and that of NS by expressing the transaction pattern of EO in the form of NS elements, namely data elements and workflow elements. In order to implement transactions without combinatorial effects, it prescribes two guidelines: (1) additional state transitions need to be created in order to comply with the SoC and SoS theorem, and (2) the cancellation patterns should be implemented with extensions to accommodate their adherence to the NS theorems. The study mainly discusses an emergence of combinatorial effects during the implementation process from the ontological model to the real implementation. Put another way, whether combinatorial effects may occur within the ontological model and even how to remove combinatorial effects remain beyond the scope of the study. [12] also studies an alignment and combination of EO and NS by establishing a linkage and collaboration between agile enterprises (realized with EO), and agile automated information systems (developed with NS). This research proposes mappings of concepts in EO onto elements of NS with wider coverage than [11]. It also points out that aspects such as user interfaces and non-functional requirements, which are not presented in EO, are considered as aspects in crosscutting concerns, which should be addressed separately from the functional requirements in NS. Moreover, it reveals that NS does not yet support all concepts of EO, such as a derived fact kind and information link.
[13] is another work with an approach different from the previous two studies [11,12], in which NS elements for software are directly compared and mapped to EO. Instead of the direct approach, this study compares EO concepts and not NS elements for software but the guidelines of NS Business Processes (NSBP), which are derived from NS theorems for the business process domain. Then, it analyzes to what extent the NSBP guidelines are consistent, complementing, or conflicting with prescriptions from EO. This study concludes that 13 of 25 NSBP guidelines are consistent, 12 of them are ignored and don't appear in EO, and 4 of them are conflicting (there is some overlapping).
In these studies on the relationship between EO and NS, the two artifacts are compared in the same class of artifacts.

Model-based Systems Engineering Methodology
This section revisits model-based engineering (MBE) to formulate distinct perspectives on modeling principles and design principles to prompt a good understanding of this article.
Modeling and Design MBE is sequentially decomposed into two parts: modeling and design.
Since these terms mean different things to different people, the following paragraphs are cited from the literature to formulate the meaning of them within the scope of this article: Quote 1 for an overview, Quotes 2 and 3 for modeling, and Quote 4 for designing. Quote 1 ([14, p. 2]). John G. Truxal, former Dean of Engineering at Brooklyn Polytechnic Institute, says, "Systems engineering includes two parts: modeling, in which each element of the system and the criterion for measuring performance are described; and optimization, in which adjustable elements are set at values that give the best possible performance." Quote 2 ([15, p. 107]). A conceptual model is a mental image of a system, its components, its interactions. It lays the foundation for more elaborate models, such as physical or numerical models. A conceptual model provides a framework in which to think about the workings of a system or about problem solving in general. An ensuing operational model can be no better than its underlying conceptualization.
Quote 3 ([16, p. 1]). The role of conceptual modelling in information systems development during all these decades is seen as an approach for capturing fuzzy, ill-defined, informal "real-world" descriptions and user requirements, and then transforming them to formal, in some sense complete, and consistent conceptual specifications.

Quote 4 ([17, p. 4]).
The engineer, and more generally the designer, is concerned with how things ought to be how they ought to be in order to attain goals.
Principles Let us focus on the role of principles in modeling/design as a normative notion that guides system design. A modeling/design guideline is a guideline or a set of guidelines that assist(s) us to achieve a good model/design and avoid a bad model/design. It also defines what is good and bad. It is often referred to as design guidelines, patterns, architectures, theories, et cetera.
Modeling Principle. The nature of modeling is characterized by three concepts: mapping, i.e. which element in the real world and which element in the model should be mapped with each other; reduction, i.e. which element in the real world should be selected or ignored; and pragmatism, i.e. models as the outcome of modeling activities should be made to be utilized [18, p. 157]. Thus, a modeling principle should provide guidelines for mapping, reduction, and pragmatism. Design Principle. The nature of design is difficult to summarize. Nevertheless, an anatomy of design theory proposed by [19] defines the characteristics of information systems design theory (regarded as a design principle) by specifying core components:

Separation of Modeling Principles and Design Principles
This section examines EO and NS by comparing each of them against the characteristics of modeling principles and design principles, as revisited in Section 2.3.
Is EO a modeling principle? [2, p. 10] states that "Our goal is to understand the essence of the construction and operation of complete systems; more specifically, of enterprises." This adheres to the general characteristics of modeling in the sense of Quote 3. It is also stated that "Firstly, the P[rocess]M[odel] facilitates discussions about the redesign, as well as the re-engineering of business processes [...]." in [2, p. 10], which also adheres to Quote 2. This point is also supported by the fact that the acronym of DEMO, a methodology of EO, was initially Dynamic Essential MOdelling (and later Dynamic Essential Modeling of Organizations). Therefore, EO is along the lines of modeling.
Moreover, EO seems to fully satisfy the conditions as a modeling principle as formulated in Section 2.3. As explained in Section 2.1, the operation axiom defines what and how the mapping should be-i.e. what the elements in enterprises are, and how to identify these elements-and the distinction axiom defines the reduction-i.e. which among these elements should be included in the model. The general direction of EO also adheres to the concept of pragmatism. Therefore, EO can be regarded as a sort of modeling principle.
Is EO a design principle? In EO, it seems that there does not exist any statement regarding design principles except the system design process [2, pp. 73-77], called the Generic System Design Process (GSDP) in [20]. GSDP defines the first step as function design-designing the function of the object system (OS) based on the construction of the using system (US)-and the second step as construction design-designing the construction of the OS based on the function of the OS (Fig. 3). However, it does not define guidelines for the substantial procedure, i.e. design principles, in the function design or construction design. Those substantial guidelines are called architectures in GDSP [20], but the content of the architecture is not specified there. Put differently, GDSP prescribes an ideal design process from a meta-meta-level. Therefore, EO is substantially not a design principle. This observation is supported by comparing GSDP to the components of design principles prepared in Section 2.3 and finding that they are just not on the same wavelength. For instance, purpose and scope might mean to "understand the essence of the construction and operation of complete enterprises", but they are too abstract in contrast to the ones in NS-to be evolvable. Similarly, although constructs might be actor roles and transaction kinds, these are as primitive as attributes and methods, or at the most classes; it seems unknown how to aggregate those primitives into reusable elements, for achieving the purpose (which is also as yet unspecified by EO). The justificatory knowledge of EO is social science and systems engineering. However, other components, except the ones mentioned so far, are misted. Therefore, it is hard to assert that EO is a design principle.
Is NS a modeling principle? It seems that NS does not define anything about mapping in either of information systems or business processes. Indeed, research in NSBP employs an external artifact, namely Business Process Model and Notation (BPMN), for mapping the real world to the models. The transformation matrix may look like a mapping, but this is not the one specified in Section 2.3, where mappings between objects in the real world and elements in the model are defined, because the transformation matrix represents another kind of mapping from the function (requirements R i ) in the model to the construction (primitives P j ) in the model: This is also the case for reduction. Therefore, it is asserted that NS is far from a modeling principle.
Is NS a design principle? It is almost an established understanding that NS is a design principle. NS was originally a design principle in the domain of information system development, but has been generalized and extended to be a design principle in the domain of business processes. In both the domains, the purpose is the same, i.e. to enhance evolvability and observability. The components of design principles are fully specified in [21]. Therefore, NS is regarded as a design principle.

Discussion
Reflection on EO A question then arises: what is the rationale behind the absence of design principles in EO? The answer might be given if we see the motivation of EO: starting from the point that enterprises as a phenomenon existed in the real world, but no models were available, due to the lack of modeling artifacts, to explicitly identify the components and capture interactions and mechanisms. Although EO with DEMO is occasionally considered as a design theory for organizations, the result of this present research implies that EO has accomplished the hard and important work of making enterprises designable and engineerable, rather than continuing to propose guidelines for better designs of enterprises on the layer of models. This achievement has definitely had an impact, as supported by the fact that EO and DEMO have been used on many occasions.
Strictly speaking, EO includes GSDP, as seen in Section 3. However, GSDP can be positioned in the meta-meta-level and still allow room for design principles at the meta-level to get involved. In other words, EO is noncommittal and neutral regarding design principles. Thus, as long as the model is made to adhere to the standards of EO, EO does not provide any decision criterion to evaluate the model-i.e. whether a model is better or worse than another model for the same requirement.
Another interpretation is that EO as a modeling principle may work with more than one design guideline. The design principles might be brought by NS and/or other design principles (e.g. Service-Orientation systems [22]). Unless the design principles are ones analogically transplanted from other disciplines, they can be directly built on EO, as seen in [23], in which guidelines for splitting and allying enterprises are proposed based on organizational science. "Neither modeling principles nor design guidelines are superior, nor does one include the other. Modeling principles and design guidelines are at work in different layers. In other words, if either modeling principle or design principle is ignored, the whole process of engineering cannot be completed.
Reflection on NS Another question arises: what is the rationale behind the absence of modeling principles in NS? In part, it is because that computers have been developed with the real world and conceptual models together. Here, models may refer to models represented by modeling languages such as Unified Modeling Language, or even refer to source code written in a programming language. Since the behavior of computers or CPUs is fully understood, we are knowledgeable about the components of software and their internal working mechanisms. That knowledge guarantees the solid and fine-grained alignment between these models and actual behavior including electronic phenomena in semiconductor circuits. Therefore, it requires almost no concern, and we take it for granted. This seems to be a clue which leads to answering why modeling principles are not often discussed in the field of software engineering. Instead, many discussions are diverted to the next step, i.e. how to develop a good design. Put differently, this idea is supported by the fact that when NS was extended into the business process domain, a modeling principle was required, and indeed BPMN was adopted.

Conclusion
The primary conclusion is that there is an orthogonality or complementarity between modeling principles and design guidelines. In other words, modeling principles and design principles are at least two different independent variables in enterprise engineering. This implies that EO as a modeling principle may work with design principles such as NS. In general, more than one design guideline can be employed at the same time. For example, the service-orientation design principles can be another design principle for designing enterprises. It may happen that some design guidelines conflict with each other.
The results also show that substantial design guidelines may swing and miss in a certain modeling principle, at least in EO. On the other hand, a substantial number of NSBP guidelines do not emerge in EO models because what the NSBP guidelines state are observed in the informational layer, and thus, are ignored in DEMO models. Moreover, the possibility should not be dismissed that a modeling principle itself might conflict with a design principle. Indeed, [13] pointed out that a very few components of EO conflict with the design guidelines of NS.
The direction of future research is to explore other principles that might be helpful in designing and instantiating enterprises. One approach is to fix a selection of the modeling principles and use design principles as a free variable. For instance, an as-is EO model (DEMO model, not EO or DEMO itself, but a model) can be redesigned for evolvability and observability by deriving a design principle from NS by analogy. The same original as-is DEMO model can also be redesigned differently for a service-oriented structure by deriving a design principle from service-oriented systems by analogy. The other approach is to fix a selection of the design principles and use modeling principles as a free variable. For example, NS may be able to provide a design principle for DEMO models. It may also furnish one for ArchiMate models, for instance. Since the existence of congeniality or uncongeniality between modeling principles and design principles are implied in the previous paragraph, this direction also awaits further investigation.