Keywords

1 Introduction

Organizations are investing in digital transformation and creating accessible digital services [14, 15, 38]. In this context, enterprise architecture (EA), an information management tool that helps them visualize and execute their strategies, describes the strategy, business, data, applications, and technology architectures and connections between them. EA is an appropriate method and has an important strategic and operative role in the digital transformation of organizations and ecosystems [23, 28, 35]. As a tool for managing their digital transformation processes, EA helps to create new digital capabilities and service ecosystem culture.

EA implementation and utilization projects are infamous for their problems [13, 39]. The most common issue is collaboration and communication among different partners and stakeholders [7, 37]. Earlier recommendations to solve the problems are impractical since the suggestions are rather generic [13, 20, 39], while EA problems are highly contextual [37]. There is thus a knowledge gap on how to cope with the communication and collaboration problems in the EA projects. This motivates our research. We seek answers to: How can communication and collaboration problems in EA projects be addressed? What consequences are expected from these activities?

We conducted a qualitative and comparative case study on three large-scale digital transformation projects utilizing the EA approach in the Finnish public sector. We wanted to understand how the EA project owners and team members address emerging communication and collaboration problems through different actions. We also studied the impacts of those actions. We constructed a simple model and used it to analyze the data from ethnographic observations. We argue that the communication and collaboration problems can be mitigated even during the projects by increasing and reallocating resources or changing the working practices. It requires sensitivity and distance to identify them and authority to change the situation.

The paper is organized as follows. First related research is summarized. That is followed by the research settings and methods section and our findings. The paper ends with a discussion and conclusion sections.

2 Related Literature

Digital transformation is about digitalizing the organization's services, functions, processes, and transactions. EA is a holistic approach to helping digital transformation by illustrating various details and their relationships, handling communication issues, understanding business needs, and addressing complexity and integration issues [10, 16, 30]. Social and organizational challenges and unexpected incidents impact intense digital transformation [1, 15, 42]. EA is an information management tool, and it can used for organizations’ management for different purposes [24].

EA aims to provide a holistic view of the organization and its business, data management, applications and technologies, their current and future states, and how to reach the goals [22, 41]. It will benefit organizations if they achieve various dynamic EA capabilities [2, 45]. High-quality EA is defined through seven quality attributes: alignment and integrity, the quality of EA products and services, maintainability and portability, scalability, security, reliability, and reusability [32].

EA projects tend to be large and complex. They bridge multiple departments and levels and have myriad stakeholders and several viewpoints, which make them failure-prone [13]. These failures have been studied, for example, in the public sector in general [13, 29], in government agencies, municipalities, and higher education institutions [39], and in many other settings e.g. [3, 31]. The challenges are usually not technical but relate to leadership, governance, management, staff commitment, and governmental politics [5, 21, 22]. Kaisler et al. [22], for example, recognized communication challenges between middle management, managers, and other EA stakeholders, especially on methodology and modeling issues. The problems correlate and are interwoven in convoluted causal chains [18], which makes the situation even more complex.

EA management challenges are related to EA documentation, EA planning, and EA communication and support [11]. EA project challenges are associated with the EA definition and documentation, flexibility, time pressure, and complexity [33]. The biggest challenge of the EA practices is communication between decision-makers and stakeholders [25]. As EA development is mainly about communicating and collaborating with different stakeholders, the problems there escalate quickly and cause severe issues in EA projects. Communication and collaboration problems have been identified as being common in EA projects, which also explains other EA obstacles [7]. As communication and collaboration are influenced by twenty factors [6], ranging from technical to organizational and personal issues, solving them is not easy. However, it is vital for the EA projects as they are a means for engaging the stakeholders [27], especially when they have varying backgrounds and experiences [12].

In these situations, EA artifacts, models, and descriptions are used as a communication tool [34, 44]. This, in theory, solves some of the communication problems as the models provide a common point of reference and a common language [26, 34]. Similarly, different statements have been made about paying attention to success factors and problematic issues [13, 20, 39]. Even the importance of communication skills has been acknowledged [46]. Yet, the communication problems and failing EA projects persist. One of the reasons is the context specificity of the EA and EA projects [17, 46]. Especially communication and collaboration are highly contextual and temporal [21, 37].

3 Research Methods and Settings

To understand how communication and collaboration problems are addressed in the EA projects, we conducted a qualitative and comparative case study on three public sector EA projects in Finland (c.f. [47]). We paid attention to communication problems and their root causes, to actions to solve them, and to those actions’ possible implications.

We derived the data from the first author’s retrospective analysis of his ongoing EA projects. He has been working for more than fifteen years as a chief enterprise architect or consultant in numerous EA projects, mainly in the public sector. For this study, we chose his three recent EA projects where communication and collaboration challenges have been identified as critical. As he has been actively involved in the projects, he had a unique chance to gain in-depth data and understanding about the projects, their challenges, and actions. In this paper, we rely on his ethnographic fieldwork e.g. [36], and project documentation, such as memos, project plans, and meeting minutes. With ethnographic observations, contrary to action research [8], where the researcher aims to change the situation, the researcher solely observes and reflects on different situations and actions. Although we were interested in corrective actions to solve the challenges, the first author was not in a position to actively pursue their solving – being an architect or consultant, one can merely inform the project owners about the challenges and hope for the best. There was very little he could do.

Fig. 1.
figure 1

The model for data analysis.

Full size image

To structure our analysis, we used a simple model influenced by the activity theory [9] (Fig. 1). The actor, an individual or a community, does an action. An action has one or more consequences (outcomes) that affect the EA (impact on EA). The EA continues to impact, for example, the development of its domain (impact of EA). Generic impacts are the aftermaths of all these.

Our data analysis proceeds as follows. First, the first author identified and analysed the communication and collaboration problems on two different occasions: in winter 2021 and in summer 2022. Although he was aware of various classifications, the analysis was data-driven and inductive. He classified the problems as critical (the situation is chaotic, elevation is unlikely), challenging (the situation is challenging but solvable), or desirable by using his experience as an actor in these projects. He then wrote an anonymized storyline of each project and its activities. These storylines and the first author’s experiences were used in the structured analysis of each project. Finally, the analyses were merged to create a more generic theoretical model. Although the first author analyzed the data, the findings were constantly discussed among the authors to reduce potential single-researcher bias.

Next, we will present each EA project, its storylines, and the impact chains.

4 The Cases and Observations

In this section, we present our analysis of three EA projects.

4.1 Project A

Project A is a national reference architecture by a Finnish government agency. The EA development started in Q3/2019. EA project described the baseline and target stage architectures, which include 78 strategy, business, data, and application architecture artifacts (65 diagrams and 13 tables). The architecture is already published. Initially, the project had four stakeholders and an architecture team of five members. By Q1/2022, the number of EA team members has more than doubled, and the number of stakeholders has increased by two new organizations.

In winter 2021, communication and collaboration challenges were severe as the EA team had only one EA consultant (the first author) and some representatives from Government Agency A. In summer 2022, the situation improved because the owner of the EA project increased the project's human resources and intensified communication with the domain agencies by surveying to check whether the architecture was understandable and correct.

In early 2021, a new enterprise architect and a domain expert from an agency joined the EA team. They aimed to improve the EA work and bring in necessary competencies. This had positive impacts on the EA: the EA method was used better, and the quality of the EA artifacts improved. They became more understandable and usable. The evaluation survey focused on the architecture documents. The six reviewers felt that various items were comprehensively described, but also made suggestions for improvements, many of which were noted, fostering the rigor and accuracy of the architecture. In addition, the project owner (Government Agency A) uniting two similar EA projects from neighboring domains with many links and forms of collaboration. Figure 2 shows how the reallocation of resources, in this case merging two EA projects (action), improved understandability (consequence), harmonized the EA definitions (impact on the EA) and improved their interoperability (impact of the EA).

Fig. 2.
figure 2

Detailed actions and impacts in Project A.

Full size image

Another means to improve communication and collaboration was the earlier-mentioned survey to assess the unambiguity and clearness of the EA definitions, identify shortcomings, and suggest improvements. It was conducted in parallel with the contiguous EA projects. It received a positive response and helped to improve the EA definitions. In other words, the survey increased general awareness of EA, domain knowledge, EA quality, and EA artifacts fit with the practice and practical needs.

There were two generic impacts: the actions and their consequences supported Government Agency A's EA work and improved the role of EA as a management and steering tool.

These improvements can be explained by the increment of the EA team membership. In three years, the project more than doubled the number of architects and specialists, which provided adequate resources and skills to EA artifact development and cooperation and dialogue with the government agency and other stakeholders. They became aware of how critical communication and collaboration are in the EA projects. One of the project’s success factors was simply the increase of resources.

4.2 Project B

Project B is a national reference architecture owned by the same government agency as in Project A. Its descriptions focus solely on the target stage architecture and strategy, business, data, and application descriptions. The architecture consists of 82 artifacts (58 diagrams and 24 tables) In Q1/2021, the project had three stakeholders and an architecture team of seven members. In Q2/2022, the situation changed significantly when Government Agency A launched a new extension project involving 29 new organization members and more than 100 new strategy experts, architects, and other specialists. This extension project continued and replaced the first project. The main driver for launching the extension project was to improve communication and collaboration within the field since this was found problematic in the first project.

In winter 2021, the lack of communication and collaboration had become critical because the EA team had only one EA consultant (the first author) and two representatives from the agency. By summer 2022, the situation had improved due to several actions taken within the year. First, another architect and an agency CIO were invited to join the EA team. Some domain experts and technical specialists were encouraged to attend the meetings, which increased EA and domain competencies and provided better awareness and understanding of the target area. It further influenced the EA artifacts and their quality and applicability in the domain and the use of the EA method in general. Second, Government Agency A aimed for better inter-organizational collaboration in the public sector. The Finnish public sector has traditionally been organized into sectors, each responsible for its area and tasks. The agency tried to break these siloes by encouraging, enforcing, and funding collaboration – and using EA to achieve this. This new EA project aimed to develop the reference architecture with a diverse group of representatives. Thus, a large number of organizations joined the project. It had three-fold implications: it increased the awareness of the current reference architecture descriptions, improved the quality of the EA artifacts, and made future reference architecture implementation much easy. As a result of the actions and their consequence and impacts on EA, we assume that stakeholders will have better opportunities to achieve the project objectives.

These actions, consequences, their impacts on EA, and impacts of the EA will improve the EA's role as a management and steering tool for Government Agency B. Also, collaboration and EA work will be more effective as a good example is provided. Figure 3 shows this impact chain: how adding another architect to the EA team (action) improved the team's competence (consequence), resulting in the EA method (impact on the EA) and the better usability of reference architecture (impact of the EA).

Fig. 3.
figure 3

Actions and impacts in Project B.

Full size image

Project B illustrates the power of corrective activities during the project. Almost right after the start, the project faced several communication and collaboration challenges. These were solved immediately and significantly investing in human resources in the project. As the team was then able to provide benefits, some concrete, some potential, Government Agency A decided to fund a new two-year follow-up collaboration project, replacing and continuing the first one. The new project involves 29 new organization members and more than 100 employees.

4.3 Project C

Project C is a national enterprise architecture owned by another Finnish government agency. It started Q1/2019 and closed Q2/2022. The project aimed to develop an EA architecture for a new government agency. The architecture focused on the target stage descriptions and included strategy, business, data, and application architectures. It had 105 artifacts (86 diagrams and 19 tables), all published. The project had four stakeholders and an architecture team of six members.

In the project, the EA team felt severe collaboration and communication problems with their stakeholders and owners. The EA team was thus active and pushed the agency to collaborate and arrange meetings to improve the EA and its interoperability with their other architectures. This push and these meetings improved semantic and technical interoperability between the architectures. Ultimately, in the future, this capability will hopefully deploy to different services between the agencies.

Government Agency B meetings increased confidence in the EA team: as a result, the agency representatives gave some extra tasks to the EA team. The team also marketed EA actively, further increasing the awareness of their work. These actions increased the EA team’s motivation, influencing the quality of the EA artifacts.

However, the situation did not proceed smoothly. Due to the personnel changes in Government Agency B, one of the related architecture projects was halted and not published, which jeopardized the interoperability of the architectures because the relations and the responsibilities had to be reconsidered.

Another change took place when a lawyer from Government Agency B joined the EA team, which increased the team’s motivation. They were able to create new EA artifacts where the forthcoming legislation was understood and incorporated. The relationship had mutual benefits as the lawyer better understood the boundaries set by the EA and was able to considered those when writing the legislation proposal.

The EA team also participated in the agency’s strategy process. Constant criticism and debate whether the proposed new organizational structure was needed however, created frustration among the EA team members. Luckily, this did not affect the EA descriptions, only communication with other stakeholders.

The EA team hired some external help. They contracted an experienced external enterprise architect from the same domain to evaluate the artifacts and elaborate on some project details with the team. The team was thus keen to improve the EA and ensure that it is understandable and usable by all parties. As a result of this mini-evaluation, the business model view was added to the EA artifact. It will thus contribute better to the new agency and its future operations.

The estimated and already experienced success of the EA project motivated the EA team members and their work in their home organizations. The project will have far-reaching impacts beyond a single project. Figure 4 shows how the lawyer’s joining the EA team (action) motivated the team (consequence). The legal capability impacted the EA definition by improving its legal interoperability. On the other hand, the EA work supported the writing of the act (impact of the EA).

Fig. 4.
figure 4

Actions and impacts in Project C.

Full size image

In Project C, the EA team was balanced and efficient in their actions. Each member had a specific role and responsibilities. They worked well, were motivated, and actively sought solutions. The activities were visible and appreciated. It is illustrated by a lawyer from Government Agency B who joined the group – she perceived the team supported her in writing a new law – and by participation in the agency’s strategy process.

5 Discussion

Our cases demonstrate that collaboration and communication can be improved by either reallocating the resources, changing the ways of working, or both. However, these activities usually require top management’s support or decision. It follows that it is essential to increase the awareness and knowledge of EA among senior management. In this endeavor, the enterprise architects’ communication and leadership skills are emphasized [18]. The owner of the EA project may, like in all our projects, add resources, such as people, money, or technologies, to the project to boost collaboration. On the other hand, as Project B illustrates, the EA team can improve collaboration by tuning the way they work and rearranging work processes – even during the project. Supplementary architecture descriptions and domain-related competencies from other government agencies improved cooperation between Government Agency B and the government agency, which, with enhanced working processes, fostered the EA team’s architecture capability maturity and efficiency. When these were further reflected in the project results, the architecture definitions and EA artifacts quality improved, making them rigorous and accurate. The architecture descriptions and documents are consequently executable and, for example, more interoperable with related architectures.

However, the owner's actions may easily hinder or destroy such progress. In Project A, the project owner changed, and new priorities were introduced, which slowed the progress. In Project C, a related EA project was terminated, so Project C had to be re-scoped and replanned. Interoperability issues are thus compromised when related architectures are not published or the projects face challenges. Here, the role of the project owner is critical: if she is not satisfied with the actions and progress of EA work or the EA team members, the changes are evident. Due to the multiple connotations of EA work [34], such frustrations and displeasures emerge unchallengingly. They emphasizes the collaboration and communication skills of EA teams [46].

Figure 5 summarizes all three cases and generalizes our observations. The main actors are the EA project owner and the EA team taking the actions, while external, reallocated resources (such as a lawyer in Project C) may also influence them. The main actions to be executed are reallocating resources or changing the working methods. They increase the EA team’s competencies in actual EA work and communicate and collaborate with others. It, in turn, improves the quality of EA work and artifacts and furthers their usefulness.

Fig. 5.
figure 5

Actions and impacts on the lack of communication and collaboration in Projects A, B and C.

Full size image

Despite the conditions and contexts and their influence on EA management [4, 17], we abstracted the contextual-specific communication and collaboration problems from three public sector projects to general actions and impacts. From these, we derive three propositions for EA project practitioners to prevent the obstacles.

Proposition 1: In EA projects, management can improve communication and collaboration by reallocating resources in a controlled manner.

This proposition is in line with [2] that human EA management resources have a strong influence on the development of EA management. It is in line with the observations EA has problems with gaining the project management’s commitment [5]. Even the architects need organizational and executive support and adequate resources [21].

In Project C, the EA team was invited to participate in the strategy work, but conflicting expectations emerged. All stakeholders were not committed to a common goal. One member of the strategy team even considered the whole strategy pointless. It demotivated the EA team and undermined their work. These conflicting priorities and the absence of the stakeholders’ shared view are typical engagement problems in EA [27]. Under the circumstances, collaboration is challenging to improve by increasing communication or resources if there is no shared goal. Such a lack of stakeholder involvement causes several other problems [18].

In Project A, increasing the project's human resources and conducting a survey solved many collaboration and communication problems. However, resource reallocation also created new challenges when the team's way of working changed. Similarly, Project C faced new challenges. It means that collaboration and communication must be taken into account in the EA project plans as they likely influence how the resources can be used. During the project planning phase, the key stakeholders need to be identified, and the different forms of collaboration and communication need to be planned and documented. Corrective actions, like in Project B, may not always be identified or appropriately executed. The lack of collaboration and communication must thus be considered similarly to any potential risk and addressed in the risk assessment and mitigation plan. Meticulous risk management was not done in the projects, which is understandable because EA work is a continuous process, not a project. Although EA work is, especially in the public administration sector, often considered as a project because of the funding models. The architects themselves treat EA as a process, possibly neglecting project management. It is also possible that the EA work is not supervised properly because EA projects are not considered as important as, for example, procurement projects.

This leads to our second proposition:

Proposition 2: Communication and collaboration should be addressed in the project risk management and mitigated explicitly by a communication plan and collaboration model.

Correspondingly, prior studies have identified obsolete and inadequate EA management documentation as a risk [31, 33]. Examples of risks related to the EA projects’ communication and collaboration are: sufficient and varied expertise in the EA team (Project A), communication with stakeholders (Projects B and C), the architecture definition is understandable to management and developers (Projects A, B, and C), and a communication plan is missing (Projects A, B, and C). These risks can be managed by identifying sufficient resources in a project plan, designing a communication plan for the EA project, and creating dedicated architecture documents for management and developers.

It is also necessary to better prepare the stakeholders for evidently conflicting expectations. Banaeianjahromi and Smolander [7] recommended that before initiating the EA project, increasing the personnel's trust, motivating them to collaborate, placing EA on the highest level of the organization, and ensuring that an EA team also consists non-EA experts are vital for success. The managers should also examine workflows and how the teams work [11]. These suggestions can be seen as non-technical meta-principles for EA. While Haki and Legner [19] identified some EA meta-principles, they focus on EA techniques and the quality of EA artifacts: integration, data consistency, standardization, compliance, technology independence, modularity, reusability, and usability.

This leads to our third proposition:

Proposition 3: Ensuring efficient communication and collaboration should be defined as an architecture principle in the architecture definition document. The definition should include a statement, rationale, and implications of the principle.

Contrary to Haki and Legner, we propose a communication and collaboration principle to guide architecture design and evolution [19]. Project C’s architectural principles included communication and collaboration issues. Projects A and B shared their architecture principles. None did involve the communication and collaboration principle, although its necessity was acknowledged as a side note. In Project C, the management did not sufficiently consider the principle, and the architecture boards at Projects A and B did not adopt it as a principle. The TOGAF version 10, de facto EA framework, provides examples of architecture principles. Neither does it contain such a principle. As often failing EA projects demonstrate, communication and collaboration are severe problems in EA work and should thus be emphasized as an EA principle. EA projects are no different from other development projects in terms of structure or project management, so they also require proper project planning, including resourcing, risk management, and communication plans. Explicitly described the collaboration model where the stakeholders’ roles and responsibilities are set, strengthens and eases project management, and mitigates communication and collaboration risks. Möhring et al. [33] argued that mature enterprise architecture management is a prerequisite for successful EA projects. One unanticipated result was that enterprise architecture management have been neglected in these projects. However, our study did not examine whether the project management was deficient.

6 Conclusion

Earlier research suggests that communication and collaboration problems must be solved to create impactful EA artifacts [6, 7, 13]. In this paper, we studied how contextual communication and collaboration problems are addressed in the EA projects.

Our projects used EA to manage their digital transformation processes. In Project A, collaboration with other stakeholders improved. In Project B, communication and collaboration problems were solved by expanding the project to cover 29 organizations. In both projects, the actions improved commitment to digital transformation. In Project C, collaboration with the responsible lawyer and the strategy group influenced the strategic goal to build a new organizational structure and an agency, which form the core of the future service ecosystem.

Our observations unveiled the consequences of the project resource reallocation and of changing the work practices. We then built three generic propositions for practitioners to avoid the problems. Propositions 1, 2, and 3 are targeted for project management, and the third proposition is also for senior EA architects. We showed that EA practitioners have to be prepared to manage emerging communication and collaboration issues consciously and actively.

In general, enterprise architecture management is pivotal in the success of EA projects [33]. Shanks et al. [40] found that EA service capability and EA governance both have a positive impact on the success of EA projects. [2] argued for the importance of EA modeling, EA planning, EA implementing, and EA governance capabilities. However, we argue that communication and collaboration is a threshold resource in EA projects. In this respect, our three propositions concretize the argument.

We provide theoretical and practical contributions. For theory, our propositions are a starting point for future research and to study, for example, their relation to Shanks et al. [40] or Ahlemann et al. [2] capabilities. Also, our model of analysis (Fig. 5) shows some relationships with actions and their consequences. It thus provides more understanding about the EA benefit realization practices c.f. [35, 43]. For practice, the propositions provide concrete, immediately applicable advice.

This study has some limitations. First, our research method, ethnographic observations, is subjective as the first author was living the daily life of the projects. The information was extracted from the perspective of only one person, who was involved in the actions and was not only a passive observer. He influenced the data collection by selecting what to collect and record, and his memory and potential biases have probably limited what can be reviewed in the analysis phase. Although we have tried to minimize over-subjectivity and the problems of accidental misanalyses by first writing the storyline of activities and then analyzing the storyline, and by constantly reflecting on the findings among the authors, subjectivity is still there. However, as our purpose was to analyze only one problem and how it is dealt with such potential subjective bias is minimal. Second, the context, the Finnish public sector, may set some limitations. The propositions are not related to cultural or administrative issues, but they are generic and can be applied in other contexts. The third limitation is the focus on one problem type only. However, the EA problems are intertwined when they occur, and their interaction matters [7]. This relation is left for future research.