key: cord-0725900-wa4ksvsk authors: Schweitzer, Stefan; Gerbershagen, Matthias; Elberzhager, Frank; Braun, Susanne title: Concepts and Solutions of the Digital Teams Platform to Support Mobile Work and Virtual Teams date: 2020-12-31 journal: Procedia Computer Science DOI: 10.1016/j.procs.2020.07.011 sha: 394a057caecd43b08764b586e63e946d0353b4d0 doc_id: 725900 cord_uid: wa4ksvsk Abstract New work models have been discussed for several years. Especially in the area of knowledge work, mobile and distributed work provides advantages over presence time at companies: It offers more freedom and flexibility to the employees, reduces travel time, and counteracts a major trend: the exodus from rural areas. However, to provide an optimized digital work environment for distributed teams of knowledge workers, many different aspects must be considered, including social, physical, legal, and technological aspects. In this article, we focus on the technological aspects. Nowadays, a multitude of tools and technologies exist to support the communication of distributed teams, to allow working concurrently on documents, or to support data and document exchange. However, many existing solutions only provide solutions for a specific purpose rather than a sophisticated platform that offers all of these services in an integrated manner and additionally takes care of delivering intelligent and data-driven services in a trustful and ethical way. In the research project “Digital Teams”, we aim at developing such a platform as open source. In this article, we provide the basic architecture of our platform and share the main concepts and solutions we are currently implementing, such as our dashboard, data exchange concepts, or authentication and authorization mechanisms. Today, digital transformation permeates all areas of our lives, such as transportation, communication, leisure, work, and many others. It provides support in many respects, makes processes more efficient and user-friendly, and allows fundamentally new ways of use. One area greatly influenced by digitalization is work. New work models emerged in the last decades, such as the possibility to shift from presence work to mobile work. Of course, this does not apply to all types of work, but knowledge work, in particular, is potentially suitable for such mobile work models. So, the topic is not new per se. How to make work more flexible has been discussed during the last thirty years. While some challenges have not changed much, such as those related to motivation or team-leading (i.e., social questions, see also [1] ), the technology challenges have changed dramatically during the last two decades. For instance, in the late 1990s, the Internet did not allow for large data-consuming services and communication solutions, but today this is no longer a challenge. Today, the proportion of knowledge work is steadily increasing. For instance, in North America, knowledge workers are estimated to outnumber all other workers by a one to four margin [2] . Furthermore, it is assumed that this proportion will increase even more in the future, as Industry 4.0 and the assumed even higher degree of automation will mean that added value will increasingly be generated by knowledge workers. Knowledge generation is a demanding task and often requires close collaboration of different experts in interdisciplinary teams. Despite digitalization and the availability of a lot of different digital collaboration tools, knowledge generation still often works best if team members are co-located [3, 4] . On the other hand, we have observed numerous other trends in the last decade that make this traditional form of colocated working more and more inadequate. In many western families, both parents have full-time jobs, which requires flexible working times and places, e.g., working in the evening at home when the children are in bed. German politicians are even discussing the legal right to work at home in the event that preschools close unexpectedly because of disease outbreaks or pandemics like the COVID-19 pandemic in 2020. In recent years, some countries have experienced an exodus of people from rural areas and an explosion of housing costs in the big cities. Along with that came a drastic increase in commuter traffic and rapid deterioration of air quality. All these challenges could be drastically mitigated if people could freely choose where to live (rural or metropolitan area) and also, in the case of knowledge work, if they could work from where they live (e.g., from home or from a nearby co-working space). The Digital Teams platform aims to provide a novel digital working environment optimized for distributed teams of knowledge workers. Our open and open-source platform fosters the development of an ecosystem of integrated smart tools and services. While today's integrated solutions often focus on certain functional aspects like chat or collaborative document editing, we aim at providing an open-source software platform that not only integrates all core business functions of digital collaboration, but also delivers an intelligent digital working environment that can adapt to different needs of different teams, as well as to different working situations. Teams can configure this working environment according to their specific needs, applying a best-of-breed strategy and combining tools from different vendors to be used within our solution. At the heart of this solution is a dashboard that provides different views for different working situations, e.g., times of team collaboration, meeting times, or focus times. Integrated into the dashboard is Teamo, a virtual team assistant, that protects and supports teams, e.g., by taking over routine tasks. Teamo also delivers data-driven insights to help teams and team members continuously improve regarding team collaboration, team spirit, self-caring, etc. We focus especially on exploring the potential of data analytics and artificial intelligence to deliver our vision. Our value proposition is to do this in a way that is ethical and compliant with high data privacy standards. In this article, we present our current platform concepts and selected characteristics of the platform. In Section 2, we present related work and current tools that support distributed work. Section 3 provides an overview of our objectives, the context, and the high-level concepts regarding our Digital Teams platform. Section 4 refines central concepts implemented on that platform. Section 5 summarizes the paper and provides an outlook on future work. The topic of distributed work was already discussed some thirty years ago. Townsend et al. [5] , for example, provided ideas about virtual teams and how the workplace will look like in the future. They also already mentioned the technology leap and the resulting opportunity to perform distributed work. However, from today's perspective, technological progress has been immense during the last twenty years, allowing much more sophisticated work models. In the scientific field, there are at least three main topics that are being discussed: (1) how to organize virtual teams and the work environment, (2) social aspects such as leading a virtual team, personal responsibility for self-organization, or trust building among the members of a virtual team, and (3) tools and technology. Guzman et al. [6] , for example, discuss how to organize teams to make them more mature and propose a framework that supports global virtual teams. Besides the framework and a process, a set of tools is proposed to support teams in collaborative working, and certain cultural and social challenges are also discussed. Thissen et al. [7] focus particularly on communication tools and group them into seven categories, such as chat, remote access control, web conferencing, file transfer, or mail. They performed three studies with teams to analyze different tool combinations. Based on the results, they derived lessons learned, for example letting the team select tools of their choice or fostering high communication frequency. Davidekova and Hvoreck [8] analyzed several ICT tools regarding their purpose and suitability. The authors propose a model that might help in setting up virtual environments appropriately. Furthermore, Christian and Rotenstreich [9] proposed an evaluation framework for distributed collaborative tools. They classified 16 tools regarding criteria such as coordination, visualization, or context persistence. Several tool solutions exist in support of distributed work. Such tools often focus on a certain functionality, for example, on communication, collaborative document editing, or exchange of documents. Thus, tools are often very specialized for their purpose and provide several features. For instance, communication tools such as Slack [4] offer functionalities such as video or audio call and chat. Some of these tools offer very limited solutions for additional purposes such as document sharing. Traditional document exchange platforms such as Google Drive [10] offer large storage capacities and various features that support comfortable document exchange, e.g., file hierarchies or versioning. Some of these tools offer notification mechanisms, which can be seen as a kind of communication. However, document exchange tools are no replacement for communication tools. Nevertheless, in recent years some of these specific-purpose app providers have either opened up their APIs to enable others to integrate with them or have broadened their spectrum to deliver a whole suite of apps for collaboration. For example, third-party providers can deliver chat bots for Slack. Atlassian has announced that it will integrate its collaboration tools with Slack [11]. With GSuite [12], Google provides a whole suite of digital collaboration tools. In recent years, Microsoft has positioned Teams [13] as a major competitor against Slack and has integrated it with its own cloud-based office suite O365 [14] . Furthermore, Microsoft offers the Microsoft Graph API [15], which enables direct access to data. This can also be used by third-party vendors to integrate their own apps into the Microsoft ecosystem. Thus, the big players are also driving their existing products towards becoming an ecosystem. However, all of these campaigns are still very much centered on the original product, with corresponding lock-ins to the original vendor. None of them is open source. Another issue is privacy and the physical place where data is stored (e.g., the need to comply with the European General Data Protection Regulation (GDPR)). The main objective of our Digital Teams project is the development of an open ecosystem for distributed work. The central component of the ecosystem is the Digital Teams platform. The main purpose of the platform is to offer support for knowledge workers in such a way that they can collaborate with their team from home or from co-working spaces with the same efficiency and effectiveness as if they were co-located with their team. We focus both on distributed working for people in rural and urban areas, and on providing support, mainly in the shape of organizational and smart tool support. We are developing a platform with several services that supports individuals and teams in distributed working. For example, one service is the daily planning of tasks that is shared with team members. Team members can then easily see when others are available or when future vacation is planned so that issues to be discussed can be done in time. Each person or team can adapt our solutions to their specific needs. This means that the services to be used can be selected individually. Further service categories include task management systems, chat services, or calendar services. For us, such services are provided as apps that are integrated into the platform. Different services can thus benefit from each other due to the integration into one platform. Potentially, there could be hundreds of such services in the future. One main characteristic of our platform is that we want to make it usable for a large number of service providers, so a flexible solution is a central requirement. This also means that we want to enable third-party providers to integrate their own solutions. Concretely, third parties should be allowed to develop their own apps for the platform and integrate them via an open interface. Our platform will not restrict third-party vendors in terms of where and how they have to operate these platform apps and the required underlying systems; only the integration with the platform must be ensured. Our platform's deployment strategy should also be flexible. From the perspective of the provider of our platform, we do not prescribe whether the platform should be operated as an on-premise or SaaS solution. Nor do we prescribe which cloud provider to select in case we operate it as a SaaS solution. During operation, we follow a multi-tenancy concept, i.e., several organizations or organizational units might run on the same platform but as separate entities. However, potential guest accounts might allow access to the same data or co-working between different organizational units. All of these concepts and ideas result in concrete requirements for the architecture of our platform. Among others, the most relevant ones are the following (which will be further refined from a technical perspective in Section 4): • Our solution offers the Digital Teams client as the front-end component for every user. This client integrates two main components that support the user in working in a virtual team setting (Section 4.1): o A customizable dashboard that displays different kinds of information such as personal, team, or meeting information depending on the current context (Section 4.2). o "Teamo", a virtual AI-based assistant that communicates via text or voice and can perform simple tasks such as to create new tasks during a meeting (Section 4.3). • Both the dashboard and Teamo can be extended by third-party vendors. These extensions are bundled via an app manifest and made available to users as platform apps in the platform marketplace (Section 4.4). • Single sign-on via keycloak allows the user easy access to the services of the platform as well as to services and data of various third-party systems where the user is registered (Section 4.5). • The platform`s data exchange allows third-party providers to retrieve data from various other third-party providers in a uniform data model for use in its services (Section 4.6). The different components and their relationships are depicted in Figure 1 . The client of the Digital Teams platform is implemented as an Electron [16] application. One reason for this choice is the ability to include dashboard extensions based on standard web technologies with almost no effort. This significantly simplifies the creation of dashboard extensions for external providers because many companies already offer web-based applications as part of their product portfolio. Thus, they can make use of their existing libraries and applications and do not have to build up additional knowledge about frameworks or programming languages. Compared to a pure single-page web application that runs inside a web browser, an Electron application has the additional capability to interact with the operating system by using NodeJS functions and libraries. These provide interfaces for operating system functions that are not available inside a normal browser. Another important requirement for the Digital Teams platform client is the ability to work offline. In rural areas, mobile networks are often not available or do not provide a reasonable bandwidth. Making a web application capable of functioning offline can be a challenging task, but modern web technologies already provide means for support, for example the service worker. The Digital Teams platform client solves this problem by combining different technologies: the service worker concept, the IndexedDB database, and the cache API. The latter is used for caching static assets, like JavaScript or CSS files. Required assets of the Digital Teams client web app are pre-cached by the service worker upon first access. Structured application data is stored in the IndexedDB database. If it is only necessary to store smaller amounts of data, it is possible to use the local storage. By combining these APIs, we ensure that the Digital Teams platform client can run offline. Dashboard elements can make use of these technologies as well as ensuring offline capability. The platform includes a dashboard that helps users organize their work by displaying relevant information depending on the current working context and providing supporting functions. For each user, a personal view exists. A user can be a member of one or more teams. For each team of which the user is a member, an individual team view exists. Each view contains a number of extensions. Extensions for teams are, for example, the availability of team members, a task board, or team mood recognition. The individual view can contain extensions such as a task board, an activity protocol, a work day summary, or daily planning. This dashboard is one of the platform's basic components for providing and sharing information. Another important aspect is that we allow third-party vendors to develop their own extensions. An example and details can be seen in Figure 2 . We decided to implement the dashboard as a single-page application integrated into the Digital Teams client. The dashboard uses standard web technologies such as HTML, CSS, and JavaScript. It is hosted on the Digital Teams platform so the user can access the dashboard via different browsers from all over the world. In addition, this also allows easy and fast updates without any user involvement. We utilize the ServiceWorker technology to ensure offline availability. Two relevant qualities of our dashboard that we are currently focusing on are extensibility and security. As the platform vendor, we already provide a set of extensions. However, it is possible for third parties to create their own extensions. We treat each extension as a black box. To be able to include new extensions, third parties can use standard web technologies of their choice. In the end, only a web URL is needed to include the new extension. If a third-party extension should have offline capability, the vendor is responsible for implementing the respective functionality. With respect to security, we distinguish between the dashboard and the individual extensions. The dashboard is a direct part of our platform and therefore under our control. We proclaim that this part has a higher level of trustworthiness due to the security concepts implemented on the platform. Compared to the dashboard, the individual extensions are considered not trustworthy at all because we do treat them as black boxes, as we do not know their internal implementation. For this reason, each extension is executed in an inline frame (iframe). An iframe is a sandboxed execution context provided by the browser. Communication with the dashboard is allowed to access more information and execute certain operating system functions. For example, the dashboard may access the NodeJS functionality of Electron to start external applications, such as Microsoft Word or Excel. In contrast to this, the extension is not allowed to do so because this is a potential security risk. For extensions, access to such functionality is only possible via crossdocument messaging † with the dashboard. In order to distinguish the different access levels to the platform, each extension gets a unique token. All requests to the platform have to provide such a token so that the platform can check whether this access is allowed or not. Teamo is a virtual assistant, depictured in the upper left part of Figure 2 , which can perform simple tasks on demand. Interaction is possible via chat or voice. For example, a user can ask for the day's tasks. However, not only is such 1:1 communication possible, but Teamo can also support standups, where it provides a list of open tickets to the team. We further support text-to-speech and speech-to-text. Teamo itself runs on the platform and invokes registered skills when needed. These skills themselves are hosted and run by the app providers. Dashboard extensions and Teamo skills can be bundled into Digital Teams apps. These apps can be provided by the platform owner as well as by third parties in the platform's marketplace. Each dashboard extension or skill uses a URL to access a service hosted by the app provider. For every app, a manifest is provided by the creator and stored on the platform. Tenants then determine which apps they will allow their users to use, for instance based on company agreements and legal regulations. Only special users (tenant admins) are allowed to approve apps for company usage within the admin user interface of the Digital Teams platform. Apps that are not approved by a tenant admin are not available to the user. These decisions require some information in the app manifest provided by the creator of the app. Apps must specify in the manifest which kind of data they wish to access via the data service. Such a specification may either be empty, or it may contain a set of data access rights. If it is not empty, it has to be a set of triples consisting of the domain of the data (e.g., calendar, mail), the access type (read, write, or both), and the scope (team, user, custom). A user can then decide before installing the app whether they want to accept the app's data access rights. The data service checks the rights of the app and prevents any access to data not specified in the app. The Digital Teams platform is based on open standards and open-source software components and frameworks. For authentication and authorization, we chose keycloak [17] as our Identity and Access Management solution because it is † https://html.spec.whatwg.org/multipage/web-messaging.html open source and provides full implementation of the standard protocols OpenID Connect, OAuth 2.0, and SAML 2.0, as well as several advanced features we require, for example identity brokering or clustering for high availability. One of the key features of the Digital Teams platform is its ability to abstract away the complicated and error-prone handling of identity brokering for the platform apps. A user of the Digital Teams platform may have multiple different accounts at different data provider systems connected to the Digital Teams platform; for example a Microsoft account for Office 365 and an Atlassian cloud account for Jira and Confluence. Using the identity brokering feature of keycloak enables the platform to manage these accounts. Keycloak links the user's external accounts to their Digital Teams account. After linking, it is possible for platform services to retrieve a valid external access token by invoking a REST endpoint of keycloak. The Digital Teams platform uses OpenID Connect 1.0, an extension of the OAuth 2.0 standard, which is supported by many open-source and commercial libraries and frameworks. To further simplify the development of a platform app, a library will be provided to platform app vendors. This library abstracts away authentication and authorization details and provides a very convenient JavaScript-API for an app to retrieve data from the platform. Each app retrieves one token per user and Digital Teams client, which is why malicious apps as well as lost devices can be blocked easily by revoking the corresponding tokens (important aspect in order to fulfill the various security compliance rules of different enterprises). In a mobile work environment, especially in rural areas, Internet access might not always be available. However, using some functions, such as adding a task to one's personal task board, still make sense even without Internet access, because the newly created task can be automatically synced to the server in the background when the user's device goes online again. To enable this automatic background sync, users of the Digital Teams platform have to stay signed in even though they are working offline. The OpenID Connect specification [18] already considers such a scenario and provides two means for handling this. In order to access our platform's API, a valid access token is always required. These access tokens are only valid for a short period of time and an application must request a new access token if its current one is invalid. If the user has been offline for a short period of time, they can use the refresh token flow as described in the OAuth 2.0 standard to get a new access token for the Digital Teams platform. For longer offline periods, refresh tokens are not suitable because they also expire at some point. The OpenID Connect specification provides a special kind of token for this, the offline token. This token never expires, is not restricted by any session lifetime, and is thus suitable for such scenarios if stored securely on the user's device. It can be used to obtain a new access token after a longer offline period. This requires some additional measures to be taken to keep the security risk at an acceptable level. Thus, this feature needs to be explicitly enabled for each tenant and user in keycloak. The data service of the Digital Teams platform provides an interface for external and internal services to retrieve and write data from third-party data providers as unified data models. Data service models are structured according to domaindriven design into different domains, like tasks, calendars, and chats. The data service implements the Command Query Responsibility Segregation (CQRS) pattern [19] , which separates reads and writes into different models and uses "commands" to update and "queries" to read data. Furthermore, the data service asks different providers for the data of the requesting user, transforms the results into a harmonized domain model, and combines these results. In addition, the data service filters out data that the requesting user or a requesting service is not allowed to see. For example, an external data provider may return data of users who do not have an account with the Digital Teams platform. For the tasks domain, the data service offers a special interface for offline synchronization of data. This interface is based on a semantics-driven optimistic data replication approach [20] . The approach enables truly offline-capable applications because it resolves conflicts that may arise if two or more users manipulate the same data record on a sematic level. Solving these conflicts only with a syntactical approach may not be possible or may lead to undesired results, e.g., lost updates. In this paper, we presented the Digital Teams platform and the fundamental concepts implemented. Our platform aims to provide a novel digital working environment optimized for distributed teams of knowledge workers, facilitating the demanding task of knowledge generation in an increasingly challenging working world. Teams can configure this working environment according to their specific needs, applying a best-of-breed strategy by combining tools from different vendors within our solution. While today's solutions often focus on certain functional aspects like chat or collaborative document editing, we aim to provide an open-source software platform that not only integrates all core digital collaboration business functions, but also offers an intelligent dashboard that can adapt to different working situations. Integrated into the dashboard is Teamo, our virtual team assistant, which protects and supports teams and team members. According to our current development roadmap, we will first focus on providing the dashboard as a minimum viable product capable of automatically adapting to different working situations, like meeting times, focus times, collaboration times, etc. Another important aspect regards the transfer of real-world experiences into the digital collaboration space. This is particularly relevant for virtual meetings and helps to make them less cumbersome and exhausting, especially for meeting moderators. We will address those needs with a dedicated dashboard meeting view and corresponding dashboard extensions. At the end of the project, we plan to evaluate our solution especially in team settings with knowledge workers living and working remotely in rural areas who have to collaborate with co-workers being co-located in metropolitan regions. Our goal is to show that with our solution, teams staffed with members living in rural areas and members living in big cities can work together remotely as smoothly and productively as if all team members were co-located in the same place. Finally, we hope that our solution can contribute to less commuting and fewer emissions, as well as to a revival of rural areas if more digital pioneers like ourselves rediscover the countryside as their preferred place to work and live. Virtual Teams: A Review of Current Literature and Directions for Future Research. DATA BASE Management information systems for the information age Economic fundamentals of the knowledge society Slack Virtual teams: Technology and the workplace of the future How to get mature global virtual teams: A framework to improve team process management in distributed software teams Communication tools for distributed software development teams ICT Collaboration Tools for Virtual Teams in Terms of the SECI Model An Evaluation Framework For Distributed Collaboration Tools Google Drive Microsoft Teams Build cross-platform desktop apps with JavaScript Open Source Identity and Access Management OpenId Foundation (2020, March) Semantics-Driven Optimistic Data Replication: Towards a Framework Supporting Software Architects and Developers This research was partially funded by the German Federal Ministry for Economic Affairs and Energy in the project Digitale Teams (project number: 01MD18007C). We thank Sonnhild Namingha for proofreading.