=Paper= {{Paper |id=Vol-2218/paper12 |storemode=property |title=EA Management in the German Public Sector: An Initial Perspective on Priorities |pdfUrl=https://ceur-ws.org/Vol-2218/paper12.pdf |volume=Vol-2218 |authors=Anna Sonnenberger,Kurt Sandkuhl |dblpUrl=https://dblp.org/rec/conf/bir/SonnenbergerS18 }} ==EA Management in the German Public Sector: An Initial Perspective on Priorities == https://ceur-ws.org/Vol-2218/paper12.pdf
        EA Management in the German Public Sector:
            An Initial Perspective on Priorities

                        Anna Sonnenberger1 and Kurt Sandkuhl2
                                1,2
                                BEC, Elmenhorst, Germany
              2
              Institute of Computer Science, University of Rostock, Germany
          [anna.sonnenberger, kurt.sandkuhl]@uni-rostock.de



       Abstract. Worldwide, Enterprise Architectures (EAs) have been gaining popu-
       larity due to benefits, like, e.g., increased transparency of dependencies between
       business and technology, reduction of efforts for system customization or opti-
       mizing integrated and enterprise-wide processes and matching actions. Private
       businesses and the public sector show significant differences in the use of EA.
       Thus, the application of reference architectures originating from the private sec-
       tor for purposes in the public sector creates substantial challenges. For a better
       understanding of the challenges, it is necessary to identify the most affected EA
       layers and the insufficiently defined, modeled or described elements of EA
       models in general. Based on an investigation in the Germany, this paper identi-
       fies weaknesses of EA in the public sector, like an incompletely modeled tech-
       nology layer, and also strengths, such as existing definitions, descriptions and
       models of enterprise objectives. These findings are the foundation for deriving
       actions and recommendations to strengthening the existing structure and turning
       it into a coherent overall architecture for federal and state agencies in Germany.

       Keywords: Enterprise Architecture, Enterprise Architecture Management, Ref-
       erence Models and Architecture, Public Sector.


1      Introduction

Fundamentally, IT is gaining in importance, making the development of IT strategies
necessary. A holistic and guiding strategy development cannot be reduced to solely
the IT perspective or solely the business perspective. Both must be adapted and tuned
to achieve long term goals such as transparency, cost reduction and short term process
adjustment [3, 4, 9, 18, 23, 24]. Past research has been mainly focused on the private
and not the public sector (cf. section 2). In contrast to private enterprises, public au-
thorities have some characteristic features, which are mainly due to their enormous
scope of tasks, the hierarchical and externally induced organizational structure, as
well as their (legal) principles, obligations and horizontal decision-making processes.
   In Germany the constitutional law defines both the principle of federalism (GG
Art. 20(1)) and responsibilities of the departments (GG Art. 65). This characterizes
the organization and task fulfillment of state agencies. Thereby processes like making
2


decisions and carrying information about the right places are complex and not as di-
rect as in private enterprises [18].
   Private (i.e. for-profit) companies aim to grow and maximize their profit, whereas
public enterprises are only permitted to fulfill the assigned tasks by not taking risks
and keeping fiscal limits [18]. All of the characteristics of the public sector result in
difficult management, confusion due to heterogeneity, complexity and slow reaction
times for adjustments and change. To compensate, IT and its strategies become more
important and have to align with the organizational structure.
   There is a need of firstly knowing and secondly modeling the structure of the agen-
cy while introducing and mapping EA´s in order to achieve flexibility to adapt to
changing frameworks - material, institutional, organizational, or IT. This requires the
definition and description of elements, their modeling among each other and proce-
dural relationships. Attention: Political programs determine the organizational strate-
gy. This is subject to strong fluctuations, for example due to election cycles. There is
no continuity due to the constant influence of laws and authorities, the principle of the
department and federalism [3, 4, 5, 9, 18, 23, 24].
   Therefore this research tries to answer the following Research Questions (RQ):
   1. Which common elements of selected EA frameworks are already implemented
        in the public sector in practice? To what extent?
   2. Which architecture layers are difficult and why?
The common vocabulary to understand this work and background from EA are de-
fined in Section 2. After that, the methodology for answering the questions is de-
scribed in Section 3. Subsequently, in Section 5, the lessons learned from the request-
ed documents in 3.2 are mapped to various established reference architectures (sec-
tion 4) and their perfection and definition are classified. The gaps and strengths of the
current mapping of EA in the healthcare sector are discussed. The work concludes
with a summary and an outlook of further research in section 6.


2      Background

In order to reach a basic understanding of the terms in the field of EA and its man-
agement (EAM), important terms like enterprises and their strategies are explained as
used for this work (section 2.1). Due to its holistic, continuous importance for intro-
ducing, modeling and using EA, the term of EAM is specified in section 2.2.


2.1    Terminology
„Enterprises name complex and highly-integrated systems, containing various entities
working together to reach a common goal or to produce a common product” [23].
Consequently it can be an entire company, a collaboration of several ones, a specific
number of departments of a company, as well as all other forms of separations and
networking units [21, 23]. Obviously, they are characterized by relationships and
inter-dependencies across their boundaries, resulting in being influenced by both ex-
ternal and internal factors [23]. EA “is a complete expression of the enterprise; a




                                          121
                                                                                       3


master plan […] between aspects of business planning such as goals, visions, strate-
gies, and governance principles; aspects of business operations such as business
terms, organization structures, processes, and data; aspects of automation such as
information systems (IS) and databases; and the enabling technological infrastructure
of the business such as computers, operating systems, and networks” [21]. EA in the
field of public authorities is an iterative improvement process to achieve models of
the current and future state, transitions between them, the entire business improve-
ment and strategic outcomes. [5, 7, 10]
   Enterprise strategies name the abilities for identification and evaluation of oppor-
tunities in the organizational business corresponding specific aims. In practice, strate-
gies are understood as impulses for actions to reach certain goals. These should be not
redundant advantages, which are not replaceable by others [23]. For this work, espe-
cially the strategies of public agencies must be focused to depict their core target.
There is, naturally, no competition within the public sector, just legal requirements of
the business tasks. Therefore, holistic and overarching strategies must be explicitly
defined from above (by law) for federal systems. [5, 18, 24]


2.2    Enterprise Architecture Management
In general, an EA captures and structures all relevant components for describing an
enterprise, including the processes used for development of the EA as such [1]. Re-
search activities in EAM are manifold. The literature analysis included in [28] shows
that elements of EAM [8], process and principles [11], and implementation drivers
and strategies [24] are among the frequently researched subjects. Furthermore there is
work on architecture analysis [16], decision making based on architectures [15] and
IT governance [22]. However, there is no specific focus on EAM use in the German
public sector.
   The existing research on EAM and IT governance for the public sector to a large
extent is specific to certain countries. This is obviously caused by the strong influence
on national regulations and laws on governing structures, decision and implementa-
tion procedures, and policies. Much work for the public sector has been done in the
USA (see, for example, [19]) which is due to the fact that the Clinger-Cohen act al-
ready in 1996 made it mandatory for public agencies to show how planned invest-
ments in information technology would improve efficiency and effectiveness. Similar
regulations and related research can be observed in Australia (see [2]). Examples for
EA in public administration in Europe can be found in Denmark, the Netherlands [14]
and Finland [26]. However, due to the specifics of the German governmental system
with its federal structure and a combination of state-level and federation-level regula-
tions, the work from other European countries is not easily applicable in Germany.


3      Methodology

As a fundamental basis for the identification of layers, their elements and dependen-
cies of EA´s in public administration a literature search was carried out. Literature,




                                          122
4


which is primarily related to the use of EA in other countries, was identified and ex-
amined with regard to the above mentioned emphases on the implementation of EA
and identified difficulties and adaptations.
   Afterwards one German state agency for health and social affairs was examined. It
aims to picture a holistic and general pre-version of the actual state of EA(M) in Ger-
many´s public administration.


3.1     Literature Analysis
As part of a literature review conducted in the department of the University of Ros-
tock (see [24]), the current state of using EA and EAM in public administration in
Germany was examined. Primary literature (19 documents) was searched by access-
ing various databases (AISeL, SpringerLink and Google Scholar) and defining a
comprehensive search query1 of German and English keywords to make the identifi-
cation traceable. Only documents published between 2007 and 2017 have been con-
sidered. Secondary literature (6 documents) was obtained from the references of the
primary literature. The selection of the total amount of 25 selected papers by abstract
and full-text analysis yielded 13 relevant documents over all. Due to the small amount
of existing literature on the subject, a free Internet search of company pages and liter-
ature was carried out.
   The sources provide information related to the requirements for EAM, possible
procedures for introducing it, or up-to-date status information. Most of the literature is
based on common EA frameworks, and extends or provides guidance on its introduc-
tion and principles. The work of Birkmeier et al. [5] should be highlighted as they
developed their own way of aligning business and IT architecture. According to the
authors, it is to be integrated into existing EAM frameworks. The majority of sources
emphasize the differences between private and public characteristics of companies,
the need for EAM for public administration, and attempt to provide guidance, less in
the form of reports from experience in the field (e.g. [7]), but rather in context of sci-
entific papers and case studies (e.g. [18]).
   Another focus of the analysis – the comparison of Germany to the countries Fin-
land and USA - offered the following legislation: There are no laws for the usage of
EA(M) in Germany. The Federal Ministry of the Interior just provides guidelines for
the EA usage in public administration. These primarily include objectives and man-
agement aspects like increasing the cooperation of institutions and IT effectiveness as
well as its cost reduction. In contrast, the USA is pioneering the use of EA(M) due to
the Clinger Cohen Act as a legal obligation to reduce maintenance costs and avoid
unnecessary expenditures. Finland also passed a similar law in 2011.
   In conclusion, the digitization in the area of EA(M) has hardly been discussed in
public administration so far. However, the authors of the reviewed literature empha-

    1
    („Enterprise Architecture Management“ OR „Enterprise Architecture“ OR „EAM“ OR
„Unternehmensarchitektur“) AND („Public Sector“ OR „öffentlicher Bereich“ OR „Public
Administration“ OR „öffentliche Verwaltung“) AND („Germany“ OR „Deutschland“)




                                           123
                                                                                        5


size the need for EAM implementation also in public administration due to the digital
age and the increasing demands on it. Keywords are efficiency and effectiveness.
These efforts are slowed down by the limited budget, the legal fluctuations and the
requirements of the public administration. The overall picture sets little or no previous
implementation in the German administration.


3.2    Initial Analysis of the Examination Object
The aim is to gain an overview of the formal structuring of the object under investiga-
tion. The initial research object is one German state agency in the field of health and
social affairs. For this purpose, various question catalogs were sent to the contact
person in the agency, which should cover the main elements of EA (e.g. organization,
processes / processes, roles, instruments).
   In short, it can be stated that the organizational objectives are well formalized and
defined. The legal regulations and guidelines make this necessary. The interplay of
roles is also formalized, but has gaps for specific cases due to the lack of mapping
processes in form of scenarios. The complete technology level of the agency is out-
sourced to a data center. This and the limited time of this initial investigation step are
hampering the information acquisition and their mapping (using models). In-depth
analyzes must follow here in order to map interfaces between organizational and
technical levels.
   Permitted types to answer the requested issues were formal definitions (e.g. organ-
izational charts and balanced scorecards), descriptions and explanations (e.g. monitor-
ing instruments as part of strategic controlling) as well as experience reports (of agen-
cy experts) referring to processes, roles and rights.


4      Reference Enterprise Architecture

EA Frameworks offer a set of documents, data, roles, models and their relations to
provide a common approach with a defined vocabulary to depict the entire enterprise
[3, 4, 9, 13, 17, 18, 21, 23].


4.1    TOGAF – The Open Group Architecture Framework
TOGAF [25] is a holistic EA reference modeling that is currently available in version
9.2. It was developed by members of The Open Group Architecture Forum and is
constantly being revised. The approach is aimed primarily at the controlling and exe-
cuting bodies of the architectures, regardless of the view to be processed (data, busi-
ness or IT).
   TOGAF defines components (Building Blocks) and an architecture development
method (ADM) for the creation of EA. A distinction is made between four levels of
the organization that requires an EA: 1. Business architecture, 2. Data architecture, 3.
Application architecture, 4. Technology architecture.




                                           124
6


   Based on the definition, description and modeling of the individual building
blocks, ADM must be carried out cyclically in order to always be up-to-date and op-
timized for the company conditions. [8, 17, 25]


4.2    FEAF – Federal Enterprise Architecture Framework
Based on the Clinger-Cohen Act, the USA are pioneers in the definition of architec-
tural frameworks in order to optimize the development of public authorities. FEAF is
developed by the USA Chief Information Officers Council since 1999. [17, 21]
   Due to provide a common approach of aligning strategic, business and technology
aspects, it differentiates several models, which mainly aim to improve the interopera-
bility within the government. Furthermore it aims to make IT acquisition as well as
the general share of information and resources easier, to reduce costs and to improve
customer services. [21]
   The reference model of FEAF differentiates between four layers: 1. Business archi-
tecture, 2. Data architecture, 3. Application architecture, 4. Technology architecture.
   Based on these layers, six reference models are derived:
   - Performance Reference Model (PRM) to support the analysis of integrated EA
        by comparing both material and monetary incomes and outcomes of strategic
        actions,
   - Business Reference Model (BRM) as the combination of business and service
        components to depict the entire organization and its elements,
   - Data Reference Model (DRM) to store data and their meaning in specific stor-
        ages of interest,
   - Application Reference Model (ARM) to categorize standards and technologies
        of single applications or whole systems,
   - Infrastructure Reference Model (IRM) to categorize the standards and tech-
        nologies of the network to support and enable data delivery and capabilities,
   - Security Reference Model (SRM) to provide a common terminology and
        methodology in the field of federal agencies security to achieve business
        goals.
   The first und last mentioned models are superior to the other layers.


4.3    ISO 19439
ISO 19439:2006 defines the International Standard of an enterprise modeling frame-
work, including modeling principles and dimensions. It aims to provide a "unified
conceptual basis for model-based enterprise engineering that enables consistency,
convergence and interoperability of the various modeling methodologies and support-
ing tools. The framework does not encompass methodological processes; it is neutral
in this regard" [13].
    “There are three dimensions for defining the scope and content of an enterprise
model” [12, p.1321]: 1. Phase dimension in relation to the life cycle of an enterprise
model, 2. View dimension, which differs between four specific objectives to enter-
prise entities, 3. Genericity dimension describing the enterprise elements in an ab-




                                         125
                                                                                         7


stract way. The designated model views can be expanded for specific conditions, e.g.
user concerns.
   Furthermore, seven modeling phases are mentioned to run cyclically and iterative-
ly. The most important ones are layer three to five due to defining the business func-
tion within its domain (overall collection of processes, inputs, outputs, resources and
capabilities), resulting in specifying the concrete field of domain operations and addi-
tionally describing needed information for the tasks of operational systems. [12, 13]


5      Adaption of Reference EA into the Public Sector

To outline the weaknesses and strengths of defining the EA of a public office, the
named elements of the three chosen approaches (see section 4) are summarized and
broken down to their common layers and related core elements. The illustrated priori-
ties are based on the empiric data (cf. Section 3.2).
   Domains are considered as layers, containing specific components (e.g. processes
and roles) and offering services for layers above. Due to the massive influence, de-
termination and support of public agencies by both internal and external entities, the
environment layer is set on top. Depending on the view, specific scenarios can be
derived and analyzed on a focus.
   As a conclusion of the comparison (see table 1), common EA elements were men-
tioned and summarized in one view (cf. table 2). It is common to differentiate the
Business Architecture in objectives/scopes and its modeling. The other layers were
taken over. The columns are based on Zachman´s Framework due to depicting the
main questions of modeling EA. Views can be summarized and mapped to some of
the mentioned elements.

                     Table 1. Comparison of selected EA frameworks.
                       TOGAF                         FEAF                   ISO 19439
Architec-     Business Architecture       Business Architecture
ture          Data Architecture           Data Architecture
Domains       Application Architecture    Application Architecture
              Technology Architecture     Technology Architecture
              (Security Architecture)     (Security Architecture)
                                          (Performance Architecture)
Process of    Cyclical                                                  Cyclical
EA            Up-to-date                                                Iterative
Modeling      Optimized
Views                                     What, How, Where accord-      Function View
                                          ing to Zachman´s              Information View
                                          Framework2                    Resource View
                                                                        Organization View


2
 Zachman´s Framework, developed in 1987 by John Zachman, is one of the earliest and well-
known EA frameworks. It is focused on roles, perspectives and their related elements. Nowa-
days, the framework is considered as basis and aid for other frameworks such as TOGAF. [17]




                                           126
8


Table 2 shows the well-definedness of the actual implementation of the EO. It is used
to outline the findings regarding RQ1. A grading scale of three is used. Red is the
weakest grade, illustrating that no effort has been made to reproduce or even aspire it
yet. Dark green represents the most strongly modeled units. Bright green defines
items with potential for expansion. Black elements could not be included in the previ-
ous research process due to the complexity of elements and/or their assignment to
different departments (e.g. Data Architecture) on the one hand, but also to the lack of
knowledge about structures (Network Architecture) on the other hand.

    Table 2. Illustration of EA core elements and their degree of implementation. (cp. [6], [27])
                      Data           Function           Network        People         Motivation
                     (What)           (How)             (Where)        (Who)            (Why)
Environment        Data value    Operational           Messag-      Personal        Operations
                   storage       Instructions          ing (send-   (external       (due to laws
                                                       ing and      and internal)   and standards)
                                                       receiving)
Business           Important     Processes, Mis-       Operating    Organiza-       Business goals/
Architecture       things,       sion                  locations    tional Units    strategies/
Objectives         concepts                                                         policies/ vision

Business           ERM,          BPM                   Networks     Organiza-       Business plan
Architecture       business                                         tion charts,
Model              language                                         roles, skills
Data/ IS           Data          Flow Diagrams,        Distribu-    Models of       Business rules
Architecture       Model         Application           tion         roles, data     in detail
                                 Architecture          systems      and access
Technology         Data          Pseudo-code,          System       User Inter-     Business rule
Architecture       architec-     structure chart       architec-    face Design     design
                   ture                                ture
Technology         Data          Detailed pro-         Network      Screens,        Rule specifica-
Architecture       design        gram design           architec-    security        tion in program
                                                       ture         architecture    logic

   Obviously, in terms of RQ 2, the first levels of EA are highly structured and de-
fined in practice of this public agency. The Environment is well defined due to mainly
use lists and other forms of written formulations, not specific models. This decreases
downwards from level to level. This is justified by the determination of organizational
elements by the federal government, the states or the leadership of the individual
agency. Information systems, data as well as technological aspects are largely the
responsibility of the manufacturers of software solutions, the supervisors of specific
specialized procedures or data centers. Effort and time are needed to analyze the af-
fected structures.


6        Conclusion and Future Work

This analysis is based on the research results of just one public agency in Germany.
The study could be extended to additional authorities in order to strengthen the pic-




                                                 127
                                                                                                9


ture. Beyond that, further research expects to analyze and model example processes of
the EO. Thereby a comparison of both, the described and defined facts towards the
reality, as well as the prior detected weaknesses and strengths of the literature towards
the current reality are needed.
   For writing a study in the field of EA it is important to define the terms relating to.
The chosen Reference EA´s are mentioned because of depicting an international
standard (ISO 19439), a highly referenced model (TOGAF) and an architecture ex-
ample, which is already used in public practice of a different country. Further archi-
tectures (e.g. military frameworks) might offer different elements and layers.
   The research results demonstrate that the purely formal and descriptive layers of a
corporate architecture are well-defined in the public sector. In contrast, there are
strong deficits, the more you go down the hierarchy. Based on the findings, recom-
mendations for the implementation of EA can be developed in future work..


References
 1. Ahlemann, F., Stettiner, E., Messerschmidt, M., Legner, C.: Strategic enterprise architec-
    ture management: Challenges, best practices, and future developments. Springer, Ber-
    lin/New York (2012).
 2. Ali, S., Green, P.: IT governance mechanisms in public sector organisations: An Australian
    context. Journal of Global Information Management 15, 41-63 (2007).
 3. Aier, S., Riege, C. Winter, R.: Unternehmensarchitektur – Literaturüberblick und Stand
    der Praxis. Wirtschaftsinformatik 50(4), 292-304 (2008).
 4. Autere, R.: Ministry of Finance - Enterprise Architecture in public sector,
    https://vm.fi/en/enterprise-architecture-in-public-sector, last accessed 2018/06/18.
 5. Birkmeier, D., Gehlert, A., Overhage, S., Schlauderer, S.: Alignment of Business and IT
    Architectures in the German Federal Government: A Systematic Method to Identify Ser-
    vices                      from                      Business                      Processes,
    https://pdfs.semanticscholar.org/5ca8/91b5541146a05d70d595110f85a180d93f81.pdf, last
    accessed 2018/02/10.
 6. Bondar, S., Hsu, J., Pfouga, A., Stjepandic, J.: Agile Digitale Transformation of Enterprise
    Architecture Models in Engineering Collaboration. In: Pellicciari, M., Peruzzini, M. (eds.)
    Procedia Manufacturing - 27th International Conference on Flexible Automation and Intel-
    ligent Manufacturing, FAIM2017, vol. 11, Modena/Italy (2017).
 7. Brehme, N.: Management von Unternehmensarchitekturen? Auch für Behörden!,
    https://publikation.msg.group/fachartikel/165-beitrag-im-public-kundenmagazin-
    management-von-unternehmensarchitekturen-auch-fuer-behoerden/file, last accessed
    2018/02/10.
 8. Buckl, S., Dierl, Th., Matthes, F., Schweda, C.M.: Building Blocks for Enterprise Archi-
    tecture Management Solutions. In: Practice-Driven Research on Enterprise Transfor-
    mation, Lecture Notes in Business Information Processing, vol. 69, pp. 17-46 (2011).
 9. Esswein, W., Weller, J.: Unternehmensarchitekturen – Grundlagen, Verwendung und
    Frameworks. HMD – Praxis der Wirtschaftsinformatik 262, 6-18 (2008).
10. Federal        Enterprise       Architecture        Program         Management         Office,
    https://web.archive.org/web/20101016043354/http://www.whitehouse.gov/sites/default/fil
    es/omb/assets/fea_docs/FEA_Practice_Guidance_Nov_2007.pdf,                 last      accessed
    2018/07/30.




                                               128
10


11. Glissmann, S., Sanz, J.: An Approach to Building Effective Enterprise Architectures. In:
    HICSS 2011, IEEE Computer Society 2011, pp. 1-10, Washington DC/USA (2011).
12. Goepp, V., Rose, B., Caillaud, E.: Reference modeling for eco-design. In: IFAC Proceed-
    ings, vol. 45(6), pp. 1321-1326, Romania (2012).
13. International        Organization      for      Standardization       ISO       19439:2006,
    https://www.iso.org/standard/33833.html, last accessed 2018/07/21.
14. Janssen, M., Hjort-Madsen, K.: Analyzing enterprise architecture in national governments:
    The cases of Denmark and the Netherlands. In: HICSS 2007, IEEE Computer Society
    2007, Washington DC/USA (2007).
15. Johnson, P., Ekstedt, M., Silva, E., Plazaola, L.: Using enterprise architecture for CIO de-
    cision-making: On the importance of theory. In: Second Annual Conference on Systems
    Engineering Research (2004).
16. Johnson, P., Lagerström, R., Närman, P., Simonsson, M.: Enterprise architecture analysis
    with extended influence diagrams. In: Information Systems Frontiers 9(2-3), 163-180
    (2007).
17. Matthes, D.: Enterprise Architecture Frameworks Kompendium – Über 50 Rahmenwerke
    für das IT-Management. In: Xpert.press. Springer, Berlin/Heidelberg (2011).
18. Obermeier, M.: Enterprise Architecture Management in der öffentlichen Verwaltung: De-
    sign, Einführung und Evaluation. Dissertation TU München, München (2014).
19. Pang, M. S.: IT governance and business value in the public sector organizations - The role
    of elected representatives in IT governance and its impact on IT value in US state govern-
    ments. In: Decision Support Systems 59, 274-285 (2014).
20. Sandkuhl, K.; Simon, D., Wißotzki, M., Starke, C.: The Nature and a Process for Devel-
    opment of Enterprise Architecture Principles. In: 18th International Conference BIS 2015,
    Poznań, Poland, LNBIP 208, pp. 260-272. Springer, Berlin/Heidelberg (2015)
21. Schekkerman, J.: How to survive in the jungle of Enterprise Architecture Frameworks:
    Creating or choosing an Enterprise Architecture Framework. 2nd edn. Trafford Publishing,
    Canada (2004).
22. Simonsson, M., Johnson, P., Ekstedt, M.: The effect of IT governance maturity on IT gov-
    ernance performance. In: Information systems management 27(1), 10-24 (2010).
23. Sonnenberger, A.: Enterprise Architecture Management in Small and Medium Enterprises.
    Bachelor thesis Universität Rostock. Rostock (2012).
24. Szilagyi, T.: Enterprise Architecture Management and Digitization in the German Public
    Sector. Literature analysis Universität Rostock, Rostock (2018).
25. The Open Group Standard TOGAF Version 9.2. van Haren Publishing,
    http://www.opengroup.org/About-TOGAF-Version-9.2, last accessed 2018/07/21.
26. Valtonen, M. K.: Management Structure Based Government Enterprise Architecture
    Framework Adaption in Situ. In: IFIP Working Conference on The Practice of Enterprise
    Modeling, pp. 267-282, Springer, Cham (2017).
27. Wambler,                           S.:                    Agile                        Data,
    http://www.agiledata.org/essays/enterpriseArchitectureTechniques.html, last accessed
    2018/07/02.
28. Wißotzki, M., Sandkuhl, K.: Elements and Characteristics of Enterprise Architecture Ca-
    pabilities. In: 14th International Conference BIR 2015, Tartu, Estonia, LNBIP 229, pp. 82-
    96. Springer, Berlin/Heidelberg (2015).




                                              129