Frank Wolff
email: frank.wolff@dhbw-mannheim.de

Explorative Survey into Goals, Focus, Experiences and Extent of Enterprise-wide Process Modelling in Practice

Keywords: Modelling goals, Modelling practice, Enterprise modelling, Business process modelling, Experiences

Enterprise modelling promises many potential returns to companies but also entails some challenges for those institutions who engage in enterprisewide modelling activities. To improve understanding in this area, an explorative survey has been devised with a number of companies from diverse industries. The focus is on business process modelling but also IT models are addressed. Most companies align their enterprise process modelling to one leading goal. While the extent of the model portfolios is very impressive, modelling often still does not cover all of the company. Further in many instances reported issues were the motivation of experts to cooperate with modelers, the integration of organizational and IT-models, and modelling tool related topics.

Introduction

Enterprise modelling comprises many facets, notably strategy, organization, and resources, particularly IT-systems. In practice and research diverse modelling methods have been devised (e.g., MEMO [START_REF] Frank | Multi-Perspective Enterprise Modeling: Foundational Concepts, Prospects and Future Research Challenges[END_REF], ArchiMate [START_REF] Lankhorst | Enterprise Architecture at Work -Modelling, Communication and Analysis[END_REF], BEN [START_REF] Braun | A Comprehensive Enterprise Architecture Metamodel[END_REF], or ARIS [START_REF] Scheer | ARIS: Business Process Modelling[END_REF]). In this but also other respects, research in enterprise modelling is predominantly constructive or technically oriented. Only a smaller part of research is concerned with the creation and usage of models in an extensive organizational context.

To provide some more insights in this field, the research documented in this paper is set up to gather a) experiences on major issues in enterprise modelling and b) evidence on the extent and the complexity of practical modelling in companies.

Communication with practitioners in enterprise modelling often indicates that enterprise-wide modelling is not executed as intended by management and specialists in charge of modelling methodologies. Therefore, also unresolved questions, dependencies between different areas and frictions in organizational practice are searched for, as they are important for management of enterprise-wide modelling and can well direct new research.

Explorative Research in Enterprise Modelling Practice

Enterprise modelling is in many ways crucial to company interests. Information presented in the models is oriented towards future plans of the company, or it can uncover problems which would otherwise remain unnoticed. For these reasons, it is rather subtle to gather and compile findings on practical usage of enterprise modelling in companies. In chapter 1.3 and 2 the related problems will be discussed in more detail.

This paper is a first step in research to collect practical experiences in enterprises on the usage of modelling, its extent and main issues to manage enterprise-wide modelling activities. It is connected to endeavours to better understand the underlying mechanisms and dependencies in large concerted modelling activities to support its management and sustainability. [START_REF] Wolff | An Evaluation Framework for Enterprise Architecture Modelling[END_REF], [START_REF] Franz | Value-driven Process Management -The Value Switch for Lasting Competitive Advantage[END_REF] It complements other research like a) related research in theoretical areas with validation by company examples, e.g.: [START_REF] Persson | Enterprise Modelling in Practice: Situational Factors and their Influence on Adopting a Participative Approach[END_REF] and [START_REF] Löhe | Overcoming implementation challenges in enterprise architecture management: a design theory for architecture-driven IT Management (ADRIMA)[END_REF], b) reports from industrial practice cases, e.g.: [START_REF] Kopetzky | When Giants Learn How to Dance -The Introduction of Process Management to a Health Insurance Fund[END_REF] and [START_REF] Kogelschatz | Closed Control Cycle for Business Process Management on the Credit Suisse Securities Platform[END_REF] or c) surveys on influential factors for success of enterprise modelling in industry [START_REF] Yilmaz | Factors Influencing Productization of Enterprise Modeling: A Qualitative Inquiry into the Scandinavian Strand of Methods and Tools[END_REF] and [START_REF] Eikebrokk | Towards a Model of Process-Modelling Practice: Quantitative Validation and Results[END_REF].

Issues in Enterprise-wide Modelling

Enterprise modelling comprises a plethora of aspects which influence the results an organization can reap from its modelling effort. [START_REF] Wolff | Ökonomie multiperspektivischer Unternehmensmodellierung[END_REF] Therefore, in an exploratory study to get more insight into influential factors for management, only a few prominent aspects can be investigated. Hence, the survey centres on: a) the organizations and their goals which direct the modelling, b) basic methodological aspects, like, the modelling language, the organization of model development and integration between different kinds of models, c) crucial elements are captured in two categories, c1) the modelling tool and c2) further emphasized experiences. d) Finally some results from enterprise-wide modelling are reported, the extent of modelling, success stories and economic issues. Figure 1 depicts an overview on the topics.

Consideration of Potential Research Methods on Enterprise Modelling Practice

Research in enterprise-wide modelling practice is challenging in various respects. The company models often contain vital information of and for an organization. Therefore, also their creation and other aspects are handled confidential. Another aspect is comparability and precision of data. In many contexts of business research one is accustomed to a high degree of precision, especially, if information can be gathered by measurements. But the field of modelling is quite diverse and highly specialized. Also measurements are rarely used. Hence, a study in the practice of enterprise modelling usually relies on information provided by experts. This and the differentiation of organizations advise to consider the effect of varying perspectives and potentially resulting differences in interpretations. Before considering the demands of adequate interpretation of collected data, the method to gather information must be determined. Generally, there are a number of different methods available to collect evidence from a number of organizations. Most prominent are questionnaires and interviews. [START_REF] Babbie | The Basics of Social Research[END_REF] A questionnaire can be well adapted to standardized or properly understood objects of investigation. As the practice of enterprise modelling as a wider organizational effort has seldom been described in a homogenous frame, an investigation with a questionnaire is not advisable. Also the response rate, in this kind of surveys, is quite low and would probably distort the results. [START_REF] Dillman | Internet, Mail and Mixed Mode Surveys[END_REF] For these reasons and because of the exploratory character, it was decided to base the survey on semi-structured interviews with practitioners. The discussions were directly documented in notes and compiled afterwards. Unclear information was validated after the interviews in a number of cases. Criteria for the selection of partners were: a) the organization practiced a concerted modelling covering most or crucial parts of its business; b) it employed a central repository for integrating different results; and c) the organizations should vary in respect of size or industry or another major characteristic to provide for a more realistic account of enterprise modelling in practice.

In the beginning, it was intended to investigate different perspectives in enterprise models, like business process models, IT models, and strategic models. However in the early stages, most contacts were established with practitioners in the field of business process modelling. This provided a common basis and had positive effects for the documentation of the findings. While not looking at enterprise architecture models directly, nevertheless, the IT perspective was very prominent as for numerous companies the processes are fundamental for IT-system development. Another topic, which was regularly addressed, was supplementing the business processes with relevant information on supporting IT resources.

There are some limits inherent in this kind of approach and research. They are rooted in the subjective judgements and interpretations of the participants, and further connected with the impossibility to reach statistically satisfying samples. Nevertheless, the research is based on input from very experienced practitioners with in depth knowledge on the topic. Also often different hierarchical levels of the organization were involved like senior manager and modelling specialist. So information from different perspectives had been collected. Sometimes a person was only able to provide information from one perspective or specific information was not available. This is a limitation in this survey. It is due to the sophisticated topic and the exploratory character of the talks. Anyway, very illuminative, although not all desirable, information could be obtained. To account for this, the specific number of entries has been documented in most findings of this survey. For the reasons stated, it is in a number of cases lower than the total of the surveyed organizations.

The general method used was the interview. But as the interview part was complemented with information provided by the researcher, the term talk is used frequently in this paper. The organizations represented in the survey stem from diverse industries and also have different sizes. However, there are some industries represented with a higher proportion as in industry in general.

Another challenge was to interpret the individual elements of information in an appropriate way. In this respect the interpreter had to work carefully, as the statements from the practitioners in many cases were bound in their experiences and background. [START_REF] Bonsack | Rekonstruktive Sozialforschung[END_REF] It was an advantage that the researcher had worked in this field for many years. So it was usually possible to specify the specific terms used and information given by inquiring their context and meaning.

Results of the Survey on Selected Organizations

The talks with the organizations presented in this study started in the middle of 2015 and the last was in spring 2016. When this research was initiated, it was intended to focus on qualitative issues but also collect some quantitative data. This quantitative data was meant to complement the qualitative information. When the interviews were analysed and prepared for communication, another challenge emerged. As the information originated from confidential contexts, it could not be straightforwardly presented. This potentially would have revealed specific organizations described. When considering this, the author remembered research findings of a survey on numerous modelling methods in morphological boxes. This kind of box can represent the distribution of characteristics giving an overview on the findings. 1 This quality makes it particularly suitable for communicating a rich, but nevertheless realistic picture of the current state of enterprise-wide modelling with focus on business processes.

The organizations examined represent a wide variety of typical users of business process modelling as shown in Table 1. The financial industry seems to be over weighted. This may be due to the available contacts but it also reflects the more widespread use of process modelling in this sector because of legal requirements. The size of the organizations varies widely between medium sized organizations with 400 employees (minimum of stated values) and large organization with 130,000 employees (maximum of stated values). The average number of employees was 31,000. The distribution of sizes of the organisations is mixed in relation to industry, so there are smaller and bigger organizations in most of the industries. Six of the organizations are international. Most of them use an integrated approach with common process patterns shared in all countries and only adapted for specific regional requirements.

Organizations Overall: 11 -(Major interviews: 10 ; partial interviews: 1)

Industry

Financial Local organization 5

Entries 11

Tab 1. Overview on the organizations presented in the study.

Goals of Enterprise-wide Business Process Modelling

The goals of a modelling activity are pivotal for many aspects, how modelling is set up and performed in an organization. [START_REF] Wolff | Better Segmentation of Enterprise Modelling Governance through Usage Perspectives. The Practice of Enterprise Modeling[END_REF] As modelling can support multiple goals of an organization, this aspect is separately presented in a) the main goal of business process modelling (Table 2), and b) further goals the organizations are striving to reach with its modelling activities (Table 3). The fulfillment of legal obligations is the main goal to model business processes for most companies. Organizations have to comply with standards from regulatory agencies, e.g., in the finance sector or in health care, but also with other governance standards like Sarbanes-Oxley Act or COBIT. Fewer organizations, but still one third, stated that their main focus was on IT and other development projects. One international organization used its models to standardize procedures in different locations, and to swiftly establish new sites.

Main Goal Number of Organizations

Most, but not all, organizations mentioned further goals, they pursued with business process modelling. Some mentioned more than one additional goal. Perhaps not surprisingly, most organizations (6) regard their models as source to find options for improving their business. Four organizations use their business process models in projects and as knowledge base. Two organizations employ their process models for process controlling. Also mentioned was the provisioning of information for data protection laws and an additional use in risk management. Anyway, the emphasis in the reported experiences was always placed on the main goals.

Additional Goal Number of Organizations

Remarks

Business Reorganization and Improvement

Methods and Structures used for Enterprise Business Process Modelling

The organizations represented in the survey are using different modelling languages and furthermore their methodological rules for model structure vary. In Table 4 the characteristics of the distribution of values are described. Most organizations used EPC (Event driven Process Chains) as their modelling language. Some tendency was noted to switch to BPMN (Business Process Modelling Notation). Sometimes BPMN was used in parallel with other languages. But in other cases, depending on the overall integration of processes and the repository, a more sophisticated transition was deemed indispensable. Anyway, also disadvantages were noted in respect of BPMN and the compactness of its representation of roles in separate lanes. Besides EPC and BPMN also Process modelling based on ISO (International Standards Organization) Flowchart notation was employed by 4 companies. They noted a good acceptance by readers of the models of business departments. Concerning the levels of modelling (from process overviews to detailed steps of work), the organizations had similar structures with the number of levels ranging from 4 up to 6 and an average of 5 levels. The number of types of base process areas in the company process map varies to a greater extent, in this study between 7 and 26. As Footnote 4 indicates, this number is depending on diverse organizational conditions and may be dominated by the domain or political valuations of its management.

Process

Organization of Modelling

The organization of modelling reflects the distribution of work between the central modelling department and the specialists in the field who know how actual work is done and by that the fundamentals of the business processes.

For reasons of the different required know-how 5 and the motivation to share it in models, some advocate a central modelling approach and others a decentralized 2 Two of the methods used standard symbols from the business modelling tool employed and two other organizations had custom designed symbols and elements. However, they were semantically close to the ISO Standard for Flowcharts which has been noted in the table. 3 The overall number of modelling languages used is bigger than the entries (organizations represented in this aspect of the study). The reason for this is that two organizations are temporarily using two languages in parallel. 4 As for this aspect only three values were available, the value 24 was the middle value stated.

It was annotated by the responsible for modelling that the top management had mentioned the extreme values of their competitors having 10 or 32 types of processes which were both reckoned as inacceptable. The result with 24 types was well situated in the middle.

approach. This was reflected in the approaches chosen by the examined organizations. Five of them followed the strategy of central modelling and the same number used decentralized modellers. All persons responsible for modelling were aware of the limitations of both approaches. One organization reported to use a combined or mixed strategy depending on the know-how of the department. Others mentioned internal discussions to switch from one mode to the other. A main influential factor in both scenarios is the number of active modellers. The number of central modellers ranged between 5 and 10, and the minimum number of decentralized modellers was 30 and its maximum 500. While the number of central modellers is more likely to be criticised for the associated cost, the higher numbers of decentralized modellers require more support and effort to create high quality models.

Kind of division of work

Integration of IT-Modelling and Business Process Modelling

Enterprise modelling is based on an integration of different perspectives. In practice of business process modelling which became the focus of this survey, this is reflected by the high importance of the integration of IT-systems in process models. All partners of the dialogues were aware of the relevance. One organization is using a single repository for IT-system and process models. Two large organizations are replicating their IT-Systems from the EA models or CMDB to the process model repository and three organizations plan to implement a replication. Only two organizations stated that they will not combine the information of the IT and the process sphere. Although there are convincing arguments for full integration (compare [START_REF] Frank | Multi-Perspective Enterprise Modeling: Foundational Concepts, Prospects and Future Research Challenges[END_REF], [START_REF] Scheer | ARIS: Business Process Modelling[END_REF]), the vast majority of organizations decide for a separated approach. This may originate in its correspondence with the internal department structures.

Integration of IT-system-and Process models

Single repository: 1

Replication of IT-Systems: 2

Replication of IT-Systems planned: 3 None 2 Tab 6. Integration between process models and information on IT-Systems used.

Some Important Aspects of Enterprise Modelling Tool in Practice

The modelling tool is an indispensable prerequisite for effective modelling in a longterm and wider organizational context. [START_REF] Frank | Multi-Perspective Enterprise Modeling: Foundational Concepts, Prospects and Future Research Challenges[END_REF] In many organizations the tool is synonymous for modelling activities. This may entail issues, if a tool gets a bad reputation. In these cases the organizations introduced new labels for the access of the process models. For several organizations a major update of the modelling tool version was mentioned as an important challenge and change. Some organizations reported that they had completed a corresponding update or were considering it. This was independent of the type of tool employed. Some had completed this update, including e.g., new symbols in their models. They reported a considerable effort with 5 or more people working 2 to 4 months to transfer and adapt the models to the new version. This may be a reason, why the other 4 organizations stated, they did not want do this kind of change in the near future, although it would be possible. Some other aspects concerning the modelling tool were indicated more briefly by a number of the organizations. Two organizations referred to a change of their modelling tool. All others were steady and consistent concerning the tool. Anyhow, some participants mentioned internal discussions about other options to the current modelling tool. More than half of the questioned organizations reported that besides the standard modelling tool, also other tools were used by some departments or for different objectives.

Big tool version change with change of modelling elements

Four organizations used dedicated views for different stakeholders. Additionally, some important supplementary functions were mentioned by the practitioners. These were a) the provision of workflows for the quality assurance and b) a publishing portal for an easy access to the models for all employees. A few more crucial factors for successful enterprise wide modelling were addressed by the practitioners. Three organizations emphasized the relevance of having a sponsor with a high senior management position in the organization. Similarly important to that, others deemed the existence and practical realization of having a) common reference or contact points for process interfaces and b) role models employed in a consistent way. For one organization, this was a clear success factor while another organization reported problems due to low realized standards in this respect. Further, two organizations stressed the significance of the training of users and modellers for creating good models and achieving the desired results with them.

Aspect

Extent of Enterprise-wide Business Process Modelling

One motive for this survey was to investigate the actual realization of extensive integrated models in practice. So it also inquired on this aspect. The answers were split in two categories. Many, but not all, practitioners declared to have models that were integrated for major parts of the organization. But they also reported of other repositories (or parts of it) that were only fragmentarily integrated.

The maximum number of process models in a systematic framework was 4000. The average was 1850 models and the minimum value stated was 400 process models. These numbers may be criticised because they have not been standardized by weight factors, to account for the fact that the models vary usually in size. Anyway, they convey a notion on the substantial effort the organizations accomplished. The size of an integrated model also accounts for a main influence on the complexity of the models. The overall coverage of the processes of the organization by the available models was asserted only in a few cases. The respective statements supported the impression that the coverage varied by a considerable degree. While some claimed to have an almost full coverage others had just increased the coverage to 50 percent.

The number of the systematic models is complemented with the number of models in all repositories of some of the organizations. It is much higher. This was mostly attributed to the fact that these models also contain older versions. Additionally, they also comprise more detailed or specialized models not included in the central core. Overall, the sample represents very experienced organizations and practice. A number of the participants reported systematic process modelling for 20 years and the average was 12 years. Only very few organizations only had a short experience (min 2 years) in enterprise-wide process modelling.

Systematic (parts of) overall model

Max. 4.000 Aver. 1.850 Min. 400 Entries 8

Number of actual models in the repository

Max. 55.0006 Aver. 22.600 Min. 3000 Entries 4

Active number of years in process modelling

Max. 20 Aver. 12 Min. 2 Entries 10

Tab 10. Number of process models in organizations presented in the study.

Success stories of Enterprise Business Process Modelling

An important boost for an extensive modelling endeavour may be provided by a very successful application of the process models in an organization which is communicated widely. In this respect, four success stories were reported explicitly. They were based on vital projects of the organizations and ranged from extensive reorganizations for new business requirements over the accomplishment of regulations to providing plans and analytical information for improvement of organizational designs and IT systems.

Reported success story of the presented organizations 1 Reorganization of one division including a subsequent quality certification.

2 Fast accomplishment of regulatory requirements.

The solution was taken up as blueprint by the modelling tool provider.

3 Reorganization of the SEPA-Payments of a company, with continual improvement activities based on the processes.

4 Design of a new logistics center based on optimized processes.

Tab 11. Success stories reported.

Economic Issues for Enterprise Modelling Organizations

A complete and monetary economic evaluation of enterprise modelling activities would be desirable but, from a practical point of view, it would be extremely challenging. In the first place, this is due to inherent problems in the valuation of the benefits. [START_REF] Wolff | A Multiperspective Framework for Evaluating Conceptual Models in Organisational Change[END_REF] The benefits of models are often connected with a long-term usage and most of the benefits have quite subtle effects on other activities, so a valuation would have to rely on many assumptions. In the second place, in practice, the cost for modelling is not attributed to dedicated cost centres. [START_REF] Wolff | Ökonomie multiperspektivischer Unternehmensmodellierung[END_REF] In the survey, this was reflected by answers of all participants that no direct capitalization of modelling costs is practiced. 7 Hence from a financial perspective, they are not regarded as assets. Anyway, if one considers the typical effort for average models, the number of models and then calculates the value, this easily results in values of several million Euros for the large organizations. 8 Six organizations explicitly mentioned their current concern to minimize cost for modelling. This is quite reasonable for organizations which are forced by legislation 7 The number of organizations is lower than the complete survey as public organizations in Germany do not use typical commercial accounting schemes with the activation of costs for long-term assets. 8 Although this practice may be justified by the relatively low amounts for these companies in relation to other assets, nevertheless, they represent a distortion of information with relevant motivational effects that impede modelling in many cases. (For the effects of distorted cost information, compare [START_REF] Johnson | Relevance Lost: The Rise and Fall of Management Accounting[END_REF])

to conform to standards but do not directly reap other substantial benefits from the models. In respect of the typical effort to create a process model, two organizations stated similar experiences for the average effort to model a process. It was 2 days for the modeller and this effort had to be multiplied by 2 up to 4 for the work of other participants in the modelling process. At first glance, this factor may seem somehow too high, but it becomes more reasonable, if one considers the diverse additional effort connected with more people getting informed a few times and involved in quality assurance. This increases the effort for a design activity in enterprise modelling by much more than is obvious and straightforwardly noticed.

Important economic issues of enterprise modelling

Number of Organizations

Remarks

Critical Remarks, Conclusion and Further Research

The information gathered in this survey represents genuine findings from modelling practice of a considerable number of organizations. But the study has drawbacks in some aspects. They are rooted in a) the not overall representative sample and b) a necessity to interpret the statements of the participants. These pitfalls have been addressed in the methodological section. 9 Both have impacted the findings. 9 One further condition, which was not explicitly addressed, is that the study has been performed in one country, in Germany. Nevertheless, it comprises directly a small number of companies from other countries. Furthermore, the author attended several international conferences of business process modelling practitioners. In these conferences much evidence has also been given on the respective topics of this survey. This evidence corresponds in its general tendency quite well to the findings in the survey. For some respects e.g., the Nevertheless, the interpretation has been carried out cautiously. This has been documented in the paper by numerous additional notes. The concentration of the survey on enterprise-wide process modelling helped to reach more consistency than if process and IT modelling would have been covered simultaneously.

The findings illustrate a multifaceted picture of process modelling practice. While it is normally emphasized that models easily support a number of goals, most organizations clearly focus on one main goal. This may indicate further potential for higher gains from models. On the other hand, organizations do not systematically care for the economics of their modelling activities. Partly they are concerned with the cost aspects, but from a management accountant perspective, it is performed merely superficially. A complete long-term evaluation of benefits and costs is not established in any of the surveyed organizations. It will not be easy to improve on this, while there is only a limited awareness of the economic potential of enterprise models in organizations. This may be connected with the relatively small number of success stories reported in the study.

In respect of IT modelling, there has been high evidence on the demands for a high level of integration in its models. Nevertheless, this is not achieved easily. The challenges only partially appear to originate from the technical domain. However, they are predominantly rooted in the social interaction between the different participants of modelling. The impressive number of process models in the repositories of large organizations demonstrates the relevance of practical modelling in organizations. Combined with the identified challenges, this also indicates some potential for improvements which hopefully may be facilitated by further research.

Generally the findings of this survey advocate research with focus on issues of long-term commitment in enterprise modelling associated with specifically adapted approaches to observe and steer effort and benefits of modelling, in other words, the performance of the crucial interdependent factors involved in the modelling activities.

Further research directly connected to this survey may take a number of directions. This includes the following alternatives: a) to directly build on this survey and enlarge the sample, b) to change the perspective and investigate the practice of enterprise architecture modelling (concentrating on IT artefacts), c) to explore the reasons why most organizations are not able to employ the models for more than one purpose or d) to investigate the practical obstacles to integration of models. The last questions c) and d) seem to be most interesting because they are crucial to improve the options for organizations to obtain substantially higher benefits.

Fig. 1 .

 1 Fig. 1. Issues for research in practice of enterprise-wide modelling activities.

6 ITTab 3 .

 63 Further goals for business process modelling of organizations questioned.

Tab 7 .

 7 Effect of major version changes of the modelling tool.

  Methodological characteristics in process modelling of organizations in the study.

	modelling methods	EPC: 9 (decreasing)	BPMN: 2 (rising)	ISO Flowchart languages: 4 2 oriented	Entries: 11 3
	Levels of modelling	Max. 6	Aver. 5	Min. 4	Entries 4
	Types of
	base	Max. 26	24 4	Min. 7	Entries 3
	processes
	Tab 4.

  Characteristics of division of labor in modelling activities in organizations of the study.

		Central modelling: 5	Decentralized modelling: 5	Mixture of both: 1	Entries 11
	Central modellers	Max. 10	Aver. 7	Min. 5	Entries 4
	Decentralized modellers	Max. 500	Aver. 130	Min. 30	Entries 6
	Tab 5.

  Emphasized experiences of crucial factors for their enterprise-wide process modelling.

					Number of	Remarks
					Organizations
	Change of process modelling tool		2	One after 20 years of
						usage, the other due to
						problems in the beginning
						stages of its utilization
	Different tools in the organization	7
	besides the central tool explicitly
	noted
	Dedicated	views	for	special	4
	stakeholder groups required
	Tab 8. Further aspects of modelling tools.
	2.6 Further Important Experiences
	Emphasized experiences by the	Number of	Remarks
	practitioners		Organizations
	Support or direct linkage of	3	E.g., having a CPO in top
	process responsibilities to top		management or executive
	management					manager fostering process
						governance
	Process interfaces and common	3	One participant reported good
	role models					experiences with well-defined
						interfaces,	while	another
						referred to interface problems
						due to cultural differences
	Training of users and modelers		2	A start with E-learning was
						not sufficient, only when
						classroom courses started
						modelling activities were
						taken up by departments
	Tab 9.

  Tab

	No capitalization of	8	Modelling costs are sometimes
	modelling costs		capitalized as costs in larger
			IT-or change projects
	Low cost of modelling	6	One organization is
			considering to switch from
			central to decentralized
			modelling to minimize visible
			costs
	Modelling effort for average	2	To include also the cost for
	business process model = 2		domain specialists, this value
	working days		has to be multiplied by a
			factor between 2 and 4

12. Economic issues in enterprise-wide business process modelling.

The research on modelling methods using the morphological box was[START_REF] Kühn | Methodenintegration im Business Engineering[END_REF]. In general, the morphological box has been mainly utilised to foster creativity but it is also employed in business analysis.[START_REF] Ritchey | Wicked Problems -Social Messes[END_REF]

This refers, on one hand, to the knowledge of the domain and, on the other hand, to the knowledge of process modelling and the integration of processes into comprehensive repositories. If modelling is performed only by modelling specialists, the motivation for the domain specialists is lower to support the creation of models than if they are self-constructed. But high demand on quality and integrity seldom can be realized by decentral modellers.[START_REF] Wolff | Ökonomie multiperspektivischer Unternehmensmodellierung[END_REF]

One administrator of a very large organization indicated to have 900.000 models in about 200 repositories of the company's divisions. They practiced process modelling for more than 20 years. Anyway, this value was not included in the main study, as only few other characteristics of the organization were available.


Robert Winter
email: robert.winter@unisg.ch

Establishing 'Architectural Thinking' in Organizations

Keywords: Enterprise Architecture Management, Architectural Coordination, Architectural Thinking

des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

Extended Abstract

Over the past decades, we have witnessed an enormous growth of investments in information systems (IS) in organizations. On the one hand, increasing investments in IS had a significant impact on most organizations' performance. On the other hand, these investments resulted in a significant complexity of the corporate IS architecture (i.e., the organization's fundamental IS components, their inter-relationships, and the principles governing their design and evolution [START_REF]IEEE Recommended Practice for Architectural Description of Software Intensive Systems (IEEE Std 1471-2000[END_REF]), which mainly results from the allocation of project ownership and IS design decision authority to local (business) units. This practice of managing the IS architecture has brought about a large and evergrowing number of heterogeneous IS, which are costly to maintain, tightly interrelated, and which lack flexibility with regard to business changes and technical innovations. Over the years, many organizations have lost control of their IS architecture complexity, i.e., were unable to steer the evolution of their IS architecture so that it maintains a sufficient flexibility in conforming to constantly changing business requirements and technical innovation.

To address this challenge, scholars and practitioners have broadly propagated the concept of enterprise architecture management (EAM) for systematically aligning locally governed IS investments with enterprise-wide objectives. In its traditional fashion, EAM establishes centralized, top-down driven, enterprise-wide governance mechanisms that aim at maintaining transparency, coherency, and ultimately flexibility of IS architecture. Such governance mechanisms include, but are not limited to developing, maintaining, and enforcing top-down, centralized architecture principles, architecture compliance checks, to-be architectures, and committees or procedures for architectural coordination, to eventually influence local IS development projects. The EAM discipline has matured over the last decades by (i) diversifying its scope from software architecture to application architecture and from process architecture to business architecture, (ii) widening its focus from single solutions to functional/business areas, to enterprise-wide, or even to cross-enterprise architecture management, (iii) expanding its sphere of influence from a single architectural layer (e.g., IT artifacts or business artifacts) to various interdependencies across the entire business-to-IT stack, and by (iv) representing not only as-is or to-be states of architectural entities, but also roadmaps or scenarios to cover the entire architecture life cycle. Following EAM's raise in maturity, it has largely gained momentum so that organizations established various 'architect' roles and functions.

Notwithstanding the abovementioned advances, the EAM discipline still struggles with some formational challenges. First, although many architects tried to position themselves as a linking-pin 'between' corporate management, business/project owners and IT, their backgrounds and competency profiles often kept them close to the corporate IT functions [START_REF] Aier | Unternehmensarchitektur -Literaturüberblick und Stand der Praxis[END_REF]. Second, exercising EAM as a centralized mechanism for coordinated IS development, which aligns local projects with enterprise-wide priorities, is the antagonist of un-coordinated IS development projects in pursuing local goals. From local business stakeholders' perspective (e.g., a particular market, product, function owner), the promoted enterprise-wide coordination by EAM are naturally regarded as a "restriction of design freedom" [START_REF] Dietz | Architecture. Building strategy into design[END_REF]. The latter hence threatens EAM's acceptance by those local actors that not only own business change problems, but also respective IS development projects.

EAM's traditional way of dealing with "resistance to coordination" is (i) to communicate its local efficiency contributions (e.g., reduced IT operations costs due to less heterogeneity and more re-use) and (ii) to increase its local effectiveness (e.g., by governance measures). For both strategies, however, empirical research demonstrates an S-shaped benefit curve [START_REF] Ross | Enterprise Architecture Is Not Just for Architects[END_REF]. After harvesting 'low hanging fruits' in early stages of EAM, it becomes increasingly difficult to keep up with large benefit realizations in later stages. At some point, an optimal productivity level of EAM will be reached after which additional EAM efforts cannot justified with the argument of realizable business value [START_REF] Ross | Enterprise Architecture Is Not Just for Architects[END_REF]. Simultaneously, IS architecture complexity can be expected to remain high or even increasing.

The abovementioned observation cannot be related to immaturity of EAM concepts or deployment, but rather to general acceptance problems of EAM by local stakeholders [START_REF] Winter | Architectural Thinking[END_REF]. Convincing local stakeholders that overall benefits on the enterprise-wide level justify individual sacrifices remains a difficult undertaking. Illustrative examples of such challenge cannot only be found in enterprises (e.g., centralizing procurement processes), but are also common in public policy (e.g., imposing speed limits around schools, imposing smoking bans in public areas, transforming energy production and consumption).

In order to move to the next level of EAM productivity, it appears necessary to shift the focus from an enforcement-centric view (i.e., enhancing EAM governance) towards an influence-centric view (i.e., improving the EAM influence on local stakeholder decisions) [START_REF] Winter | Architectural Thinking[END_REF]. This implies not to focus on the traditional EAM players (IT unit, architects, enterprise management) any more, but instead on "that other 90% of the enterprise" that are not directly related to the IT function [START_REF] Gardner | Point-Counterpoint: Enterprise Architecture and Enterprise Transformation as Related but Distinct Concepts[END_REF]. As these stakeholders (e.g., business market, product, function owners) cannot be controlled by EAM measures with a reasonable effort, EAM needs to focus not only on enforcement, but also (or even more) on influence. As a consequence, control as a central theme of EAM research is complemented by informing, legitimating, and socializing [START_REF] Haki | A Stakeholder Perspective to Study Enterprise-wide IS Initiatives[END_REF].

How can the behavior of independent actors be effectively influenced so that enterprise-wide objectives are sufficiently addressed even if they require individual sacrifices? The "New institutionalism" offers an explanation why and how regulations become institutionalized by actors, i.e., develop "a rule-like status in social thought and action" [START_REF] Meyer | Institutionalized Organizations: Formal Structure as Myth and Ceremony[END_REF]. Relying on this theoretical lens, when a pressure is exerted with the aim of complying with some 'grand design', individuals' reactions to such pressure can be explained in a range of acquiescence, compromise, avoidance, defiance and manipulation reaction [START_REF] Oliver | Strategic Responses to Institutional Processes[END_REF][START_REF] Pache | Embedded in Hybrid Contexts: How Individuals in Organizations Respond to Competing Institutional Logics[END_REF]. Weiss et al. [START_REF] Weiss | Institutionalization and the Effectiveness of Enterprise Architecture Management[END_REF] employed this theoretical lens to study EAM and show that an individual actor's response towards EAM measures (i.e., pressures) depends on social legitimacy, efficiency, organizational grounding, and trust. Following Social legitimacy, actors gain social fitness inside the organization when they comply with architectural guidelines. Furthermore, actors become more efficient when following architectural guidelines. Organizational grounding that EAM is anchored within the organization's values in terms of strategy definition, top management support or the position in the organizational hierarchy. Finally, trust reflect actors' confidence on the fact that the EAM function does the right things in a right way [START_REF] Weiss | Institutionalization and the Effectiveness of Enterprise Architecture Management[END_REF].

Based on these insights, which explain under which conditions individual actors comply with restricted design freedom, appropriate preconditions can be derived to increase the acceptance of EAM:

1. Actors need to be convinced that their social status will be raising if they comply with EAM measures -and vice versa. 2. Actors need to understand that they can be more efficient if they comply with EAM measures -and vice versa. 3. Actors need to perceive EAM as something that is strategically important for the organization. 4. Actors need to perceive EAM deployment as transparent, useful, and professional.

Exemplary measures to create such preconditions can be:

1. Create transparent conditions to business people who of their peers is compliant and who is not. For instance, label applications in a way that users see whether they use a compliant or a non-compliant application (works like energy efficiency labels)and provide evidence that the user perception of an actor's compliance is impacting his/her social status. 2. Demonstrate the positive impact of EAM measures -as well as the damage of ignored or compromised EAM measures. For instance, seriously calculate the avoidable lifetime ownership costs of a redundant application. For IS portfolios of a business unit, as another example, explain complexity costs and show how EAM measures reduce operations or project costs. 3. Position EAM leaders on high levels of the organizational hierarchy -and not as a specialist team in IT management. Discuss architectural issues in important/powerful corporate committees. Promote successful specialists or line/project managers to architect functions and successful architects back into line/project management. 4. Ensure that architects and architectural artifacts are not only visible in the business, but also are able to credibly position themselves as business-and synergy-oriented. For instance, the use of coherency-oriented, high complexity models should be avoided. Instead, when interacting with local business stakeholders the focus of architects should be on lightweight artifacts and local concerns ("boundary objects" [START_REF] Abraham | Crossing the line: overcoming knowledge boundaries in enterprise transformation[END_REF][START_REF] Star | Institutional Ecology, 'Translations' and Boundary Objects: Amateurs and Professionals in Berkeley's Museum of Vertebrate Zoology[END_REF]).

The presented measures promise to influence local decision-makers on the business side towards increasing their acceptance of EAM-related design restrictions. This way of thinking and acting by local and individual actors (i.e., not only restricted to architects and IT people) in considering enterprise-wide, long-term concerns as well as fundamental IS design and evolution principles in day-to-day decision making practices (e.g., change requests), has been termed "Architectural Thinking" (AT) by Ross and Quaadgras [START_REF] Ross | Enterprise Architecture Is Not Just for Architects[END_REF]. AT promises to move EAM to the next productivity level, as additional acceptance (and thus EAM impact) can be achieved without heavily increased (and expensive) EAM governance efforts. However, AT can neither be designed, deployed, nor implemented like traditional EAM governance. As a way of thinking, AT can only be propagated in an organization by creating supportive conditions [START_REF] Winter | Architectural Thinking[END_REF]. While we have yet not witnessed large-scale AT initiatives in practice, many organizations have become aware of the approach and have implemented selected measures in order to explore potentials of EAM evolution (e.g., [START_REF] Aier | Implementing Architectural Thinking: A Case Study at Commerzbank AG[END_REF]). A frequently implemented measure is to move the architecture function away from IT and more towards a business unit, and to create architecture spin-offs in business units or project offices of large projects ("Design Authority"). We also note an increasing number of initiatives to broadly demonstrate the value contribution of EAM and/or to explain architectural coordination goals to the business. Likewise, architecture functions have started to develop and track strategy-or business-oriented performance indicators (e.g., resistance to change, solution sustainability, or architectural fit [START_REF] Stutz | Kennzahlen für Unternehmensarchitekturen -Entwicklung einer Methode zum Aufbau eines Kennzahlensystems für die wertorientierte Steuerung der Veränderung von Unternehmensarchitekturen[END_REF]).

In order to design effective and efficient artifacts that raise EAM impact to the next level, further insights into the institutionalization mechanisms are necessary. From a static perspective, explanatory research may identify additional or modified justificatory foundations. Differentiated studies are also needed to better understand contingencies, such as organizational subcultures, industry characteristics (e.g., speed), or management styles, among others.

From a dynamic perspective, one avenue is to analyze the overall performance of EAM (both on the project and the enterprise-wide level) as a result of de-central knowledge acquisition and cooperative learning [START_REF] Brosius | A Learning Perspective on Enterprise Architecture Management[END_REF]. Being very much in line with our call for shifting EAM focus on influence rather than enforcement, the autonomous character of knowledge acquisition as well as learning would imply major EAM capability and instrument adaptations.

A second avenue for dynamic analysis is based on archetype theory [START_REF] Miller | Organizations: A Quantum View[END_REF] which understands organizations as configurations of (i) structural arrangements and (ii) interpretative schemes. An interpretative scheme describes an organization's conception on what it should be doing, how it should be doing, and how it should be judged. This conception is shaped by the prevailing set of ideas, beliefs, and values. The structural arrangement implements and reinforces the ideas, beliefs, and values through establishing organizational structures and processes that reflect the respective beliefs and values [START_REF] Greenwood | Organizational Design Types, Tracks and the Dynamics of Strategic Change[END_REF]. In an ideal case, organizations will evolve towards a situation of organizational coherence, where the structural arrangement and the interpretative scheme represent an "appropriate design for adequate performance" [START_REF] Greenwood | Organizational Design Types, Tracks and the Dynamics of Strategic Change[END_REF] Schilling et al. [START_REF] Schilling | Introducing Archetype Theory to Information Systems Research: A Literature Review and Call for Future Research[END_REF] explore this lens from an IS research perspective. Such an analysis could help to better understand how "measures aimed at creating preconditions for EAM acceptance" interact with organizational ideas, beliefs and values so that, ultimately, local actors can be effectively influenced to better comply with enterprise-wide goals.

While the static and the dynamic perspectives help to better understand AT and design appropriate interventions, continuing empirical analyses will be needed on how organizations learn to move from traditional EAM towards AT and how these two approaches complement each other.

Acknowledgement. The author wishes to thank Stephan Aier, Maximilian Brosius and Kazem Haki for their feedback to earlier version of this text.


Nesat Efendioglu

Robert Woitsch

Wilfrid Utz

A Toolbox Supporting Agile Modelling Method Engineering: ADOxx.org Modelling Method Conceptualization Environment

Keywords: Meta-modelling, Modelling Method Design, Agile Modelling Method Engineering, Conceptualization

The importance of Modelling Method Engineering is equally rising with the importance of domain specific modelling methods and individual modelling approaches. In order to capture the most relevant semantic primitives that address domain specifics needs, it is necessary to involve both, method engineers as well as domain experts. Due to complexity of conceptualization of a modelling method and development of regarding modelling tool, there is a need of a guideline and corresponding tools supporting actors with different background along this complex process. Based on practical experience in business, more than twenty EU projects and other research initiatives, this paper introduces a toolbox to support the conceptualization of a modelling method. The realized toolbox is introduced and evaluated by two EU-funded research projects in the domain of e-learning and cloud computing as well as additionally by an in-house development project in the area of decision modelling extensions. The paper discusses the evaluation results and derived outlooks.

Introduction

The importance of Modelling Method Engineering is equally rising with the importance of Domain Specific Conceptual Modelling Methods and individual modelling approaches. In addition to existing standards (e.g. BPMN, DMN, CMMN), a growing number of groups around the world design their individual modellingmethods (in accordance with the definition of such a method by [START_REF] Karagiannis | Metamodelling platforms[END_REF] [START_REF] Karagiannis | Agile Modeling Method Engineering[END_REF]) for a variety of application domains.) The engineering of such applicable modelling tools as a result of the conceptualization process of modelling methods, is complex, especially when considering the mapping of the entire spectrum from language artefacts and corresponding functionality to concrete implementable and deployable modelling tool capabilities. Besides that, there are branching knowledge domains into more refined and specialized subdomains, where each domain needs to be characterized by its own abstraction and refinement of concepts from reality. Hence, in order to capture the most relevant semantic primitives that address domain specific needs, it is necessary to involve both the method engineers as well as domain experts. Today, there are different approaches, guidelines and practices for the development of modelling tools available that do not consider the full spectrum of the design and collaborative development of a modelling method, which unavoidably leads to limitations in the conceptualization of it [START_REF] Hrgovcic | Conceptual Modeling of the Organisa-tional Aspects for Distributed Applications: The Semantic Lifting Approach[END_REF]. There is a need of a guideline and corresponding tools supporting method engineers along the complex conceptualization process taking all phases into consideration and ensuring collaboration among stakeholders involved in the process. Karagiannis proposes in [START_REF] Karagiannis | Agile Modeling Method Engineering[END_REF] the Agile Modelling Method Engineering (AMME) framework. Authors of [START_REF] Efendioglu | Modelling Method Design: A Model-Drive Approach[END_REF] propose the Modelling Method Conceptualization Process that based on AMME, guides the method engineers during conceptualization. The work at hand proposes a toolbox that supports this process, evaluates it in two European Research projects, and one additional in the context of an in-house research project, and discusses evaluation results.

The remainder of the paper is structured as follows: Section 2 briefly revisits AMME, the Modelling Method Conceptualization Process and outlines each tool in the toolbox. Section 3 presents evaluation cases and discusses the evaluation results, while section 4 concludes the paper and gives an outlook on future work.

Modelling Method Conceptualization Environment

AMME is proposed in [START_REF] Karagiannis | Agile Modeling Method Engineering[END_REF] to support modelling method engineering during propagation and evolution of modelling requirements. The OMiLab Lifecycle [START_REF]Idea and Objectives[END_REF] instantiates AMME and defines the internal cycle of a modelling method conceptualization with five phases; (1) "Create" as a mix of goal definition, knowledge acquisition and requirements elicitation activities that capture and represent the modelling requirements; (2) "Design" specifies the meta-model, language grammar, notation and functionality as model processing mechanisms and algorithms; (3) "Formalize" aims to describe the outcome of the previous phase in non-ambiguous, formal representations with the purpose of sharing results within a scientific community; (4) "Develop" produces concrete modelling prototypes and finally (5) "Deploy/Validate" involves the stakeholders in hands-on experience and the evaluation process as input for upcoming iterations. Due to the involvement of several stakeholders with varying knowledge backgrounds, perspectives and different objectives, in the conceptualization of a modelling method, the authors of [START_REF] Efendioglu | Modelling Method Design: A Model-Drive Approach[END_REF] propose so-called Modelling Method Conceptualization Process (as depicted in Fig. 1) by adding additional feedback channels into the OMiLab Lifecycle between: (1) Create and Design, to prove, if the designed modelling language covers the identified application scenarios and considers the identified requirements; (2) Design and Formalize to ensure formal approval of modelling language, as well as (3) Design and Develop -to improve modelling language in earlier stages before it is released and deployed.

The work at hand introduces a toolbox called "Modelling Method Conceptualization Environment" (as depicted in Fig. 2) that instantiates the above process and supports method engineers during each phases. The only exception is that of the "Create" phase, as this part is regarded as the most creative phase and standard tools and methods (also in some cases pen and paper can be the most appropriate tools) to can be freely selected. Modelling Method Conceptualization Environment proposes a combination of tools, such as the Modelling Method Design Environment (MMDE, available at [START_REF] Adoxx | LearnPAd Developer Space[END_REF]) for the Design, the ADOxx Library Development Environment (ALDE) and ADOxx, for Formalize and Develop, ADOxx.org Tool Packing Services and Developer Spaces for Deploy/Validate Phases.

Fig. 2. The Toolbox: Modelling Method Conceptualization Environment

It is worth to mention that one of the objectives is to provide loosely coupled tools, so method engineers have the flexibility to decide to use one, a combination of tools from the toolbox or even use other appropriate tools of their choice, (e.g. method engineer uses MMDE during the Design Phase, but formalize the modelling method design with mathematical models or use another development tool during the Develop Phase and deploys them at the Developer Spaces and enable validation).

In the following sub-sections current abilities of the tools from the environment are shortly presented.

Create

Modelling Method Design Environment

The Modelling Method Design Environment (MMDE) is itself a modelling tool to design other modelling methods. MMDE has been implemented based on lessons learned and the experience of the authors, who have been involved in modelling method/tool development activities in more than 20 EU research projects for varying domains. Based on these lessons learned, UML [START_REF]Documents Associated With UML Version 2.0[END_REF] has been identified as a fitting starting point. Hence, the MMDE takes a subset of UML and extends it with required concepts and functionalities in order to overcome the following (Ch), which are introduced by [START_REF] Efendioglu | Modelling Method Design: A Model-Drive Approach[END_REF] after a state of the art analysis about specification of conceptual modelling methods: Ch1-Definition of functional and non-functional requirements and their relation between the concepts in modelling methods; Ch2-Fragmenting the whole meta-model into individual meta-models composing concepts for different sub-domains and still be able to define links between concepts in different individual meta-models; Ch3-Having another abstraction layer to represent modules and layers of modelling language as well as relation among them without representing the complexity of abstract and concrete syntax; Ch4-Assigning different concrete syntax to the concepts in modelling language; Ch5-Possibility to design modelling procedure and mechanisms & algorithms of a domain specific modelling language.

To overcome Ch1, "Requirements" model type is implemented that allows the elicitation of requirements, specifying their status as well as dependencies among them. The described requirements in this model type can be referenced to (a) all the modelling classes modelled in the related model type "Meta-Model" classes, (b) graphical notation (concrete syntax) definitions modelled in the "Graphical Notation" model type, (c) the "Modelling Stack" definition and (d) to the functionalities modelled in "Mechanisms & Algorithms" models. For Ch2 and Ch3, we extend the class diagram from UML with concepts, so method engineers can differentiate between class and relation class as well as relate different meta-models (-fragments) with each other using "Weaving" techniques as they are introduced in [8] [START_REF] Woitsch | Hybrid Modeling: An Instrument for Conceptual Interoperability[END_REF]. The modularization and layering of modelling language is essential to avoid complexities during the design of domain specific modelling methods [START_REF] Selic | The Theory and Practice of Modeling Language Design for Model-Based Software Engineering-A Personal Perspective[END_REF] [START_REF] Karagiannis | Model Driven Design for e-Applications: The Meta Model Approach[END_REF]. Hence, we propose representation of the modelling stack as the "Meta-models Stack model type allowing method engineers to differentiate meta-models in sense of different model types that target different fragments of the system. In order to target Ch4 and specify a proper graphical representation (concrete syntax) of each concept in a meta-model, we introduce another model type called "Graphical Notation" model type(allows definition of concrete syntax of model types with specifying graphical representations for each constructs in meta-models. This model type allows the description of graphical representations either assignment of vector graphics code written in GraphRep Language [START_REF] Adoxx | GraphRep[END_REF] or with the assignment of concrete images in PNG, JPG or Bitmap format including a description of the functionalities in the notation (e.g. attribute-value dependent visualization, context related views) In order to target Ch5 to define the applicable modelling technique as steps and corresponding results we propose a model type called "Modelling Procedure" model type". The Modelling Procedure Model Type allows method engineers to define the steps with their required inputs and produced outputs, as well as the sequence of steps based on inputoutput relationships, in order to introduce case specific proper usage of their modelling method. Based on this procedural view, concrete Mechanisms and Algorithms can be derived and depicted as Sequence and Component Diagrams from UML these diagram types has been implemented as model types in MMDE). Further details about MMDE can be found in [START_REF] Efendioglu | Modelling Method Design: A Model-Drive Approach[END_REF].

ADOxx Library Development Environment

The ADOxx Library Development Environment (ALDE) aims to enable formalization and parallel development of modelling tools libraries based on the designs deriving from Design Phase, merging different libraries and ensuring maintainability. As an experimental prototype ALDE uses the Resource Description Framework (RDF) as a format for data interchange [START_REF] W3c | RDF-Resource Description Framework[END_REF].

ALDE is a development environment based on the Eclipse IDE [START_REF]Eclipse IDE for Java EE Developers[END_REF] and includes a meta²model defined in RDFS, the ALDE vocabulary. Having the vocabulary and utilizing Apache Ant® as a build mechanism [START_REF]Apache Ant Download[END_REF], the environment enables the definition of the transformation processes from ADOxx Library Languages to RDF and vice versa. Moreover ALDE serializes libraries in an arbitrary RDF format; for the prototypical realization RDF Turtle [START_REF] W3c | RDF 1.1 Turtle Terse RDF Triple Language[END_REF] has been used and includes the RDF XTurtle Editor developed by [START_REF]The Research Group Agile Knowledge Engineering and Semantic Web (AKSW)[END_REF]. Having libraries in RDF Turtle format and a RDF Turtle Editor available, method engineers can adapt declaratively and script libraries collaboratively using standard functionalities of source-code management systems. Merging several libraries or integration of parts of libraries in each other becomes possible.

ADOxx.org Tool Packaging Services and Developer Spaces

The ADOxx.org Tool Packaging Service [START_REF] Adoxx | AutoPDP Tool Packaging Service[END_REF] is a web-based service that allows method engineers of the ADOxx community to build verified, professional and installable distribution packages that can be distribute to interested stakeholders. The service combines and validates all available inputs, integrates all elements, compiles the necessary artifacts and signs the outcomes and creates the actual installer as a download archive.

As a collaboration space for the development and deployment phases, the concept of "Developer Spaces" has been introduced in ADOxx.org [START_REF] Adoxx | ADOxx.org Developer Spaces[END_REF]. These spaces enable sharing of intermediate/release results, discussing development resources from all pre/past phases in the form of source code, snippet, examples and distribution packages with the community.

Evaluation

The toolbox introduced above has been applied in three different cases for evaluation: two EU-funded research projects in the domain of eLearning and cloud compu-ting and additionally in an in-house development project, in the area of decision modelling extensions. These cases have been selected since the involved partners have varying profiles and expertise in development and in modelling tool engineering. In the following subsection we introduce the cases and requirements in method engineering manner. Afterwards the evaluation results are discussed.

Case 1: Conceptualization of a Modelling Method for E-Learning: The FP7 project Learn PAd [START_REF]The EU Project Learn PAd[END_REF] proposes a process-driven-knowledge management approach based on conceptual and semantic models for transformation of public administration organizations into learning organizations. Learn PAd proposes a model-driven collaborative learning environment. In this case, 4 domain experts and method engineers have been involved. In addition, two developer teams, each consisting of 4 developers worked on the implementation of the tool. The results of the conceptualization process of this modelling method can be found at Learn PAd Developer Space [START_REF]LearnPAd Developer Space[END_REF], as well as the developed prototypes [START_REF]LearnPAd Developer Space -Downloads[END_REF] can be downloaded and feedback can be given.

Case 2: Conceptualization of Modelling Method for Cloud Computing: The H2020 project CloudSocket [START_REF]CloudSocket Project[END_REF] introduces the idea of Business Processes as a Service (BPaaS), where conceptual models and semantics are applied to align business processes with Cloud-deployed workflows [START_REF] Woitsch | Business Process as a Service, Model Based Business and IT Cloud Alignment as a Cloud Offering[END_REF]. .In this case, 6 domain experts and method engineers have been involved, as well as two developer teams, one with 5 developers, the other one with 2 members The results of the conceptualization process of this modelling method can be found at CloudSocket Developer Space [START_REF]CloudSocket Developer Space[END_REF], as well as developed prototypes [START_REF]CloudSocket Developer Space -Downloads[END_REF] can be downloaded and feedback can be given.

Case 3: Integration of exiting BPMN and DMN Modelling Methods:The inhouse project requires integration of an already implemented DMN [START_REF] Omg | Decision Model and Notation, Version 1.0[END_REF] Modelling Method into existing BPMN 2.0 [START_REF] Omg | Business Model and Notation Version 2.0[END_REF] realization as part of the a commercial product. . In this case, 3 domain experts and method engineers, and a team of two developers have been involved.

Evaluation Results

The evaluation process was enacted in the following steps: (1) Provisioning: the tools -of the toolbox have been provided to the stakeholders in the involved cases. (2) Team Formation: representatives, -of the stakeholders in the project created development teams consisting of domain experts and method engineers following the conceptualization process and developing tools individually. (3) Feedback Phase: individual results have been consolidated periodically through video conferences and workshops, constituting the evaluation results. In all cases each tool from the toolbox except ALDE has been utilized, ALDE has been utilized just in Case 3.

Feedback on MMDE.

Pro: It is possible to specify requirements and dependencies among them as well as tracing them; (2) to define modelling language fragments and modules, (3) layering the modelling language with navigational constructs; (4) definition of syntax, semantic and assignment of notation (concrete syntax); (5) definition of weaving among construct in different meta-models; (6) assignment of (multiple-) graphical notation (concrete syntax); [START_REF]Documents Associated With UML Version 2.0[END_REF] explicit definition of modelling procedure; Contra: It is not possible to define application scenarios and use cases, and design results can be exchanged solely using ADOxx specific formats or as static content (image, PDF or HTML).

Feedback on ALDE.

Pro: it is possible to transform libraries in a machine as well as human interpretable format, ability to use reasoning algorithms, due to standard semantic formats; reduces complexity to edit, merge and maintain libraries.

Contra: To take over results from Design Phase require manual steps. Without knowledge of RDF and Turtle syntax, it is difficult for software engineers that using well-known programing languages (e.g Java, C++), to get used familiar with; it requires different transformation scripts for different meta-modelling technologies (such as ADOxx, EMF).

Feedback on ADOxx.org Tool Packing Services and Developer Spaces.

Pro: It is possible to have an installation package to distribute to interested stakeholders, building your own community around the modelling method, and get feedback from them.

Contra: Setting up and handling issues of a certain Developer Space involves certain manual steps, such, as the interested stakeholder has to send an e-mail to the administrator with a request of an own Developer Space.

Conclusion and Outlook

In this paper we introduce a toolbox instantiating the Modelling Method Conceptualization Process, which supports agile modelling method engineering. The toolbox has been evaluated through an analysis of three different cases: two EU research projects and one in-house project. The evaluation results put forward that having an approach and a corresponding toolbox following the idea of model-driven engineering approach is effective in terms of transferring knowledge from the analysis of requirements up to the development of solutions. Being two main tools, MMDE and ALDE, experimental prototypes that are at very early stage of development, lack of full integration or automatic data exchange ability, and the need of manual steps building Developer Spaces came out as major limitations of the toolbox. As an outlook the following items derived from the evaluation: (1) currently we are evaluating development alternatives of MM-DSLs with using Java, Xtend [START_REF]Xtend[END_REF] or RDF; building on existing work [START_REF] Visic | Developing Conceptual Modeling Tools Using a DSL[END_REF] in the field, (2) enabling graphical modelling method design to transform into machine understandable format, (3) formalization of modelling method design using mathematical models such as FDMM [START_REF] Fill | FDMM: A Formalism for Describing ADOxx Meta Models and Models[END_REF], (4) automatization of tooling services and deployment onto developer spaces, (5) full integration of tools around new MM-DSL.

Fig. 1 .

 1 Fig. 1. Modelling Method Conceptualization Process

Acknowledgment

This work has been partly supported by the European Commission co-funded projects Learn PAd (www.learnpad.eu) under contract FP7-619583 and CloudSocket (www.cloudsocket.eu), under contract H2020-ICT 644690