Keywords

1 Introduction

A major concern for IT managers during the last few decades has been business-IT alignment [1, 2]. The emergence of the global and increasingly complex organizational environments has entailed a wider use of decentralized structures within them. Decentralization allows organizations to encounter some of the past decade’s most important business concerns, including cost reduction, productivity, agility, and time to market [3]. However, the alignment can become increasingly difficult when utilizing a decentralized structure due to the decision-power being pushed out into the organization, increasing the challenge of moving in a unanimous direction [4, 5]. Research has shown that an organization with effective alignment between business and IT outperform non-aligned organizations in both turnover and growth [2, 6, 7].

To solve the alignment problems, there are multiple theoretical approaches available. Earlier research has presented approaches such as developing a digital business strategy [6, 8], following IT governance models [9], and implementing enterprise architecture frameworks [7]. Enterprise Architecture (EA) is a comprehensive framework that links an enterprise’s main components, e.g. business strategy and goals, processes, information systems and infrastructure [10], providing a holistic, model-based blueprint of the enterprise. EA frameworks used in today’s organizations are mostly The Open Group Framework (TOGAF) [11], Federal Enterprise Architecture (FEA) [12], Department of Defense Architecture Framework (DoDAF) [13], British Ministry of Defense Architecture Framework (MODAF) [14], and NATO Architecture Framework (NAF) [15]. Sandkuhl et al. [16] mention that TOGAF is more widely used across multiple branches than the other frameworks previously named. According to The Open Group’s blog [17], the amount of TOGAF certified people across the globe has now exceeded 60 000, compared to 7000 the year 2011 and 13 000 during the year 2013 which gives an indication of its fast-paced growth.

By combining business strategy and goals, processes, and information systems in an enterprise and not solely focusing on specific aspects (such as strategy or IT governance), it should be possible to solve the business-IT alignment problem. However, previous research has shown that there are discrepancies between the EA and its possibility to solve major CIO concerns, such as decision support for issues related to the IT organization and estimating and managing costs [18]. Furthermore, Speckert et al. [19], argue that EA frameworks do not support decentralized organizational structures. Combined with [20] stating that the frameworks were initially developed focusing on a centralization of IT and management; it entails an emergence of problems such as governance and decision-making irregularities in decentralized organizations.

The paper presents a case study research conducted in a large Swedish company in the real estate business domain. The research critically analyzed TOGAF and the way of working in the organization. Using the elicited knowledge, it attempted to highlight insufficiencies of TOGAF in contrast to the identified federated structural aspects of the organization, and suggest potential improvements. The results should facilitate further harmonization between EA and federated organizations as well as it should increase the business-IT alignment of organizations with similar characteristics.

The paper is organized as follows: Sect. 2 presents a brief overview of EA and TOGAF, different organization structures, and related works. Section 3 describes the organization of the case study, while Sect. 4 provides research results in details. Section 5 follows with a discussion of the results, and Sect. 6 provides concluding remarks as well as relevant directions for further research.

2 Background

2.1 EA, TOGAF

Situated at the level of an enterprise, EA regards an interconnected overarching set of methods, principles, and models utilized in the development and implementation of an enterprise’s organizational structure, business processes, information systems, and infrastructure, attempting to align business with IT [21]. Because developing an EA generates a significant number of architectural components, e.g. artefacts, dividing the EA into different architecture layers provides a structure among the components and reduces the number of elements residing in the same model. TOGAF is an EA framework created by The Open Group [22] defining a subset of architecture layers: Business Architecture; Information System Architecture (including Data- and Application Architecture); and Technology Architecture. Furthermore, the framework enables the inclusion of other architectural styles, such as Security Architecture and Service Oriented Architecture (SOA). TOGAF is divided into six parts, and each part is accounted for as a main component: Architecture Development Model (ADM), ADM Guidelines and Techniques, Architecture Content Framework, Enterprise Continuum and Tools, Reference Models and Architecture Capability Framework. Below we describe the framework’s essences relevant for the results of the study.

ADM describes a process for developing and managing the TOGAF core [11]; the process is repeatable and an iterative cycle for building and transforming the organization. Figure 1 below visualizes the ADM process, with the circles representing the main phases A-H and a continuous Requirements Management phase, and the arrows representing the flow of artefacts between the phases.

Fig. 1.
figure 1

TOGAF’s ADM process (left) and Architecture Governance Framework [11]

Full size image

Architecture Capability Framework presents support to establish, operate and control at the enterprise level the architecture function according to the organization structure, business processes, roles, responsibilities, and skills, controlled at the enterprise level [11]. Two vital concepts involving the implementation, development, and governance of the EA, is Architecture Governance and Architecture Board, both positioned in the Architecture Capability Framework. The concept of Architecture Governance [11, Chap. 50] includes a framework and guidelines regarding architecture governance. TOGAF suggests that architecture governance could be practiced in four separate domains, including corporate, technology, IT, and architecture governance. In turn, each domain and their area of responsibility may exist in multiple levels within the whole enterprise. The Architecture Governance Framework is shown in Fig. 1.

To increase the success rate of architecture’s governance, TOGAF suggests the implementation of an Architecture Board. The concept of Architecture Board [11, Chap. 47] refers to a cross-organization group overseeing the implementation of the architecture strategy. Its main responsibilities include providing the basis for all decision-making regarding the various architectures, enforcing architecture compliance, and ensuring compliance and adherence with specified Architecture Contracts, which details joint requirements regarding the architectures. TOGAF suggests that the Architecture Board should consist of four or five members.

2.2 Organizational Structure

Enterprise activities are often grouped into subdivisions - departments, such as marketing, sales, manufacturing. The capabilities, responsibilities, and interconnection of the various subdivisions are defined in enterprise’s organizational structure referring to the formal configuration between individuals and groups regarding the allocation of tasks, responsibilities, and authority within the organization [23, p. 1]. Furthermore, [24, p. 451] states that organizational structure shapes an ecology of distinct frames that exist at the level of organizational subunits. Organizations can be distinguished from a few different dimensions [23], where the relevant for this study is The Type of Decentralization, referring to where decisions in the organization are conducted.

Deciding upon the degree of decentralization in an organization can be a difficult task. Typically, different organizations, although facing similar conditions and environment, will choose different settings of decentralization, as described in [25]. In Fig. 2, three main kinds of organizational structures are visualized, including (a) Centralized, (b) Federated, and (c) Decentralized. The circle shaped forms in the figure represent various subunits of the organization, and the archs refer to the steering forces of decision-making power and authority.

Fig. 2.
figure 2

Three types of organizational structure

Full size image

A centralized structure induces that the steering forces flow from a center unit towards the various subunits, and with a decision-making process where all authority and power resides within one center, e.g. a top management group or one specific individual, providing a tight type of structure with increased coordination and supervision [26]. A federated structure, similarly to the centralized approach, contains a center; however, the steering forces between the center and subunits are bidirectional and exist between the subunits, making the central unit informal. A federated structure consists of multiple (semi-)autonomous subunits sharing a common mission and purpose. Usually, the subunits together share the control of the central body, and each subunit enters the larger association voluntarily. A decentralized structure contains no central unit, i.e. authority and decision power are shared among organizational subunits [26].

Utilizing a centralized structure implies that all decisions are founded on knowledge relying on the central unit. However, by moving towards a more decentralized approach, decisions can be made by people with increased knowledge regarding the specific area of business. Decentralization suits situations when sufficient knowledge to support the decision-making process is too cumbersome to transfer or when cognitive limitations exist in the central unit. Furthermore, decentralization enables quicker adoption to local dynamic environments by reducing steps in the decision-making process, and it contributes to stimulating creativity and innovation [26]. According to [27], a trade-off exists between knowledge transfer costs and control costs. Larger organizations with expanding potential facing volatile and unstable environments tend to generate more specialized knowledge that is increasingly difficult to transfer to decision makers, thus making decentralization a more appropriate approach. Furthermore, according to [25], a more decentralized structure induces better alignment between the subunits’ ideas and their environment, although at the cost of reduced learning and improvement between subunits.

2.3 Related Work

A significant amount of research has been conducted in the area of business-IT alignment and EA, however, the articles related in the same context as ours – decentralization issue, are very few. [27] emphasizes that the frameworks were initially developed focusing on a centralization of IT and central management, entailing emergence of problems such as governance and decision-making irregularities due to the characteristics of non-centralized organizations. In an article by Lindström et al. [18], a survey was conducted concluding that the available EA frameworks fulfill the needs and solve problems in theory, but when compared to actual practical problems, there are discrepancies. The survey indicated that the major concerns of Chief Information Officers (CIOs) in Sweden are to decrease the cost of business-related elements e.g. personnel, increase the interplay between the IT and business parts of the organization, provide technological solutions supporting the business part of the organization, and improve the quality of IT systems along with decreasing the costs of IT related elements. The survey revealed that some of the available EA frameworks provide insufficient support to solve the top concerns of the CIOs, and the authors suggested further harmonization between the concerns and EA framework’s foci is needed. Similar conclusions were derived in [16, 17] stating that discrepancies between TOGAF and the federated organizational structure exist. Speckert et al. [19] addressed the challenge of EA for decentralized organizations by investigating and concluding that commonly utilized EA frameworks need to be extended to support such organizations (included even FEA, which despite the recognition of individual units prescribes standards that are to be followed throughout the organization limiting thus flexibility and opinions of the units). However, as for the aspect of solving the identified problems, the results of this paper differ. [19] suggests a more theoretical solution, by utilizing peer production in the matters of decision making and governance within EA. The developed artefact of this study is closer aligned to the practical operational conduct of federated organizations and thus in more depth reflecting the characteristics of such organizations. Therefore, the results comprise increased alignment between EA, in particular TOGAF, and federated organization’s actual way of working.

3 Business Case

The business case regards a federated Swedish organization concerned in developing, building and managing real estate. The organization consists of multiple semi- autonomous subunits. They are autonomous in the sense of having their customer base, deciding upon what services they provide, and having full ownership of their economy (Fig. 2). 28 federated units share a common mission and a purpose defined at a national level. The enterprise is owned by its members and can be split into two parts, national level, and regional level (Fig. 3).

Fig. 3.
figure 3

The organizational structure of the enterprise

Full size image

At the regional level, the core business is executed. The autonomous subunits own the deliverables and the results that are produced. To be a member of the enterprise/federation organization, a membership is needed, as well as compliance with company’s regulations. The structure and operational concepts deciding how the subunits conduct and manage their internal business is solely decided upon within each subunit without the interference of external actors.

At the national level, there exists coordinating and supporting functions. The National Association is the owner of the company brand and it is responsible for the company’s vision, public appearances that regard national statements, as well as all political involvement. AFS is the internal business support organization (swe. Affärsstöd) merging the IT infrastructure and digital services of the federated organization into one company to achieve synergy effects. This for example implies that different IT functions already existing within the federated organization have been combined into one starting thus to provide a centralized IT service. AFS works with joint processes and approaches that the subunits within the federated organization decide upon. Based on the needs of the federated organization, new solutions are developed with the goal to be competitive as well as customized towards the federated subunits’ needs. This implies that all necessary joint solutions, whether they are IT- or business oriented, are developed, delivered and maintained by AFS. However, being autonomous, it is not mandatory for any subunit of the federated organization to purchase joint solutions.

Merging of multiple processes and infrastructure into one has entailed several problems. AFS has centralized the IT infrastructure, while applications and IT decisions are still decentralized. Business needs in the federated organization are identified through a longer development process, which increases the time to market and decision-making times. The CIO of AFS has therefore requested an analysis of how the concept of EA, and more specifically TOGAF, could solve important practical problems within the organization such as lack of integration schemes, guidelines regarding data-handling, architectural and platform documentation, and other, while at the same time fully adhering to the established federated structure and way of working.

4 Case Study Results

4.1 Data Collection and Analysis

The case study combined document-readings (internal-business) and semi-structured interviews as the main data collection methods. To analyze the way of working through the interviews, it was necessary to determine a representative sampling. Since the organization is well known to one of the authors, the purposive sampling was used, i.e. the respondents were picked according to their knowledge regarding the organization and its operations. The employees positioned as either chief of a business unit or supporting functions were deemed to have extensive knowledge concerning the organization, and thus they were able to provide adequate insights and information. Data collection and sampling were conducted until theoretical saturation was reached, i.e. when the analysis of new data solely contributed to the confirmation of previously derived insights, which was achieved after 8 interviews.

The analysis has resulted in a thematic map consisting of the key concepts reflecting the federated organization’s ways of working (Fig. 4).

Fig. 4.
figure 4

Thematic map from the study analysis

Full size image

Subunit.

The federated organization consists of multiple subunits. The subunits are fully autonomous economic powers in charge of day-to-day operations, inferring a complete control and decision mandate, except for certain guidelines and policies specified on the national level. Induced by the autonomous nature of the subunits, the federated organization lacks a joint business strategy. The concept denoted Characteristics is coupled to every Subunit and influence its Needs. Some examples of Characteristics is the size (number of employees), turnaround, economic strength, amount of members/customers, business units, way of working, local competition. Various characteristics infer different needs, such as larger subunits having an expanded need for automation due to the increased demand for employees in non-automated processes. The subunits of the federated organization have different needs, which can be either unique or shared with other subunits. The subunits desire to have their needs solved by joint solutions, but not all unique needs in a subunit can be addressed, inducing complications for the subunits and the federation. Furthermore, investing in information systems is expensive, and the subunits will not survive the market competition if they keep moving in separate directions. Developing joint solutions that work for all subunits is more efficient. To gather the proposals for the development of joint solutions and to allow each subunit to voice their opinion, the federated organization has developed and implemented a way of working, further described as Business Governing.

Business governing.

The concept embraces the way of taking federated business decisions by combining Networks, Steering Committees and Board. The business governing function in the federated organization embraces all matters, whether they are IT-related or business-related. The business decisions are empowered, either through AFS that develops IT solutions to support the business, or through the networks handling strictly business-oriented matters, such as policy updates. Each core business area within the federated organization has its own Network. The networks are populated by representatives from the subunits working in the relevant business areas. By introducing the concept of networks, the federated organization has simplified the subunits possibility to voice their opinion and to further increase the anchoring of proposed ideas, boosting the persuasive force of steering in a common direction. The concept of network acts as an interface towards the subunits to ensure their possibility to fulfill their democratic rights. The Steering Committee is democratically chosen and populated directly from the network representatives. By further aggregating the networks into smaller groups, proposals can be prioritized and discussed in a democratic matter, while also reducing the number of stakeholders involved, which could otherwise distort the attention towards the holistic progress of the federated organization. The steering committees could be described as filters percolating the proposals and forwarding prioritized proposals to the board. The Board is populated by business manager representatives from the subunits. The board’s task is to assess the proposals received from the steering committee. In the assessment process, the board will check adherence with the federated organization deciding whether the proposal would induce a positive or negative outcome not solely for individual subunits. An idea assessed and accepted by the board will eventually lead to development.

Development.

The development of common solutions within the federated organization entails multiple constraints, problems, and considerations. The various Characteristics and Needs of the individual Subunits and the great span of differentiation among them produce a challenging way of creating common solutions, as it requires various reorganizations in the subunits and control over employees, process descriptions, which is a big job especially for larger subunits. The maturity level regarding the subunits ability to receive and utilize solutions further infers problems to the development process, as although subunits may require the specific common solutions, their ability to receive and utilize it correctly could be cumbersome. Furthermore, multiple subunits possess existing individual solutions, which affect the outcome and their interest in newly developed common solutions. Additionally, a major concern regarding the development process involves financing, as it is voluntary for the individual subunits to participate and purchase the common solutions. The development phase is initiated by a pilot study, which involves a group of subunit business representatives deemed as experts within their respective fields. The finalized pilot study suggests a solution (whether the solution is bought on the market or self-developed) with complete pricing including user-support, system administration, future adjustments, etc. AFS presents the solution to all the subunits, which then have a choice to buy the solution, or not. In the development process, when attempting to solve a common need shared throughout the whole company, a lack of requirements exists. Often, subunits, as well as AFS, will have separate information systems that need to be integrated with the new joint solution. There is an identified discrepancy between the documentation of requirements from the development unit that eventually hands over the responsibility to the IT governance unit, causing an inadequate and complicated workflow.

Change.

The Change represents how the development of joint solutions affects the subunits and federation. The subunits’ capability to receive created joint solutions greatly varies, inducing implications in the implementation process, i.e. how receivable the change is in the specific subunit. This is due to the subunits’ different existing solutions, maturity levels (resource pool, commitment, knowledge, etc.), local strategies, and characteristics. Hence, change management is of great importance and it can become a major concern for producing desired outcomes of the common solutions. Furthermore, it is of great importance to persuade as many subunits as possible with the necessity for change in order to decrease the overall costs and simplify future development.

4.2 Business Case and TOGAF

In this section, the derived and analyzed way of working in the federated organization is compared to relevant propositions and concepts from TOGAF. The ADM process is the heart of TOGAF, providing a method for developing and managing the EA lifecycle. However, due to the generic level of the ADM process and its main components such as Architecture Capability Framework being in the focus of this study, i.e. their insufficiencies in the support, TOGAF lacks customization towards organizations of various structures, such as federated organizations.

According to the Architecture Governance, the successfulness of the architecture function requires certain organizational structures, processes, roles, and responsibilities. The organizational structures and roles are clearly defined within the ramification of a centralized organization. However, TOGAF provides less or nearly no support regarding decision-making power and mandate to organizational structures not utilizing a centralized, hierarchical structure.

Set in contrast to the federated organization’s way of working, some areas of concern can be identified. In the federated organization, the concept of an enterprise-wide control system trying to control adherence to the common strategy, would be neglected due to the autonomous nature of the subunits and the fact that no party within the federated organization could possibly hold that type of mandate. Requirements produced within the federated organization require increased involvement of subunits in order to boost the anchoring, such as IT-security aspects for example. The Requirement Managements phase is a major component inside the ADM process. Its main objective is to ensure that requirements are available and managed throughout the whole ADM process and all of its relevant phases. However, TOGAF does not mention within the different phases how the requirements should be collected and prioritized except that the prioritization should be conducted according to the architecture vision.

The concept of Architecture Board is according to TOGAF a key success factor of Architecture’s governance. Compared to the federated organization’s way of working, multiple concerns can be identified. The suggested size of 4–5 members, would neglect the subunits’ possibility to voice their opinion, as 10 members would not be able to handle a large quantity of subunits, inducing a decreased level of anchoring regarding proposals. Furthermore, as the Architecture Board is a major part of the Architecture Governance, and the fact that it should act as a top management type of group controlling adherence and compliance regarding the EA, it would be neglected in the federated organization due the autonomous state of the subunits. Furthermore, controlling adherence to the architecture vision could be problematic, as there is no authority holding the ability to supervise the subunits’ actions.

Considering the concepts of Change and Development derived in the analysis of the interviews in comparison to the proposed relevant concepts of TOGAF, the identified problems involves the areas of governing and decision-making. The proposed relevant areas regarding change and development in TOGAF, stating what is needed to solve the practical problems of an organization, such as documentation and integration, is deemed appropriate for various organizational structures. However, the areas of how it should be implemented and maintained could become problematic, as mentioned previously in this section. As mentioned controlling adherence to the architecture vision could be problematic, as there is no authority holding the ability to supervise the subunits’ actions.

Concluding, a gap exists between TOGAF’s proposal for having a governing body (architecture board, architecture governance), and the ability for a federated organization to have a governing body that is formed according to the TOGAF documentation. TOGAF does not provide necessary details to support federated organizations. Any provided guideline or examples involve a centralized way of working, such as illustrated Architecture Governance and Architecture Board. From an enterprise-wide organizational viewpoint, this approach of working is not feasible nor supportive to a federated organization.

4.3 Proposal

The main requirement of the proposed solution is to support federated organizations to implement and maintain an EA such as TOGAF by adding an extension according to the specifics of the federated organizational structure characteristics as it is earlier described. Two main alternatives excelled from the generated ideas that were discussed:

Alternative 1: Design an entity (conceptual) model representing an organizational structure that will serve as an alternative to the Architecture Board, i.e. an extension to the Architecture Capability Framework [11, Chap. 45]. The organizational structure will provide guidelines to the decision and governing aspects of an EA, and support the implementation and maintenance of an EA in federated environments.

Alternative 2: Design a method for supporting an organizational structure change in the federated organizations using TOGAF. The artefact would provide guidelines on how the federated organization should restructure in order to adhere to the concepts of TOGAF, and thus enable a successful transition into utilizing the framework.

Selecting alternative 2 would result in an organization-specific solution, requiring possibly major restructuring within the enterprise, which in turn would substantially affect the organization’s way of working. In addition, the foundation of the enterprise is of greater importance than any framework, as it has been developed and refined over a significant period. The selection of alternative 1 is further validated by the fact that it would result in a more generalized solution, i.e. trying to fit TOGAF onto the organization rather than the opposite. The resulting conceptual model will contribute to federated organizations’ ability to adhere and include all relevant subunits, allowing increased anchoring of proposals throughout the whole enterprise.

In Fig. 5, the proposed solution (artefact) of alternative 1 is presented. The circles of the figure represent the entities of the model. The cardinality of the specific entity is inferred by the amount of circles, i.e. multiple circles imply a higher quantity of the entity. The arrows in Fig. 5 refer to how the various entities are related.

Fig. 5.
figure 5

The proposed artefact – an extension to support federated organizations

Full size image

The Subunits are completely autonomous and control day-to-day operations. They generate their own revenue, and are enabled to produce ideas commonly influenced by specific needs and characteristics for new developments. The Network is populated by representatives from the Subunits. Each core business area within the federated organization has its own Network. The Steering Committee is democratically chosen from the Network, by the Network representatives, in order to prioritize the ideas. The Board consists of business manager representatives from the Subunits in order to accept or decline ideas imparted from the Steering Committees.

In the model, subunits influence all aspects of business development. The subunits populate the networks, which in turn populate the steering committees. Furthermore, the subunits also populate the board. The selection of representatives for the steering committee is performed utilizing a democratic process, while each subunit decides on their representative on their own. By involving the subunits in every area and aspect of the decision making process, an increased anchoring of proposals can be reached. Increased anchoring and subunit involvement provides greater possibility of convincing subunits to steer in a common direction, benefiting the federated organization as a whole.

The proposed model can be positioned as an extension within the Architecture Governance Framework (Fig. 1, right). The governance framework is a part of the overarching Architecture Capability Framework, which is an integral part of successfully operating an architecture function within the enterprise. As an extension of the Architecture Governance Framework, the artefact will be seen as an alternative solution, replacing the CIO/CTO function and the Architecture Board. The artefact is not contradicting or refining any other concepts proposed in TOGAF; in the ADM process or the content meta-model.

5 Discussion of Results

In this section, an example of a theoretical case utilizing the designed and developed artefact will be compared to the current TOGAF recommendations. The theoretical case starts with the emergence of multiple needs in the subunits of a federated organization, and ends with an enterprise-wide impact. In Table 1, the managing of the needs by TOGAF and the proposed solution is presented.

Table 1. Theoretical case comparison
Full size table

The main goal of implementing a framework such as TOGAF is to optimize an enterprise’s capability to support change and to increase the successfulness in delivering business strategy. Its popularity on the market is a sign that it supports that capability. However, while using examples of typical centralized organizational structures and the broad generalization given in the framework, it needs to be expanded to giving examples for other organizational structures. In organizations that are not centrally controlled, the decision mandate of what and how something should be done cannot be given to only one group. The solution that is proposed should be seen as an extension or alternative to TOGAF’s Architecture Board [11], and as such will affect the Architecture Governance and Requirements Management.

The problem is not unique to the examined organization’s domain. There are multiple businesses in Sweden, both public and private, facing the same governance and alignment problems. The decision rights are decentralized while the IT is attempting to be centralized and the whole organization uses a federated structure. One could always argue that all companies are unique depending on the granularity. However, this study approaches the federated characteristics and business procedures with a holistic view. Thus, this proposal is a representative for generalization towards larger federated organizations.

6 Concluding Remarks

The paper presented a case study research conducted in a large Swedish company in the real estate business domain. It contrasted TOGAF’s concepts and methods related to governance with the way of working in the federated organization of the case study. Using the elicited knowledge from organization’s experts, it emphasized insufficiencies of TOGAF to support the identified federated structural aspects of the organization, and suggest potential improvements. In particular, the concepts regarding governing and decision making in TOGAF, including but not limited to Architecture Governance, Architecture Board, and Requirements Management, would be neglected in a federated organization due to the autonomous state and quantity of various subunits.

The resulting solution, with similar areas of impact as the Architecture Board proposed by TOGAF, is aimed to act as a support to guide federated organizations when implementing and maintaining an EA, such as TOGAF. By ensuring the involvement of all relevant subunits, and further increasing the anchoring of proposals throughout the organization, the artefact could increase the alignment between business and IT.

The presented solution should be of a particular interest for the case organization, as it was produced utilizing its own structure and the way of working as a model. Large federated organizations would also benefit from the result as it could provide guidance and increased success rate when implementing TOGAF.

To further confirm the validity and control the functionality of the presented solution, it should be tested in an actual practical case involving a federated organization and their implementation of TOGAF. Secondly, as the artefact was derived utilizing only one specific federated organization, future research should involve multiple federated organizations in order to increase the credibility of the results and to further contribute to an increasingly generalized conclusion. Thirdly, as this research involved a federated organization not utilizing TOGAF, it would be of interest to analyze a federated organization working with TOGAF to identify concrete practical problems in their day-to-day business. The focus towards TOGAF can be a hindrance when researching concerns that focus on organizational forms and concepts. Finally, a research direction of interest includes analysis for supporting customers’ preferences [28] in different organizational forms.