# Government Architecture: Concepts, Use and Impact

Marijn Janssen, Leif Skiftenes Flak, Øystein Sæbø

► To cite this version:

Marijn Janssen, Leif Skiftenes Flak, Øystein Sæbø. Government Architecture: Concepts, Use and Impact. 12th International Conference on Electronic Government (EGOV), Sep 2013, Koblenz, Germany. pp.135-147, 10.1007/978-3-642-40358-3_12. hal-01490901

HAL Id: hal-01490901

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

Submitted on 16 Mar 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
# Government Architecture: Concepts, Use and Impact

Marijn Janssen¹, Leif Skiftenes Flak², Øystein Sæbø²

¹Delft University of Technology, Faculty of Technology, Policy and Management, Jaffalaan
5, 2628 BX Delft, The Netherlands
m.f.w.h.a.janssen@tudelft.nl

²Center for eGovernment, Department of Information Systems University of Agder, 4604
Kristiansand, Norway
{leif.flak, oystein.sabo}@uia.no

**Abstract.** Government architecture (GA) is a relatively young discipline in which concepts are slowly emerging. Often terms and concepts are used in various ways and there is no uniform agreement on these concepts. Further, the relationship between GA, benefits and public value creation is unclear. In this paper we unravel and define GA concepts that are often used by governments. Although GA is used in different ways there are common concepts. GA practice in two different countries, the Netherlands and Norway, indicates that although the Netherlands clearly has more experience with GA than Norway, both countries employ similar concepts. Nevertheless our study confirmed the assumption of conceptual confusion. In both countries GA efforts are concentrated towards guiding design projects and dealing with complexity. We found that the impact of GA is ill understood. We defined central concepts of GA, and propose a conceptual model illustrating the relationships between GA concepts, its use, benefits and public value drivers.

**Keywords:** Enterprise architecture, design, design science governance, government, government architecture, public value

## 1 Introduction

Current developments within the government sector focus on issues like access to open data, shared services, cloud computing and data integration between private and public organizations increase the importance of government architecture (GA). Government from across the world have embraced the concept of GA [1-3] which is often inspired by information systems architecture [4], information architecture [5] or Enterprise Architecture (EA) [3, 6]. The term ‘information systems’ refers to the various socio-technical elements, ‘information’ refers to information as a fourth production factor, whereas “enterprise” refers to the scope of the architecture dealing with multiple departments and organizations rather than with a certain organizational part or individual components and/or projects [8]. In government various terms are used including enterprise architecture [3], or national enterprise architecture [7] or national or domain reference architecture [9]. We prefer to avoid the word enterprise to avoid any association with business, and prefer the wording government architecture to refer to the scope of the government in contrast to the enterprise.

adfa, p. 1, 2011.

© Springer-Verlag Berlin Heidelberg 2011
Governments have adopted a variety of models and often developed their own cus-
tomized frameworks and applications that fit their country or organizational situations
best, resulting in a variety of GAs [7]. Over time, these GAs developed in their own
directions and adopting their own vocabularies may result in conceptual unclearness
and indistinct concepts [7]. There is no “one-size-fits-all” architectural method that is
equally effective and a contingency approach is often taken [10]. Much can be learned
from each other, but learning is made difficult by the various meanings that are given
to the same concepts. Having a clear vocabulary is necessary to advance our under-
standing of the field and to understand how the various research efforts and conceptu-
alizations are related to each other.

The concept of architecture is ambiguous and lacks a common agreed upon defini-
tions [11]. Smolander [12] argues that a plausible reason for why it is difficult to de-
fine architecture as a concept is that the source domain i.e. building architecture is
equally ill-defined and that the meaning of architecture changes according to the type
of stakeholder, situation under study, and the phase of the project. A common under-
standing and methodological consistency seems far from being developed [13]. There
is a body of literature comparing different approaches and frameworks with each
other [13-15]. Aier et al. [2008] and Simon et al. [13] provide an overview of EA
literature, compare different frameworks and approaches found in the literature along
the following criteria: the understanding of enterprise architecture (i.e., the degree of
consideration of architectural layers); the representation of enterprise architecture
(modelling languages, tool support); and the use of enterprise architecture (e.g.,
documentation, analysis, and planning).

In general, an architecture is the conceptual description of the set of elements and
the relationships between them [16] aimed at creating a coherent and consistent set of
relationships among (sub)systems [17]. A commonly used definition is that of the
architecture working group as described in the IEEE Std 1471-2000 "Architecture is
the fundamental organization of a system embodied in its components, their relation-
ships to each other, and to the environment, and the principle guiding its design and
evolution" [18]. According to this definition architecture consists of the following
elements; architectural principles, implementation guidelines, system structure and
components. Architectural principles are the foundation for making necessary design
decisions and guide the development. Implementation guidelines focus on how or-
ganizations can adopt and implement their own architectures, whereas system struc-
ture and components focus on the components of the system and their relationship.

This paper is a first attempt to provide clarity concerning the concepts, use and im-
pact of GAs. EA can be used within a single organization, but in GA needs a scope
that goes beyond a single organization and domain. Due to the wide variety or stake-
holders, domains and diversity of government the complexity of GA may exceed the
complexity of traditional EA. Further, as GA can be described as the backbone of
modern public value creation and production it is seen as essential to ensure that GA
is developed to leverage public value. We therefore develop a conceptual model in-
cluding the central concepts of GA, direct and indirect benefits from GA and public
value drivers. This model can be extended and refined in further research.
There is a limited amount of existing conceptual research on GA and there is no uni-
formity among definitions or GA methodologies. This heterogeneity can be attributed
to the abstract and diverse character [13-15]. To get a grip on this, we adopted a com-
bination of deductive and inductive approaches to address our research problem, in line with Simon et al. [13] we will utilize applied research to overcome potential gaps between theoretical foundations and the application of EA management.

We applied inductive reasoning by starting from specific observations in Norway and the Netherlands to broader generalizations and theories, in other words; moving from the specific to the general. We opted for investigating two different situations in which GA are developed and in use, namely the Netherlands and Norway. This allowed us to observe a variety of different conceptualizations of direct and indirect benefits relating to GA. We explored the situation by first analysing publicly available data from both countries, by reading reports, presentations, project documents and websites. Thereafter, our findings were discussed by key personnel working in these GAs projects. Using literature we then sought for patterns and common elements in these observations resulting in our conceptualization. From the usage patterns we derived the main GA components, which are defined based on insights from the literature. Finally a model is developed which shows the contribution how the GA components create value.

The paper is organized as follows. Next, GA usage pattern is derived, resulting in conceptualization of main concepts, which are illustrated by observations from our two countries. Finally we conceptualize relationships between impacts and value of GA before we conclude.

## 2 Government Architecture usage patterns

GA development can be characterized by elements that are used to influence the development of the architectural landscape. GA is intended to direct and help developers in their design activities. Architecture influences the design decisions and the investments of an organization and in turn is influenced by behavior and design decisions. A GA actually emerges as a result of implementing individual projects. As such, architecture and design are closely linked as architecture aims at guiding designers in their design efforts.

Design science, as conceptualized by Simon [20], focuses on creation of artefacts to solve real-world problems. Design science research combines a focus on the IT artefact with a high priority on relevance in the application domain, which is also the intention of GA. Typical GA artefacts include framework, tools, principles, patterns, basic facilities and shared services [9]. These are used to influence new design projects at the conceptual level of implementation level. At the conceptual level the initial architecture of a project is influenced, whereas already available facilities and shared services can be used when implementing the design.

The information systems (IS) community have recognized the importance of design science research to improve the effectiveness and utility of the artefact in the context of solving real-world business problems [21]. Design science research in IS addresses what are considered to be wicked problems [22, 23] that can be characterized by unstable requirements and constraints based on ill-defined environmental contexts, complex interactions among components, inherent flexibility to change design processes as well as design artefacts, a critical dependence upon human cognitive abilities (e.g., creativity) to produce effective solutions, and a critical dependence
upon human social abilities (e.g., teamwork) to produce effective solutions. GA is aimed at tackling a broad range of issues as the architecture aims at guiding a variety of design projects ranging from integrated service provisioning to social media platforms. Complexity is at the heart of the architecting challenges. When projects fail, one of the reasons is typically that the system or situation was more complex than originally expected. Many of the architecture methods, models principles, rules, standards and so on are aimed at simplifying the situation.

GA cannot be viewed as a isolated instrument as it needs governance to be effec-
tive [e.g. 7]. GA is shaped by the interaction among stakeholders and influenced by
contemporary developments. The organizations can adapt their GA strategy according
to the path dependencies and anticipated or desired benefits. Whereas the initial focus
might be on reducing administrative costs in the Netherlands and interoperability in
Norway current developments like cloud computing and open (linked) data influence
these developments. This results in expanding GA to be able to deal with new con-
temporarily challenges.

The GA exhibits emergent phenomena like new standards, technology, innovations and players entering the field and there is no central control or invisible hand. In both countries the GAs are aimed at guiding and directing the development of ICT-projects in the government. This is a generic pattern that provides some commonalities. An important distinction is the use of the project start architecture (PSA) and GA [25]. Whereas GA refers to the government domain or organization as a whole, start architecture refers to the initial architecture developed for a certain project. PSA is derived from the EA and provides guidance for project-level decision-making. GA influences the design decisions and the investment behaviour of an organization and is in turn influenced by behaviour and design decisions. Further, GA influences the design decisions and the system architecture that will be developed by a project.

The usage of architecture is about the balance the use of the architecture in design
projects and providing leeway to the designers to deal with the inherent complexity
they are working in. Too much freedom results in heterogeneity, whereas too little
freedom may result in mechanistic views, reduced creativity, inappropriateness of
dealing with uncertainties and solutions that are not appropriate for the given situa-
tions. Figure 2 provides an overview of the EA elements (in the box) and how they
are used when developing PSA. This framework is created by relating main process
step (grey blocks) used in design project to the elements of GA used in each of these
steps. When a project is initiated the project requirements will be have to comply with
the requirements as posed in the GA, such as the level of security and privacy. There-
after, the EA framework will provide the structure for developing the PSA. The PSA
will be filled in based on the input provided by EA elements principles, guidelines
and standards. Elements that are not filled in have to be complemented by the project.
If new elements can be added this might result in an update of the GA and the GA has
to be adopted continuously. Also the realization of a new system or the evaluation
might result in new insights, which can be fuelled into the GA. Once the process is
completed the PSA is finished.
<figure><img src="image_2.png" /><figcaption>**Fig. 1.** Common architecture usage patterns</figcaption></figure>

The above usage patterns are based on how GA should be used to guide develop-
ment projects, although we found that many times this usage pattern was more dy-
namic and ad-hoc. In a similar vein the GA can be used to guide modification of daily
activities. This follows a similar process in which the PSA is updated and guided by
the common architecture elements.

Conceptual clarity is needed; hence we will further discuss and define the elements of GA by applying the elements from the framework and discussing practice in the Netherlands and Norway.

The Netherlands was a frontrunner in the field, and in 2004 the Ministry of gov-
ernment reforms initiated the development of a national GA aiming to reduce red
tape, whereas at a later stage the emphasis shifted toward interoperability, due to the
focus of the EU on interoperability. A second version of was released in 2007 and in
2009 a third version was released, focusing on managers and administrators. Whereas
the second version contained a large number of principles this number was reduced in
the third version.

Norway has had action plans for ICT in government or eGovernment since the
early 2000s. Architecture became part of these plans in 2006, as part of a Government
proposition. A central part of the Norwegian architecture is a number of suggested
common public ICT components, with the idea that functionality required by the ma-
nority of services should be developed once and made publicly available for re-use. Norway lacks an explicit focus on GA at the national level. However, several typical components of GA have been focused upon but the step of organizing it in a GA has not yet been formally initiated.

## 2.1 Frameworks

Zachman [4] introduced the concept of architecture frameworks that provide multiple views on information systems. Frameworks are used for describing and understanding EA [26]. The frameworks model(s) chosen determine what aspects can be captured at what level of abstraction. In EA the use of frameworks has been given much attention and a variety can be found [1, 14, 27], although many of them cannot be qualified as architecture frameworks. A framework often is realized as a matrix that visualizes the relationship between the various elements in each domain [9].

In the Netherlands GA is developed by adopting one part of the Zachman model. The architecture is driven by requirement for EU, Dutch government, businesses and citizens. The model is primarily used as a way to structure and interrelated architecture principles and best practices. The web-based version contains hyperlinks to these principles and practices. The framework is generic due to the need for covering all public organizations. As the national EA is generic there are a number of domain architectures, which are derived from the NEA and provide more details and are customized to the domain.

In Norway a three level conceptual framework from 2006 is supplemented recently by a proposed set of core national common components, including guidelines for how to use and administrate these common components. In addition, Norway refers to EU and European frameworks.

In summary, the framework is used to specify how information technology is related to the overall business processes and outcomes of organizations, describing relationships among technical, organizational, and institutional components. This view on EA is expressed by providing codified understanding of elements.

**Definition:** Architecture Frameworks structures and interrelates architecture elements to allow design of the elements independently and at the same time ensuring coherency among elements.

## 2.2 Architectural principles

The use of architectural principles for designing service systems are commonly used in the design of systems [28, 29]. Principles are particularly useful when it comes to solving ill-structured or ‘complex’ problems, which cannot be formulated in explicit and quantitative terms, and which cannot be solved by known and feasible computational techniques [20]. Principles are commonly used for guiding stakeholders in the design of complex information systems [28, 29]. Principles are often based on the experiences of the architects, which they have gained during many years of information systems development [e.g., 29]. Similarly, Gibb [30] suggested that principles are the result of engineers reflecting on the experiences gained from previous engineering projects, sometimes combined with professional codes of conduct and practical constraints. Principles have been defined in various ways and they have
been used interchangeably with other problem solving notions, including laws, pat-
terns, rules and axioms [31]. The Open Group have defined design principles as “gen-
eral rules and guidelines, that are intended to be enduring and seldom amended, that
inform and support the way in which an organization sets about fulfilling its mission”
[32]. The disadvantage of this definition is that it does not make any differentiation
with guidelines, which are more indicative and do not have to be followed. Ideally,
principles should be unrelated to the specific technology or persons [33]. Principles
should emphasize "doing the right thing" but should not prescribe 'how' is should be
accomplished. Principles are normative in nature.

In the Netherlands the principles are used to ensure that everybody is guided by the same starting points and adopt the same approaches when developing new systems. This should warrant that requirements like flexibility, interoperability, security and maintenance are met.

Norway has developed seven high level architectural principles as part of govern-
ment propositions, to guide the design of service systems. Moreover, a number of
national common components and core set of registries are re-used to avoid dupli-
cated development and arrange for consistency.

*Definition: Principles are normative and directive statements that guide in decision making when designing new systems.*

**2.3 Architectural guidelines**

Guidelines are aimed at supporting architects, commonly shaped as statements or
other indications of policy or procedure by which to determine a course of action.
Similar to principles they are aimed at transferring the knowledge obtained by experi-
ence to others. Whereas principles have to be followed, guidelines do not need to be
completely followed and allow for discretion in its interpretation. Furthermore, guide-
lines might result in the need to make trade-offs, e.g. open access vs. security. Open
access might make it more difficult to ensure security and security might prefer re-
stricted access. Guidelines can be viewed as recommended practice (e.g. use of open
source software) that allows some discretion or leeway in its interpretation and use
(not always open source can provide a suitable solution).

Interestingly, neither of the countries had explicit mentions of requirements in the
available material on EA. In the Netherlands, some ‘principles’ are in fact guidelines,
whereas Norway has no explicit guidelines but reference to EU and other nations
guidelines.

*Definition: Guidelines are rules of thumb for determining courses of actions al-
lowing leeway in its interpretation.*

**2.4 Standards**

Standards management is viewed a new direction of EA business efforts [13],
whereas it has been given considerable attention by governments. The EU framework
initially was focussed on standard setting and interoperability and only at a later stage
included architecture elements.

There are a variety of types of standard, like open standards or technical standards.
In general, standards are definite rules or measures established by some authority
determining what a thing should be, often accompanied by some criteria to qualify if
standards are obtained or not [34]. Standards are aimed at ensuring quality and that
different elements are able to interoperate with each other. Standards specify or define
policies that are subsequently adopted by a large number of members. Standards are
essential for facilitating GA and enables organizations to influence the actions of units
without explicitly prescribing how to handle internal information-processing activities
[35]. In GA standards are essential for the interaction between public government
organizations and their interaction with external entities, by defining interaction inter-
faced between various systems. There exists a wide variety of standards providing
organizing logic for applications, data and infrastructure logic [36], including stan-
dards on [35]:

* Physical infrastructure management, standards on underlying technologies required to run organisations, like computers, networks, servers and database management

* Human IT Infrastructure management, standards on human IT resources such as organisational IT skills, expertise, competence and knowledge

* Integrating Business applications, to define strategic directions for managing applications and the integration between them

* Enterprise data integration, focusing on the integration of critical data elements and databases for cross-organisational integration, and define data elements

In the Netherlands some standards are referred to in the GA framework, whereas other standards are put on a comply or explain list. This means that designers should adhere to these standards, and if they do not they have to explained this into details.

I Norway a general "Catalogue of standards" (recommended or mandatory) for the public sector is available through a designated web portal. A broadly composed Standardization council maintains the catalogue.

*Definition: Standards are set of well-defined policies and specification used as rules to form unifying practices across projects and organizations.*

## 3 Conceptualizing government enterprise architecture impact

In business there is limited knowledge about the effect of EA practices [37] and we found that the same applies to the government domain. The patterns in the previous (sub)sections show the process how GA is used and updated, but not how this process contributes to the creation of public value. Therefore we investigated the overall aims and benefits of the GA. The GA elements are used to create value and these elements are shown on the left in figure 2.

The process we induced from the two countries is aimed at creating observable direct or indirect benefits, which are shown in the middle of Figure 2. Direct benefits include better interoperability, reuse, flexibility/agility and information quality. Indirect benefits include better communication, decision-making and fit between organization and technology.
<figure><img src="image_3.png" /><figcaption>Fig. 2. Conceptualizing GA and its impact</figcaption></figure>

The main goal of government is to create a wide-range of public values for their citizens. Hence, these observable direct and indirect benefits of GEA should contribute to the creation of public values. Public values are a “good, service or outcome which supports, meets or conforms with one or more of an individual or group’s values” [38] are an “important (but often taken for granted) motivation for strategy and implementation of eGovernment projects” [39]. Rose and Persson [39] define three primary values, administrative efficiency, services improvement and citizens engagements which are shown on the right side in Figure 2. Administrative efficiency represents the search for value, expressed by efficiency, effectiveness and economy [39], and are deconstructed into target variables such as return on investments, net present value and increases capacity and throughput. Service improvements derive from customer orientation, focusing on how to use ICT to provide better services to the public [39], including issues like better access to services and information, online access to services, and cost-savings for citizens and other external stakeholders. Values related to citizen engagement combines ideals on community empowerment with democratic values such as citizens access to information [39]. Citizen engagement values relate to the engagement, empowerment and use of eGovernment services for citizens’ involvement, and citizens’ role in the design and development on eGovernment services provided by the public.

Based on the conceptualizing of GA introduced in section 4 above, and the benefits and public value drivers introduced here, we conceptualize intended GA effects. The GA elements result in direct and indirect benefits that ultimately should contribute to the generation of public values.
# 4 Conclusions

We sought for patterns and common elements of GA in this research. The practices in two countries were investigated and it was found that GA consists of frameworks, principles, guidelines and standards to guide design project and deal with the complexity. These elements are used to direct and guide initiatives occurring at all levels of government. We inductively derived a generic pattern on how GA was used in government. GA frameworks, principles, guidelines and standards were identified as the main concepts used in both countries. Although these four concepts might look clear at first glance, they were not in the practice. For instance, in the Netherlands principles include statements ranging from a very high conceptual level, down to technology-specific statements explicitly telling how to do things. Defining the common elements of GA can result in a vocabulary with enables easier communication between stakeholders. The definition proposed in this paper should be viewed as a first start to better define concepts and can be further refined by investigating more practices. Furthermore, the number of main concepts can be expanded in further research, as GA might serve other purposes and concepts might change over time.

Based on the use of the four concepts a model was developed showing how GA benefits help in the realization of public values. In the situation studied the architectural efforts are focussed on creating benefits like better interoperability, reuse, flexibility/agility and information quality and indirect benefits like better communication, decision-making and fit between organization and technology. Although we acknowledge the importance of these outcomes, these are primarily the benefits viewed from the IT perspectives, whereas the motivation for initiating the architectural efforts was the creation of public values. Therefore we argued that these direct and indirect benefits should result in three types of public values; administrative efficiency, services improvement and citizen engagement. The resulting conceptual model provides a starting point for conceptualizing the impact of GA and should be further refined and tested in further research.

Although our aim is to provide conceptual clarity among the concept, GA is not a uniform concept and can have various interpretations and purposes. The differences between countries revealed similarities and differences. The Netherlands, being a front-runner in this area, has more years of experience with GA efforts than to Norway. Nevertheless it was rather surprising to see that Norway still has no formal descriptions of GA at least not at the national level. In the Netherlands GA focus has shifted over the years suggesting that concepts might also change over time. Further research is needed to explain differences among countries and to better understand the consequences of the differences. This can help to determine which architectural concepts are essential and which are supportive for creating public values.

# References

1. Peristera, V., Tarabanis, K.: Towards an enterprise architecture for public administration using a top-down approach. European Journal of Information Systems 9, 252-260 (2000)
2. Weerakkody, V., Janssen, M., Hjort-Madsen, K.: Integration and Enterprise Architecture Challenges in E-Government: A European Perspective. International Journal of Cases on Electronic Commerce 3, 14-38 (2007)

3. Hjort-Madsen, K.: Enterprise Architecture Implementation and Management: A Case Study on Interoperability. In: Conference Enterprise Architecture Implementation and Management: A Case Study on Interoperability. IEEE, (Year)

4. Zachman, J.A.: A Framework for Information Systems Architecture. IBM Systems Journal 26, 276-292 (1987)

5. Periasamy, K.P., Feeny, D.F.: Information architecture practice: Research-based recommendations for the practitioner. Journal of Information Technology 12, 197-205 (1997)

6. Richardson, L., Jackson, B.M., Dickson, G.: A Principle-Based Enterprise Architecture: Lessons From Texaco and Star Enterprise. MIS Quarterly 14, 385-403 (1990)

7. Janssen, M., Hjort-Madsen, K.: Analyzing Enterprise Architecture in National Governments: The Cases of Denmark and the Netherlands. In: Sprague, R. (ed.) 40th Annual Hawaii International Conference on System Sciences (HICSS'07). IEEE, Big Island, Hawaii (2007)

8. Ross, J.W.: Creating a strategic IT architecture competency: Learning in stages. MISQ Quarterly Executive 2, 31-43 (2003)

9. Janssen, M.: Socio-political Aspects of Interoperability and Enterprise Architecture in E-government. Social Science Computer Review (SCORE) 30, 24-36 (2012)

10. Riege, C., Aier, S.: A Contingency Approach to Enterprise Architecture Method Engineering. In: Feuerlicht, G., Lamersdorf, W. (eds.) Service-Oriented Computing – ICSOC 2008 Workshops, vol. 5472, pp. 388-399. Springer Berlin Heidelberg (2009)

11. Corneliussen, M.S.: IT Architecturing: Reconceptualizing Current Notions of Architecture in IS Research. In: Golden, W., Acton, T., Conboy, K., Heijden, H.v.d., Tuunainen, V.K. (eds.) European Conference on Information Systems (ECIS), pp. 494-504. AIS, Galway, Ireland (2008)

12. Smolander, K.: Four metaphors of architecture in software organizations: finding out the meaning of architecture in practice. In: Conference Four metaphors of architecture in software organizations: finding out the meaning of architecture in practice, pp. 211 - 221 IEEE, (Year)

13. Simon, D., Fischbach, K., Schoder, D.: An Exploration of Enterprise Architecture Research. Communications of The Association for Information Systems 32, 1-72, (2013)

14. Schekkerman, J.: How to Survive in the Jungle of Enterprise Architecture Framework: Creating or Choosing an Enterprise Architecture Framework. Trafford (2003)

15. Leist, S., Zellner, G.: Evaluation of current architecture frameworks. In: Conference Evaluation of current architecture frameworks, pp. 1546-1553 ACM, (Year)

16. Armour, F.J., Kaisler, S.H., Liu, S.Y.: A big-picture look at Enterprise Architecture. IEEE IT Professional 1, 35-42 (1999)

17. Doucet, G., Gøtze, J., Saha, P., Bernard, S.: Coherency Management: Using Enterprise Architecture for Alignment, Agility, and Assurance. Journal of Enterprise Architecture 4, 9-20 (2008)

18. Architecture_Working_Group: IEEE Std 1471-2000 Recommended Practice Architectural Description of Software-Intensive Systems. IEEE Standard 1471-2000 (2000)

19. Auyang, S.Y.: Foundations of Complex-System Theories in Economics, Evolutionary Biology, and Statistical Physics. Cambridge University Press, New York (1998)

20. Simon, H.A.: The Sciences of the Artificial. MA, MIT Press, Cambridge (1996)
21. Hevner, A., March, S., Park, J., Ram, S.: Design science in information systems research. MIS Quarterly 28, 75-105 (2004)

22. Rittel, H., Webber, M.: Planning problems are wicked problems. In: Cross, N. (ed.) Developments in Design Methodology, pp. 135-144. John Wiley & Sons, New York (1984)

23. Hevner, A., Chatterjee, S.: Chapter 2 Design Science Research in Information Systems. In: Hevner, A., Chatterjee, S. (eds.) Design Research in Information Systems Theory and Practice, pp. 9-22. Springer (2010)

24. Johnson, N.F.: Simply Complexity. A clear guide to complexity theory. Oneworld, Oxford, UK (2010)

25. Berg, M.v.d., Steenbergen, M.v.: Building an Enterprise Architecture Practice. Tools, Tips, Best Practices, Ready-to-Use Insights. Springer, Heidelberg (2006)

26. Kaisler, S.H., Armour, F., Valivullah, M.: Enterprise Architecting: Critical problems. In: Conference Enterprise Architecting: Critical problems. (Year)

27. Guijarro, L.: Interoperability frameworks and enterprise architectures in e-government. Government Information Quarterly 24, 89-101 (2007)

28. Van Bommel, P., Hoppenbrouwers, S.J.B.A., Proper, H.A., Van Der Weide, T.P.: Giving Meaning to Enterprise Architectures: Architecture Principles with ORM and ORC On the Move to Meaningful Internet Systems 2006: OTM 2006 Workshops. Springer Berlin (2006)

29. Richardson, G.L., Jackson, B.M., Dickson, G.W.: A principles-based enterprise architecture: Lessons from Texaco and Star Enterprise. MIS Quarterly 14, (1990)

30. Gibb, T.: Towards the Engineering of Requirements. Requirements engineering 2, 165-169 (1997)

31. Maier, M.W., Rechtin, E.: The art of systems architecting. CRC Press, Boca Renton (2002)

32. TOGAF: The Open Group Architecture Framework. Version 8.5, Enterprise Edition. (2004)

33. Perks, C., Beveridge, T.: Guide to Enterprise IT Architecture. Springer (2002)

34. http://www.britannica.com/bps/dictionary?query=standard

35. Boh, W.F., Yellin, D.: Using Enterprise Architecture Standards in Managing Information Technology. Journal of Management Information Systems 23, 163-207 (2006)

36. Ross, J.W., Beath, C.M., Goodhue, D.L.: Develop Long-Term Competitiveness through IT Assets. Sloan Management Review 38, 31-42 (1996)

37. Schmidt, C., Buxmann, P.: Outcomes and success factors of enterprise IT architecture management: empirical insight from the international financial services industry. European Journal of Information Systems 20, 168-184 (2010)

38. Bannister, F.: Citizen centricity: a model of IS value in public administration. Electronic Journal of Information Systems Evaluation 5, (2002)

39. Rose, J., Persson, J.S.: E-Government value priorities of Danish local authority managers. IT Management in Local Government: the DISIMIT Project. Software Innovation, Aalborg 27-56 (2012)