Enterprise interoperability development in multi relation collaborations: Success factors from the Danish electricity market

ABSTRACT

Increased complexity and the risk of fragmentized business processes and data in many-to-many relationships is hindering development of interoperability. This study aims at clarify what are the success factors for overcoming issues of business process and data fragmentation in the development of enterprise interoperability in multi relation collaborations. A case study allowed for in-depth understanding of experiences and conditions. Seven deep interviews with actors in the Danish electricity market provided empirical data. A literature study formed the base for the analytical framework. Success factors fell into the categories of general project and change management, business process and information and data.

KEYWORDS:

• Alignment
• enterprise architecture alignment
• enterprise interoperability
• multi relation collaboration
• success factors

Introduction

One of the trends in society is the increasing diversity of collaborations between enterprises in a changing environment. Interoperability has therefore been put forward as an essential for the success of private and public sectors (Folmer, Sinderen, and Oude Luttighuis 2014; Da Silva Avanzi et al. 2017) as it contributes to effective data exchange when systems efficiently use the functionality of each other. For instance, the European Union has mentioned interoperability as one of its priorities (European Commission 2017). Interoperability is not only an issue of software and information technologies. It is also a question of better understanding of business processes (Naudet et al. 2010; Xu 2011; Jardim-Goncalves et al. 2013; Suša Vugec, Tomičić-Pupek, and Vukšić 2018) implying the use of communication and transactions support of business information between collaborating enterprises in usually, a one-to-one relationship (Chen and Doumeingts 2003; Hjort-Madsen 2006; Daclin, Chen, and Vallespir 2008; Mouzakitis, Sourouni, and Askounis 2009; Adenuga, Kekwaletswe, and Coleman 2015). However today, enterprises have to develop interoperability not only with partners, but with suppliers and customers in multi-partnerships, enterprise networks and dynamic supply chains as well (Anaya and Ortiz 2005; Norta, 2010, Khadka et al. 2011; Kadar et al. 2013; Santos et al. 2013; Agostinho et al. 2016; Da Silva Avanzi et al. 2017).

Service development in the context of many-to-many relationships hence, face information systems and business processes surge that increases complexity and the risk of fragmentation (Legner and Wende 2006, Daclin, Chen, and Vallespir 2008; Mouzakitis, Sourouni, and Askounis 2009; Li et al. 2015; Panetto et al. 2016). Fragmentation can be found when e.g. a flow or activities forming one centralised process crossing internal and external organizational boundaries, is executed under technical and legal frameworks of each independent partner. Several business processes owned and executed by a set of partners can also be a source of fragmentation. Complete processes might divide into fragments by different enterprises organisational boundaries, and related business data sets might also be fragmented (Li et al. 2015). Further, isolated business functions create business process and data fragmentation that may result in decisions made independently without considering the larger effect for all partners. Outsourcing and division of business, in order to lower costs or focus on core competencies are said to be another source of fragmentation and the cause of poor business decisions. Also, fragmentation can be an effect of low motivation for sharing data and business functionality with partners (Hjort-Madsen 2006; Khalaf and Leymann 2012; Janssen 2012; Li et al. 2015). The increased complexity and the risk of fragmentized business processes and data in many-to-many relationships is hindering development of interoperability unless there is better understanding. Thus, enterprise interoperability development in multi relation collaborations calls for better guidance.

There are several studies of critical success factors in different fields of research providing guidance for information systems development. For example, enterprise systems projects (Ahmad, Haleem, and Syed 2012), operational process discipline (Snider, Da Silveira, and Balakrishnan 2009), enterprise resource planning and business process (Muscatello and Chen 2008), project management principles (Ehie and Madsen 2005), change management (Finney and Corbett 2007), enterprise risk management (Zhao, Hwang, and Low 2013). However, the understanding of success factors for managing enterprise interoperability development in multi relation collaborations and the grappling of fragmentation issues is weak. The aim of this study is thus, to clarify what are the success factors for overcoming issues of business process and data fragmentation in the development of enterprise interoperability in multi relation collaborations.

This paper is structured as follows. The analytical framework, presented in the following section combines earlier research and conceptualizations in three different fields: (i) critical success factors, (ii) enterprise architecture and (iii) enterprise interoperability. The methodology section then presents a case study as the chosen methodology together with arguments for data collection and analysis chosen in line with the research focus. It is used as a setting to (a) further contribute to existing research within the area with details and contextual aspects, and at the same time (b) stay open to unforeseen aspects that might enhance our general knowledge. The results and analysis sections are structured according to the analytical framework. Finally, the discussion and conclusion sections bond it all together by highlighting in what way the study answers to the research question.

Analytical framework

Critical success factors were chosen as a well-known concept for guiding understanding of information systems data and business analysis. It was used for creating understanding of success factors. Enterprise architecture is a complex field in which the chosen alignment dimensions model is aimed at creating understanding of the harmonious connections between information systems and business. The model was chosen as relevant for broadening our understanding of organizational aspects in enterprise interoperability development. Enterprise interoperability is yet another substantial field in which the chosen interoperability dimensions model is aimed at revealing barriers and concerns to information technology and organisational development. This model was chosen as relevant for deepening understanding of information technology aspects in enterprise interoperability development.

Critical success factors

Critical Success Factors is a multidimensional concept and a method which clarifies the important elements of success for competitive performance, such as top management commitment, linkage to business, technical alignment, knowledgeable personnel, and user involvement. It was originally developed to align information technology planning with the strategic direction of an organization (Rockart 1979). Critical Success Factors also define important aspects of performance which are basic of any organization to achieve its mission such as engagement, audience, emotion. Therefore, performance literature cannot be understood without its audience and social context (Caralli et al. 2004; Thomas 2005; Ika, Dialbo, and Thuillier 2012; Cahyaningsih, Sensuse, and Sari 2015).

Enterprise architecture

Enterprise architecture is continuous practice of describing organizational elements in order to understand complexity and managing change (EARF 2009). Enterprise architecture is described as a documentation, a roadmap or plan as well as a management process to achieve goals and understanding the business (Scott-Morton 1991; Gøtze et al. 2009). Greefhorst and Proper (2011) characterized enterprise architecture as an instrument to articulate the future direction of an enterprise, that serves as a coordination and steering mechanism toward the actual transformation of the enterprise. However, other scholars described enterprise architecture as methods, models and principles guiding a systematic approach to the activities of design, analysis, planning and documentation of organizational structure, business process, information systems and their relations to each other and to the environment (Kluge, Dietzsch, and Rosemann 2006; Gøtze et al. 2009; Stelzer 2010; Gorkhali & Xu 2017). While, Enterprise architecture is also a strategy to align business architecture and information system architecture within an enterprise (Xu 2014; Rouhani et al. 2015). A variety of terms such as ‘harmony,’ ‘linkage,’ ‘fusion,’ ‘fit,’ ‘match’, ‘integration’ has been used, but in the long run the term ‘alignment’ has gained widespread acceptance in literature and in corporations (Avison et al. 2004; Silvius 2009).

Alignment dimensions

While understanding organizations as social systems, Magoulas et al. (2012) and Pessi et al. (2013) argues that enterprise architecture takes an interest in the harmonious balance of business and IT. An aligned enterprise must continually balance issues of integration versus separation, homogeneity versus heterogeneity and monolithic simplicity versus fruitful complexity. In particular the acceptance and comprehension of alignment between information systems and the functional, structural, infological and sociocultural dimensions of an enterprise, as shown in Figure 1.

Figure 1. Enterprise architecture alignment dimensions (Based on Magoulas et al. 2012).

Functional alignment is understood as the state of connection between the information system and processes. It may be expressed as an equation of required information capabilities and the available information capabilities. Substantially functional alignment concentrates on issues of coordinated development, i.e. how the development of the information systems has been synchronized with the development of enterprise processes. The validity of functional alignment should therefore be based on process effectiveness; how well technological resources support the tasks and priorities of core business processes (Sabherwal and Chan 2001; Magoulas et al. 2012; Pessi et al. 2013).

Structural alignment is understood as the state of connection between the information systems and the decisional rights and responsibilities. It may be expressed as an equation of established structure and accepted structure. A balanced equation means that the established structure is accepted by the stakeholders of the enterprise. The main idea here is that information and knowledge are important sources of authority and power (Magoulas et al. 2012; Pessi et al. 2013).

Infological alignment is understood as the state of connection between information systems and the stakeholder’s knowledge. The stakeholders are the source of knowledge and experience as well as conflict due to their individuality. It may be expressed as an equation of required knowledge and provided information and sometimes extra information. The main idea, in this case, is that information is an addition to knowledge, and that addition is communicated through language. Infological alignment expresses the requisite for information systems to promote comprehensibility and meaningfulness whilst absorbing cognitive distance and differences in perspective (Magoulas et al. 2012; Pessi et al. 2013).

Socio-cultural alignment is understood as the state of connection between the areas of information systems and the areas of goals, objectives and values. It may be expressed as an equation of stakeholders’ expectations and delivered contributions. The main idea here is that information and knowledge ties business and/or social communities together. The validity of the socio-cultural alignment may be defined in terms of cultural feasibility, i.e. shared values and priorities, social feasibility, codetermination, shared visions, shared goals as well as continuity of mutual commitments. Furthermore, it is of profound interest to determine the manner in which the organization settles upon its common goals (Magoulas et al. 2012; Pessi et al. 2013).

Contextual alignment is understood as the state of connection between the enterprise as a whole, its boundaries and interaction with the external environment. It may be expressed as an equation of expected enterprise behaviour and the observed enterprise behaviour. When it comes to the concerned relationships, there is only indirect impact on the information systems and the various areas of interests. The mentioned areas may seem unrelated, yet because information flow permeates the organization it is important to be aware of how various areas influence each other. However, it is very difficult for the enterprise to make changes beyond the boundaries of its enterprise areas. Thus, the enterprise should take into consideration the opportunities and obstacles as they are usually known as motivation for organizational change. To acquire alignment as a whole it is critical to consider, enterprise behaviour and observed enterprise behaviour in relationship to the indirect interaction between organizational areas and environmental circumstances (Magoulas et al. 2012; Pessi et al. 2013).

Enterprise interoperability

Interoperability is described as a multidimensional concept that covers many perspectives and approaches from different application domains (Gürdür and Asplund 2018). The aim of enterprise interoperability is to provide the right information at the right place at the right time (Vernadat 2007). Enterprise interoperability is the ability of two or more enterprises to communicate and interact effectively with the external systems that they utilize to collaborate seamlessly, over a sustained period of time to achieve specific objectives. The interaction takes place different levels; at organizational, application, and data levels. The data or technical level this is the ability to send the information in bits and bytes, the application or syntactic level this is the ability to read the information, the semantic at organizational level and this is the ability to understand the information (Scholl et al. 2012; Lampathaki et al. 2012; Daclin, Chen, and Vallespir 2016). Enterprise interoperability is an essential component to build agile organizations using different services and processes. Modern organizations are then considered from the intra or inter-organizational point of view, their need to be made interoperable both in terms of their business processes, their applications or IT systems, and even their human resources to confront current business challenges (Vernadat 2007). The Enterprise interoperability has thus the meaning of coexistence, independence and associated environment (Lampathaki et al. 2012). However, focus of interoperability efforts can also be divided in three main categories: administration to administration; administration to business and administration to citizen (Gøtze et al. 2009).

Enterprise interoperability dimensions

Enterprise interoperability framework is a tool for solving specific enterprise interoperability problems that can occur. As illustrated in Figure 2, it defines three basic dimensions: interoperability barriers, interoperability concerns and interoperability approaches (Daclin, Chen, and Vallespir 2008; Guédria, Naudet, and Chen 2015; Daclin, Chen, and Vallespir 2016).

Figure 2. Enterprise interoperability dimensions (Based on Daclin, Chen, and Vallespir 2008).

Interoperability barriers are of three types. Conceptual barriers are about the problems of syntactic and semantic of information to be exchanged. This barrier concerns the modelling at high levels of abstraction and modelling at the level of programming. Organizational barriers are related to the responsibilities and authority so that interoperability can occur in good situations. Technological barriers are related to information technologies. This barrier concerns the standards that are utilized to present, store, exchange, process, and communicate data by the use of computers (Daclin, Chen, and Vallespir 2008, 2016).

Interoperability concerns identifies different levels of enterprise where interoperability happened. The business level refers to working in a harmonized way at the levels of organization in spite of for example, the different modes of decision-making, methods of work, legislations, culture of the organization and commercial approaches. However, that business can be developed and shared between organizations. The process level aims at making different processes working together. A process defines a sequence of services (functions) according to a specific need of a referred organization. generally, in an organization, several processes run in interactions (serial or parallel). In the case of a networked enterprise, internal processes of two organizations have to be connected to create a common process. The service level is about identifying, composing, and making function together with different applications (designed and implemented independently) by solving the syntactic and semantic differences, as well as finding connections to various heterogeneous databases. The service is not limited to computer-based applications but also concerns functions of the organization or the networked enterprises. The data level aims to making various data models (hierarchical, relational) and various query languages working together. Furthermore, their contents are organized depending on conceptual schemas (i.e. vocabularies and sets of structures of data) that are related to particular applications (ATHENA 2005).

Interoperability approaches includes three ways to develop interoperability. In the integrated approach, there is a common format for all models. This format has to be as detail as models. The common format is not necessarily a standard but must be agreed by all parties to elaborate models and build systems. The unified approach has a common format but only at a meta-level. This meta-model is not an executable entity as it is in the integrated approach but provides a mean for semantic equivalence to allow mapping between models. The federated approach has no common format. To establish interoperability, parties must accommodate on the fly. Using federated approach implies that no partner imposes their models, languages and methods of work. This means that they must share an ontology. (Daclin, Chen, and Vallespir 2008, 2016).

Construction of analytical framework

The analytical framework for clarifying what are the success factors for overcoming issues of business process and data fragmentation in the development of enterprise interoperability in multi relation collaborations was constructed by combining the above presented fields of research. All dimensions in enterprise architecture alignment and two dimensions, barriers and concerns in enterprise interoperability were relevant for structuring the result and for analysis. Based on the theory three categories were selected for structuring related success factors. The categories are general project and change management, business process and information and data, see Table 1.

Table 1. Analytical framework construction.

Theory	Success factor found in theory	Category selected for structuring related success factors
Enterprise Architecture Alignment Dimensions	Functional alignment - the connection between the information system and processes expressed as an equation of required and available information capabilities.	Business process
	Structural alignment - the connection between the information systems and the decisional rights and responsibilities expressed as an equation of established structure and accepted structure.	General project and change management
	Infological alignment - the connection between information systems and the stakeholder’s knowledge expressed as an equation of required knowledge and provided information and sometimes extra information.	Information and data
	Socio-cultural alignment - the connection between the areas of information systems and the areas of goals, objectives and values expressed as an equation of stakeholders’ expectations and delivered contributions.	Business process
	Contextual alignment - the connection between the enterprise as a whole, its boundaries and interaction with the external environment expressed as an equation of expected enterprise behaviour and the observed enterprise behaviour.	General project and change management
Enterprise Interoperability Dimensions	Interoperability concern: Business level - working in a harmonized way at the levels of organization.	Business process
	Interoperability concern: Process level - making different processes working together.	Business process
	Interoperability concern: Data level - making various data models and various query languages working together.	Information and data
	Interoperability concern: Service level - identifying, composing, and making function together with different applications.	Information and data
	Interoperability barrier: Organizational - responsibilities and authority considerations so that interoperability can occur in good situations.	General project and change management
	Interoperability barrier: Conceptual - syntactic and semantic consideration of information to be exchanged.	Information and data
	Interoperability barrier: Technological - consideration of standards utilized to present, store, exchange, process, and communicate data by the use of computers.	Business process

Methodology

In order to fulfil the aim of this study to clarify what are the success factors for overcoming issues of business process and data fragmentation in multi relation collaborations a qualitative approach and case study was chosen as it allows for an in-depth understanding of interviewees experiences of the subject and its conditions (Creswell 2014; Yin 2013). A literature study formed the base for the analytical framework. Documents, publications and the web about the energy market from the different parties in Denmark were used as background material in the empirical study for understanding the development situation (Yin 2013). According to Järvinen (2004), the selection of interviewees is a critical and important part of the research methodology. In this study, the data hub project was chosen as it represents a case in which many market partners collaborate in a multi relation. Seven interviewees from the project partners were chosen with respect to their different views of the development process and its success factors. One interviewee was from the Data Hub Owner Transmission System Operator (TSO); the project manager for the data hub project. Two interviewees were selected from an IT vendor company; one functional architect and one product manager. Two interviewees were selected from an electricity supply company; one billing manager and one project and IT development manager. Finally, there were two interviewees from a grid company; one market data coordinator and one project manager. Semi-structured interview questions, based on the analytical framework, were formulated in English for collection of empirical data. Both authors participated in all interviews in Denmark on two occasions. There were 3–4 interviews made each time. Each interview took place during the day in a meeting room at the company where the interviewee worked and lasted between 2–3 hours. The interviews were all conducted in English, which was accepted by all respondents upon asking. Every interview was recorded on a computer brought by the authors. The analysis was prepared by transcribing the recorded material from the interviews and encoding it according to the Analytical framework section. The empirical result was then analysed with the help of the analytical framework to find similarities and differences between theory and practice. The findings were discussed and the success factors were concluded.

The Danish electricity market case

The Nordic electricity markets in Denmark, Norway, Finland and Sweden are in a big transition. The implementation of the EU Directive 299/72/EC calls for changes in the national electricity regulatory frameworks (NordREG 2013; Swedish Energy Markets Inspectorate 2017). The purpose of the directive is to open up the electricity markets in the European Union allowing electricity customers to enjoy free choice of supplier, price competition, and a reliable supply. One core element includes ownership unbundling, which implies the separation of companies’ sale operations from their transmission networks. According to NordREG (2006) the Nordic wholesale electricity market is a good example of an electricity market with international co-operation. The co-operation has taken place across different platforms at government level, energy regulators and transmission system operators. Already in August 2005, the Nordic energy ministers set the objectives for further development of the Nordic electricity market, nominating ‘a truly common Nordic retail market with a free choice of suppliers’ to be one of its strategic priorities (NordREG 2009). The major change in the Danish electricity market involves the implementation of a new Supplier Centric Model, in which the electricity supplier will be the customer’s primary contact for e.g. billing, moving and switching supplier.

The market changes affect both the electricity suppliers and the distribution grid companies. As an example, previously both the electricity supplier and the grid company sent separate invoices which was a cause for fragmentation, but in the new data hub model, as shown in Figure 3, the grid company provides metering data and billing information and the electricity supplier sends a common invoice to the customer.

Figure 3. The new data hub model of the Danish electricity market.

The new Danish data hub replaces an old way of communicating point to point between the companies. It was implemented in order to coordinate and manage the data transactions between the grid companies and the electricity suppliers. The Danish data hub was introduced in two steps: Version 1 was introduced in 2013 without implementing the full Supplier Centric Model, and version 2 was introduced 2016 with the full Supplier Centric Model.

The Danish data hub project was chosen in this study as it represents a case in which many market partners collaborate in a multi relation. Also, the project is completed and people were free to talk about their experiences. It is thus, a relevant case for investigating what are the success factors for overcoming issues of business process and data fragmentation in the development of enterprise interoperability in multi relation collaborations.

Result

Enterprise architecture alignment dimensions

Functional alignment

The Data hub owner had the main responsibility for all decisions, to introduce the data hub, the Data hub owner explained that one of the most important issues to them was to make the system well-functioning in the electricity market. In version 1, the Data hub owner engaged grid companies, suppliers and IT vendors to a limited extent. This meant that some grid companies and suppliers did not join the project until several months after it went live. The respondents from the Supplier and from the Grid company were very clear they had no effect on the decision process at all.

“We have nothing to do with decisions about the Data hub.”

(Supplier)

In version 2, the Data hub owner engaged IT vendors in the project from the beginning. The Supplier and Grid companies didn’t understand the magnitude of the project and that it was a market project that affected their entire business and processes, not a single IT system. The Data hub owner made it very clear that the project could only succeed if everyone was on board.

“The success for us would be to have everyone on board when we go live.”

(Data hub owner)

Structural alignment

The Data hub owner was also the main responsible for the development process. In version 1, The Data hub owner didn’t work with IT vendors, instead they worked with different grid companies and suppliers, but without much involvement in the process. In the second version, the Data hub owner realized that knowledge and ideas at IT vendors were very important for the process and for solving problems, and they were therefore closely linked to the project.

“It is very effective to ensure that all of us are on track of the process.”

(IT vendor)

In version 2 the Data hub owner described that, based on law, they had a forum called Dialog forum and technical implementation for getting input on the development process. The Data hub owner described the implementation; there were cooperative meetings and daily phone meetings with more than 100 participants every morning. They listened to what was going to happen the following day. There was also eLearning; courses were made by the end of the implementation before going live. All together it made closer relationship to the market parties. Grid companies and suppliers were invited, but not all of them, were instead involved through their IT vendor. Through IT vendors, they had the opportunity to be informed and educated and get support in their development process, which was primarily concerned migration of data. Migration of data was an area that was lifted and focused more on the second version. Therefore, large portions of customer responsibility were moved from grid companies, changes were small for them, while suppliers had major changes in their systems and processes.

“Everything was new, every working process was new.”

(Supplier)

Infological alignment

In version 1, the Data hub owner developed a 230 pages long requirement specification in little cooperation with market companies. This was considered an old-fashioned development process by the Data hub owner. The IT vendors implemented something based on the technical specifications but could not see the whole picture of the supply chain. In version 2, the Data hub owner instead developed detailed business requirements specification in cooperation with the IT vendors. The second version specifications were based on descriptions and analyses of process flows in combination with validation rules. Validation rules was important beside the process map to make it detailed enough. The validation rules decide how the process works. There were about 47 processes and around 600 rules with a lot of market parties sending these to the data hub. Although some suppliers were invited in the process most suppliers and grid companies were engaged by the IT vendors. The Grid company thought the business requirements specification guide was problematic. However, they could take any process change, read it and try to understand it. The IT vendor then told them how it would be presented in the system. IT vendor used the Scrum method, a well-known agile development process and they had weekly meeting to discuss what to do.

Socio-cultural alignment

The respondents from the Supplier and from the Grid company explained that the project goal for the whole country was one invoice for the customer instead of two different invoices. The Grid company added, to provide the free market equal for all suppliers. IT vendor centred on the purpose of the data hub stated in the law, i.e. European Union legislation, the first one was to ensure better communication second, was to comply with the legislation. The respondents from the Supplier thought that the Data hub owner did a project evaluation and that it was ongoing. The IT vendor said they had not been evaluated yet. The Data Hub owner did a project evaluation, but not technical evaluation. The Data hub owner said that the data quality has increased significantly.

“The data quality is better than it has never been before”

(Data hub owner)

Enterprise interoperability dimensions

Interoperability concern: business level

Danish grid companies went from having 3.2 million Danish households to having 70 suppliers as their customers. There were big changes in the companies’ business models. They now focused on operating, maintaining and expanding the electricity grid and to have little interaction with the end customers. The suppliers in Denmark all faced a new role of dealing with increased competition and number of services to the consumers. The Data hub owner pointed out that in previously there had been little movement in the market, not many end customers switching suppliers, almost like a monopolistic market. New actors have appeared on the market, and there have been some mergers and acquisitions. The interviewed supplier had also started bundling products, e.g. electricity and fibre.

“This transformation of the market going from monopolistic market to a competitive.”

(Data hub owner)

The respondents from the Supplier and Grid company explained how their businesses had undergone structural changes. They were both in the same enterprise from the beginning. First the enterprise merged four companies to one, and then the grid company was separated, also physically, to clearly define the roles according to the Supplier Centric Model.

Interoperability concern: process level

There were major changes in processes and communication among all the companies. The Supplier Centric Model made a clear division of responsibilities between the grid companies and the suppliers. All communication took place through the data hub. The respondents from the Grid company explained how their metering data and information for billing was processed in the data hub and then used by the suppliers. There was a case processing system in the data hub in which questions and problems could be solved. It was pointed out by the interviewees that all former direct contacts between the parties were replaced by communicating through the data hub. It was also the case that all grid companies didn’t know who the supplier was, while the supplier companies knew the other way around. Supplier and grid companies were separated physically and in data hub version 2 they split up completely with separated IT systems as well.

“We communicate just through the Data hub. It’s forbidden to talk to Grid companies directly.” (Supplier)

“We used to work together in one location so socially it’s so different because before we had this conversation with the Suppliers so we miss that.” (Grid company).

The biggest changes took place in the supplier’s processes. While the grid companies released the support to end customers, their customer service departments consequently were decreased. At the same time the suppliers’ departments significantly increased.

Interoperability concern: data level

Data consistency and data quality were lifted as major issues in the implementation of the data hub. Data consistency refers to ensuring that data in the grid companies and suppliers’ databases are consistent with the data in the data hub. Data quality refers to ensuring that data like metering data or billing data actually is correct in the data hub. This had been an issue already before the data hub and low data quality was a big problem also in data hub version 1. The Data hub owner in some cases even had anticipated an unwillingness from the companies to deliver correct data or complete missing data. Therefore, the migration of data to the data hub version 2 included a one year long subproject including several mandatory tests of uploading data from the companies to the data hub. The company that did not fulfil the requirements of uploading and validating data was not approved by the Data hub owner to go live when the version 2 of the data hub was deployed. At the end, all companies passed and were approved to go live. Consequently, a large part of the implementation projects in the companies were spent on migrating data.

“One of the first things I did was to make sure that two parties were not able to change the data. It was not allowed to have a split data responsibility as we had in the first version. Sometimes the Supplier change the data and the Grid company change the same data afterwards because they say well this is the customer spelled and no one ask the customer.” (Data hub owner)

Another issue discussed was the ownership of data and the rights to change data. In data hub version 1 the data responsibility was split and data could be changed by several parties because the responsibilities for customer and billing were shared by both grid companies and suppliers. In data hub version 2 it was strictly regulated, not two parties could change the data, and the responsibility, use and ownership of data was distinctly split.

Interoperability concern: service level

There was a regulation between the companies and the Data hub owner about sending data to the data hub without necessary delay, not later than one day after it was changed in the local systems. There were over one billion transactions per year. The companies also were allowed to do changes in data regarding the previous day. There was a service level agreement regulating the support and response to the companies.

“We have an obligation say that, on the normal conditions we will distribute the data within one hour on to the propertied market parties.” (Data hub owner)

Interoperability barrier: organisational

The respondents from the Supplier and from the Grid company explained that many of the grid companies and suppliers had previously been parts of the same company, but the split of responsibilities in the Supplier Centric Model forced the companies to split and clearly separate the organizations and the systems. This could be a problem for small companies with a limited number of employees that no longer can share and divide internal tasks between them. That was also realized very late by many companies. The suppliers struggled with the extra load on their customer service departments and were in most cases forced to increase the staff, while the grid companies had to decrease their staff.

Interoperability barrier: conceptual

There were changes needed in the Danish electricity law. Those changes were interpreted into regulations (acts) which in turn gave direction for the requirement specifications which stated the details for the implementation. Many revisions, also of the legislation, had to be made during the development process. After going live, some processes in the business requirements specification had been open to interpretation and misused by some parties. The interviewed grid company also experienced that changes of certain things like price elements in the data hub was restricted and had to be decoded and approved by the Data hub owner.

Interoperability barrier: technical

The first version of the data hub used the Electronic Data Interchange For Administration, Commerce and Transport (Edifact) standard for communication, but it could not contain the amount of data needed without amendments, so it was removed and replaced by the more modern Epix standard in the second version of the data hub.

Analysis

Here the result is analysed with the help of enterprise architecture alignment dimensions and enterprise interoperability dimensions from the analytical framework for clarifying what are the success factors for overcoming issues of business process and data fragmentation in the development of enterprise interoperability in multi relation collaborations.

Enterprise architecture alignment dimensions

The Data hub owner had the main responsibility for all decisions. The Supplier and the Grid company were not involved in the decision process, they had little power over the change in version 1. This is contrary to structural alignment (Magoulas et al. 2012; Pessi et al. 2013). Magoulas et al. (2012) and Pessi et al. (2013) mentioned that information and knowledge are important sources for authority and power over the change issue and must be coordinated and aligned in the project with other partners. However, in version 2, they were involved in the decision process and the project was more successful. In version 1, the Data hub owner didn’t work with IT vendors, instead they worked with grid companies and suppliers, but without much involvement in the process. According to Magoulas et al. (2012) and Pessi et al. (2013) this is an example functional misalignment of required information capabilities and available information capabilities. In version 2, the Data hub owner focused on listening to what was going to happen and made closer relationship to the market parties. There were also eLearning courses at the end of the implementation. Before going live in version 2, information capabilities and required information were available. Functional issues were therefore better aligned (Magoulas et al. 2012; Pessi et al. 2013). In the Data hub version 1 the Data hub owner was not working together with market companies. At the start, the IT-vendor realized that there were different views of the process posing a risk to development and that is according Magoulas et al. (2012) and Pessi et al. (2013) an infological problem. Therefore, an agile development process was chosen to create common understanding of the process and to overcome the infological problem of knowledge and understanding. However, in the Data hub version 2 the requirements for all their processes were written together with the market participant who gave input both to the interface and the process flow. Thus, Data hub version 2 treated the individual stakeholder as a source of knowledge. That corresponds with Magoulas et al. (2012) and Pessi et al. (2013) who states that the stakeholders are the source of knowledge and experience in the process. All respondents had an overall perspective or understanding of the development process from their role, their mission, responsibility and power. For example, to the IT vendor the Data hub was an important project for the energy market and the increase of competition in the market. However, IT vendor understanding of the information system development was not as clear as the development of the enterprise. In the way, the Supplier talked about the invoice to the end customer and consumer protection and not so much about the development of the data hub. Often the vision or overall European Union goal for the project were not fully shared among the respondents. This is an example of sociocultural misalignment (Magoulas et al. 2012; Pessi et al. 2013).

Enterprise interoperability dimensions

The parties involved had to think out of the box. The grid company went from having 3.2 million Danish households to having 70 suppliers as their customers. They harmonized their business with the new customer and changed the business focus. Suppliers had to understand how to make a new product. This goes with Integrated Project (2005) which explains how the business level refers to working in a harmonized way at the levels of organization in spite of, the different modes of decision-making, methods of work, legislations, culture of the company and commercial approaches. According to the Data hub owner this had been a monopolistic market, so they had never thought in terms of competition and how to improve the business accordingly. However, the development was necessary due to the law and the market and they had to accept the change. This disagree with what is explained by Daclin, Chen, and Vallespir (2008), Daclin, Chen, and Vallespir (2016) and Integrated Project (2005) that the business level refers to working in a harmonized way. Supplier and Grid company were separated physically and in Data hub version 2 they split up completely with separated IT systems as well. The IT vendor and the Data hub owner focused on the fact that all of the communication went through the Data hub. For supplier and grid, it was a matter of change of the company’s internal processes, but for IT vendor and data hub owner it was the development of an IT system and processes. This is in line with Daclin, Chen, and Vallespir (2008) and Daclin, Chen, and Vallespir (2016) which highlight the process level and making various processes, or sequences of services and functions for a specific need, working together. To the Data hub owner, it was important to avoid a split responsibility of data ownership and rights to change data. It had thus to be a concern of all parties involved. The respondents did not mention anything about different data model and query languages working together (Integrated Project 2005; Daclin, Chen, and Vallespir 2008, 2016). There was a new standard service level agreement about how to act in different cases between Supplier, Grid company and the Data hub owner. There was also an agreement that stated how long they had to do with the resolution part that already exist in the market. That is compatible with Daclin, Chen, and Vallespir (2008) and Daclin, Chen, and Vallespir (2016) that the service level is about identifying, composing, and making function together with various applications. The term `service’ is not limited to computer-based applications but also concerns functions of the company or the networked enterprises.

The Supplier struggled with the extra load on their customer service department and were in most cases forced to increase the staff. For the Grid company it was much of a continuation of what they were already doing but they needed to reduce the activities and the number of their employees. It was learning by doing from beginning to end which helped remove structural barriers inhibiting the new enterprise collaboration (Daclin, Chen, and Vallespir 2008, 2016). However, the respondents did not neither mention anything about definition of responsibilities and authority for interoperability take place under good conditions nor did they mention how to reshape responsibilities in a new organizational setting (Daclin, Chen, and Vallespir 2008, 2016). During the development process the legislation changed which caused some revisions of processes and rules in the new system. The Supplier thought some of the processes in the business requirement specification guide were open to interpretation. The Grid company did not have any responsibility regarding metering points and price elements. These were barriers in the development of the Data hub. However, according to theory they are not conceptual barriers related to the problems of syntactic and semantic of information to be exchanged. This category of barriers concerns the modelling at high levels of abstraction as well as modelling at the level of programming (Daclin, Chen, and Vallespir 2008, 2016). The Data hub owner had Edifact standard which was a direct barrier to the second version of the Data hub. It was removed and then they only used the Epix standard. It was a very compact information model and the problem was that it could not contain the data needed to send. This is in harmony with (Daclin, Chen, and Vallespir (2008) and Daclin, Chen, and Vallespir (2016) who mention technological barriers related to the use of information technologies. This category of barriers concerns the standards that are used to present, store, exchange, process, and communicate data through the use of computers.

Discussion

The provided case from the Danish electricity market is an example of enterprise interoperability development in multi relation collaborations. The analysis demonstrate that the data hub was a market project that influenced all enterprises involved and restructured the entire market. However, in the systems development process there were two versions of the data hub. Version 1 of this new information system had a traditional hierarchical process with late involvement of the market parties. Furthermore, there were repeated actions and inaccurate activities with no or little balance between functional and technical point of view. A traditional hierarchy of command with a centralized decision process made the stakeholders struggle to understand and adapt to the change while using the new system. Trial and error characterized the situation and the development process was not effective. We argue that it was caused by lack of communication in a fragmented crowd of enterprises. Creativity is needed to go beyond organisational boundaries and find new ways to communicate the change of both information systems and business activities in order to collaborate in a multi relation.

Version 2 of the data hub development had clear and separated responsibilities with early and full involvement of all market partners. Moreover, e-learning, mail and daily discussions contributed to discovering right on time positive and negative issues important to the development and improved skills and understanding. We argue that the process then started from required information and treated the individual stakeholder as a source of knowledge. It is good to communicate between partners and synchronize different activities of change, but there must be a system that structures and facilitates that. All stakeholders must therefore be involved from the beginning. Information systems should be developed in line with the restructuring of the market. Thus, that was what happened in version 2. In other words, there was focus on sharing individual and overall goals to achieve the supplier centric model and a harmonised electricity market. Migration of data, data consistency and data quality were lifted as major issues in the implementation of the version 2 of the data hub. We argue that strong involvement and engagement from all parties, dialogue and education assisted in the transformation and changed the market from a monopolistic market to competitive market.

Indisputable, based on all the differences between version 1 and version 2, the indication is that the project started with an improvised trial and error process. It went on to a more controlled learning by doing or reactive process. In order to be more proactive and efficient in multi relation enterprise collaborations in terms of time, economical and human’s resources we conclude that several success factors should be considered for overcoming issues of business process and data fragmentation.

Conclusion

The aim of this study was to clarify what are the success factors for overcoming issues of business process and data fragmentation in the development of enterprise interoperability in multi relation collaborations. The implementation of the new Danish data hub model was a market project that influenced all enterprises and restructured the entire market. From this case, we conclude the following success factors.

Success factors found related to general project and change management

• Market, enterprises and information systems change are of equal concern.

• Individual stakeholders and market parties are important sources of knowledge.

• A close relationship benefits all market parties.

• Sharing of market participants’ individual and overall goals.

• Flexibility of chosen method towards both technological and social systems change.

• Focus on strong involvement and engagement from all parties.

• Focus on communication, dialogue between market parties, as well as education.

Success factors found related to business process

• Carefully designed business processes with validation rules and market regulations.

• Market parties need to validate their processes before being approved to work.

• Clear separation of communication and roles between the market parties.

• Centralized and unified communication and case processing through data hub.

• Clear responsibility for the customer’s processes.

• Other findings show that the companies’ business models have been affected by the process changes, and there have also been structural changes in the business.

Success factors found related to information and data

• A carefully designed and executed migration of data.

• Strong focus on data consistency and data quality.

• Extensive and exhaustive work with data cleansing before uploads.

• Multiple uploads of data and validation before approval to go live.

• The responsibility, use, and ownership of data distinctly defined.

• Work with definitions and concepts.

The above success factors depend on each other.

Future study

This study is the first step in addressing the broader and deeper problem of enterprise interoperability in multi relation collaboration. It has highlighted a number of success factors such as data quality. A future study could be to further investigate data quality impact on interoperability in multi relation collaboration in the new electricity market. For instance, centralized information resources will face unclear issues of data ownership, responsibility, security, access, traceability, reliability, and long-term data retention. Another future study could be to investigate the new electricity market effects for end customer benefits and market partner possibilities for developing new services.

Disclosure statement

No potential conflict of interest was reported by the authors.

Additional information

Funding

This work was supported by the European Regional Development Fund, ISERV project [ID 20201030]. .