Keywords

1 Introduction

In Enterprise Architecture (EA) business aspects, software applications, data, and infrastructure are modeled together in a structured way in order to manage the enterprise and make well-informed decisions. In a company where the main business is to develop complex hardware (HW) and software (SW) products the discipline of EA is mainly used to handle the overall commonly used office IT and the processes it supports, more rarely does EA include the development of the customer products. Furthermore, the business units in charge of the development are usually good at modeling the system under development, their product, in a formal way. However, these two approaches rarely meet formally.

Generally speaking, while the product architecture is handled in a formal way and relations between its elements are specified and controlled in a systematic way, the organizational part is not considered to be a part of the architecture and the system as whole. This makes the analysis of the impact between product and organization a very tedious task. In the context of a business unit with strong HW and SW product focus, we propose to consider the organizational part as a legitimated system that has to be described, specified, and analyzed in a systematic way in the same manner as the product.

The focus of this paper is to analyze the hidden dependencies in the organization under transformation. We have not explicitly modeled the product and its relation to the organization structure in this paper, but the blueprint of the product architecture is implicitly presented and inherited in the structure of the original organization. For analyzing the hidden relations between organizational elements we have applied an evolution of Design Structure Matrices (DSMs) called “Hidden Structure” [1, 2], a methodology mainly used for analysis of product-related artifacts. We have created a number of to-be scenarios, which are containing mappings of new process proposals on our organizational units. The aim with this transformation is to become more agile and lean, but it is also necessary that this potential organizational architecture is implemented without increasing communication dependencies between different teams. The visualization of the architecture that the hidden structure method provides, including dependency maps, makes it a valuable tool used for identifying impacts on the architecture. Our results show that one of the to-be scenarios dramatically increase the complexity, while the two other are neither increasing nor (remarkably) decreasing the complexity when transforming into a more agile and lean organization.

The paper unfolds as follows: Sect. 2 presents related work and Sect. 3 the hidden structure method. In Sect. 4 our case is described together with its results and a discussion. Future work is outlined in chapter Sect. 5. And finally, Sect. 6 concludes the paper.

2 Related Work

Product architectures have been given a lot of attention throughout the years, both in academia and in practice. Today there are numerous initiatives aiming to guide and aid the design and evolution of product architectures. For instance, in software architecture [3] state “… software architecture has matured to encompass a broad set of notations, tools, and analysis techniques. Whereas initially the research area interpreted software practice, it now offers concrete guidance for complex software design and development.” However, there is less focus on the organizational aspects of SW development when it comes to treating the organization as a complex system that needs to be modeled and analyzed to the same extent.

The focus on products is also the case in the community of Design Structure Matrices (DSMs), e.g. [4, 5]. Baldwin et al. [1] developed a method to visualize the hidden structure of software architectures (one example of a product architecture) based on DSMs and classic coupling measures. This method has been tested on numerous software products, such as Linux, Mozilla, Apache, and GnuCash. In one study by MacCormack et al. [6] an early version of this hidden structure method was employed to show the relation between the product architecture and its development organization.

For some time now enterprise architecture models have been used in order to model complex systems including organizations, processes and supporting IT [7–9]. Although modeling has been the main focus of EA initiatives, running analyses on these models is getting more and more attention. Different approaches have been suggested [e.g. 10] and numerous of analyses have been proposed (for instance [11–14]).

Recently the field of enterprise architecture started to test the hidden structure method with the aim to visualize and measure complex systems. In [15] the hidden structure method was used on a Biopharmaceutical case to reveal the hidden dependencies in its enterprise architecture incl. business groups, software applications, databases, schemas etc. Data from this case was then used to show that the cost of changing applications with many indirect dependencies (metrics derived using the DSM based hidden structure method) was more expensive than applications with few [16]. In [17] the authors employed the hidden structure method on application portfolio data from a Telecommunication case.

In this paper we aim to make use of the success of combining DSMs, hidden structure, and EA.

3 The Hidden Structure Method

The method we use for representing architectures is based on and extends the classic notion of coupling. Specifically, after identifying the coupling (dependencies) between the architecture elements, we analyze the architecture in terms of hierarchical ordering and cyclic groups and classify elements in terms of their position in the resulting network (this method is described in [1]).

In a Design Structure Matrix (DSM), each diagonal cell represents an element (node), and the off-diagonal cells record the dependencies between the elements (links): If element i depends on element j, a mark is placed in the row of i and the column of j. The content of the matrix does not depend on the ordering of the rows and columns, but different orderings can reveal (or obscure) the underlying structure. Specifically, the elements in the DSM can be arranged in a way that reflects hierarchy, and, if this is done, dependencies that remain above the main diagonal will indicate the presence of cyclic interdependencies (A depends on B, and B depends on A). The rearranged DSM can thus reveal significant facts about the underlying structure of the architecture that cannot be inferred from standard measures of coupling. In the following subsections, a method that makes this “hidden structure” visible is presented.

3.1 Identify the Direct Dependencies and Compute the Visibility Matrix

The architecture of any complex system can be represented as a directed graph composed of N elements (nodes) and directed dependencies (links) between them. This directed graph can be represented as a DSM. If the DSM is raised to successive powers, the result will show the direct and indirect dependencies that exist for successive path lengths. Summing these matrices yields the visibility matrix V (or VSM), the far right matrix in Fig. 1, which denotes the dependencies that exist for all possible path lengths. The values in the visibility matrix are constrained to be binary, capturing only whether a dependency exists and not the number of possible paths that the dependency can take [1]. The matrix for n = 0 (i.e., a path length of zero) is included when calculating the visibility matrix, implying that a change to an element will always affect itself.

Fig. 1.
figure 1

A directed graph with the corresponding DSM and VSM.

Full size image

Several measures are constructed based on the VSM. First, for each element i in the architecture, the following are defined:

  • VFIi (Visibility Fan-In) is the number of elements that directly or indirectly depend on i. This is found by summing entries in the ith column of V.

  • VFOi (Visibility Fan-Out) is the number of elements that i directly or indirectly depends on. This is found by summing entries in the ith row of V.

In Fig. 1, element A has VFI equal to 1, meaning that no other elements depend on it, and VFO equal to 6, meaning that it depends on all other elements in the architecture. To measure visibility at the system level, Propagation Cost (PC) is defined as the density of the VSM. Intuitively, propagation cost equals the fraction of the architecture that may be affected when a change is made to a randomly selected element.

3.2 Identify and Rank Cyclic Groups

The next step is to find the cyclic groups in the architecture. By definition, each element within a cyclic group depends directly or indirectly on every other member of the group. First, the elements are sorted, first by VFI descending then by VFO ascending. Next one proceeds through the sorted list to find different cyclic groups. These groups are referred to as the “cores” of the system. The largest cyclic group is defined as the “Core”. Once the Core is identified, the other components in the architecture can be classified into groups, as follows:

  • “Core” elements are members of the largest cyclic group and have the same VFI and VFO, denoted by VFIC and VFOC, respectively.

  • “Control” elements have VFI < VFIC and VFO ≥ VFOC.

  • “Shared” elements have VFI ≥ VFIC and VFO < VFOC.

  • “Periphery” elements have VFI < VFIC and VFO < VFOC.

Using the above classification scheme, a reorganized DSM can be constructed that reveals the “hidden structure” of the architecture by placing elements in the order Shared, Core, Periphery, and Control down the main diagonal of the DSM, and then sorting within each group by VFI descending then VFO ascending (cf. Figure 3 for an example of a hidden structure sorted DSM).

The method for classifying architectures into different types is discussed in empirical work by Baldwin et al. [1]. Specifically, the authors find a large percentage of the architectures they analyzed contained a large cyclic group of components that was dominant in two senses: (i) it was large relative to the number of elements in the system, and (ii) it was substantially larger than any other cyclic group. This architectural type is classified as “core-periphery.” Where architectures have multiple cyclic groups of similar size, the architecture is referred to as “Multi-Core”. Finally, if the Core is small, relative to the system as a whole, the architecture is referred to as “Hierarchical”.

4 Case

In this paper we describe; (1) the application of the DSM method in order to reveal the hidden organizational structure of an enterprise architecture, and (2) how the method was used as pilot for a what-if analysis transforming the organization in a large project, developing both HW and SW.

4.1 Motivation

SW and HW design has in the past years seen a transition from waterfall based design approaches towards agile and lean. The main driving force for this transformation is to increase time-to-market of SW and HW features by breakdowns of smaller tasks and by utilization of small cross-functional teams. This transition is quite successful for organizations involving a limited number of designers in total, i.e. with less than 100 people, split up into cross-functional teams with less than 10 team members. However, scaling up these design approaches towards several thousand of designers working for developing large SW/HW products is still a challenge and not fully understood and solved, neither in academia nor in industry (what we are aware of).

Performing such a transition in one big organizational change is therefore a considerable business risk due to the lack of understanding. A step-by-step approach is therefore less risky. However, even with a step-by-step approach there are major risks that need to be considered. It would be of great help if it would be possible to analyze the impact different changes have in each step, in order to understand the consequences.

Given the assumption that an agile and lean project organization will decrease lead-time and increase efficiency at the end of the transition, intermediate steps must not add unnecessary complexity. This is important since the organization must be able to maintain and deliver its SW features and HW deliveries to the customers during the transition period. It is therefore not always about an explicit boost of productivity during a transition step, but also about not destroying the already achieved improvements.

Our case takes place at Ericsson, a large telecom infrastructure provider. We focus on one part of Ericsson, which is basically an enterprise in itself divided into seven organizations (here called A–G). These organizations contain up to eight sub-units each, numbered in sequential order. Customers were also included as the last part of the development chain, the last step out of the development units, i.e. as one sub-unit for each organization The organizations and sub-units are the artifacts/components used in our DSM analysis.

The content of the DSM is realized from use-cases starting with a customer offer and ending with the SW and/or HW being delivered to the customers. Every use-case is modelled as a flow of events through the organizations. Typical examples of elements within our organizations are units or sub-units for product management, early phases investigations (EP), product development (PD), product integration (CI), product and system verification (SV), release management (RM), product packaging (PP), etc.

The DSM was created by analyzing the dependencies and deliveries between the above-mentioned organizations developing the HW and SW. The details of the DSM are not revealed in this paper. Figure 2 shows the DSM together with some high level, schematic outline of the flows used. The example flows are shown to outline the input data for the DSM. The flows are the result of a separate activity within Ericsson to visualize what is called the football field of the organization, i.e. a few pages of explanation of how the organization is working with product development. Thus, the flows are not only revealing the organizational architecture, but also the way of handling the product artefacts in this architecture, i.e. the (SW & HW) elements of the products and their development. For simplicity only the major flows are used, e.g. infrequent feedback loops are not considered. For a better understanding we here provide an example for such a flow. The DSM is created from a number of “send operations” between two organizations or sub-units. Let’s assume two sub-units “A” and “B”. “A” sends (e.g. an order, SW, HW) to “B”, in a flow picture indicated by an arrow from “A” to “B”. In the DSM this is modeled as “B” is dependent (on order, on delivery, etc.) on “A”. Ericsson realizes SW and HW for multi-standard (e.g. GSM, LTE, WCDMA) networks. An example flow could be that sub-unit Product Line for multi-standard (PL-MS) offers a feature to a customer running a multi-standard network and checks for commercial interest: (DSM operation: Customer dependent on feature offer from PL, Customer => PL-MS). PL-MS orders a consequence impact study from e.g. GSM RAN Product Development Organizations Early Phases (EP) sub-unit, doing such studies (DSM: GSM RAN EP => PL-MS); Next steps are: PL-MS orders feature from e.g. GSM RAN Product Development Program (GSM RAN PD => PL-MS); GSM RAN PD sub-unit sends HW and/or SW with updates to Continuous Integration (CI) sub-unit within GSM RAN (GSM RAN CI => GSM RAN PD). GSM RAN CI sends HW and/or SW with updates to Continuous Integration sub-units in PDU WCDMA RAN (WCDMA RAN CI => GSM RAN CI) and PDU LTE RAN (LTE RAN CI => GSM RAN CI). Then the SW/HW with the feature is sent to the Product packaging (PP) sub-units within all three RAN PDU’s and from there to each PDUs Release Management (RM) sub-unit, which next provides the SW/HW in a release together with other features to the multi-standard customer(s). In the DSM, each of those “send operations” is modeled as explained further above and indicated as an arrow in Fig. 2 below.

Fig. 2.
figure 2

From high-level process models to DSM.

Full size image

4.2 Results

Based on the original DSM (see Fig. 2) we derived our VSM, which we used in order to sort the DSM revealing its hidden structure, see Fig. 3.

Fig. 3.
figure 3

The organizational architecture DSM, sorted according to the hidden structure method explained in Sect. 3.

Full size image

From the hidden structure method sorting we can see that the architecture is a core-periphery architecture (or more precise a core-control architecture). We have no elements in the DSM being labeled Shared, and only two units in the Periphery. We have one large Core containing 19 of the total 55 elements. These core units have outgoing dependencies to all other core elements (VFO = 19) and have in-flowing dependencies from 53 units (i.e. the Core and the Control elements, VFI = 53).

The Propagation Cost (PC) of the VSM is calculated to 47 %, meaning that a new request or a change in the product development might need to be communicated through 47 % of the units in the organization. From this analysis, it cannot be derived if 47 % is a good or bad number. However the PC can be used in order to compare different alternatives for changing the organizational architecture. This is further explored in our to-be analysis, e.g. an increase of the PC after a change will reveal increased complexity in the product development. If the PC is neither increasing or decreasing after an organizational change, then it can be concluded that the change did not add additional complexity, e.g. if the organizational change was done to have more parallel development between agile teams and the PC is not increased, then the change may have fulfilled its purpose without increasing the number of dependencies between the different organizational units, i.e. the “complexity” in the interworking is constant before and after the change, which is a positive outcome of the change despite that the PC stayed constant.

4.3 To-Be Analysis

The next step in our organizational architecture analysis was to test the consequence of different changes to the architecture and its elements. All changes shall result in a possibility to implement a transformation from product specific architecture elements to cross-functional elements. The main driving force behind this is the move towards becoming more agile and lean, from now on called “Agilean”. Teams (our DSM elements) should be able to pull orders/features from a prioritized list and to take full end-to-end responsibility for such a feature without negotiation between product domains about the allocation of skilled people in a specific domain (which is the case today). The domain specific fan-in and fan-out dependencies are in such a transformation equal for all resulting units, i.e. all such architecture elements would form a cyclic group in the DSM.

We analyzed three possible to-be scenario alternatives: (1) Agilean transformation within existing organizations, with the target to remove dependencies within an organization and maximize parallel work. (2) Agilean transformation on the front-end side of our organizational architecture, with the target to maximize parallel work inside the core. (3) Agilean transformation on the back-end side of our organizational architecture with the target to utilize the fact that some units have the same outgoing dependencies and maximize parallel work.

The organizational transformation in Scenario 1 resulted in one gigantic core (see top-left DSM of Fig. 4), where the propagation cost increased from 47 % to 76 %, thus a scenario in which nearly everything is dependent on everything.

Fig. 4.
figure 4

Sorted DSMs for the three to-be scenarios; top-left Scenario 1, top-right Scenario 2, bottom Scenario 3.

Full size image

Scenario 2 resulted in a core-control architecture (cf. top-right DSM of Fig. 4) similar to the original DSM in terms of PC, core size, and categorization. Finally, Scenario 3 (see bottom DSM in Fig. 4) that also is a core-control architecture similar to the original. Here propagation cost decreased slightly to 43 %.

4.4 Discussion of the To-Be Analysis Results

An agile and lean transformation that is focusing only on the internal “root” organizational level (Scenario 1), disregarding fan-in and fan-out dependencies has resulted in a big increase of propagation cost and a “gigantic” core, covering 76 % of all architecture elements. An explanation for this is that the transformation was driven to maximize the possibility to use any sub-unit for any type of product changes. This is very helpful for the “pull-principle” in agilean development, i.e. that each sub-unit can pull and execute “orders/deliveries” from arrival to delivery, thus there is no longer an internal dependency between sub-units on the cost of an increase in the number of dependencies to/from external sub-units. This low focus on external dependencies caused the PC to double. Two other approaches were then tested; (i) the transformation of the front-end side (optimizing within the core, Scenario (2), and (ii) the transformation of the back-end side (optimizing specifically selected sub-units, Scenario (3). The transformation of Scenario 2 resulted in the same PC as the as-is scenario, while Scenario 3 resulted in a slightly decreased PC. Indicating that the two groups (front-end and back-end) are rather separated in their fan-in and fan-out structure, only a few new dependencies are created during the agilean transformations. In Scenario 2, the PC stayed constant. This can be explained by the fact that the selection of sub-units where the transformation was applied was done in a way that those sub-units already before the transformation had large dependencies between each other and very similar dependencies towards/from external sub-units. The decreased PC in Scenario 3 can be explained by the fact that the agilean transformation within the selected-sub-units decreased the number of dependencies between the sub-units. This decrease (over-)compensate the increased number of external dependencies. The remaining question is, whether there is a fundamental other difference between Scenario 2 and Scenario 3 that would lead to a decision in choosing between them.

When looking on the number of people working the two big groups, we see that the back-end group is a factor of 20–30 larger than the total number of people working in the core. Therefore an agilean transformation of the back-end side has potentially bigger positive scaling impact than the front-end side transformation. As the number of people in the front-end is so much smaller, the examined re-structuring of the core into a structure with very few dependencies inside the core is really feasible and the PC for Scenario 2 is not higher than the PC before the transformation. This means that we can create a large number of cross-functional teams (back-end) that can work almost end-to-end (excluding competence in core) in an agile and lean company environment.

5 Future Work

In this paper we used a rather high-level process model to gather the organizational dependencies. In our model all dependencies are only binary; this will result in a worst-case analysis and not a weighted or probable one. To make the DSM analysis more precise the dependencies between the elements could be weighted.

Our current focus will be extended beyond organizational aspects and include other artifacts in the development system. The intention is to extend the analysis to the whole production architecture, where the organization is only one part. The major components of the production architecture are; Organization, Processes, Development artifacts (tools, production related code, information, and machines). In this work Enterprise Architecture methods for modeling and analysis will play an important role.

Our long-term approach is to map the dependencies between product and production architecture; and to find a set of methodologies that can model these as one interrelated system. The product and the organization should not be considered as independent entities, but as a complex system with many levels of components and relations that are affecting and forming each other. The hidden relations and dependencies between product and organizational parts are vital to understand and analyze in order to foresee the true impact of a change on both, i.e. the two faces of the system are not independent of each other.

Other complementary analytical methods in addition to the hidden structure analysis using DSMs are needed to cover the multifaceted nature of the system. These connected models are intended to be used in the same systematic manner as product architecture models are used today, e.g. to drive the improvements and needed evolution of the production architecture.

6 Conclusions

In this paper we have used the Design Structure Matrix (DSM) based hidden structure method in order to investigation organizational transformation scenarios at Ericsson. In our case this turned out to be an appropriate approach for revealing the unknown dependencies in a complex system of organizational units communicating with each other to develop hardware and software products. We were able to identify impacts on the current as-is architecture and to (re)organize this architecture for three different to-be cases. The results of our to-be analyses show that the organizational transformation must take into account the hidden dependencies that are in part a reflection of the product architecture structures. However, for a more detailed and possibly more accurate analysis, we need to evolve the methodology further by using a less binary approach to dependency schemes. Completing the model with other artifacts such as development tools and related processes will require additional modeling and analysis techniques.