Keywords:
Astract: When designing modeling languages, researchers and practitioners often take contradicting positions. While the former argue for formal soundness and precise specification, practitioners aim for more flexibility in using a modeling language, i.e., by adapting it to a specific project context. The same distinction applies to the differentiation between modeling tools and drawing tools. While the former enable model processing functionality and support modelers in creating only valid models, in practice, too often the latter tools (e.g., Visio or even PowerPoint) are used due to their ease of use and non-constraining nature. When aiming to introduce flexibility into modeling languages, one often needs to have metamodeling knowledge. Besides, changing the metamodel requires re-deployment of tools and hampers compatibility with previously created models. In this paper, we introduce the notion of modeling language jargons as a means to countervail these two contradicting positions. With such jargons, on-the-fly adaptation of modeling languages can be achieved by business users without requiring changes to the metamodel. To illustrate the conceptualization and use of modeling language jargons we report on the Fractal Enterprise Model (FEM) language and the experience of using the FEM tool in practice.

Keywords:
Astract: This paper reports on the plenary panel discussion on "How to Build a Perfect Enterprise Modeling Method" held at the PoEM 2021 conference. The panel was charged with finding a pathway to the perfect enterprise modeling method. The panelists have a background in enterprise modeling and method engineering. So, the question is: Can method engineering help with designing a better enterprise modeling environment? The contributions in this paper should be regarded as a snapshot of our viewpoints at the time of the panel.

Keywords:
Astract: The heterogeneity in enterprise design stakeholders and models gen- erally demands for consistent and efficient transformations of enterprise design knowledge between different conceptual modelling languages. A systematic pro- cess and precise model transformation specifications are a prerequisite for realizing such transformations. The Design and Engineering Methodology for Organiza- tions (DEMO) approach represents the organization design of an enterprise in four linguistically based, semantically sound aspect models. The Business Pro- cess Model and Notation (BPMN) on the other hand enables more flexibility in creating models and benefits from wide adoption in industry, the execution of pro- cesses e.g., by simulations, and the availability of proper tooling. A transformation of DEMO models into BPMN models is thus desirable to avail of both, the seman- tic sound foundation of DEMO and the wide adoption and execution possibilities of BPMN. Previous research already developed some principles and practices for transforming DEMO models into BPMN models, based on DEMOSL 3.7. This study focuses on the latest DEMO language specification, DEMOSL 4.5, since we believe that more clarity is required to specify consistent, well-motivated trans- formation specifications. We present a list of main requirements for developing transformation specifications to transform concepts represented in a Coordination Structure Diagram and Process Structure Diagram of DEMO into corresponding concepts in a BPMN collaboration diagram. The article makes three contribu- tions: (1) Generic requirements for developing DEMO-to-BPMN transformation specifications; (2) Nine transformation scenarios that are validated by multiple demonstration cases; and (3) A comprehensive college case that demonstrates all transformation scenarios.

Keywords:
Astract: Semantic processing of conceptual models is a focus of research since several years, bridging the disciplines of knowledge-based systems, conceptual modeling, and model-driven software engineering. With the uptake of Knowledge Graphs, the research in this area gained further momentum. In this paper, we introduce a generic and extensible platform that enables the automated transformation of conceptual models into Knowledge Graphs. The platform can transform any model created by a state-of-the-art metamodeling platform (EMF and ADOxx) into standardized Knowledge Graph representations like GraphML, RDF, and OWL. In the paper at hand, we introduce our platform and evaluate it with a corpus of 5.000 UML models that we transform into Knowledge Graphs and subsequently exemplify the rich functionalities enabled by the graph structure by an automated detection of UML model smells.

Keywords:
Astract: The Digital Transformation of our society requires IT infrastructures to be more agile, more adaptive, and more connected than ever. At the same time, the owners of such infrastructures are confronted with an increase in regulatory pressure (e.g., the GDPR). These developments put a lot of stress on IT management and governance. To enable IT management and governance to better deal with these challenges, we propose to digitally transform IT governance and management itself by using a Digital Twin based approach. In line with this, we aim to create on ontology-driven Digital Twin for Governed IT Management (DT4GITM) framework. The goal of this framework is to act as a reference architecture for a Digital Twin based infrastructure that connects three interrelated systems: the IT governance processes, the governed IT management processes, and the managed organizational IT assets. The core of the framework involves a generic Governed IT Management (GITM) Domain Ontology, which is planned to be operationalized by a Knowledge Graph based approach that realizes an integrated view on the heterogenous data streams originating from the IT governance and management processes, and the managed IT assets. In this paper, we start by outlining the planned DT4GITM framework and the pivotal role of the GITM Domain Ontology within this. We then elaborate our incremental, and scenario- and case-driven strategy towards the development of the framework as a whole, and the GITM Domain Ontology in particular. This is followed by the elaboration of a specific DT4GITM scenario which serves as a first proof of principle.