Keywords

1 Introduction

The discipline of enterprise architecture (EA)has become well-established in many organizations and is continuously discussed in academic publications [1]. The achievements of the discipline in the practitioner’s domain are documented for example in EA frameworks out of which The Open Group Architecture Framework (TOGAF) [2] has received most attention in recent years [3, 4]. Achievements of academic research are published in numerous method fragments [for overviews see 1, 3, 5–7] covering EA modeling, EA planning, EA principles, etc.

Enterprise architecture describes the fundamental structures of an organization. Enterprise architecture management (EAM) is concerned with guiding changes and developments of EA. As such, the notion of EAM goes beyond EA modeling and includes the management tasks of planning and controlling business changes from an architectural perspective [8].

What defines the architectural perspective and differentiates EAM from other management disciplines, such as business process management or project management, is its holistic scope which spans three dimensions [9, 10]: (1) on a horizontal dimension, EAM often covers the entirety of artifacts of a specific artifact type (e.g., all applications or all processes) of an organization. (2) On a vertical dimension, EAM often covers all layers of an organization’s business-to-IT stack. (3) In a dimension of time, EAM is not limited (e.g., to a project or program), but covers changes of several projects or programs linking an EA’s as-is state to one or several to-be states.

Due to this holistic perspective, EAM is expected to identify and leverage those potential synergies in an organization that cannot be identified, having a partial perspective, e.g., of a single project, in a single process, or a single organizational unit. This is because all these entities often have their particular but locally restricted perspectives and strive for achieving their respective local goals. From a holistic perspective, the set of local, and in this matter uncoordinated, decisions often results in inconsistent, redundant, and/or conflicting solutions.

In practice, however, EAM’s impact often falls short of its potential benefits. One of the reasons is that EAM’s range of influence is often restricted to IT departments only [11]. In fact, EAM often has an “image problem”, and once people use the word enterprise architecture, “eyes start to roll” [12]. Involving business departments seems to be a difficult task on which EAM regularly fails to deliver. Thus, a relevant question for EAM is how to reach “that other 90 %” of an organization that are not related to IT [13]. This question is crucial since Ross and Quaadgras [14] found that more mature EAM functions “do not necessarily lead to business value” but that “business value accrues through management practices that propagate architectural thinking throughout the enterprise.” [14] Given a certain maturity level, EAM should not aim at further improving EAM methods, tools, and processes. Instead, the underlying philosophy of EAM, taking decisions informed by a holistic perspective, should be internalized by a broad range of decision makers across hierarchical levels.

Ross and Quaadgras [14] define architectural thinking as the way of thinking and acting throughout an organization that considers holistic, long-term system aspects as well as fundamental system design and evolution principles in everyday decision making, which is not restricted to architects or system developers. According to Winter [15], architectural thinking is supposed to be a lightweight, less formalized, and utility-centered approach that aims to support non-architects and people outside the IT function to understand, analyze, plan, transform, and communicate fundamental structures as well as design/evolution principles of what they perceive as their work system. Architectural thinking aims at educating these people in adopting holistic, long-term considerations in their daily decisions.

The concept of architectural thinking occurred fairly recently in academic literature and remains abstract. Therefore, our research aims to contrast the concept of architectural thinking found literature with empirical case study data. We further aim to understand whether corresponding concepts can be identified from empirical data and where existing conceptualizations can be extended. Therefore, this research provides an overview of the existing literature on architectural thinking and derives a corresponding research lens. We follow an interpretive (antipositivist) approach. Our aim is to add to the understanding of the phenomenon of architectural thinking since there is no other empirical foundation to discuss the phenomenon, yet. We contribute new aspects of architectural thinking and we add empirical instances to so far only theoretically described constructs.

We proceed as follows: in Sect. 2 we present the conceptual lens of architectural thinking and introduce related literature. We provide empirical data from a case study at Commerzbank AG in Sect. 3, followed by a discussion of the data through our conceptual lens in Sect. 4. We conclude by a summary in Sect. 5.

2 Conceptual Foundations

2.1 Differentiating Architectural Thinking from EAM

Architectural thinking has only recently been discussed as an addition to traditional EAM [14]. This shift in perception is rooted in the finding that EAM practices differ from the descriptions that are often subjected in EAM discussions. While traditional EAM oftentimes focusses on the results of architectural work, it may become much more valuable to focus on the process of gathering information relevant for architectural decisions [16] and thus involving the relevant stakeholders. Winter [15] details this perception by identifying commonalities and differences between the two concepts of EAM and architectural thinking. Both approaches share the scope concerning the fundamental structures of the organization and the principles guiding its design and evolution. The goals of both approaches are the reduction of redundancies, increasing consistency, increasing manageability, leveraging synergies, and increasing flexibility, respectively. Their scope regarding time is long-term rather than short-term.

However, Winter [15] mentions important differences (see Table 1). While EAM describes architects as the driving actors, architectural thinking promotes the individual decision-maker within the organization to taking responsibility. Local, often non-IT decision-makers are responsible, not only for achieving their respective goals, but also for contributing to the enterprise-wide goal achievement. In order to facilitate architectural thinking, the focus needs to be both extended to long-term goals of the organization and aligned with the short-term goals of decision makers. In order to mitigate the risk that architectural thinking is misunderstood as set of local optimizations, the trade-off between local and enterprise-wide goals need to be addressed and reduced. Opposed to existing, often sophisticated EAM approaches, the architectural thinking approach is supposed to be lightweight and targeted at supporting non-architects.

Table 1. Differences between EAM and architectural thinking [15]
Full size table

Some confusion may arise on how architectural thinking differs from strategy making and concrete design of the organization. Proper [17] deals with this confusion and positions architectural thinking between the strategic and the design level. The strategic level deals with definitions and evolutions of the corporate strategy. The design level copes with decisions that are related to each team’s work processes and project organization. The intermediary architecture level, which involves architectural thinking, is positioned to focus on the requirements that can be gathered from the strategic level as well as from goals and concerns of the stakeholders in the organization.

2.2 Adoption of Architectural Thinking in an Organization

The core of architectural thinking is the establishment of the architectural perspective in the organization. Lattanze [18] particularly articulates the need of EAM training programs to have the long-term goal of establishing the architectural perspective throughout the organization. He aims not only at training employees in architecture theory and principles, but also at achieving a state, where designing organizational elements, such as products etc., is a deeply rooted paradigm within the organization. This could be achieved by providing formal roles and career paths for people involved in architecture. Furthermore, architects need to be trained in marketing and communication concepts; processes need to be constructed/changed by involving architects in an early stage. This is in line with Ross [14], who states that, in order to drive the value from enterprise-wide activities, management mechanisms need to be implemented, allowing people to continuously learn how to improve their platforms.

Van der Raadt et al. [19] emphasize the origin of the “architecture lobby” when aiming at the establishment of architectural thinking. According to the authors, “an organization where architecture awareness originates with business management has different ideas about architecture and has a different momentum than an organization in which architecture awareness starts in the IT-department.”

Weiss et al. [20] describe antecedents that need to be considered for establishing an architectural perspective. They ground their research in institutional theory [21–23]. According to the authors, benefits through EAM are achieved when EAM has a “rule-like status in social thought and action”, provides social legitimacy and efficiency, and when it is grounded in the organization [24].

Winter [15] finds that the antecedents for establishing EAM are also relevant for the adoption of architectural thinking throughout the organization. Based on the work by Weiss et al. [20], Winter [15] derives challenges for the adoption of architectural thinking in organizations (Table 2):

Table 2. Challenges for the adoption of architectural thinking [based on 15; 20]
Full size table

In the following we use the dimensions from Tables 1 and 2 as the conceptual lens to analyze the empirical data presented in the next section.

3 Case Study Commerzbank AG

In this section we present case study data on architectural thinking, collected from Commerzbank AG. Two of the three authors are university-scientists and part of an applied research project at the case company. The third author is employed with the case company as an enterprise architect and involved in the initiative reported here. The goal of the case study is to contrast the perceptions from practice with the early conceptualizations of architectural thinking from academia.

3.1 About the Case Company

Commerzbank is the second-largest German bank, located in Frankfurt/Main. The company is providing services for the global banking business, having more than 52,000 employees. Similar to other companies in the banking sector, Commerzbank has to deal with challenges imposed by the recent financial crisis and the subsequent regulatory requirements, significantly impacted by low interest rates in their daily business operations. In order to cope with these challenges, Commerzbank aims at further reducing risks, optimizing the capital base, pursuing cost management, and simultaneously making long-term investments in the core bank’s earnings power, while rigorously orienting the business model toward the needs of customers and the real economy [25].

Within Commerzbank, the EAM function is part of the IT-organization and directly reports to the group chief information officer (CIO). One of the main goals of the EAM function is to support the joint definition of target processes and to align system architectures with business and IT units. Architects thereby serve as drivers of the target architecture definition process and as method providers. Target architectures are always developed within a business-driven change project or program.

3.2 About the Project

Commerzbank has recently launched a strategic investment program called Group Finance Architecture (GFA), aimed at redesigning the process and system architecture of the Commerzbank group finance function. The sponsor of the strategic initiative is the chief financial officer (CFO). The main goals of the program comprise delivering on the latest regulatory requirements, integrating financial accounting and management accounting in order to significantly faster processes, and improving the financial analysis options.

To achieve these goals, a new finance architecture needs to be designed and implemented in an almost greenfield approach. The new finance architecture serves as the nucleus for a more integrated bank steering platform. The project is supported by the EAM function for supporting and guiding the design of the new target architectures. EAM always needs to be involved in large projects and programs that are conducted at Commerzbank. The new layered architecture is based on a state of the art standard accounting software and a data warehouse, resembling the new single source of facts.

The architecture work focuses on ensuring that the new solution fulfills the defined functional and non-functional requirements. The top priority is to ensure that the results of this investment will actually serve as the core for the new finance architecture and thus as a substantial nucleus for future projects. Although a single project is usually not a suitable case for demonstrating architectural work, this particular project is a nice exemplar for demonstrating architectural work in general and architectural thinking in particular. This is due to the size of the project, where up to 150 project members need to take decisions during the five years of the project, and it is due to the fact that this project is sponsored by the CFO, i.e., from outside the IT organization. This project has to address both the long-term holistic perspective as the future nucleus for further projects as well as the local project perspective to deliver in time, in budget, and in quality.

3.3 Architectural Thinking in the Project

To align decisions of the project members, Commerzbank uses the capabilities of the EAM function. The EAM approach focusses on demonstrating its value contribution to the project members. For this purpose, EAM starts with project scoping and is primarily involved during the functional design phase; EAM is less involved when it comes to the subsequent IT development.

An important step to ensure the acceptance of architectural work is to formulate business-driven goals that need to be met by the final solution. Thus, the focus is on the solution (what does the business want to achieve?) and not, like oftentimes before in similar projects, on the way to achieve the goal (how do we want to achieve the goal?). Exemplary business goals are the convergence of finance and risk data, the support of very short time-to-market-cycles for new products, fast consideration of new (regulatory) requirements, and an overall cost efficiency. Based on these high-level business goals, more specific goals for the overall solution are formulated. Examples for such goals are:

  • The solution provides a convergent storage.

  • The solution is designed to enable short change cycles.

  • The solution design is cost efficient.

These goals are focusing on the solution and do not mention any architectural rule or paradigm. The designs are evaluated concerning their contribution to the solution’s goals. These solution goals are transparently linked to business goals. They are not the result of an architect’s or engineer’s opinion on what a favorable solution would look like.

To support the practical implementation of the solution’s goals, rules are defined for each solution layer (e.g., data warehouse, accounting solution, and reporting). Yet, those rules are formulated in a way that any design can be evaluated regarding its contribution to the solution’s goals. Exemplary rules are:

  • The implementation is achieved by customizing.

  • Each rule references a business goal that the rule should contribute to.

If a situation occurs, where the use of a rule would not contribute to the business goal, the rule is not supposed to be applied. For reasons of governance, it was necessary to communicate this set of business and solution goals as an official and binding document within the project. However, this formal binding stays effective only as long as there is good reason. The Commerzbank approach is not to rely on any formal status of architecture documents, but to rely on the good and comprehensible reasons for the business and solution targets.

3.4 Project Learnings

In this project, the most important philosophy to foster business stakeholders’ architectural thinking is to handle design and implementation decisions in a consensual way. The consensus, however, always has two components: the business driven goal definitions and the holistic architectural perspective. Sound design, from an architectural point of view, became a self-runner after the first phase of intensive collaboration between the architecture and the design team. In conflicting situations, where someone argues for a design that does not comply with the current architectural rules, and still was able to explain why the proposed design contributes to the overall goals, this new design was handled as the new architectural standard. If the respondents were not able to provide a reasonable explanation, they were in charge to argue, why in this case it might be more appropriate not to contribute to the overall solution’s goals. Thus, in this project architectural thought and action were focused on the individual decision and the respective justification in a given situation rather than on the codified architectural rules. However, discussing the individual decisions fosters the understanding of the various and possibly conflicting perspectives of the involved parties. It also fosters the conscious and deliberate decision-taking, since every decision potentially serves as the architectural standard in subsequent comparable situations. This decision focus is similar to the “case-law” in the US legal system, contrary to codified law, which is prevalent in European countries. Finally, the developed solution at Commerzbank, designed by the project team, serves as one of the best solutions in the market, but even more important as the gold standard within the organization itself.

Discussing success factors of architectural thinking at Commerzbank, stakeholders mentioned the definition of architectural thinking as an important goal. Thus, the restriction of conflicting goals, appropriate performance management and incentive systems, the involvement of long-term beneficiaries in the project as well as a shared mental model among stakeholders have become critical success factors; silo-mentality, unknown or ignored interrelations, locally focused performance indicators, missing boundary spanners such as architects, and “content-free” project manages whose involvement ends with the project, were characterized as major challenges in this context.

4 Discussion

In Sect. 2 we introduced the currently scarce and abstract concepts of architectural thinking. In Sect. 3 we presented case data concerning the topic of architectural thinking aimed at contrasting the abstract concepts. Here we discuss how architectural thinking was applied in the described project, aimed at answering the research question, what the constituents of architectural thinking in practice are. Therefore we employ the conceptual lens codified in Tables 1 and 2 in order to analyze the empirical data. The results of this analysis and the answer to our research question are summarized in Table 3.

Table 3. Architectural thinking and the case study findings
Full size table

One of the most important determinants of architectural thinking is the ownership of architectural considerations by all stakeholders in the project. This is given in the case described above—the sponsor is as much involved in architectural considerations as the individual project members, and can therefore improve the architectural rules by providing better ones.

Concerning the hosting organizational unit, architectural thinking was rather hosted in the program management than in the involved business lines. This might be an intermediary step of introducing architectural thinking. Program management is more often regarded closer to the business units than the EAM function. However, a high degree of architectural thinking would even further include business units.

Individual decision-makers have been identified as the addressed stakeholders. As described earlier, they had the opportunity and responsibility to participate in the architecture process and were encouraged to contribute their ideas.

The provided benefits were discovered to exist both locally and globally, i.e., enterprise-wide. Concerning the first dimension, the architecture guidance has proven to be a useful instrument to achieve local projects goals. Globally, the overall solution was successfully delivered, too.

The threat for a beneficial realization is a local project architecture that does not deliver the nucleus for further projects and thus, limits the overall impact to a local solution.

The method was strongly influenced by the EAM experts. Guidelines were collected and managed in order to achieve a business-driven design. However, all the goals, rules, and rationales are formulated in a non-architect-language, i.e., using the vocabulary of the project’s sponsors.

Another newly discovered aspect complements the findings by Winter [15] and others. While traditional EAM oftentimes performs governance by stating rules or principles as well as by enforcing a project’s compliance, architectural thinking in the presented case focuses on the consensus for each decision and thus establishes case-law thinking. Such a philosophy is much more flexible in adapting to new situations, stakeholder requirements and benefits, since the actual context of the decision is well documented.

Similar results are found regarding the adoption challenges for architectural thinking. Table 3 lists the specific implementations of adoption mechanisms discussed in [15, 20] for the presented project. However, beyond the “softer” factors described by Winter [15] the case data also delivers examples for the more formal mechanisms of governance and rule enforcement as such described by Weiss et al. [20]. These governance mechanisms, however, are no classical EAM governance mechanisms like project proposal or milestone reviews for architectural compliance. Instead, the processes of decision-making and the role of decisions are established and fostered in governance mechanisms.

Summarizing our analysis leaves the specific project reported herewith most characteristics of architectural thinking and challenges for adopting architectural thinking being addressed. In addition, we find a new characteristic that has not yet been described in architectural thinking literature. Although the project has been set up with the general idea of architectural thinking in mind, it did not follow any blueprint of architectural thinking. Therefore, the project can only partially serve as a demonstration or even an evaluation of the architectural thinking paradigm. It is rather a case that reflects the abstract concepts of architectural thinking. Also, the intended dimensions of architectural thinking, i.e., to reach “that other 90 %” of an organization that are not related to IT [13] are not met by the case. Rather the project represents a sandbox for architectural thinking. In fact, it is much easier to establish architectural thinking in a team of 150 project members, sharing an overall project goal, than in an entire organization where the overall goals and the individuals’ goal contributions might be much less recognizable. Given the limits of effectiveness of traditional EAM and the proposed approaches of architectural thinking, the case data nevertheless deliver an encouraging statement for following this research avenue.

5 Conclusion

In this paper we illustrate the concept of architectural thinking, which aims at reaching “that other 90 %” of an organization that classical EAM does not reach, with empirical cases study data. Therefore we contribute practical implementation exemplars of architectural thinking beyond the abstract definitions of architectural thinking proposed in academic literature so far. We find all of the dimensions and challenges mentioned in literature to be applicable in practice.