Abstract
Enterprise architecture (EA) has been embraced by governments as an instrument to advance their e-government efforts, create coherence, and improve interoperability. EA is often viewed as a codified understanding covering elements ranging from organization till infrastructure. It is aimed at closing the gap between high-level policies of organizations and low-level implementations of information systems. Important elements of EA are a framework, tools, principles, patterns, basic facilities, and shared services. EA is influenced by the social interdependencies and interactions among stakeholders in which it is embedded. The survey among public organizations shows that current EAs are primarily product oriented, whereas sociopolitical aspects are often neglected. Architecture implementation also involves learning effects and requires effective communication among participants. The author argue that the architecture concept should be reconceptualized and can only be effective if they incorporate relational capabilities, clear responsibilities, and sound governance mechanisms.
Keywords
Introduction
The need for EA is founded in fragmentation that takes place on several levels within government. First of all, highly fragmented, heterogeneous, and unrelated software applications are used. Second, the development of data sets is often carried out in isolation without regarding integration and the interoperability among data is poorly managed. Finally, related and organizational units that have many isolated yet overlapping functions usually take their decisions independently without looking at the large impact. Motivated by an increasing complexity and size of information systems, Zachman (1987) introduced the concept of information architecture for business. Nowadays this is often denoted as enterprise architecture (EA) to refer to the enterprise-wide scope of the efforts. Within the public sector, EA (or Government Enterprise Architecture) has been heralded as an instrument to progress e-government. EA is not limited to e-government and is about the strategic shaping of information systems and supports the alignment of strategic objectives with information technology (IT) by ensuring coherence among the elements. The EA provides a long-term view of a company’s processes, systems, and technology and can be viewed as a kind of destination plan (Ross, Weill, & Robertson, 2006).
EA is still a challenging concept as there are many conceptions and a variety of definitions (e.g., Architecture Working Group, 2000; Doucet, Gøtze, Saha, & Bernard, 2008; Janssen & Verbraeck, 2005; Ross, 2003; Schekkerman, 2003) that hinder a uniform view. Generically, architecture is the description and prescription of a set of elements and the relationships between them. The common element in these definitions is that EA refers to a blueprint described at a certain level of abstraction. Whereas another way of looking at EA is as a means to inform, guide, direct, and constrain the decisions taken by human beings within organizations. EA can improve interoperability, but it can also contribute to other objectives at the same time. The underlying vision on EA is that it will give insight into the opportunities and limitations provided by the ICT landscape and can serve as a vehicle for development.
In contrast to the promises of EA, reality often shows the opposite; organizations are struggling to understand their ICT landscape and to get control over it so they can lead it in the right direction. The transition toward the digital area requires organizational and institutional transformations (Gascó, 2003). Despite the focus on transformation and organization, EA is predominantly viewed as a product (Schekkerman, 2003), there are some expectations that take the social network (Dreyfus & Iyer, 2007), governance (Janssen & Hjort-Madsen, 2007) or institutional aspects (Hjort-Madsen, 2007) into account. Despite these attempts, the architectural products (artifacts such as the frameworks, principles, and tools) have been in the center of attention, rather than the sociopolitical aspects of EA. Although the focus often lies on EA as a technical instrument, the goals and scope of EA are often organizational in nature. This article aims at widening the view on EA by investigating the sociopolitical aspects of EA.
EA Objectives, Products, and Governance
Architecture Objectives
EA can be viewed as an instrument or tool for enabling interoperability. Interoperability is a multifaceted concept and refers to the ability to let independent systems communicate and exchange information with each other (Scholl & Klischewski, 2007). Yet EA can support a broader range of objectives and typically goes beyond the interoperability aspect and also influences decision making on all kinds of aspects (which might ultimately influence interoperability). While interoperability approaches typically consider systems as a black box by looking at the interfaces and external visible behavior and providing meta-models, EA also aims at influencing the internal design of systems. In the black-box approach, knowledge about the system design decisions and internal operations is not required. In contrast, EA opens the black box and also guides the design and looks for coherency among element to ensure coordinated decision making. The latter should, for example, ensure reuse of components and design patterns and at the same time limit the skills, expertise, and competences and efforts needed for control and maintenance. The use of EA should result in independent components that are interoperable and, if orchestrated properly, can operate in concert and at the same time are future proof.
It has been recognized that EA can serve a multitude of purposes, including communication, evaluation, design, and redesign instrument (Bharosa, Janssen, & Wagenaar, 2007). Table 1 provides an overview of the typical goals of EA as found in the literature. This table shows the variety of objectives and emphasizes that are possible. EA objectives might be overlapping or conflicting to some extent and shifting over time. For example, having modular components is useful for decomposing complexity; enabling the reuse in many processes, reconfiguration and composition, but is more difficult for accomplishing interoperability. This should result in the creation of flexible and agile enterprises. Over time there has been a shift in the focus of EA efforts. Whereas initially the goals were focused on dealing with the complexity and ensuring that silos can be connected, over time goals like agility and flexibility have become more important. Having multiple and conflicting objectives adds to the overall complexity and to the multitude views on EA.
Overview of Enterprise Architecture (EA) Goals
Simply stated, the ideal of EA is to have a coherent landscape that can be easily adapted, is efficient, and is continuously aligned with the strategic objectives. Reality is more stubborn as realizing objectives might be more difficult and more costly than anticipated. Furthermore, there are complaints that EA is merely a tool of the IT department instead of the management.
EA as Product
Motivated by an increasing complexity and size of information systems, Zachman (1987) introduced architecture and completed it 5 years later (Sowa & Zachman, 1992). Zachman’s article was the response to the needs of his IBM clients that had requirements for data standards and information sharing strategies across several systems. Their main contribution is the development of a framework consisting of a two-dimensional classification matrix in which the rows represent particular stakeholder views and the column the viewpoints ranging from higher to lower abstraction levels. A framework defines and interrelates the various elements from multiple stakeholders’ view. In EA, the use of frameworks has been given much attention and a variety can be found (Guijarro, 2007; Peristera & Tarabanis, 2000), although many of them cannot be qualified as architecture frameworks. The enterprise framework concept, in general terms, specifies how IT is related to the overall business processes and outcomes of organizations, describing relationships among technical, organizational, and institutional components of the enterprise. This view on EA is expressed by providing codified understanding of elements. An Enterprise Architecture Framework (EAF) often is a matrix that visualizes the relationship between the various elements in each domain. Despite the importance of these interrelationships, the main focus is on the elements and the relationships among the elements are often given limited attention. The relationship between EA and interoperability frameworks is confusing. On one hand, one part of an EAF might be focused on interoperability, while on the other hand an interoperability framework can be viewed as a type of EAF. EAF are often supported by all kinds of tools that help to create and main the enterprise models.
To give direction to the development and in view of the many stakeholders and the complexity of these frameworks, principles have gained the attention to guide EA efforts (Richardson, Jackson, & Dickson, 1990). Ideally, principles should reflect the strategy of a organization in such a manner that it is unrelated to the specific technology or persons (Perks & Beveridge, 2002). Principles emphasize “doing the right thing” but they do not suggest what means should be used to accomplish this goal. From a policy view, principles can emphasize certain decisions like the preference for open source software.
In a similar vein, patterns can be often part of EA and are able at directing design (Fowler, 2002). Whereas principles are high level and contain policy choices, patterns provide practices that can be reused by others. These patterns can typically speed up the development process by avoiding that developers need to find their own solutions. Furthermore on the long term, this can contribute to lower control and maintenance costs.
Initially EA has been used as an instrument to ensure coherency and find similarities among elements. More recently building blocks and shared services have become part of the EA as they provide the infrastructure that can be reused when developing systems. A shared service can be defined as “the concentration of dispersed service provisioning activities in a single organizational entity” (Janssen, Joha, & Zuurmond, 2009, p. 16). This concept is based on the idea that basic services are developed and shared among the many governmental users to create new systems. Components can be software components, but also business processes or even complete organizational functions, often denoted as shared services. The main advantages are that organizations do not have to develop everything themselves but instead can reuse existing infrastructure elements. At the same time, a basic infrastructure stimulates standardization and ensures interoperability.
These developments resulted in the following important elements of EA as product:
Framework: description and prescription of the skeleton of the business and IT to guide its implementation.
Tools: Instrument supporting the creation and maintenance of architectures.
Principles: standards and policies directing the development and evolution over time. These principles can include any guidelines including best practices descriptions and implementations models.
Patterns: patterns that can be reused to solve commonly occurring problems.
Basic facilities and shared services: a set of reusable building blocks and services to develop new systems and guiding practices to use them.
In summary, EA vision is often presented at a high abstraction level to outline strategic directions. The architecture provides a kind of “skeleton” and destination plan. Working on a high level is often facilitated by architectural principles, and implementations are supported by infrastructure facilities, shared services offering standards.
Types of Architectures
There is a wide variety of different architectures. IT architects and managers used numerous proverbs in conjunction with the term “architecture.” These are often related to the focus of the architecture. An important distinction is the use of the start architecture and EA. Whereas EA refers to the organization as a whole, a start architecture refers to the initial architecture developed for a certain project or system. An EA actually emerges as a result of implementing individual projects.
Within governments, architectures can range from general architectures focusing on the government-as-a-whole to highly specific for a certain organization in one particular domain. We call the first type of architectures reference architectures to depict that they are used as a frame of references for organizational architecture and not limited to the scope of the enterprise (i.e., organization). An example of the latter is a EA for water management. In the Netherlands, the national reference architecture (NRA) is based on input from international standards and the European interoperability framework (EAF), although it should be noted that the Dutch national reference architecture was founded years before the EAF. Furthermore, whereas the NRA has a broader orientation, recently the focus has been narrowed to interoperability to give more freedom to other types of domain architectures. Whereas there is only one national architecture, there are various architectures for specific domains and many organizational architectures, as visualized in Figure 1 . In the ideal situation, the architectures of organizations are based on the domain architectures (if any), which in turn is based on the national architecture. Organizations might be directly deviated from the national architecture if no domain architecture is available. In practice this can be the case, as public organizations might have developed their architectures before the domain or national reference architecture was developed. Furthermore, organizations might want to deviate from the national or domain architectures to accommodate their unique characteristics better. The essence is that a large number of stakeholders are involved, all having their own concerns, and trying to influence the other levels.
Overview of types of EA in government. EA = enterprise architecture.
EA Governance
The many different architectures and multiple aims show that EA is part of a larger system influenced by policy makers at various levels in the government, ranging from central to the decentral level. EA efforts are as much organizational as technical. This observation has given rise to the embedding of EA in a sociopolitical landscape. Especially the objective of alignment and ensuring coherence among the aspects cannot merely be viewed from a product perspective. EA as a product assumes that the elements will be aligned and integrated without needing further coordination and negotiation among stakeholders. In this approach, alignment is often pursued by making models from a certain point of view and ensuring that these models fit with each other. In contrast, the sociopolitical perspective on EA looks at other elements like collaborating among stakeholders including aspects such as trust, goodwill, power, and mutual interests. EA is an activity in which many, diverse stakeholders are involved, all having their own objectives. Alignment and integration require understanding of each other’s needs and requirements that go beyond the definition of models at various levels. In the past, applications have been developed to function as stand-alone applications. These stovepipes need to be opened to share data, which requires investment. In parallel, the persons working in these stovepipes need to become aware of each other efforts and use EA as a boundary spamming tool to coordinate each other efforts.
A huge barrier to effective use of EA is the lack of understanding about how decisions are made, what processes are being implemented, and what the desired outcomes are. EA should be understandable by all stakeholders in order to make it work. The creation of a shared vision, communication among stakeholders, and evaluation of the impact seem to be crucial aspects. The governance of the relationship between the architects, who are primarily in charge of developing these building blocks and project managers, project architects, and others who are the intended users, is a main concern. Good relationships, feedback loops, and understanding is a key for effective use of EA. Enterprises generally design three kinds of governance mechanisms: (a) decision-making structures, (b) alignment processes, and (c) formal communications (Weill & Ross, 2005). The decision-making structures involve the committees and roles that are responsible for decision making. Alignment processes are the procedures and routines for securing and ensuring involvement in governance decisions and their implementation. Formal communications is about reaching effective IT governance, by ensuring two-way communication good participation/collaboration relationship between business, IT, and architects. For ensuring EA use and compliance with the architecture (as product), effective governance mechanisms are key.
Research Approach
Based on the background that is lined out above, a survey was developed to identify the aims of EA and the shift in the goals over time. The survey consisted of closed and open questions to increase our understanding of the use of EA to advance e-government effort to accomplish objectives. Both functional and social aspects were covered. All closed questions were asked for both the current as well as the desired situation. The questions were structured using the three areas (a) EA goals, (b) EA products, and (c) EA governance.
The survey was conducted in the Netherlands during the period from September to November 2009. In total 39 respondents were contacted including a mixture of organizational functions ranging from line management and decision makers to enterprise architects. Each respondent was first sent an invitation letter and background letter per e-mail. Thereafter the interviewees were contacted to make an appointment. Most of the respondents were interviewed during a face-to-face interview session lasting between 45 and 90 min. The others were contacted by telephone during an interview lasting between 10 and 25 min. The interviews by telephone were more focused on the closed questions, while in the face-to-face interviews more attention was given to the open-ended questions.
Findings
Inspired by the previous literature review, the first questions were aimed at understanding the EA goals in order to understand both the current objectives and the desired future objectives. Figure 2 shows the outcomes of these questions. According to the interviewees, enhancing interoperability and ensuring client orientation are the main goals in the current situation and remain the most important goals in the future. The results confirm our expectation that EA can serve a multitude of goals. In the future, the interviewees expect that other goals become as well as important and need to be supported by EA. Enhancing flexibility and agility, IT business alignment, supporting decision making, and enabling transformation are goals that are expected to become more important. This confirms the expectation that EA goals are dependent on the circumstances and context.
Current and desired goals.
In the future, the respondents expect that interoperability and client orientation keep their importance but they also envision a shift toward an emphasis on using EA as a pathway for developments, bridging the gap between IT and business and enabling transformation and public sector change. The latter confirms the current shift to transformational government (Irani, Elliman, & Jackson, 2007; Weerakkody & Dhillon, 2008).
Other types of goals were included as well. Often mentioned goals include ensuring organizational wide security and privacy. One of the interviewees mentioned that ensuring compliance with new and changing legislation was missing in the list of EA goals. This interviewee commented that this was related to flexibility and agility and ensuring compliance and adapting to the ever-changing regulations might become the main concern in the next years.
The next range of questions concerned questions about EA products. Figure 3 shows that EA principles and standards are the main instruments used in most organizations, closely followed by EA frameworks. Not all organizations have frameworks or want to adapt a framework. According to the interviewees, this decision is often related to the size of the organization and the importance that is given to architecture in an organization. The number of EA tools and the use of facilities and shared services as part of the EA efforts have been limited so far. The interviewees expect that EA tools use will rise and that shared services will be adapted as part of the architecture. Infrastructure facilities and shared services are viewed for the same purposes, the outsourcing of technology and even processes in order to focus on the core business. The expectation is that this will contribute to more efficiency and easier control and maintenance. This will save organizations from the burden to manage all technology in-house without having the risk of outsourcing to a software vendor.
Enterprise architecture products.
Figure 4 shows the current attention that has been given to the type of governance mechanism for directing EA by the respondents. Only formal communication is mentioned several times, whereas the other types of mechanisms are hardly used. It can be concluded that governance has not kept pace with the architecture developments. Whereas EA has matured, the architectural governance lags behind. This is confirmed by the statements during the interviewees. A number of interviewees commented on the lack of attention to the governance and relational aspects. One person stated “the most important aspects are neglected, the decision-makers and other users are not involved,” whereas another said “the paradox is that EA efforts are aimed at integrating the various organizational elements, whereas the architecture efforts are not integrated in the organization.” The comments of the interviewees raise the discussion about the effectiveness of EA. One person expressed this point of view as “EA is useless without good governance.”
Governance of enterprise architecture.
Discussion and Implications
The goals in literature and the results show that generally interoperability is viewed as one of the main goals of EA and it will remain one of the main goals. EA can have a large number of goals and can have various products and dimensions, which can explain the variety of views on the EA concept and the lack of consensus of a uniform definition. Architecture is often been given various meanings depending on it contextual usages or the specific purposes.
EA is a tool intended to generate value in a variety of areas. In this respect, architecture is viewed as an outcome or results that does what its designers intended and should generate the desired outcomes. This product view takes a mechanistic view on architecture, in which EA will automatically bring the desired value. The architects often adopt this perspective when developing an architecture. The product view is dominated by making blueprints, business cases, investment decisions, and outlining projects. It can be viewed as the rational view on IS value creation in which organizational efficiency and effectiveness are maximized (Kling, 1980).
The sociopolitical view is the contrasting view, in which architecture is viewed as emergent and shaped by the interactions among stakeholders. This view is characterized by a focus on the humans involved, the adoption of the EA and organizational working processes, and routines to accomplish the desired objectives. The accomplishment of the benefits is viewed as a goal that can only be achieved if the organizational staff adopts and accept the EA. The EA should be widely known by the organizational members. As such the adoption process influences the gaining of objectives. In this view, we argue that there is a need for reconceptualizing EA. Architecture implementation consists of social interactions resulting in the understanding and acceptance of the architecture by enabling mutual learning effects in which organizational members learn to understand, appreciate, and use the EA. Architectures are extended over lengthy periods of time and influenced by many factors. Building an architecture is not a single activity that has a clear beginning and end. EA is influenced by its use, as people using the EA interpret it, might extend it (i.e., domain or organizational architecture), provide feedback for improvement, and are involved in reviewing EA in this way influencing its shape. EA changes may be formally negotiated or just become a de facto practice as persons are using them in a certain way. EA might be interpreted by stakeholders in different ways to fit their own purposes. Over time architecture is shaped by a wide range of stakeholders, all exercising some influence. The shaping of EA is influenced by current trends (e.g., flexibility and agility) and movements (EA as nice-to-have or EA that one has to comply with) and the result of projects, which are used as feedback instrument to the EA (see Figure 1). Organization might promote certain trends, like the sharing of services, which in turn influence the EA. The bottom line is that EA is influenced by the social interdependencies and interactions among stakeholders in which it is embedded.
There is a need for governance structures and mechanisms through which stakeholder influence can be tunneled and understood. Stakeholders influencing the EA might do this informally or formally by employing decision-making procedures and routines. Although each stakeholder might be correct in pursuing certain objectives from their point of view, EA is aimed at meeting objectives for the organization a whole, which might need balancing the different interest in an integral way (e.g., openness or security). Despite giving directions to the decision making, EA should not become too stringent and it should provide some degrees of freedom for designers and implementers. EA is thus dependent on both the differentiation and the integration among the many stakeholders in the IT and business domain.
The pervasive role of EA is in communications instead of in outlining frameworks and blueprints. The interviewees indicated that successful architects spend a great deal of time on communication. One interviewee formulated that “their (architects) job is to explain what should be done to a wide variety of poorly informed people and to convince them that adherence will provide greater benefits.” Furthermore, the interviewees indicated that architecture should be embedded in the daily procedures and routines that everyone in the organizations knows. Taking a too narrow view and not involving governance aspects will not result in the accomplishment of the desired benefits. As such, there is a need for a shift toward a more relational and governance view on EA. Architects are largely dependent on others to accomplish the EA aims, which are often outside the (direct) hierarchical control and asks for a relational approach based on goodwill, mutual trust, and understanding.
One of the respondents stated that “effectiveness is determined by communication. Not by the instruments and frameworks, although these are necessary.” These kinds of approaches demands capabilities that go beyond the tool view. Capabilities have to be developed to address the relational challenges to ensure compliance with and the updating of the architecture. The key to relational capability is to ensure voluntary and collaborative behavior based on mutual trust and goodwill. Stakeholder participation should balance the IT and business involvement and ensure the resolving divergent perspectives and stakeholders conflicts. Relational capabilities should stress the shared learning and dialogues among all stakeholders. This should ensure that EA are understood and will be used.
Conclusion
EA is a way to progress e-government and interoperability in particular, although the scope of architecture does not need to be limited to the public domain or interoperability. EA originates from business and is often viewed as a codified understanding of elements ranging from organization to infrastructure. EA can support a broader range of objectives and typically goes beyond the interoperability aspect and also influences decision making on all kinds of aspects. EA provides coherence and direction using frameworks, tools, principles, patterns, basic facilities and shared services as the main architectural products. Whereas these EA products have been given much attention, our survey shows that architectural governance is underdeveloped. EA is often viewed from a product view in that it does what its designers intended and should generate the desired outcomes. The sociopolitical view is the contrasting view which takes into account the social interdependencies and interactions among stakeholders in which the architecture is embedded. Despite it significant, there is limited research about the sociopolitical view this field. From this view, we argue that there is a need for reconceptualizing EA. We plea for a broader look at EA that includes both capabilities and a governance structure and mechanisms. Doing EA should be incorporated in everyday’s processes and routines. The use and acceptance is determined by the social processes surrounding the architecture. As such, there is a need to swap from the dominating blueprint focus to a relational and governance focus. The use of effective governance widens the scope from having merely a technical focus and being an artifact toward viewing EA from a broader sociopolitical perspective. EA researchers should focus much more on the desire to understand how and to what extent the EA leads to improved organizational performance within firms. There is a pressing need to move forward with measuring performance of the EA and to understand which factors affect its performance.
Footnotes
The author(s) declared no conflicts of interest with respect to the authorship and/or publication of this article.
The author(s) received no financial support for the research and/or authorship of this article.