Kudryavtsev Dmitry
email: d.v.kudryavtsev@gsom.spbu.ru

Sadykova Dinara
email: ddsadykova@gmail.com

Towards architecting a knowledge management system: requirements for an ISO compliant framework

Keywords: knowledge company, knowledge management system, enterprise architecture management, enterprise modeling, knowledge mapping

Nowadays, enterprises must be knowledge-driven to be competitive and survive in knowledge economy. It means that knowledge must be a key value-creating resource for such organizations, and knowledge management system shall be embedded into overall enterprise management system. Knowledge management is now not only a possible best practice of industrial leaders and a topic of academic research, but also a "must have" element of every company. Accordingly, knowledge management has been recently included into ISO 9001:2015 and ISO 30401 standards specifying requirements for knowledge management systems. The main research question of the current paper is how to embed knowledge management requirements of ISO into frameworks for enterprise architecture modeling and management? This paper analyses and summarizes knowledge management-related ISO requirements for enterprise management system and transform them into requirements for domain-specific modeling language. Knowledge management-oriented enterprise modeling frameworks are further studied and compared against ISO requirements. This comparison demonstrates fragmented support of ISO requirements. Thus, the research highlights the need for ISO compliant knowledge-oriented extension for existing, proven EM frameworks and provides requirements for it.

Introduction

Motivation and Problem statement

Knowledge has become a key resource in modern economy. Companies need to learn how to create value and make money out of knowledge. Key capabilities of a 21 stcentury company are acquiring new knowledge, applying current knowledge, retaining current knowledge and handling outdated or invalid knowledge. Knowledge man-agement (KM), a rather new discipline, helps companies to establish these capabilities. "The inclusion of Knowledge Management within the recently released ISO 9001:2015 marks a huge change within the world of KM. For the first time, one of the global business standards explicitly mentions knowledge as a resource, and speci-fies expectations for the management of that resource. This provides a long-awaited level of legitimacy for KM which could be a game-changer." [START_REF] Fry | Knowledge Management and ISO[END_REF] Even more, ISO 30401 was published in 2018, and it contained requirements for knowledge management system (KMS). Thus, today many companies begin to implement knowledge-related ISO requirements. These implementations require enterprise trans-formation.

On the other hand, enterprise modeling (EM), enterprise engineering (EE) and architecture management (EAM) are proven approaches for coordinating business transformations [START_REF] Mcginnis | Enterprise modeling and enterprise transformation[END_REF][START_REF] Harmsen | Informed governance of enterprise transformations[END_REF][START_REF] Proper | Architectural Coordination of Enterprise Transformation[END_REF]. Enterprise Modelling, according to [START_REF] Vernadat | Enterprise Modeling and Integration: Principles and Applications[END_REF] "is concerned with representing the structure, organisation and behaviour of a business entity, be it a single or networked organisation, to analyse, (re-)engineer and optimise its operations to make it more efficient". Enterprise models include "concepts that are suited to support the conjoint analysis and design of information system and action system" [START_REF] Frank | Multi-perspective enterprise modeling: foundational concepts, prospects and future research challenges[END_REF]. Enterprise engineering (EE) and architecture management (EAM) are strongly connected to EM. These disciplines are concerned with designing or redesigning business entities, typically, using enterprise models. EAM and EE "provide methods and techniques for an aligned development of all parts of an enterprise" [START_REF] Sankuhl | Enterprise Modeling: Tackling Business Challenges with the 4EM Method[END_REF].

It seems reasonable that knowledge-driven companies and KMS (as management systems) complying with ISO requirements should be designed and implemented involving EM and EAM frameworks. So the final goal of our research is to suggest ISO compliant knowledge-oriented extension for existing, proven EM and EAM frameworks. Such an extension will not only help to design, implement and support KMS, but also seamlessly integrate it into overall enterprise architecture of a company. This extension will be used by enterprise architects and their teams; it can be also useful for chief knowledge officers or knowledge managers, if they are familiar with EM and EAM.

It seems reasonable that knowledge-driven companies and KMS (as management systems) complying with ISO requirements should be designed and implemented involving EM and EAM frameworks.

Although there are many papers integrating EM/EA and KM (e.g. [START_REF] Woitsch | Process oriented knowledge management: A service based approach[END_REF][START_REF] Buckl | Future research topics in enterprise architecture management-a knowledge management perspective[END_REF][START_REF] Meneses-Ortegón | Knowledge Management in Enterprise Architecture Projects[END_REF][START_REF] Kalpic | Business process modelling in industry-the powerful tool in enterprise management[END_REF]), they consider this link from very different perspectives, and it is unclear if there are existing KM-oriented enterprise modeling frameworks which satisfy requirements on domain-specific modeling language and EAM method.

Research Questions and Approach

The current paper addresses the following research question: How to embed KM-related requirements of ISO into frameworks for enterprise architecture modeling?

In order to answer this question, the following subquestions are suggested:  What are KM-related ISO requirements for EM language?

 Do existing KM-oriented enterprise modeling frameworks satisfy the requirements for this language? Answers to these questions will provide the basis for the future design-oriented research [START_REF] Österle | Memorandum on design-oriented information systems research[END_REF] aimed at creating and evaluating of ISO compliant knowledge-oriented extension for existing, proven EM frameworks.

Although it is also necessary to have ISO compliant EAM method for architecting, implementing and supporting KMS and knowledge-driven organization, due to the size limitations the analysis of requirements for EAM method is out of the scope of the current paper.

Specification of the KM-related ISO requirements for EM language is based on the [START_REF] Frank | Outline of a method for designing domain-specific modelling languages[END_REF]. In order to find or design the necessary extension for EM languages/framework, we follow the method proposed by Frank (2010), which has already been successfully applied in other projects. The method suggests a macro process model for developing domain-specific modeling languages. The macro process consists of 7 steps [START_REF] Frank | Outline of a method for designing domain-specific modelling languages[END_REF]: 1. Clarification of scope and purpose, 2. Analysis of generic requirements, 3. Analysis of specific requirements, 4. Language Specification (abstract syntax), 5. Design of Graphical Notation (concrete syntax) and 6. optional Development of Modelling Tool. The process ends with the evaluation and iterative refinement of developed artefacts [START_REF] Sankuhl | Enterprise Modeling: Tackling Business Challenges with the 4EM Method[END_REF]. Within this paper, we focus on the first 3 steps.

The current paper starts with the analysis of KM-oriented requirements for enterprise management system within ISO 9001:2015 and ISO 30401:2018 standards (section 2). Then it synthesizes KM-oriented ISO requirements for EM language (section 3). Overview and categorization of approaches at the intersection of KM and EM/EAM helped to identify relevant KM-oriented enterprise modeling approaches (section 4.1). The selected modeling approaches were compared with the KMoriented ISO requirements for EM language (section 4.2).

Analysis of KM-oriented requirements in ISO standards

KM-related ISO requirements for enterprise management system are provided in ISO 9001:2015 and in ISO 30401:2018. This section analyzes these two standards and elicit integrated KM-related ISO requirements for EM language from them. The analysis starts from informal description of main KM-related elements within the standards, after that a detailed semantic analysis of the texts of standards is provided. The text analysis identifies required concepts for ISO compliant knowledge-oriented EM extension.

ISO 9001 was revised in 2015. The revised standard, ISO 9001:2015, includes the new clause 7.1.6 Organizational knowledge. The requirements of this clause are:

"Determine the knowledge necessary for the operation of its processes and to achieve conformity of products and services. This knowledge shall be maintained and made available to the extent necessary. When addressing changing needs and trends, the organization shall consider its current knowledge and determine how to acquire or access any necessary additional knowledge and required updates. NOTE 1: Organizational knowledge is knowledge specific to the organization; it is generally gained by experience. It is information that is used and shared to achieve the organization's objectives.

NOTE 2: Organizational knowledge can be based on: a) Internal Sources (e.g., intellectual property, knowledge gained from experience, lessons learned from failures and successful projects, capturing and sharing undocumented knowledge and experience; the results of improvements in processes, products and services); b) External Sources (e.g., standards, academia, conferences, gathering knowledge from customers or external providers)."

As Nick Milton of Knoco Limited notes, "this new clause is not a Knowledge Management standard, nor does it require an organization to have Knowledge Management in place as a formal requirement. As a clause in a Quality standard, it simply requires that sufficient attention is paid to knowledge to ensure good and consistent quality of goods and services." [START_REF] Fry | Knowledge Management and ISO[END_REF] The text analysis of the KM-related fragment is presented in table 1. "The purpose of this standard for knowledge management is to support organizations to develop a management system that effectively promotes and enables valuecreation through knowledge" [START_REF]2018 Knowledge management systems -Requirements[END_REF]. This standard is led by principlesit starts from KM guiding principles: Nature of knowledge; Value; Focus; Adaptive; Shared understanding; Environment; Culture; Iterative. These principles can be transformed into the corresponding principles of EAM framework.

Main KM definitions in ISO 30401:2018 standard: "Knowledgehuman or organizational asset enabling effective decisions and action in context" [START_REF]2018 Knowledge management systems -Requirements[END_REF].

"Knowledge management -management with regard to knowledge" [START_REF]2018 Knowledge management systems -Requirements[END_REF]. Where management is considered as "management process of planning, organizing, directing and controlling the outcomes of people, groups or organizations" [START_REF]2016 Human resource management -Vocabulary[END_REF] "Knowledge management systempart of a Management system with regard to knowledge. Note 1 to entry: The system elements include the organization's knowledge management culture, structure, governance and leadership; roles and responsibilities; planning, technology, processes and operation, etc." [START_REF]2018 Knowledge management systems -Requirements[END_REF]. Where management system according to [START_REF]2018 Knowledge management systems -Requirements[END_REF] is a set of inter-related or interacting elements of an organization to establish policies, and objectives and processes to achieve those objectives.

According to [START_REF]2018 Knowledge management systems -Requirements[END_REF] "the organization shall establish, implement, maintain and continually improve a knowledge management system, including the strategy, processes needed and their interactions, in accordance with the requirements of this international standard."

ISO 30401:2018 includes KM-specific part and universal part, which is applicable for any management system. The description of a KM system is a specific part, while management activities, which "establish, implement, maintain and continually improve" KM system, are standardized and follows the template from the proposals for management system standards (see ISO/IEC Directives Part 1 and Consolidated ISO Supplement, Annex SL [START_REF]Proposals for management system standards[END_REF]). These management activities correspond to steps of PDCA-cycle and are the following: Context of the organization; Leadership; Planning; Support; Operation; Performance evaluation & Improvement.

Clause 4.4 of the ISO 30401:2018 includes the description of KMS, which shall be established, implemented, maintained and continually improved by an organization. This clause was used for eliciting the requirements for KM-oriented EM language (see table 2). In several cases, where the text of the standard made references to other clauses, these clauses were analyzed and necessary concepts were extracted. Some fragments of ISO standards text were considered as explanatory and were not used for extracting required concepts (objects and activities). The organization shall establish, implement, maintain and continually improve a knowledge management system, including the processes needed and their interactions, in accordance with the requirements of this document.

Establish a KMS Implement a KMS Maintain a KMS (Continually) Improve a KMS

Text of the ISO standard

Required objects and activities 4.4.2 to 4.4.4 include requirements, each representing a dimension of the knowledge management system, which are interdependent. Acknowledging and incorporating these dimensions within the knowledge management system and putting them in place through a managed change process is required for the implementation of an effective and holistic knowledge management system within the organization.

Dimension of the KMS

Knowledge development

The organization shall demonstrate that the knowledge management system covers the following activities, for effectively managing knowledge through its stages of development through systematic activities and behaviours, supporting the knowledge management system objectives and covering the prioritized knowledge domains defined in 4. [Knowledge] representation c) Combination: synthesis, curating, formalizing, structuring or classifying of codified knowledge, making the knowledge accessible and findable.

[Knowledge] combination d) Internalization and learning: reviewing, assessing and absorbing knowledge; incorporating it into practice.

[Knowledge] internalization and learning

Text of the ISO standard

Required objects and activities 4.

Knowledge management enablers

The organizational knowledge management system shall include and integrate elements of all the following enablers to create an effective knowledge management system. This shall support the knowledge management system objectives and cover the prioritized knowledge domains defined in 4.3: KM enablers KMS objectives Prioritized knowledge domains a) Human capital: roles and accountabilities, including all knowledge management system stakeholders; making sure that knowledge management is encouraged within the organization (covered in detail in Clause 5).

Human capital

Knowledge management culture

Embedding a knowledge management culture across the organization is critical for sustained application of knowledge management. A culture where connections and knowledge activities are encouraged, and knowledge is valued and actively used, will support the establishment and application of the knowledge management system within the organization.

KM culture

KM-oriented ISO requirements for enterprise modeling language

Based on the analysis of ISO standards, the following requirements for EM language were synthesized: R1: An EM language for ISO compliant design of KMS should provide concepts for modeling organizational context for KM and KMS. Concepts: R5: An EM language for ISO complient design of KMS should provide concepts for modeling Activities, behaviours, means for knowledge development and knowledge conveyance and transformation. R6: An EM language for ISO complient design of KMS should provide concepts for modeling KM enablers. Concepts: 6.1. Human capital ( Roles and accountabilities, KM stakeholders); 6.2. Processes (Knowledge activities, Organizational processes); 6.3 Technology and infrastructure (Digital channels, Virtual workspace, Physical workspace); 6.4. Governance ( KM strategy, KM expectations, KM policy); 6.5. KM culture (Attitudes, Norms).

Management activities, which "establish, implement, maintain and continually improve" KM system are not reflected in these requirements since they mostly correspond to activities in EAM method, rather then enterprise modeling language (see futher research directions in the conclusion).

4

Study of KM-oriented enterprise modeling approaches

Overview of approaches at the intersection of KM and EM/EAM

There are many research papers studying a link between KM and EM or EA. In order to select the right approaches for further analysis (see section 4.2), we analyzed and organized existing into the following categories (fig. 1): A. Enterprise modeling and/or enterprise architecture management are used for designing and implementing KMS; B. Enterprise model is a codified organizational knowledge describing the way enterprise operations are organized;

 KIPO (the knowledge-intensive process ontology) [START_REF] França | KIPO: the knowledge-intensive process ontology[END_REF] & corresponding KIPN (Knowledge Intensive Process Notation) [START_REF] Netto | A notation for knowledge-intensive processes[END_REF],  Knowledge modelling in weakly-structured business processes (KM-WSB) [START_REF] Papavassiliou | Knowledge modelling in weakly-structured business processes[END_REF],  Rapid knowledge work visualization for organizations (Know Flow toolset) [START_REF] Strohmaier | Rapid knowledge work visualization for organizations[END_REF].

A.1.3. Agent-Oriented KM Modeling  An agent oriented approach to analyzing knowledge transfer [Strohmaier et al, 2007] (Knowledge Transfer) [START_REF] Strohmaier | Analyzing Knowledge Transfer Effectiveness--An Agent-Oriented Modeling Approach[END_REF],  Modelling knowledge transfer: A knowledge dynamics perspective [START_REF] Mougin | Modelling knowledge transfer: A knowledge dynamics perspective[END_REF]] (KDP) [START_REF] Mougin | Modelling knowledge transfer: A knowledge dynamics perspective[END_REF]. A.1.4. Holistic KM modeling approaches  Modeling Knowledge Work for the Design of Knowledge Infrastructures [START_REF] Maier | Modeling knowledge work for the design of knowledge infrastructures[END_REF],

where the concept of knowledge stance was discussed to integrate the process oriented and the activity-oriented perspective (Knowledge stance modeling).  Knowledge-MEMO [START_REF] Schauer | Modeling Techniques for Knowledge Management[END_REF] multiperspective modeling method for knowledge management.

A.2. Design of a KMS as an information system Some research papers focus on the specification of IT infrastructure of KMS, e.g. [START_REF] Maier | Enterprise knowledge infrastructures[END_REF].

B. Enterprise model is a codified organizational knowledge, which describes how enterprise operations are organized Focus: capturing, externalization, formalization, structuring and distribution of knowledge about an enterprise. Enterprise model development is considered as creating and populating knowledge repository. Examples of typical publications in this category: [START_REF] Kalpic | Business process modelling in industry-the powerful tool in enterprise management[END_REF], [START_REF] Stirna | Building knowledge repositories with enterprise modelling and patterns-from theory to practice[END_REF], [START_REF] Lillehagen | Active knowledge modeling of enterprises[END_REF]. "Process modeling as a tool that allows the capturing, externalization, formalization and structuring of knowledge about enterprise processes" [START_REF] Kalpic | Business process modelling in industry-the powerful tool in enterprise management[END_REF] "Models of an enterprise capture knowledge" [START_REF] Frank | Multi-perspective enterprise models as a conceptual foundation for knowledge management[END_REF] "Enterprise Modeling has been defined as the art of externalizing enterprise knowledge, i.e., representing the core knowledge of the enterprise" [START_REF] Vernadat | Enterprise Modeling and Integration: Principles and Applications[END_REF] "The Active Knowledge Modeling (AKM) technology is about discovering, externalizing, expressing, representing, sharing, exploring, configuring, activating, growing and managing enterprise knowledge" [START_REF] Lillehagen | Active knowledge modeling of enterprises[END_REF] "Building knowledge repositories with enterprise modelling and organizational patterns" [START_REF] Stirna | Building knowledge repositories with enterprise modelling and patterns-from theory to practice[END_REF] Limitations: enterprise models cover only a fragment of enterprise knowledge (tacit knowledge is not covered; knowledge about product, customer, partners external environment etc. is only partially represented in enterprise models), so methodologies from this category are not sufficient for designing and implementing KMS.

C. Knowledge management helps to improve enterprise architecture management practices

Focus: Knowledge management methods and techniques are used to improve EAM practices. Examples of typical publications in this category: [START_REF] Meneses-Ortegón | Knowledge Management in Enterprise Architecture Projects[END_REF], [START_REF] Wibowo | Knowledge Management Support for Enterprise Architecture Development[END_REF]. "EA projects generate a series of artifacts that contain knowledge directly or indirectly which can be reused or transferred from project to project. In this paper, the interest in providing a KM framework for TOGAF-based EA, to capture, store and reuse lessons learned in the first phases of the project." [START_REF] Meneses-Ortegón | Knowledge Management in Enterprise Architecture Projects[END_REF] "KM in general has 3 processes, i.e. create, classify, and retrieve. These three processes can be utilized to support EA Team in formulation of enterprise architecture. This paper suggests the use of knowledge chain, labels (tagging), and taxonomy to develop knowledge base that can helps EA Team in formulation process of enterprise architecture" [START_REF] Wibowo | Knowledge Management Support for Enterprise Architecture Development[END_REF] In [START_REF] Wibowo | Knowledge Management Support for Enterprise Architecture Development[END_REF] authors present a step-by-step model of knowledge management in an enterprise architecture is proposed with reference to a business strategy. This model suggests the use of knowledge chain, labels (tagging), and taxonomy to develop knowledge base that can helps EA Team in formulation process of enterprise architecture. Also, in [START_REF] Meneses-Ortegón | Knowledge Management in Enterprise Architecture Projects[END_REF] was covered the similar problem, in this paper, the authors propose a KM metamodel for the EA based on TOGAF for the collection, storage and reuse of knowledge. Validation is presented by examining a specific case in a consulting company.

D. Knowledge management provides analytical framework for EM&EAM Examples of typical publications in this category:

 Business process modeling through the knowledge management perspective [START_REF] Kalpič | Business process modeling through the knowledge management perspective[END_REF].  Future research topics in enterprise architecture management-a knowledge management perspective [START_REF] Buckl | Future research topics in enterprise architecture management-a knowledge management perspective[END_REF].

Analysis of the KM-oriented enterprise modeling approaches

Based on the requirements listed in chapter 3, an analysis of the approaches in table 3.

The columns describe the main approaches for KM-oriented enterprise modeling (see category A in previous section). The rows list the requirements. The results of the analysis are at the intersection.

a modeling approach suggests similar concepts and/or use them in a limited way. KM Culture is not modeled, but it is questionable whether it is worth modeling or not. Holistic KM modeling approaches [START_REF] Maier | Modeling knowledge work for the design of knowledge infrastructures[END_REF][START_REF] Schauer | Modeling Techniques for Knowledge Management[END_REF] better fulfil the requirements, but not completely. As a result, we can conclude that there is no any approach, which satisfy the requirements outlined in chapter 3.

Conclusion

ISO has recently included KM-related requirements into its standards, i.e. ISO 9001:2015 Quality Management Systems -Requirements and ISO 30401:2018 Knowledge Management Systems -Requirements. Many organizations started implementing these ISO requirements. EM and EAM may be used to support organizations within this process. The final goal of our research is to suggest ISO compliant KM-oriented extension for existing, proven EM and EAM frameworks. Such extension will not only help to design, implement and support KMS, but also to seamlessly integrate it into overall enterprise architecture of a company. This paper analyses and summarizes KM-oriented ISO requirements for enterprise management system. This analysis helped to specify KM-oriented ISO requirements for EM language. Existing research papers integrating KM and EM/EA were subsequently studied. Research categorization was suggested. KM-oriented modeling frameworks were studied and compared against KM-related ISO requirements. This comparison demonstrated fragmented support of ISO requirements. Thus, the research highlighted the need for ISO compliant KM-oriented extension for existing, proven EM frameworks.

Further research is needed to achieve the final goal of the research, which is to suggest ISO compliant KM-oriented extension for existing, proven EM and EAM frameworks. Thus, the research needs to:  Analyse management activities required by ISO, which "establish, implement, maintain and continually improve" KM system, and compare them with existing EAM methods (both generic and KM-oriented). Since the description of these activities for KMS mostly follows the ISO template for other management systems (see ISO/IEC Directives Part 1 and Consolidated ISO Supplement, Annex SL [START_REF]Proposals for management system standards[END_REF]), it seems reasonable to compare this generic ISO template with existing EAM methods;  Compare methods and techniques for knowledge and knowledge assets mapping [START_REF] Balaid | Knowledge maps: A systematic literature review and directions for future research[END_REF][START_REF] Schiuma | The next generation of knowledge management: mapping-based assessment models[END_REF] with determined requirements. These approaches have a long history and provide many ways for describing organizational knowledge, its sources, application areas (strategic themes, business processes) and development plans, but are less formalized than modeling approaches that we've analyzed in section 4.2.  Develop, demonstrate and evaluate ISO compliant knowledge-oriented extension for existing, proven EM and EAM frameworks.

3

 3 new knowledge: means to provide the organization with knowledge that was previously unknown or unavailable within the organization.New knowledgeAcquiring new knowledge Means b) Applying current knowledge: means to make knowledge effective, integrating the current relevant knowledge of the organization in order to enable improved actions and decision making.Current knowledgeApplying current knowledge Means c) Retaining current knowledge: means to safeguard the organization from the risks of knowledge loss.Current knowledgeRetaining current knowledge Means d) Handling outdated or invalid knowledge: means to protect the organization from making mistakes or working inefficiently, as a result of use of knowledge inappropriate within the current organizational context. Knowledge conveyance and transformation The organizational knowledge management system shall include activities and behaviours, supporting all different types of knowledge flows, through systematic activities and behaviours, supporting the knowledge management system objectives and covering the prioritized knowledge domains defined in interaction: exchange and co-creation of knowledge through conversations and interactions; between individuals, teams and across the organization.Human interaction b) Representation: making knowledge available through demonstrating, recording, documenting and/or codifying.

Table 1 .

 1 Analysis of clause 7.1.6 Organizational knowledge in ISO 9001:2015

	Text of the ISO standard	Required objects	Required activities
	Determine the knowledge	Knowledge	Determine necessary
	necessary for the operation	Necessary knowledge	knowledge
	of its processes and to	Knowledge necessary for the
	achieve conformity of prod-ucts and services.	operation of its [organiza-tion] processes Processes
		Knowledge necessary to
		achieve conformity of prod-
		ucts and services
		Products and services
	This knowledge shall be		Maintain knowledge
	maintained and made avail-		Make knowledge available
	able to the extent necessary.
	When addressing changing	Needs	Consider its [organization]
	needs and trends, the organ-	Trends	current knowledge
	ization shall consider its	Organization	Determine how to acquire
	current knowledge and determine how to acquire or access any necessary addi-tional knowledge and re-quired updates.	Current knowledge	any necessary additional knowledge Determine how to access any necessary additional knowledge Determine required
			knowledge updates
	ISO 30401:2018 "Knowledge management systems -Requirements" was pub-
	lished in November 2018.

Table 2 .

 2 Analysis of clause 4.4 Knowledge management system in ISO 30401:2018

	Text of the ISO standard	Required objects and activities
	4.4.1 General

Knowledge management culture: Attitudes and norms regarding sharing, learning from mistakes

		Roles and accountabilities
		KM stakeholders
	b) Processes: defined knowledge activities applied and em-	Processes
	bedded within organizational processes, including proce-	Knowledge activities
	dures, instructions, methods and measures (covered in Clause	Organizational processes
	8).
	c) Technology and infrastructure: digital channels, virtual	Technology and infra-
	and physical workspace and other tools.	structure
		Digital channels
		Virtual workspace
		Physical workspace
	d) Governance: Strategy, expectations and means of ensur-	Governance
	ing the knowledge management system is working in align-	KM strategy
	ment (covered in detail in Clauses 5 to 10).	KM expectations
		KM policy (from clause
		5.2)
	e) (covered in detail	KM culture Attitudes [regarding shar-
	in 4.5).	ing, learning from mis-
		takes …]
		Norms [regarding sharing,
		learning from mistakes
		…]

of knowledge flows within Knowledge conveyance and transfor- mation.

  An EM language for ISO complient design of KMS should provide concepts for modeling Types Concepts: Human interaction; [Knowledge] Representation; [Knowledge] Combination; [Knowledge] Internalisation and learning.

	1.1. Organizational Processes, which requires knowledge;
	1.2. Products and Services, which requires knowledge;
	1.3. KMS objectives.
	R2: An EM language for ISO complient design of KMS should provide concepts for
	modeling Knowledge and its status. Concepts: Knowledge; Knowledge	domain;
	Status of knowledge (Necessary knowledge; Current knowledge; New knowledge;
	Outdated knowledge; Invalid knowledge; Prioritized knowledge domains).
	R3: An EM language for ISO complient design of KMS should provide concepts for
	modeling Stages of knowledge development. Concepts: Acquiring new knowlede;
	Applying current knowledge; Retaining current knowledge; Handling outdated or
	invalid knowledge.
	R4:

C. Knowledge management helps to improve enterprise architecture management practices; D. Knowledge management provides analytical framework for EM&EAM.

Fig. 1. Categories of approaches at the intersection of KM and EM/EAM

A. Enterprise modeling and/or enterprise architecture management are used for designing and implementing KMS Focus: analysis and design of an effective and efficient KMS "Modeling is one of the key tasks that helps on the one hand to understand, analyze and improve business processes (business process reengineering), organizational structures in general and structures and processes of KM initiatives in particular. On the other hand, modeling supports the design, implementation and management of information systems, in this case of knowledge management systems." [START_REF] Maier | Knowledge management systems: information and communication technologies for knowledge management[END_REF] Modeling approaches in this category can be subdivided into the next groups: A.1. Design of a KMS as a management system (Focus of our analysis) A.1.1. Business process-oriented approaches  KM extensions to ARIS (KM ARIS) [START_REF] Allweyer | Modellbasiertes Wissensmanagement[END_REF],  PROMOTEa framework for process-oriented KM, which includes modeling language and method. The focus of this approach is on "modelling, identification, accessing, storing, distribution, and evaluation of knowledge in a process-oriented manner." [START_REF] Woitsch | Process oriented knowledge management: A service based approach[END_REF],  B-KIDE: A Framework and a Tool for Business Process-Oriented Knowledge Infrastructure Development (B-KIDE) [START_REF] Strohmaier | B-KIDE: A framework and a tool for business process-oriented knowledge infrastructure development[END_REF].

A.1.2. Knowledge work-oriented approaches

This group partially intersects with the previous one, but has many special features. As we see in most approaches, the links between KM and business process management are defined. KM has links to processes, roles, organizational units (KM ARIS, PROMOTE, KM-WSB, KIPO, B-KIDE, Knowledge-MEMO, Know Flow toolset). Only a small part of the approaches models technology and infrastructure, but not fully (e.g. PROMOTE, B-KIDE, Know Flow toolset). There is lack of relationships between knowledge and products/services of an enterprise. Some modeling approaches partially fulfil the requirements (see "+/-" sign), which mostly mean that


Anne Gutschmidt
email: anne.gutschmidt@uni-rostock.de

Valentina Sauer

Kurt Sandkuhl

Alexey Kashevnik

Identifying HCI Patterns for the Support of Participatory Enterprise Modeling on Multi-Touch Tables

Keywords: HCI patterns, participatory enterprise modeling, multitouch table, task analysis, video analysis

This paper deals with the question of how software enabling participatory enterprise modeling on a multi-touch table should be designed. We will present a pre-selection of existing HCI patterns addressing the requirements which come along with collaboratively creating enterprise models on a shared workspace. Moreover, we examined a software prototype based on a task model and video analysis. The videos show participatory modeling sessions and give hint on frequent activities and deficiencies of the prototype. Based on our results, we will give recommendations of HCI patterns which should be applied when designing software tools for participatory enterprise modeling on multi-touch tables.

Introduction

Enterprise models are supposed to capture and represent the situation in an enterprise, either in terms of the current state of affairs or of the planned future situation [START_REF] Sandkuhl | Enterprise modeling. The Enterprise Engineering Series[END_REF]. In this context, a precondition for high quality enterprise models is to fully and correctly elicit the relevant knowledge from within the enterprise under consideration for the defined scope and purpose of modeling. Participatory enterprise modeling (PEM) is an elicitation technique considered as in particular valuable, when an agreement and a joint view of different stakeholders on the current or future situation are important [START_REF] Stirna | Enterprise Modeling -Facilitating the Process and the People[END_REF]. Various methods, techniques and tools have been proposed by the scientific community to support PEM (cf. section 2.1). However, constantly emerging new technologies make more and more new tools possible. We argue that with an increased use of multi-touch tables (MTT) and large touch screens, more attention should be paid on adapting or specifically designing tools for participatory, facilitated and collaborative EM. More concretely, the paper addresses the design of user interface and human computer interaction (HCI) for MTT in the context of PEM. This may also contribute to light-weight modelling tools and the research agenda for extending the reach of enterprise modeling [START_REF] Sandkuhl | From expert discipline to common practice: A vision and research agenda for extending the reach of enterprise modeling[END_REF]. Our conjecture is that HCI patterns from software engineering (cf. section 2.2) provide relevant and reusable knowledge for the design of PEM tools. Based on a general task analysis for goal modeling as selected part of EM and using the results of a video analysis revealing problems and challenges in PEM on a multi-touch table, we aim at contributing to an understanding of specific requirements in PEM tool design. The main contributions of the paper are (1) a list of HCI patterns supporting participation and enterprise modeling, (2) a task analysis of typical EM activities and (3) results of evaluating the HCI patterns for improving a modeling tool on a multi-touch table. The remainder of the paper is structured as follows: Section 2 will present the theoretical background dealing with the areas of PEM (section 2.1) and HCI patterns (section 2.2). In section 3 we will present our selection of HCI patterns where we list patterns we found most fitting for PEM on a MTT. We examined a software prototype to determine which of the previously selected HCI patterns have already been applied (section 4). Furthermore, we documented basic user interactions enabled by the prototype in a task model (section 5) and, based on video recordings of thirteen PEM sessions, we analyzed the interactions with the aim of identifying potentials of improvement (section 6). The paper closes with a general discussion in section 7.

2 Theoretical Background

Participatory and Collaborative Enterprise Modelling

A General Background In general terms, EM addresses the systematic analysis and modelling of processes, organization structures, product structures, ITsystems or any other perspective relevant for the modelling purpose [START_REF] Vernadat | Enterprise modeling and integration (emi): Current status and research perspectives[END_REF]. A detailed account of EM approaches is provided in [START_REF] Stirna | Participative enterprise modeling: experiences and recommendations[END_REF]. PEM and involving different stakeholder groups in EM has a long tradition (see, e.g., [START_REF] Stirna | Participative enterprise modeling: experiences and recommendations[END_REF]). Since several stakeholder groups are involved in the modelling process and have to work together on one model, this process calls for participation of everyone involved. In this PEM process the methodology experts and domain experts work together on the model [START_REF] Gutschmidt | Multi-touch table or plastic wall? Design of a study for the comparison of media in modeling[END_REF]. By working together right from the beginning, it is more likely that the final model will be accepted by the participants and they will commit to it. Furthermore, the stakeholders will agree with the model, after all, they worked on it, too. Another advantage of PEM sessions is that they can increase the quality of the model, by introducing people into the process who hold valuable knowledge of the enterprise and its processes. Domain-specific modelling languages (DSML) [START_REF] Van Deursen | Domain-specific languages: An annotated bibliography[END_REF] are supposed to support these various stakeholders in model creation and use. The scientific literature on EM offers several views as its constituents (see, e.g., [START_REF] Frank | Multilevel modeling[END_REF][START_REF] Henderson-Sellers | Situational method engineering[END_REF]), like the modelling procedure or modelling method, the result of modelling (i.e. the model), the tool support, and the organizational structures establishing modelling within an organization. However, not all researchers in EM agree on the above EM constituents. Some researchers emphasize the importance of meta-models and modelling languages for capturing different perspectives [START_REF] Frank | Multilevel modeling[END_REF]. Tool support is often seen as inseparable manifestation of modelling approaches and notations [START_REF] Gonzalez-Perez | Metamodelling for software engineering[END_REF], but in other research work as aid to support modelling [START_REF] Dietz | Enterprise Ontology: Theory and Methodology[END_REF]. Organizational structures and role descriptions are often neglected in EM approaches.

Participatory Enterprise Modeling Sessions When an enterprise decides to start an enterprise modeling project with actively involving stakeholder representatives, they will have to invest resources into that project: Most obviously, they will have to exempt employees from work to let them take part in modeling sessions. The participants should come from different parts of the company, and have adequate domain knowledge which is why they are called domain experts. They should also have the authority to suggest organizational changes contained in the final models [START_REF] Stirna | Enterprise Modeling -Facilitating the Process and the People[END_REF]. Stirna and Persson [START_REF] Stirna | Enterprise Modeling -Facilitating the Process and the People[END_REF] propose a number of 4-8 participants per session. In addition to domain experts, a company should recruit so-called method experts. Their purpose is to support the domain experts in creating enterprise models based on their knowledge of modeling notation and method. Usually, a facilitator leads the discussion and modeling process while being completely neutral about the content. A tool operator assists the domain experts in creating the actual models. He or she helps handling the modeling tool and generating syntactically correct models. Optionally, a secretary may take additional notes to document the rationale of the creation process [START_REF] Sandkuhl | Enterprise modeling. The Enterprise Engineering Series[END_REF][START_REF] Stirna | Enterprise Modeling -Facilitating the Process and the People[END_REF]. An enterprise modeling project may comprise multiple modeling sessions lasting several hours and possibly involving different domain experts who create and refine models [START_REF] Stirna | Enterprise Modeling -Facilitating the Process and the People[END_REF].

Modeling Language Enterprise models are usually represented by diagrams containing geometric shapes such as rectangles or circles. These shapes reflect concepts and are usually connected by lines or arrows representing relationships. All model elements may be labeled, giving further information. In a formal language both syntactical and semantic rules have to be followed when drawing the actual model [START_REF] Stirna | Enterprise Modeling -Facilitating the Process and the People[END_REF]. A goal model in the 4EM notation, for example, consists of differently colored rectangles, e.g., a green rectangle represents a goal, an orange rectangle represents a problem. The rectangles usually contain an expressive description and a number. To show that a certain problem hinders a goal, a relationship between these components must be added including the respective label [START_REF] Sandkuhl | Enterprise modeling. The Enterprise Engineering Series[END_REF].

HCI Patterns

HCI patterns, also called HCI design patterns, describe successful best practice solutions for reoccurring User Interface (UI) design problems, therefore also affecting implicitly the usability of software tools [START_REF] Specker | Exploring usability needs by human-computer interaction patterns[END_REF]. These patterns should support the designers and keep them from reinventing the same solutions over and over again. Their advantage is that useful design solutions can be captured and generalized in the form of a pattern to solve similar problems with them [START_REF] Wurhofer | Introducing a comprehensive quality criteria framework for validating patterns[END_REF]. The development of UIs is complex, therefore, reusing knowledge, already gained by previous design processes, helps the designers and developers to work more efficiently and improve their productivity [START_REF] Borchers | A pattern approach to interaction design[END_REF][START_REF] Kruschitz | Human-computer interaction design patterns[END_REF][START_REF] Kruschitz | Analyzing the hci design pattern variety[END_REF][START_REF] Guerrero-García | A method to align user interface to workflow allocation patterns[END_REF]. A pattern is the relationship between a certain context, problem and solution [START_REF] Alexander | A pattern language. Volume 2 of Center for Environmental Structure series[END_REF]. It describes the context within which the patterns can be used, the problem that has to be solved by the pattern and its solution [START_REF] Guerrero-García | A method to align user interface to workflow allocation patterns[END_REF]. Initially, this idea of patterns was developed by Christopher Alexander for architectural designs [START_REF] Alexander | A pattern language. Volume 2 of Center for Environmental Structure series[END_REF]. The "Gang of Four" adopted the pattern concept for the design of object-oriented software [START_REF] Gamma | Addison-Wesley professional computing series[END_REF]. Eventually, patterns were also adopted by the HCI community. While the Gang of Four gives instructions about how to implement a pattern, HCI patterns are about the general design of an interface and its purpose for the user. The pattern concept not only included the patterns themselves, but also a pattern language. A pattern language consists of patterns and their relationships, i.e. a network of patterns. High-level patterns in this network may be solved by low-level patterns [START_REF] Kruschitz | Analyzing the hci design pattern variety[END_REF]. Since the patterns of one language are connected to each other, it is apparent that a pattern language combines patterns for a given family of design problems in a specific domain [START_REF] Kruschitz | Human-computer interaction design patterns[END_REF][START_REF] Lukosch | Communicating design knowledge with groupware technology patterns[END_REF]. Successor and predecessor relationships between patterns are a key concept when working with pattern languages, since they enable finding closely related patterns [START_REF] Kruschitz | Human-computer interaction design patterns[END_REF].

Selecting HCI Patterns for Participatory Enterprise Modeling on MTTs

We have scanned existing lists of patterns [START_REF] Van Welie | Welie.com: Patterns in interaction design[END_REF][START_REF] Tidwell | Common ground[END_REF][START_REF] Tidwell | Designing interfaces[END_REF][START_REF] Remy | A pattern language for interactive tabletops in collaborative workspaces[END_REF][START_REF] Laakso | User interface design patterns[END_REF] and further works presenting HCI patterns [START_REF] Coram | Experiences -a pattern language for user interface design[END_REF][START_REF] Lockton | Exploring design patterns for sustainable behaviour[END_REF] which covered concepts that could be applied to MTT. While the lists of Tidwell [START_REF] Tidwell | Designing interfaces[END_REF][START_REF] Tidwell | Common ground[END_REF] and van Welie ( [START_REF] Van Welie | Welie.com: Patterns in interaction design[END_REF] are most often cited, Remy et al. [START_REF] Remy | A pattern language for interactive tabletops in collaborative workspaces[END_REF] created a pattern list specifically for the MTT. We particularly looked for HCI patterns that fit the requirements of the special context of PEM with a multi-touch table. We formulated major concepts which helped us selecting and categorizing fitting patterns, and also reflected the above-mentioned requirements. Figure 1 shows these concepts in bold letters with thick frames at the top of the diagram. The remaining elements represent existing HCI patterns we have found in the above-mentioned sources. The arrows represent relationships among the elements, e.g. space may be saved using collapsible panels. A pattern may also serve several concepts. Moreover, patterns may be related.

Usually, enterprise models become very big and complex. So, space for interactions will become more and more scarce as a model is growing. To save space, several patterns may be used, such as collapsible panels or hover tools [START_REF] Tidwell | Designing interfaces[END_REF]. Tidwell introduced the pattern hover tools for mouse-based applications [START_REF] Tidwell | Designing interfaces[END_REF], where elements are displayed only when hovering the mouse icon over an object. For touch devices, there is not yet an equivalent to hovering, but only touching. Tidwell is of the opinion that touching may cause precipitate commitment. Nevertheless, it may ensure that the displayed model is not cluttered by displaying editing options which are not needed at the moment. Different views [START_REF] Van Welie | Welie.com: Patterns in interaction design[END_REF] may be used as an alternative, where users may switch between editing view and "final" view that is showing just the model.

Depending on the size of the table and of the model elements, it may be difficult to see/read or reach certain objects. As mentioned before, there should be 4-8 domain experts plus at least one method expert present at a modeling session. Thus, the software must present the model in a way that is visually and physically available to several persons at a time. Patterns such as zooming [START_REF] Remy | A pattern language for interactive tabletops in collaborative workspaces[END_REF][START_REF] Tidwell | Designing interfaces[END_REF] and extending reachability [START_REF] Remy | A pattern language for interactive tabletops in collaborative workspaces[END_REF] support physical and visual reachability.

As mentioned above, the modeling tool is mainly handled by the tool operator. However, Stirna and Persson suggest that domain experts should be involved by e.g. letting them write down their ideas on colored cards, present them to the group, discuss them and then cluster related cards [START_REF] Stirna | Enterprise Modeling -Facilitating the Process and the People[END_REF]. Thus, the editing software for the MTT should not be tailored to only the tool operator. It should also offer domain experts an easy way of capturing their ideas in their own words with the MTT. A third party like the tool operator may accidentally change the meaning of statements. Still, the tool operator may then assist in composing a syntactically correct model. Furthermore, the software should not be designed in a way that one person may take over a whole modeling session. Remy et al. [START_REF] Remy | A pattern language for interactive tabletops in collaborative workspaces[END_REF] introduced a pattern called balanced participation. This implies that there must not be any conflict about or restricted access to resources, especially input devices. An overlay menu [START_REF] Van Welie | Welie.com: Patterns in interaction design[END_REF], possibly with multiple instances, instead of a single fixed menu could support this. When providing a horizontal work surface, different perspectives must be provided for users possibly standing at all sides of the table. This is addressed by the pattern desktop orientation [START_REF] Remy | A pattern language for interactive tabletops in collaborative workspaces[END_REF] meaning that the orientation of the interface can be changed. Balanced participation could also be promoted by user identification [START_REF] Remy | A pattern language for interactive tabletops in collaborative workspaces[END_REF]. In private spaces participants may take notes of their own ideas, possibly with embedded electronic devices such as tablets [START_REF] Remy | A pattern language for interactive tabletops in collaborative workspaces[END_REF], before sharing them with the group analogous to the above mentioned card writing. However, the content produced in private space should be meant to be shared, otherwise it might undermine collaboration.

The modeling task itself brings some special requirements with it. As mentioned before, models can become very complex. So, the table should be large enough to both display the model and let all participants have access to the model (large collaboration table [START_REF] Remy | A pattern language for interactive tabletops in collaborative workspaces[END_REF]). According to [START_REF] Stirna | Enterprise Modeling -Facilitating the Process and the People[END_REF], domain experts should not be burdened with details of the modeling notation. Consequently, at best, the software should make obvious what can be done (e.g. with input hints [START_REF] Tidwell | Designing interfaces[END_REF]), and it should not allow what should not be done (e.g. with constraint input [START_REF] Van Welie | Welie.com: Patterns in interaction design[END_REF]), possibly already considering notation rules.

As domain experts should not be expected to be experts on digital touch devices such as tabletops either, the software must be very intuitive and easy to handle. An intuitive interface may be implemented based on patterns such as input hints, good defaults [START_REF] Tidwell | Designing interfaces[END_REF] and constraint input [START_REF] Van Welie | Welie.com: Patterns in interaction design[END_REF] such that users know what to do. With easy handling, we mean that it should not be difficult or effortful to see content on the table or to perform an interaction on the MTT. E.g., the "fat-finger" problem may be prevented by applying a pattern such as generous borders applied to the components of a model or buttons and keys With the MTT, different input devices are available. While the physical keyboard is often felt as more convenient, but occupying space on the work surface, on-screen keyboards may be instantiated for every user at each required spot and easily dismissed if no longer needed [START_REF] Remy | A pattern language for interactive tabletops in collaborative workspaces[END_REF]. Input tangibles may be used as an alternative [START_REF] Remy | A pattern language for interactive tabletops in collaborative workspaces[END_REF], although there must be some additional space where these objects can be stored beyond the work surface (physical object storage bin [START_REF] Remy | A pattern language for interactive tabletops in collaborative workspaces[END_REF]).

In an enterprise modeling session, it is also of interest how ideas evolved. The rationale may be documented by a secretary [START_REF] Sandkuhl | Enterprise modeling. The Enterprise Engineering Series[END_REF]. User identification may add information in a way that the author information of components in the model can be saved in addition.

Identifying HCI Patterns in a Prototype PEM Editor

In order to confirm the suggested HCI patterns, they should actually be applied in existing software. To our knowledge, there does not yet exist a commercial enterprise modeling editor especially developed for collaborative working with a MTT. Therefore, we have examined a prototype developed at the university of Rostock, as a starting point. In previous studies, we have worked with this prototype [START_REF] Gutschmidt | Empirical insights into the appraisal of tool support for participative enterprise modeling[END_REF][START_REF] Gutschmidt | On the influence of tools on collaboration in participative enterprise modeling-an experimental comparison between whiteboard and multi-touch table[END_REF] which allows creating goal models according to the 4EM notation on a MTT. In particular, it supports collaboration by enabling simultaneous input by several users. We wanted to know whether some of our selected HCI patterns from section 3 have already been applied in the software and present their concrete implementation. Due to space limitations, we can only describe a small selection. In Fig. 1 we have marked the patterns we have found in the prototype with a check mark.

In the editor, localized actions [START_REF] Tidwell | Common ground[END_REF] in terms of buttons directly accompanying components and relations, simplify the handling and support balanced participation, i.e. users can manipulate all the objects they can reach without having to access a menu possibly situated somewhere else. E.g., each component has a button to set it to an editing mode and to generate a new relation starting from this component. Moreover, when the user touches one of the text fields of a component which is in editing mode, an on-screen keyboard [START_REF] Remy | A pattern language for interactive tabletops in collaborative workspaces[END_REF] is attached right below the component. This keyboard belongs only to this component (localized object actions), every component may have its own keyboard. Thus, the keyboard is not a resource to be shared which should also promote balanced participation. Thus, actions referring to an object are situated in its close proximity as can be seen in Fig. 2a.

These buttons, however, are hidden by default in order to save space and keep an uncluttered view. Only when a user touches the component, the buttons appear. After a few seconds, the buttons slowly fade out following the pattern hover tools [START_REF] Tidwell | Designing interfaces[END_REF] (see Fig. 2a). By offering the possibility to rotate components, the pattern desktop orientation [START_REF] Remy | A pattern language for interactive tabletops in collaborative workspaces[END_REF] is partly implemented. Only single elements, but not the whole model can be rotated to a participant's respective orientation.

When a user wants to create a new component, a menu (see Fig. 2d) must be opened by hand gesture [START_REF] Remy | A pattern language for interactive tabletops in collaborative workspaces[END_REF], namely tap and hold. The same gesture is also used to set a relation into editing mode, e.g. for setting a label or deleting it. There is no fixed menu, but the menu can be opened at any point on the work surface as described in the pattern overlay menu [START_REF] Van Welie | Welie.com: Patterns in interaction design[END_REF]. The pattern balanced participation [START_REF] Remy | A pattern language for interactive tabletops in collaborative workspaces[END_REF] is implemented by allowing several instances of the menu. That way, participants do not have to share this resource. For the creation of the actual component from the menu, the pattern constrained input was used. The menu allows the creation of only those elements that are included in the modeling language. There is no free drawing.

WYSIWYG [START_REF] Tidwell | Designing interfaces[END_REF] is applied when drawing a relation and moving elements. E.g., components may be moved and rotated, and the effect of these actions can be seen immediately. Moreover, if a relation is connected to a component in movement, the relation's orientation and length is adapted automatically like a physical rubber band. Although the physical conditions do not belong to the software, we want to add some more patterns which may also have an influence on using it. The multitouch device is embedded in a wooden table making the hardware invisible [START_REF] Borchers | A pattern approach to interaction design[END_REF] and offering some space on the table's wooden frame and below the table to store physical objects such as a physical keyboard or handouts (physical object storage bin [START_REF] Remy | A pattern language for interactive tabletops in collaborative workspaces[END_REF]). Due to this setting, we are dealing with a horizontal work surface which cannot be tilted [START_REF] Remy | A pattern language for interactive tabletops in collaborative workspaces[END_REF]. It was technically not possible to use tangible objects nor user identification [START_REF] Remy | A pattern language for interactive tabletops in collaborative workspaces[END_REF] with the concrete device (cf. section 6.1).

Task Analysis

In order to further examine the software prototype and find potentials of improvement, we wanted to create an overview of user interactions with the software necessary to generate a model. We decided to use Hierarchical Task Analysis (HTA) to attain a graphical representation of theses interactions we could then examine. HTA may help discovering those parts of a task which may cause a user to eventually fail or to succeed [START_REF] Stanton | Hierarchical task analysis[END_REF]. The basic idea of HTA is that there is a general task at the highest level which consists of an operation. Each operation is connected with a goal whose accomplishment can be measured. Goals can be decomposed into sub-goals, thus the connected goals are decomposed into sub-goals. So-called plans determine the order in which (sub-)operations should be executed, including the formulation of conditions and circumstances by which operations are triggered [START_REF] Stanton | Hierarchical task analysis[END_REF][START_REF] Annett | Hierarchical task analysis[END_REF]. Examining the software prototype, we considered creating a goal model as main operation which we decomposed into sub-operations. We furthermore defined plans indicating when each operation is triggered. The resulting task model (see Fig. 3) will lead us later in the observation study presented in section 6.

When creating a goal model with the prototype editor, the user may repeatedly check the model before deciding on an action. When the user decides to add a new component, a menu must be opened offering the possibility to create as many components as desired. When the user wants to change the description or type of a component, or wants to delete the component, the editing mode of the component has to be started. Relations between components may be created starting from one component, drawing the relation to the target component. If a relation was created erroneously, it may be deleted right away. Relations may be labeled with a type by first starting an editing mode. The editing mode is also necessary if the relation is to be deleted. The general appearance of the model may be changed by moving and rotating components.

Video Analysis

From a previous study, we used secondary data to find out which of the interactions contained in the task model occur most frequently. We examined video recordings of thirteen modeling sessions performed with the software prototype without interventions of a tool operator. This might give hint on critical points that should be improved or supported in a better way by HCI patterns. For the same purpose, we examined what caused the most difficulties for its users. We also recommend additional patterns, marked with a plus sign in Fig. 1.

Method and Sample

Thirteen teams of three persons performed an enterprise modeling task on an MTT (3M Multi-Touch Display C5567PW, size: 1210 x 680mm) in a study conducted in 2018 at the University of Rostock [START_REF] Gutschmidt | Researching participatory modeling sessions: An experimental study on the influence of evaluation potential and the opportunity to draw oneself[END_REF]. The teams had to create a goal model for a fictitious company within half an hour. 27 of the 39 participants were students, among them students of psychology, business information systems, pedagogy, biology, physics, chemistry, economics, engineering and computer science. On a scale from 1 (novice) to 5 (expert) the participants reported to be quite inexperienced in the modeling notation (µ = 1.3, σ = 0.8) and with MTT (µ = 1.2, σ = 0.5).

The modeling sessions were video recorded from two perspectives, one showing the table from above, another one capturing the front view on the team. We analyzed the video recordings looking for specific difficulties the participants had during the modeling. Sometimes, participants commented on their problems during the critical incident. At other times, clearly identifying problems with the use of the software turned out to be difficult and is dependent on the observer's interpretation. Moreover, we counted the interactions introduced in our task model (Fig. 3).

Results and Recommendations

The difficulty which occurred most often (µ = 11.2 times over all sessions) was that menus were opened accidentally. When movements, such as dragging a component, were performed too slowly, this was misinterpreted by the software as tap-and-hold gesture, and unwanted menus were opened. The challenge is to choose hand gestures which are easy enough for the user to perform but clear enough for the system to be distinguished from other actions. We suggest a double tap as a substitute since more complex gestures might make the software less intuitive [START_REF] Remy | A pattern language for interactive tabletops in collaborative workspaces[END_REF]. Hand gestures have to be thoroughly tested.

Three types of negative incidents were often caused by a lack of space: the editing mode was opened accidentally (µ = 3), a new relation was created by accident (µ = 2.6), and the wrong component was moved (µ = 2.3). As the models grew in complexity, more and more elements were overlapping. To save space, hidden buttons were used. Although the buttons were no longer visible they were still active. This caused users to accidentally press hidden buttons of closely situated components creating new relations etc. To solve this problem, we could disable buttons when they are not visible. Putting buttons inside the components bears the danger of accidentally triggering actions where components should only be moved. A hand gesture could be used to replace one button, possibly mitigating the problem. Close proximity of model elements was, however, only one reason for these negative incidents. Accidental actions were also triggered by participants leaning or putting sheets of paper on the table. Remy et al. [START_REF] Remy | A pattern language for interactive tabletops in collaborative workspaces[END_REF] suggested physical object storage bin for storing items such as keyboard or tangible objects, but no surface to actually lean on or put down sheets of paper is mentioned. In the future, additional frames around the MTT might turn out as a pattern. Nevertheless, such a frame can be in conflict with reachability of all elements on the MTT depending on the size of table and frame.

Considering the interactions to be performed with the goal of creating an enterprise model, opening a component's editing mode was performed most frequently (µ = 31.4 times over all sessions), followed by closing a component's editing mode (µ = 30.1) and editing a component's description (µ = 29.8). This frequency might encourage to believe that these interactions should be additionally supported. E.g., one could think about simplifying the access to editing functions as we have already described above. Another option could be to automatically set a component into editing mode after having created it. This, however, could be in conflict with creating a pile of items where participants create a kind of repository similar to a stack of cards.

Creating a new relation is the next most frequently performed interaction (µ = 25.8). It is performed by tapping on the component resulting in the display of an arrow button. When the button is pressed a new relation arrow is generated pointing to a red circle that must be drawn to the target component (see Fig. 2b). We observed that some users wanted to draw the arrow button to the target component right away. It seems that this button implies this functionality. Either the button symbol has to be changed or, better because reducing the number of steps, the expected behavior should be implemented. The latter would also make dismissing new relations obsolete and simplify the creation process.

Drawing a relation occurred 20.8 times on average over all sessions. It seems to work well for the participants, probably being very intuitive. Opening the editing mode of the relation was performed equally often (µ = 19.8). The low occurrence of editing interactions such as changing the relation type (µ = 11.4) and changing a relation arrow's direction might be explained by the way they had to be accessed (see Fig. 2c for illustration of the editing mode). We observed that some participants did not expect a tap-and-hold gesture but simply tapped once on the relation. The latter would, however, increase the danger of triggering unwanted actions. Nevertheless, it should be taken care that hand gestures are consistent for similar functions. Moreover, good defaults could be provided for new relations taking into consideration syntactic rules.

Creating components occurred with an average frequency of 18.8 times. We see the possibility of opening multiple menus for the creation of components at every spot as a major advantage when supporting this interaction. It also enables the creation of a pile of components compared to a participant grabbing a pile of cards he or she can write on.

Closing a menu (µ = 14.8) and closing the relation editing mode (µ = 14.5) occurred with a similar frequency. They could be made obsolete by closing them automatically after an interaction was performed. It must be investigated and compared how useful users find each feature.

Deleting a relation (µ = 4.6), deleting a component (µ = 2.5), dismissing a new relation (µ = 2.5) and changing a component's type (µ = 2.4) occurred rarely. Participants did not seem to experiment with model elements after they had created them. Nevertheless, an undo function is fundamentally advisable with inexperienced users. Opening a menu was also a rare interaction (µ = 4.4). Menus remained open although they took a lot of space. Either users prefer a constantly present menu or the actions necessary to open (tap-and-hold) and close a menu are considered as too effortful.

We also observed how much participants moved and rotated components. For the interactions, we measured the average overall amount of time over all sessions. As some users tended to perform one big movement in several small steps, frequencies would have given a distorted impression of the actual movement behavior. We noted that rotation was rarely used (µ = 4.6 seconds). One reason might be that rotating components is too difficult. Secondly, rotating single elements might not be seen as beneficial when the remaining model keeps its original orientation. Remy et al. [START_REF] Remy | A pattern language for interactive tabletops in collaborative workspaces[END_REF] suggest a generally adaptable desktop orientation. This would be a global function requiring the awareness and approval of all users such that no one will be disturbed while working. 5.8 seconds were spent on average on handing over components to another person, and 13.8 seconds were spent on average on moving components to oneself. Due to space problems and layered objects, users often moved components to a place were they could interact with them more conveniently (µ = 17.5 seconds). Movement that we could not assign to any of the above categories made about 179.1 seconds on average. We often observed that participants repeatedly rearranged components to minimal extend, similar to fidgeting with a pen.

In one of the modeling sessions, a software bug made the system crash. As there was no autosave, the model had to be recreated quickly. Although the bug has been removed, autosave is fundamentally advisable.

The space problem caused several difficulties. It could generally be mitigated by a zoom function. A global zoom is again a function whose activation must be agreed on by all active users. A panning navigator should additionally be used to give users some orientation about what part of the model they are currently viewing. Another option would be to make all elements smaller by default, but still recognizable, and offer a zooming function for a single component for further examination and editing. Furthermore, the menus are very big in relation to the work surface and the other model elements. To save space, the menu could be replaced by simply creating default components, set into editing mode from the beginning. This would, however, make creating a pile of components difficult. The work surface could be extended using embedded electronic devices which may also serve as private spaces. Finally, one could also consider buying a bigger table, however a large collaboration table could undermine reachability.

General Discussion

New digital devices such as MTT appear very attractive in the context of PEM. They can be a useful tool for collaboratively gathering knowledge and ideas. The intent of this paper was to present experiences and give inspiration on how to design software for MTT serving PEM. HCI patterns provide proven solutions to frequent design problems which may be reused by interface designers. We have searched existing lists of HCI patterns, many of them do not originally refer to touch applications. We presented a selection of HCI patterns we assume to be suitable for PEM on MTT. However, a pattern is really a pattern when it is repeatedly used. To our knowledge, there is no commercial PEM software which is originally made for MTT. So, as a starting point, we investigated a software prototype to check whether we would find some of the previously selected patterns and we showed what kind of interactions are required to create an enterprise model on an MTT with this prototype. Our task and video analysis have shown that the number of interactions may actually be reduced in the prototype. The results of the video analysis also revealed shortcomings of the prototype which might be overcome by using additional HCI patterns from our selection.

One of our major findings is that certain patterns may be in conflict. E.g., in the prototype, multiple instances of menus and on-screen keyboards were used. On the one hand, this supports balanced participation. On the other hand it takes a lot of space. The lack of space is a severe challenge, yet, a large collaboration table could make it difficult for users to recognize and reach all elements. A zoom function could also help solving the space problem, however, as a global function it might disturb users in their work. Thus, we recommend to use global functions with care. Hand gestures are a beneficial means for saving space. Nevertheless, we recommend to test which gestures users find intuitive and convenient. Furthermore, there must be consistent gestures for similar functions. We observed modeling sessions where participants were usually standing. We found that some persons tended to lean on the table or put down paper on it. Thus, we would recommend to use a frame around the table, but thoroughly considering that this will not restrict reachability.

Eventually, our selection of HCI patterns can certainly not be considered as complete or final. We hope to be able to investigate more applications in this area in the future to further test, confirm and adapt our selection of HCI patterns.

Fig. 2 .

 2 Fig. 2. Example screenshots of the prototype showing a) localized object actions, on-screen keyboard and hover tools, b) drop-down chooser for selecting a component type, c) a relation in editing mode with drop-down chooser, and d) overlay menus and a newly created relation with tool tip/input hint.

Fig. 3 .

 3 Fig. 3. Task model with basic user interactions with the prototype modeling editor.

  Selection of HCI patterns suitable for PEM on a MTT. Please note that HCI patterns may have different names in the pattern catalogues. A check mark means, the pattern has been found in the software, a plus mark means, the pattern should be added.[START_REF] Tidwell | Designing interfaces[END_REF]. The pattern WYSIWYG (what you see is what you get)[START_REF] Tidwell | Common ground[END_REF] should make interactions quicker, as immediate feedback of one's action is given.

			Document	rationale	On-screen identification + User	keyboard	Pen	input	Dynamic Tangibles + Input Physical keyboard keyboard relabeling	+ Embedded	electronic	devices
			Input	devices
					Generous	borders							Localized	object	actions	High	precision	Hand	gesture	Autosave + [25]
			Easy	handling												Convenient	environment	actions
					WYSIWYG	[22]				Extra	step	Proximity &	similarity	Invisible	hardware	Explorable	interface/	undo	Zooming +	[23,24]
	Participatory	EM on MTT	Intuitive	interface												+
			Support	modeling	Constraint	input			Input	hint		Good +	defaults	Center	stage	[21,23]	Color &	contrast
			Balanced	participation	Overlay	menu	Private + space			Large	collaboration	table	Disable	irrelevant	things	Sovereign	posture
																Pile of	items
			Physical/visual	reachability		Extending	reachability	[24]		Desktop	orientation	Panning + navigator
			Save	space		Collapsible	panels [23,21]		Physical object	storage bin	[24]	Hover	tools [23]	Drop down	chooser [21-23]	View	[21]	Symbols/Icons	[21,26,27]
	Fig. 1.

Close Editing Mode of Relation 5.3.4 Change Direction

			Plan 0: Do 1 Then 2 Or 3 Or 4 Or 5	0. Create Goal Model
			Until Model is
			accurate and
			complete Then
			Exit
	1. Check Model Plan 2: Do 2.1 If Menu closed Do 2.2 Then Do 2.3 Then 2.4	2. Add Component 2.1 Check Menu	3. Change Component 3.1 Check Editing Mode	Plan 3: Do 3.1 If Editing Mode is inactive Do 3.2 Then 3.3 Repeat 3.3 until Component is accurate and complete If component exists and state is OK Do 3.4	4. Create Relation Plan 4: Do 4.1 Then If Relation is erreneous Do 4.2 Else 4.3	5. Change Relation 5.1 Check Editing Mode	Plan 5: Do 5.1 If Editing Mode is inactive Do 5.2 Then 5.3 If Relation exists and state is OK Then 5.3	6. Structure the Model Plan 6: Do 6.1 If Position is wrong Do 6.2 Or 6.3 Else Do 6.4
	If Menu no longer needed Do 2.5	2.2 Open Menu	3.2 Open Editing Mode of Component		3.3 Edit Component	4.1 Create New Relation at Component	5.2 Open Editing Mode of Relation	5.3 Edit Relation Plan 5.3: Do 5.3.1	6.1 Check Appearance of Element
		2.3 Choose Component 2.4 Create Component 2.5 Close Menu	Plan 3.3: Do 3.3.1 If Components text is Type is inaccurate Do 3.3.3 Else Do 3.3.4 Else If Components inaccurate Do 3.3.2 3.4 Close Editing Component Mode of	3.3.3 Change Component type 3.3.1 Check Component Description of Component 3.3.2 Change	other Component Relation with 4.3 Connect Component Relation at 4.2 Dismiss New	5.4	Relation Type 5.3.2 Change Relation 5.3.1 Check If Relation Type is inaccurate Do 5.3.2 Else Do 5.3.3	Element 6.3 Rotate 6.2 Move Element
					3.3.4 Delete Component			5.3.3 Delete Relation

Acknowledgements. Part of the research has been developed in scope of a project financed by Government of Russian Federation (Grant 08-08).