During the last decade the manufacturing industry focused on the realization of industry 4.0 aspects. Besides the implementation of new technologies, existing software structures also need to be reviewed and adapted in this context. To stay competitive in the global market, especially small and medium-sized companies need to emphasize on better cooperation with other organizations. This leads to the implementation of cross-organizational distributed software system structures. The development of distributed systems faces different challenges - technical and code-centric as well as social challenges. This paper focuses on the social challenges that appear in distributed development processes. After defining the main challenges, the paper introduces a development approach that is based on the integration of a Federated Management System (FMS). FMS is a technical approach to minimize social challenges by the generation of system transparency and the provision of a platform for communication and interaction. It facilitates a distributed system development of cross-organizational event-based systems.
The manufacturing industry is subject to current trends in the market, such as
increasing product variety, custom and individual fabrication, as well as reducing
production and delivery times [
Most of the Industry 4.0 approaches are based on comprehensive data
acquisition and usage. By now, data is captured by several different devices and
systems. It needs to be collected and stored in order to process it for further
purposes. To support the manufacturing industry in its current challenges, several
research projects, e.g., [
By analyzing the outcome of these researches, it is noticeable that all developed architectures show distributed system structures. Which means that parts of the systems are separated but work together like a single system.
Mishra & Tripathi [
Considering the schema that is displayed in Figure 1, a distributed system may
belong to one up to three of the displayed categories. Each category implicates
specific challenges that need to be considered [
Effective collaborations within distributed systems require adequate technical
solutions. But especially for systems that have distributed users and/or developers,
an adoption of good organizational practices and development processes is also
necessary [
The integration of system users and developers with different knowledge in
the development phase of a software is not a new aspect. All agile methods
already implemented this aspect to enhance the field of knowledge and to get
feedback early in the development phase [
Allaho & Lee [
Transparency is a very important aspect, also for Carbot et al. [
Promoting contribution not only refers to system developers, it also includes
system users. Wikipedia is probably the most known example. There, a high
amount of system users are motivated to contribute to the system [
The importance of a medium for communication between system developers
was also addressed in the work of Mu¨ller [
Social Challenges in Distributed System Development
Based on the observations that were made, the social challenges in distributed
software project can be summarized as:
C1 how to provide transparency (motivated by [
Transparency (C1) needs to be established in the entire distributed system. That means, architectural aspects (relating the hardware and software) need to be transparent as well as system contributions from users (e.g., feedback) or developers (e.g., system extensions). System transparency helps to understand the systems structure and behavior. Hence, it can be seen as the main social challenge in distributed systems.
System contributions (C2) are very important as they expand and improve the system. System transparency helps to minimize entry barriers for new contributors. Furthermore, the knowledge about a system’s functional and operational range may inspire people to contribute new extensions and improvements.
The optimization of collaborations (C3) is important to maintain efficiency in system development and system operation. The system, or its environment, should provide a possibility (e.g., a tool) for users and developers to manage and optimize their collaborations. 4
This section provides an overview of the context and the assumptions under which the development strategy, presented in the following section, was developed. Since processes in the manufacturing industry are mostly triggered by occurring events (e.g., start and finish of tasks, error announcements, attainment of states, such as temperatures) it is assumed to have a system that has an event-driven architecture: information is published to a broker that routes it to subscribing services.
To support collaborations among small and medium-sized companies, an inter-organizational system usage should be supported by the system. That may enable companies to integrate machines and devices to the system and share information with a federated group of organizations.
Furthermore, the system should enable decentralized system development, where system components are developed by autonomous groups of software developers. They may develop new system components (services) that can be added to the system.
In order to develop a strategy that supports the development of such systems, in summary, we assume that: – the system shows a distributed system structure in all categories (software & hardware, users, and developers) – the system is based on an event-based approach (publish-subscribe pattern) – the system is situated and developed in a trusted domain (no security considerations) – the system will be developed in an agile manner (continuous system development and enhancement) 5
To support the development of cross-organizational event-based systems, we developed a federated system development strategy that helps to handle the social challenges as they were stated in Section 3. To manage the challenges we message exchange
developed an architecture of a Federated Management System (FMS) that needs to be integrated to the systems architecture.
Figure 2 displays an architectural sketch of our federated development strategy for cross-organizational event-based systems. In the upper part, the figure displays a system architecture that exchanges event messages between two companies via a broker (the assumed system situation). In this situation, social challenges appear because of the distributed system usage.
E challenges E social
The lower part of the figure shows the FMS that needs to be integrated. It consists of a Federated Message Archive (FMA) component that includes an event-database and a graphical user interface (GUI). The FMA component is connected to the systems broker. Whereas other services only listen to specific events, the FMA subscribes to all messages that might be posted in the system. Consequently, the broker forwards all messages to the FMA which stores them in the event-database. In doing so, the FMA collects several information about posted events, such as message type, message type’s publishing frequency, message content and more.
The GUI of the FMS, see Figure 3, provides access to the information in the FMA. It is the operative component that uncovers system information to users and enables transparency in the system environment. As displayed in Figure 3,
DB access
to system information a user may search for specific information that is shared via the system, e.g., information related to orders. Hence, the system displays a list of messages that are related to the search term. In this example the user can see that there exist more than one message type that is related to orders: topic ’order/new’ and topic ’order/accepted’. Furthermore, the user can explore the messages content, e.g., the single attributes, in order to get the information he or she is locking for.
By searching for a specific message topic, the user can obtain further information about a specific message type. After forwarding a search query of a message topic to the FMA, all collected messages of the specific message type are compared and analyzed by the FMA component. Findings are formatted and sent to the GUI were they are displayed to the user. Hence, the user can obtain specific information about a message type, such as the frequency in which it is used or specific information about attributes that are held in the message content (e.g., range of attributes values or most common value).
The GUI of the FMA can be accessed by every developer that belongs to the trusted group of organizations in which the system is implemented (see Figure 1). This ensures a high degree of transparency within the whole system community (C1).
New developers that are interested in system contribution and join the crossorganizational system environment get access to the FMS. Due to transparency that is provided by the FMS, new system developers are able to get to know the systems structure and behavior. By analyzing events that were stored in the FMS, new developers can learn how messages are structured and how they can be subscribed in order to use their information for further purposes.
Besides the provision of system information, the FMS furthermore provides a wiki-based area where system developers are able exchange information. By this, system users get the opportunity to ask for special services and for system extensions within the system community. Concrete demands on system extensions may animate developers to contribute to the system (C2). Especially for new contributors it might be easier and more motivating to start contribution on a concrete task.
The wiki-based area of the FMS supports communication among the system participants. This is very important to optimize collaborations (C3). The wikibased area may not only be used for placing demands, but also for coordinating contributions. Developers can quote on which functionality they are currently working and several developers are able to coordinate their collective work via, e.g., Kanban boards. Furthermore, new developers can ask for help within the community and senior system developers may share their knowledge and experiences. 6
In this paper we presented an approach to handle social challenges in crossorganizational event-based systems. First, we presented a classification model of distributed systems which shows that distributed systems can be categorized into three categories: hardware & software distributed systems, as well as users distributed and developers distributed. Depending on their category of distribution, distributed systems face different challenges. Systems that have distributed users and/or developers have to handle not only technical and code-centric issues, but also social challenges. In this paper, we focused on social challenges and summarized them as follows: 1) provision of transparency, 2) attraction and support of new developers and 3) optimization of system collaborations. Finally, we presented FMS and how this system approach that can be used to mitigate social challenges in distributed systems.
In the future work it is planned to evaluate FMS in real system environments. To enable such evaluation, cross-organizational event-based systems will be implemented in the manufacturing environment and system developers will be asked to enhance the system by components that supports the manufacturing process. The evaluation of FMS’s usability will be done in user studies that will be undertaken with the developers of the involved companies. There will be a mixture of developers with more and less experiences to establish the different needs and requirements to the FMS. Based on the evaluations outcome, FMS will be further adapted and improved.