Data analysis—Activity theory

Data analysis from an activity theory perspective was conducted based on the series-of-events analyses, which guided the selection of activities analyzed. The analysis itself began with a depiction of the digital transformation activity. First, the different elements of the activity (i.e., the subject, object, tools, rules and norms, community, and division of labor) were identified by following the process presented by Crawford and Hasan (2006). As the elements of the activity varied as the studied transformation proceeded, multiple versions of the activity were created. Of these, two activity system presentations were selected, one presenting the initial situation and the other the situation after the transformation. These were then iteratively developed.

Then, the analysis advanced to consider activities connected to the main activity (i.e., the activities identified in the series of events analysis). In the process of analyzing interlinked activities, the created narratives of the identified series of events were used as the first step. Then, the activities were defined by iteratively defining components from the interview data. First, the interview data were analyzed from the perspective of the initial activity system. Then, the analysis proceeded to consider activities conducted during the case study and their role in the digital transformation activity system. The versions of the digital transformation activity system were iteratively updated as the analysis of the interlinked activities proceeded. Table 7 presents an example of one analyzed activity.

Table 7. Enterprise architecture activity analysis 2017 (Ylinen and Pekkola 2021a).

AT concept Quotations

Subject: EA team “The EA team is doing something that has no connection to [our actual operations]” (Consultant I, CTO).

Object: Improved management of the IT resources and consequently improved service offering

“[The objective is] customer-centricity.... When the ecosystems and architecture are considered comprehensively enough, we can offer fast services” (CIO).

Tools: Kartturi framework and modeling tools selected by enterprise architects based on their personal preferences

“[The municipality] chose the Kartturi framework as the frame of reference. Of course, we did not forget the JHS-179 either”

(Architecture team manager).

“As we did not have a specific way to document [things], we used this and that [depending on the work]” (Enterprise architecture).

Rules and Norms: ICT-law and JHS 179 regulation

“[The governmental officials] are bustling along without considering us” (CIO).

Community: IT department, business units, and IT projects

“The objective is to get the enterprise architecture and IT projects to work more closely together” (Project manager).

“[Business units] do not understand what the role of enterprise architecture is” (CIO).

“The architecture team has no communication connections to others, even inside the IT department” (Consultant B).

Division of labor: EA team overlooks EA utilization while the IT projects do the work

“The EA team does something which is not connected to others’

work” (Consultant D).

“We made reference architectures and architectural documents ..., then these documents were presented to the projects.... After this, we left them to manage the documents by themselves” (Architecture team manager).

Outcome: EA is considered a waste of resources

“Experienced experts create models for themselves …. [T]hese are not used in the holistic development” (Architecture team manager).

After identifying the different components of the main activity of digital transformation and its supporting activities, the connections between these activities were analyzed. The focus of this analysis was to identify how individual activities influence the main activity of digital transformation. Based on this analysis, an activity network was formulated that presents the way the different activities in the IT department contributed to the activity of digital transformation and also resulted in other activities.

The analysis then proceeded to consider whether contradictions existed in the depicted activity network. This included the identification of contradictions within the identified elements, between the identified elements, or between the interlinked activities. This division to three levels of contradictions was adapted from Bertelsen and Bødker (2003), although one level of contradiction was excluded as no culturally more advanced central activity was identified; therefore, contradictions between the main activity and this more advanced activity could not be analyzed.

In the contradiction analysis, special attention was given to two time points: the spring of 2017 and the endpoint of the case study (i.e., autumn 2018). The analysis followed an iterative process whereby the individual elements were first analyzed to see whether the interviewees saw them as supporting or hindering the operations in the IT department. Second, the analysis advanced to consider whether they were in contradiction with the objective of the activity. Both steps were conducted for all the analyzed activities. Third, the role of the supporting activities was analyzed to determine whether they supported the digital transformation activity.

4 FINDINGS

This chapter will first present the initial situation in the municipal IT department, focusing especially on the challenges that eventually drove this department to a large-scale transformation. To provide an in-depth view of the contradictions persisting in the department, the paradox perspective is utilized to depict tensions of the EA function. Then, the key transformation activities the IT department conducted to improve the operational situation are presented. These activities are then analyzed in more detail from the perspective of activity theory, first by analyzing the initial situation at the beginning of the data collection (spring 2017), then by considering how the contradictions drove transformation activities in the IT department, and finally by considering the situation at the end of data collection (autumn 2018). The Findings section concludes with consideration of the outcomes of the transformation.