# Understanding Enterprise Architecture: Perceptions by the Finnish Public Sector

Juha Lemmetti, Samuli Pekkola

► To cite this version:

Juha Lemmetti, Samuli Pekkola. Understanding Enterprise Architecture: Perceptions by the Finnish Public Sector. 11th International Conference on Electronic Government (EGOV), Sep 2012, Kristiansand, Norway. pp.162-173, 10.1007/978-3-642-33489-4_14. hal-01543580

HAL Id: hal-01543580

https://inria.hal.science/hal-01543580

Submitted on 21 Jun 2017

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>

Distributed under a Creative Commons Attribution 4.0 International License
# Understanding Enterprise Architecture:
Perceptions by the Finnish Public Sector

Juha Lemmetti and Samuli Pekkola

Department of Information Management and Logistics
Tampere University of Technology, Finland
juha.lemmetti@tut.fi samuli.pekkola@tut.fi

**Abstract:** Enterprise architectures (EA) support organizations in managing the complexity of their business environment and facilitate the integration of strategy, personnel, business and IT. In Finland, the use of EA has recently been mandated by the newly passed Act on the Direction of Public IT Governance. This has forced public sector authorities to familiarize themselves with the Finnish EA method. As part of the familiarization process, public sector organizations were given a chance to make statements on the proposed EA. We acquired the statements and conducted a content analysis to find out how the public sector authorities have understood the proposal and its basis, i.e. the EA itself. It turned out that while the statements were diverse and dependent on the level of previous knowledge on EA, several themes frequently appeared. Even though these problems of misunderstanding the EA concept are not new, the themes provide insights into how EA is understood. This helps researchers and practitioners to conduct their EA related works with multiple stakeholders.

**Keywords:** enterprise architecture, comprehension, public sector, content analysis, legislation.

## 1 Introduction

Enterprise architecture (EA) is defined as "*a complete expression of the enterprise; a master plan which 'acts as a collaboration force' between aspects of business planning such as goals, visions, strategies, and governance principles; aspects of business operations such as business terms, organisation structures, processes and data; aspects of automation such as information systems and databases; and the enabling technological infrastructure of the business such as computers, operating systems, and networks.*" ([18] p. 13). Enterprise architecture thus provides a holistic view of an organization. Often this view is expanded also to cover current as-is architecture, future to-be architecture, and a transition plan [2].

Despite this promising viewpoint on organizational activities, the interpretation of the EA concept has varied. Even though it has usually been understood to consist of four types of architectures – business, information, systems, and technology, the exact number of architectures and their terminology vary. For example, both [2, 21] define
five types of architectures, which, however, mutually differ: goals and initiatives, products and services, data and information, systems and applications, and networks and infrastructures in [2] vs. business model, enterprise model, system model, technology model, and detailed description in [21]. These examples, among the reviews [4, 20, 23], illustrate inconsistent definitions from the literature.

As this non-harmonized view of EA seems to confuse both EA researchers and EA practitioners that are familiar with the field and its varying terms and concepts, it is reasonable to ask whether their customers, i.e. business and IT people who are not experts on EA, understand what EA really is. If their understanding is limited, how can one convince them to adapt EA principles and practices? This issue is concretized in Finland, where an Act has recently been passed that all governmental institutions and municipalities should follow a national version of EA and its principles and practices in their IT development and activities. Even though the Act is warmly welcomed by public sector actors, there is a heated debate on its actual contents and implications. Following the governmental practices, the Ministry of Finance sent out a call for comments related to this new Act. The comments were received from 65 actors in governmental institutions and municipalities.

We took these comments and conducted content analysis on the documents to see *how EA is perceived by the public sector authorities*. We thus shed light on the complexity of the EA phenomenon and its interpretation by EA customers, i.e. non-EA experts. The analysis helps EA researchers to identify appropriate definitions of EA principles and practices (as asked in [23]), and EA practitioners to communicate with and understand their customers. Particularly these findings support EA adoption not only in Finland, but also elsewhere, where similar kinds of attempts to utilize EA in the public sector are taken.

The paper is organized as follows. First, a brief analysis of EA and its current interpretations is provided. Second, a framework for analysis is presented. This is followed by research methods and research settings. Fourth, the findings are listed. The paper ends with discussion and conclusions.

## 2 Background

Enterprise architectures support organizations in managing the complexity of their structures, information technology and business environments, and facilitating the integration of strategy, personnel, business and IT [5, 11]. EA includes architectural models needed in managing and developing the organization, encompassing the viewpoints of business, information, information systems (IS) and technology [9, 10, 13]. It describes the current architecture of the organization, provides a vision for the future architecture and a transition plan describing how to reach it [1, 13].

Even though the ideas of the above mentioned goals, different types of architectures, and EA practices are commonly shared – as evident from the quotation above – they are shared only on a general level. Stelzer [23] argues that "*no accepted definition of the term enterprise architecture has emerged yet*" (p.16). Usually, different definitions and frameworks emphasize either the business or IT viewpoint, take a process-oriented approach (i.e. present a method) or model or documentation-centric approach
(i.e. consider architectural models), and underline the practices of conducting EA work at the expense of explaining or theorizing it (ibid.). This development has resulted in EA research being, to a large extent, practice-driven and practitioner-oriented.

EA research focuses on the planning and development aspect of EA: frameworks [17, 22], planning and developing methods and tools [3, 13] and development processes [1, 17]. Critical success factors and maturity models [18, 24] and the benefits of EA [16] have also been studied. Yet it is common that these studies rarely define what EA is or what its principles are. For instance, [4] and [23] identified only seven articles where EA principles are defined. Also some standards (e.g. [6, 7]) aim at defining EA principles. Again, these are not congruent with each other or with other definitions. Thus, despite a growing number of publications related to EA, it seems that the concept of EA has been taken for granted, without it being explicitly defined, by researchers and practitioners. This vagueness has its impacts also on EA practices. Niemi [15] identified 29 stakeholders of EA, meaning there are (as) many different perceptions of the EA concept. Consequently, the goals and methods of EA, and its principles and practices, are seen, experienced, and assumed differently. For instance, software architectures, a subsection of EA architectural models, are conceived of in four different ways: as blueprint, as literature, as language, and as decision [21]. As the EA concept is broader than software architecture going beyond mere architectural descriptions, it can be assumed that a similar variety is evident also with EA – but on a much larger scale.

Goethals et al. [5] argue that EA work should be a part of the normal way of doing business, and that this work should not only be the responsibility of the ICT department. Yet they have found that business people are rarely willing to cooperate. This is because of different understandings of the concept and its importance.

This motivates our paper. We want to understand how the customers of EA practices, i.e. EA users, comprehend EA. This provides us with a basis for communicating with them, and targeting our message appropriately.

## 3 Analysis framework

To study how the EA concept is understood by the customers of EA work, we simply adopt the following basic EA items as the unit of analysis:

* Architectures. These are central in EA research and practice. EA work aims at understanding business planning, business operations, information systems and databases, and technological infrastructures and their relationships. In other words, *Business Architecture*, *Data Architecture*, *Applications Architecture*, and *Technology Architecture* are considered.

* Phases. Often in EA work, the first, current situation is modeled on understanding the processes, data and information, information systems, and technologies. This is then used as a basis to develop a vision for the future, and a plan of how to get there. Hence *as-is* architecture, *to-be* architecture, and a *transition plan* are developed.
* Levels of application. EA can be used as a tool to help strategic planning (which business/technical directions are feasible, what activities the whole organization should do, etc.) and organizational implementation and management (how to apply organizational EA principles in a certain domain, what kind of tactics could and should be used in EA work, what kind of systems should be acquired, etc.), and in routine every day operative activities (what kind of interfaces a certain system should have, how the data is managed, etc.). The scope and type of EA activities and the purposes for which EA is used differ between the levels of applications of EA. Hence, the adaptation of Mintzberg's [14] *strategic apex, middle line and operating core* equips us with a usable frame of reference.

## 4 Research settings and methods

The study was motivated by the debate on how to organize IT governance in the public sector in Finland. On February 2010 the Cabinet Committee on Economic Policy supported an initiative from the Ministry of Finance by stating that the corporate governance of the public sector IT should be enforced. The key element in this corporate function is enterprise architecture, which was seen as a tool to achieve strategic goals, for example interoperability and manageability of the public sector IT systems.

In April 2011, the Finnish Government presented a proposal for Finnish National Enterprise Architecture, which will be a part of the Act on the Direction of Public IT Governance. The EA framework, a modified version of TOGAF9 framework, will be part of legislation that eventually forces all public sector authorities to create their own EA descriptions. The EA framework is also accompanied with governance models, application instructions, modified capability maturity models, domain definitions, and other documentation.

Following the governmental practices, immediately after the proposal was presented, the Ministry of Finance sent out a call for comments and statements. This official call was sent to all public sector organizations: ministries, governmental agencies and municipalities, though anyone wanting to comment was allowed to do so. In total 70 statements were made. These statements are publicly available¹.

Table 1 summarizes the data acquired for the study. All the ministries gave their statements (coverage of ministries was 100%). The municipalities were largely represented by the Association of Finnish Local and Regional Authorities. In fact, 20 out of 28 statements from the municipalities only referred to the Association's statement and were left out of the analysis. Private organizations (5 statements) were also excluded from the study even though they had interest in the Act.

The study was conducted with content analysis [12] with the statement documents being the research data. In the first, quantitative, phase the comments that described the EA concept or its applicability with respect to the organization's current structure or processes were identified. In this phase the analysis framework described in Sec-

<footnote>1</footnote>

<footnote>http://www.vm.fi/vm/fi/04_julkaisut_ja_asiakirjat/03 Muut asiakirjat/20110923Kokona/na
me.jsp (in Finnish)</footnote>
tion 3 was utilized. Only the comments that addressed the EA framework itself or one of the architecture areas were analyzed. The comments that focused only on the readability or the structure of the EA documents, or the government's organization structures were left out. In the second phase the comments found in the first phase were subjected to qualitative analysis. The comments were categorized and themes common to many of the statements were identified.

<table><caption>Table 1. Distribution of statements from different organizations</caption><thead><tr><td>Answering body</td><td>Count</td><td>Estimated coverage</td><td>Notes</td></tr></thead><tbody><tr><td>Ministries</td><td>12</td><td>100%</td><td></td></tr><tr><td>Government agencies</td><td>7</td><td>20%</td><td></td></tr><tr><td>Other governmental bodies</td><td>8</td><td>25%</td><td>e.g. government owned companies</td></tr><tr><td>Municipalities</td><td>8</td><td>2%</td><td>8 (of 28) statements analyzed</td></tr><tr><td>Municipal agencies</td><td>10</td><td>10%</td><td>e.g. hospital districts</td></tr><tr><td>TOTAL</td><td>45</td><td></td><td></td></tr></tbody></table>

# 5 Findings

The analysis revealed that many statements focused solely on administrative issues, and some statements were only commenting on textual issues and phrasing. Thus, many statements had no elements that could be analyzed.

The findings are presented in two ways. First, the quantitative results are presented. Second, their qualitative analysis is shown.

## 5.1 Quantitative analysis

The quantitative analysis provided interesting results. Comments on the same unit of analysis were grouped together. The coverage of different architecture areas of EA is very limited. 32 statements out of 45 discussed the business architecture. Even though also applications and data architectures were mentioned in 11 statements, most often only interoperability requirements and goals were considered. Technology architecture was almost completely absent in the comments, being mentioned only twice.

Similarly, most of the statements discussed strategic level to-be architectures, as seen in Table 2. These were mainly comments about the interoperability and cost efficiency objectives. As-is architectures or transform phase were very rarely addressed.

<table><caption>Table 2. Distribution of statements in phases and in levels of application</caption><thead><tr><td></td><td>As-is</td><td>To-be</td><td>Transform</td></tr></thead><tbody><tr><td>Strategic apex</td><td>0</td><td>26</td><td>1</td></tr><tr><td>Middle line</td><td>6</td><td>8</td><td>1</td></tr><tr><td>Operating core</td><td>3</td><td>5</td><td>2</td></tr></tbody></table>

It should be noted that in theory one statement could address every unit of analysis, i.e. all types of architectures, their phases, or the levels of applicability. However, the number of units of analysis is quite low (108) in contrast to the number of statements
analyzed (45). This means that many statements did not discuss the EA concept com-
prehensively. One may thus easily argue that quantitative analysis does not reflect the
understanding of EA because the comments might refer to issues which were the most
unclear, in need of explanation, or being of most concern to the respondent. Hence,
even though quantitative analysis illustrates fragmented awareness of EA, it does not
(necessarily) describe how the concept is understood by the respondents. For that
reason, we also conducted qualitative analysis of the same data set.

5.2 Qualitative analysis

In qualitative analysis the findings were categorized according to their focus. Themat-
ic groups were identified and analyzed. This resulted in the following themes.

**Terms, definitions, and concepts.** The proposed EA is an ensemble of several documents. Most documents adopted their own definitions for terminology as there was no meta-document or such a section in any of the documents. This was pointed out by the respondents. “*The concept of enterprise architecture and related terms linked are not very familiar to many. Explaining the key terms and concepts would make the documents much easier to understand.*”<fnref n="2" /> (Ministry of Social Affairs and Health)

The use of languages was commented on as “*Ministry of Justice proposes that Finnish terms are used consistently in the documents – not in English or in a mixed language*”. This issue is emphasized since Finnish translations for EA-related terms in general do not necessarily exist.

The inconsistent use of terms was also present in the statements. For example, there
were problems with the term EA itself. It was not always clear whether the statement
was referring to EA as a development method, as an architectural principle, as an
architecture function, or as the final public sector EA that is being created by the use
of the method. In many cases, the statement did not address the proposed architecture
but the problems of the given target area preventing the creation of the final architec-
ture.

**Benefits of Enterprise Architecture.** Many statements underlined the importance of EA as a bridge between ICT management and the organization's other functions. Another frequently mentioned benefit was the ability to move from siloes to interoperable information systems. This requires the capabilities of creating requirements for call-for-tenders: “*What would be needed from the enterprise architecture is that we could create nation-wide specifications for interfaces, and at the same time, gain the capability to make them as obligatory requirements for the supplier.*” (Hospital District of Etelä-Pohjanmaa)

Another type of benefit was the description of the current state, and how it could be
improved: “*The problem has been that the consequences of the decisions made in the
development projects are not seen later in the larger scale.*” (Ministry of Employment
and the Economy) Especially the need for inter-organizational harmonization was
seen as a benefit in the adoption of EA.

<footnote n="2">² Original Finnish transcripts translated by the authors.</footnote>
Many respondents stated as a motivation for EA, that the use of EA framework ena-
bles the creation of common ICT solutions and unifies the processes within the public
sector. For example, "*The motivation of enterprise architecture is to enhance interop-
erability inside the public sector and to reduce the amount of processes and infor-
mation systems.*" (Population Register Centre)

**A new Function, a new way to work, or something else.** The organizations had various opinions on how EA work should be organized. Some organizations argued that EA development should not be separated from traditional administrative practices, and should not be a new method or tool. This is visible in the comment by Finnish Transport Safety Agency: "*Enterprise architecture has been seen as a tool for implementing the strategy. The main objective of the architectural work is to move from information system centric development to a more process-oriented development*". Another popular view was that EA can bridge the gap between IT management and line management.

Yet EA development should not create a new, separate organizational entity. These
fears were manifested in comments such as: "*From the individual organization's point
of view, it can be seen as a risk that the organization develops an independent EA
function which operates in isolation from other management and service production
needs*" (Association of Finnish Local and Regional Authorities). In one response it
was even stated that: "*Between management and IT personnel, there must not be such
a grey area [actor] with its own secret language, and only those familiar with it can
understand what is being prepared*". (National Institute for Health and Welfare)

A link between the organization's management system, and EA development and governance was requested: "*It is important to start architecture development in all organizational levels, and introduce it as a part of traditional management and development.*" (Ministry of the Environment).

**Resources and skills.** The new EA requirement was seen to require resources from the public sector organizations. This was linked with the question as to whether a separate organizational entity or an EA office should be formed inside the organization – even though its functions were not seen as being separated from the organization’s other work. The need for extra resources was stated several times in comments such as “*Developing the architecture will need lots of resources*” (Ministry of Agriculture and Forestry) and/or by quantifying them more precisely: “*Under the Ministry of Justice and its offices, this will mean a yearly input of 6 man years in Enterprise Architecture development alone. It will be difficult to organize this in our sector*”.

There were also several comments about the workload distribution: "In many cases
these EA-tasks are understood to be additional tasks to all previous duties" (Helsinki-
Uusimaa Hospital District). This was a frequently restated fear – that EA will increase
the workload of already burdened officers. However, some proposed that "it should
be considered whether a couple of Enterprise Architecture development offices, or
even a single (national) Enterprise Architecture Development Office, should be estab-
lished" (Ministry of Defence).

Some argued about the motivation of the new workload: "*The scarce resources of the
Office should be designated to [more] important development projects, not to create a*
present state Enterprise Architecture specification", since "the goal should be to develop architecture, not only write specifications" (Population Register Centre). In addition to documentation, also the amount of work related to measurable benefits and the scope of EA work were criticized as factors lowering motivation.

The need for new skills and EA knowledge was seen: "We emphasize that new skills needed for the Enterprise Architecture work are taken into account. The training and education should be coordinated" (Finnish Transport Safety Agency). Some even mentioned that these training, education and practical study materials should be coordinated with the universities, and perhaps new degree programs related to EA should be created.

**Problems seen in the adoption of Enterprise Architecture.** The adoption of EA as the main ICT design and development method was seen as problematic: "Activities in the health-care sector, as well as in other sectors, are so diverse and multifaceted that Enterprise Architecture is not a sufficient tool to govern it" (National Institute for Health and Welfare). This issue was seen in various forms. Typically, organizations have adopted their own management systems, and were reluctant to change or modify them. It was frequently seen that the ICT management is pushing itself into the field of traditional management and administration, particularly "when there are four architecture areas, and three out of four areas are information technology centric, the role and contribution of ICT management is disproportionally emphasized" (Ministry of Justice).

While several agencies operate in co-operation with their foreign counterparts and other organizations, the international aspect was brought up only once: "It is of utmost importance that the Finnish Defence Forces continue to use their own Enterprise Architecture Frameworks, governance model, and specification framework" and not to switch to national practices.

# 6 Discussion

When analyzing the results, the normative angle of the call for comments cannot be ignored. The call was triggered by the upcoming Act on the Direction of Public IT Governance, where an EA framework is named. This gives public sector organizations a strong motivation to present their statements as they will be affected by EA in the near future. Some organizations had already started their EA work, a fact which was visible in their comments. However, only a few organizations had EA experiences for more than two years, making the topic novel for most organizations.

Also the facts that EA framework is introduced by the Ministry of Finance, and that it is enforced by legislation may have had impact on the viewpoints and stressed some issues related e.g. to resources. Currently, the public sector is under constant cost scrutiny, and the introduction of a new function raises the question of financing.

However, by looking below the surface, another interesting issue arises. While the EA concept is vague and is seen as a tool, its essential features are not questioned. This is strongly related to architectures and architectural concepts, as only very few statements echoed understanding of what those are and how they can be utilized. Conse-
quently, the goal of the original call for comments, to gain views on the chosen EA
framework, did not match reality. The statements responded to the call in different
levels, focusing on different issues. This was because EA was not thoroughly under-
stood by the public sector authorities. Next, three types of contradictions are dis-
cussed.

6.1 Strategic level and operative level

The differences between strategic and operating levels were visible in the comments about the benefits and problems in adopting EA. Most EA benefits were related to the strategic level, i.e. on goals and objectives. It was seen that interoperability is the main goal of EA, while improved systems management, and sharing and (re-) using IS and their specifications are merely tools for cost reductions and increasing general efficiency and effectiveness. The interoperability issue was emphasized when considering citizens as customers. Currently, the processes within an organization are rather well-documented. However, to get one inter-organizational transaction completed, the customer must communicate with several officials in different organizations.

On the other hand, the majority of the problems were seen on the operative level, being organization-specific. They ranged from international agreements and the number and variety of parties involved to all kinds of commitments having implications to IS. Generally, the statements reflected the view that when any given architecture is introduced by the centralized IS management, there must be some aspects of the architecture that will not fit with the needs of the organizations. Several questions on how to handle this kind of conflict between different architectures were raised.

No matter whether EA was seen as a strategic level benefit or an operative level item,
the respondents did not see themselves as agents in the development (transition) pro-
cess – with two exceptions: the healthcare sector and the Defence Forces. EA was
seen as a normative element being introduced to the organizations in a similar way to
how legislation is introduced. In other words, EA is seen being something external,
with fancy high-level objectives but severe practical problems, making its use almost
impossible, particularly if no extra resources or outside consultation are provided.

6.2 As-is and to-be architectures

The contradiction between as-is and to-be architectures can be seen in the comments concerning the resources. EA development was seen as an extra burden on an already stressed organization. It was not something that would make ICT development easier. In general, EA was not seen as valuable in documenting the as-is architecture. Very few comments stressed the importance of making rigorous decisions taking into account the whole organization or across organizational borders. Although EA benefits were associated on the strategic level, the role of architecture descriptions was not seen as a means of accomplishing the interoperability issues.

The lack of comments on the transition phase gives another view to the issue of agen-
cy. To-be architecture seems to be something which is not actively developed inside
an organization. Two exceptions shed light on this ignorance. First, the Finnish De-
fence Forces have used the NAF framework since 2004, and have perhaps the longest
history of using EA in the Finnish public sector. Second, EA is a new concept to
many actors in the healthcare sector, even they have been developing inter-
organizational processes and IS for many years. Thus, the importance and role of to-
be architectures and further transition plans seem to be associated with either exten-
sive amount of experiences of EA (the Defence Forces), or endogenous needs for
inter-connected processes and systems. External coercion does not raise the need for
or understanding about those.

It seems that the meaning of as-is or to-be architectures, or transition plans are not understood unless the organization has gained some experience or realized such a need. Architecture concepts seem to be too abstract to be thoroughly understood by novice, illiterate users of EA. They thus see EA as a framework, given by someone else, being immediately usable in their work.

6.3 The role of the general administration and ICT

The conflict between general administration and ICT is visible in comments address-
ing the adoption of EA and discussing the structure of EA development.

As the initiative for the EA framework came from the Ministry of Finance and its Public ICT function, most respondents interpreted EA to be in the ICT management domain. This initiated inconsistent comments inside the statements. On the one hand, the strategic goals and ICT's role as a driver for improving productivity were accepted. On the other hand, it was found that the use of EA reassigns the decision making power from general management to ICT management. This is perhaps the main reason for emphasizing the role of the business in the statements.

However, the issues in the statements varied according to the respondents' background. The statements written by the ICT management underline the problems in communication between ICT and general management. In other cases it was not clear who has actually written the statement, but if the signing parties were from general management, the role of the business tends to be emphasized. Nevertheless, the gap between general management and ICT management was often apparent. It is unclear whether EA will actually help there – it is impossible to say whether EA will align business and ICT. Under the circumstances, it is unclear whether EA will succeed in facilitating the communication between the actors and integrating their viewpoints.

7 Conclusions

In Finland, EA was introduced to the public sector by means of legislation. EA will thus be forced to be adapted and used. This obligation makes the situation significantly different to [8], where the use was voluntary and technology-driven. [8] argued that national EA "must be viewed more broadly than just a 'city plan'", meaning that several issues, ranging from policies, actors and governance to architectural models, principles and standards and implementations, should be considered. We agree with these views. Nevertheless, we argue that before reaching the level where those "practical terms" become important, we have to consider different comprehensions of the
EA concept. We thus have to understand and make sure that all actors, or authorities in the public sector case, commonly share the same perceptions of what EA really is.

From our content analysis it can be seen that these impressions are diverse. Some see EA only as a new mandatory routine, while others see it as a new tool to achieve strategic goals of interoperability and efficiency. An exact definition how EA is understood cannot thus be made, as the statements reflect different issues. However, the following contradictions provide insights into their views:

* External, fancy high-level strategic objectives vs. severe practical operational problems in the organization

* EA as a tool to be used vs. EA as a directive which needs to be obeyed.

* EA as a common language between ICT and management vs. a secret language for dedicated enterprise architects.

* Architecture concepts too abstract to be usable vs. benefits of documenting the architectures.

We believe these contradictions help researchers in understanding how the EA customers, i.e. the users of EA frameworks, models, and principles, comprehend the topic. Thus, this is a first step in answering Stelzer's [23] call for a common definition of EA and its principles. On the other hand, EA practitioners benefit from these by being able to communicate with their clientele as they better understand different comprehensions of EA.

The study has its limitations. Content analysis provides only a glimpse of the respondents' understanding. This necessitates broader studies either by quality (e.g. by interviews) or by quantity (e.g. by surveys). Second, the focus on the Finnish public sector obviously has an impact on the generalization. But as the misconceptions were not culture-bound, but related to their organizational goals and structures, the contradictions are well applicable to other nations. However, the nationalities might have had implications, as the terms were not defined in Finnish – or in fact in any language. This might have made it difficult to write the statements and comments as the concepts were unclear. Although that was exactly what we wanted to study, it might have narrowed the scope of statements.

Thus, EA is understood differently by different authorities. It can be a new obligation in not solving the problems but just eating into resources, or it can be a new tool still not solving the problem but still requiring resources, or a new tool to be used in parallel with normal practices, assisting in the tasks which will be done anyway. Or it can be all of these at once, depending on the authority and the moment of time. To promote, enforce, or support EA in the public sector necessitates an unambiguous definition of the EA concept. Currently, its abstractness makes it difficult to explicitly comprehend and understand. A simple action – an explicit definition of the terms, would thus help the development of EA and of e-government ICT in general.

## References

[1] Armour, F.J., Kaisler, S.H. and Liu S.Y. (1999). Building an Enterprise Architecture Step by Step. *IT Professional*, IEEE Computer Society, 1(4), 31-39.
[2] Bernard, S. (2005). *An Introduction to Enterprise Architecture: 2nd Ed.* AuthorHouse.

[3] Bernus, P., Nemes, L., and Schmidt, G. (2003). Handbook on Enterprise Architecture, Springer-Verlag.

[4] Fischer, C., et al. (2010). What Is an Enterprise Architecture Principle? Towards a Consolidated Definition. *Studies in Computational Intelligence* 317, 193-205.

[5] Goethals, F., et al. (2006). Managements and enterprise architecture click: The FAD(E)E framework, *Information Systems Frontiers*, 8(2) 2006, 67-79.

[6] ISO/FDIS 15704. (1999). *Industrial automation systems — Requirements for enterprise reference architectures and methodologies*.

[7] IEEE 1471. (2000). *Recommended Practice for Architectural Description of Software-Intensive Systems*. ANSI/IEEE Std 1471:ISO/IEC 42010.

[8] Janssen, M. & Hjort-Madsen, K. (2007). Analyzing Enterprise Architecture in National Governments: The cases of Denmark and the Netherlands. *HICSS '07*.

[9] Jonkers, H., et al. (2006). Enterprise architecture: Management tool and blue-print for the organization. *Information Systems Frontiers* 8(2). 63-66.

[10] Kaisler, S.H., Armour, F., and Valivullah, M. (2005). Enterprise Architecting: Critical Problems. *HICSS'05*, 3-6 January, Hawaii, USA, 2005.

[11] Kluge, C., Dietzsch, A., and Rosemann. M. (2006). How to Realise Corporate Value from Enterprise Architecture, *ECIS 2006*, 12-14 June, Göteborg, Sweden.

[12] Krippendorff, K. (1980). *Content analysis: An introduction to its methodology*. Sage Publications, Beverly Hills.

[13] Lankhorst M. (2005). *Enterprise Architecture at Work. Modelling, Communication, and Analysis*. Springer-Verlag, Berlin, Germany, 2005.

[14] Mintzberg, H. (1980) Structures in 5's: A Synthesis of the Research on Organization Design, *Management Science*, 26(3), pp. 322-341.

[15] Niemi, E. (2007). Enterprise Architecture Stakeholders - a Holistic View. *AMCIS 2007 Proceedings*. Paper 41.

[16] Niemi, E. & Pekkola, S. (2009). Adapting the DeLone and McLean Model for the Enterprise Architecture Benefit Realization Process. *HICSS-42*.

[17] The Open Group (2006). *The Open Group Architecture Framework version 8.1.1, Enterprise Edition (TOGAF 8.1.1)*.

[18] van der Raadt, B., Soetendal, J., Perdeck, M. and H.v. Vliet (2004). Polyphony in Architecture. *ICSE 2004*, 23-28 May, 2004.

[19] Schekkerman, J. (2006). *How to Survive in the Jungle of Enterprise Architecture Frameworks: Creating or Choosing an Enterprise Architecture Framework*. Trafford Publishing.

[20] Schöenherr, M. (2008). Towards a Common Terminology in the Discipline of Enterprise Architecture. *LNCS 5472*, 400-413.

[21] Smolander, K., Rossi, M. & Purao, S. (2008). Software architectures: Blueprint, Literature, Language or Decision? *EJIS* 17, 575-588.

[22] Sowa, J.F. and Zachman, J. (1992). Extending and Formalizing the Framework for Information Systems Architecture. *IBM Systems Journal*, 31(3), 590-616.

[23] Stelzer, D. (2009). Enterprise Architecture Principles: Literature Review and Research Directions. *LNCS* 6275, 12-21.

[24] Ylimäki, T. (2007). Towards a Generic Evaluation Model for Enterprise Architecture. *Journal of Enterprise Architecture* 3(3), 9-16.