Enterprise Architecture in Denmark
Transcription
Enterprise Architecture in Denmark
[Master Thesis – December 2006] 0H Enterprise Architecture in Denmark - Trends in business driven IT within the public sector of Denmark Supervisor: John Gøtze Student: Flemming Hald Enterprise Architecture of public Denmark Master thesis, December 2006 ABSTRACT.............................................................................................................................................. 6 1H 270H INTRODUCTION ................................................................................................................................... 7 2H 271H BACKGROUND ...................................................................................................................................... 8 3H 27H INTENDED AUDIENCE .............................................................................................................................. 8 STRUCTURE OF THE THESIS ..................................................................................................................... 8 RELATIONSHIP BETWEEN THE TWO REPORTS .......................................................................................... 9 Guidance for reading....................................................................................................................... 10 4H 273H 5H 274H 6H 275H 7H 276H RESEARCH PROBLEM...................................................................................................................... 11 8H 27H 1. SCOPE OF RESEARCH .................................................................................................................. 11 9H 278H 1.1 AREAS OF SIGNIFICANCE ................................................................................................................. 11 1.2 AREAS OF LIMITATIONS................................................................................................................... 11 1.3 EXPECTED OUTCOME OF RESEARCH ................................................................................................ 12 1.4 INTENDED DELIVERABLES ............................................................................................................... 12 1.5 OBJECTIVE OF THE THESIS ............................................................................................................... 12 1.5.1 Relation between problem area and the hypothesis 1 ............................................................ 12 1.5.2 Relation between problem area and the hypothesis 2 ............................................................ 13 1.5.3 Clarification of preliminary concepts..................................................................................... 13 10H 279H 1H 280H 12H 281H 13H 28H 14H 283H 15H 284H 16H 285H 17H 286H 2. METHODOLOGY ............................................................................................................................ 13 18H 287H 2.1 INTRODUCTION ............................................................................................................................... 13 2.2 RESEARCH DESIGN ......................................................................................................................... 13 2.3 DATA COLLECTION TECHNIQUES ..................................................................................................... 15 2.4 RESEARCH REVIEW ......................................................................................................................... 16 2.5 VALIDITY ........................................................................................................................................ 16 2.6 RELIABILITY ................................................................................................................................... 17 2.7 DATA ANALYSIS .............................................................................................................................. 17 2.7.1 Pre-test.................................................................................................................................... 17 2.7.2 Measurement and scaling ....................................................................................................... 18 2.7.3 Types of questions................................................................................................................... 19 2.7.3.1 First open-ended question................................................................................................ 20 2.7.3.2 Second open-ended question ........................................................................................... 20 2.7.3.3 Third open-ended question .............................................................................................. 20 2.7.3.4 Fourth open-ended question ............................................................................................ 20 2.7.4 Tools ....................................................................................................................................... 21 19H 28H 20H 289H 21H 290H 2H 291H 23H 29H 24H 293H 25H 294H 26H 295H 27H 296H 28H 297H 29H 298H 30H 29H 31H 30H 32H 301H 3H 302H 3. KEY FINDINGS FROM THE SURVEY ........................................................................................ 22 34H 30H 3.1 BACKGROUND OF THE RESPONDENTS .............................................................................................. 22 3.2 FREQUENCY DISTRIBUTION ............................................................................................................ 22 3.2.1 EA mature areas ..................................................................................................................... 22 3.2.2 EA immature areas ................................................................................................................. 22 3.3 CROSS-TABULATIONS ..................................................................................................................... 23 3.4 DETERMINING CORRELATION ......................................................................................................... 23 3.4.1 Correlation on first open-ended question............................................................................... 23 3.4.2 Correlation on second open-ended question .......................................................................... 24 35H 304H 36H 305H 37H 306H 38H 307H 39H 308H 40H 309H 41H 310H 42H 31H Page 2 of 112 Enterprise Architecture of public Denmark Master thesis, December 2006 3.4.2.1 Economies of Scale.......................................................................................................... 24 3.4.2.2 Synergy ............................................................................................................................ 24 3.4.2.3 Improved citizen service.................................................................................................. 24 3.4.3 Correlation on third open-ended question ............................................................................. 25 3.4.3.1 Lack of resources............................................................................................................. 25 3.4.3.2 Cultural barriers ............................................................................................................... 25 3.4.4 Correlation on fourth open-ended question ........................................................................... 25 3.4.4.1 KL regi............................................................................................................................. 25 3.4.4.2 Between the municipalities.............................................................................................. 26 3.4.5 Other findings ......................................................................................................................... 26 3.5 DRAWING CONCLUSIONS ................................................................................................................ 26 3.6 INTERPRETING RESULTS ................................................................................................................. 27 3.7 SUMMARIZING CONCLUSIONS ......................................................................................................... 28 3.8 MAKING RECOMMENDATIONS ........................................................................................................ 28 43H 312H 4H 31H 45H 314H 46H 315H 47H 316H 48H 317H 49H 318H 50H 319H 51H 320H 52H 321H 53H 32H 54H 32H 5H 324H 56H 325H 4. LITERATURE REVIEW ................................................................................................................. 28 57H 326H 4.1 WORKING TOWARDS A COMMON TERMINOLOGY............................................................................. 28 4.1.1 Introduction ............................................................................................................................ 28 4.1.2 What is enterprise architecture? ............................................................................................ 29 4.2 DEFINING THE ENTERPRISE ............................................................................................................. 32 4.3 DEFINING THE ARCHITECTURE........................................................................................................ 33 4.3.1 Four common viewpoints on architecture .............................................................................. 33 4.3.2 Why Enterprise Architecture? ................................................................................................ 33 4.4 LEGACY OF EA ............................................................................................................................... 35 4.4.1 Relationship to systems analysis and design .......................................................................... 35 4.4.2 Relationship to strategy and business planning ..................................................................... 36 4.4.3 Relationship to component-based and service-oriented architectures................................... 36 4.4.4 Relation to social aspects ....................................................................................................... 36 4.4.5 Development of Systems Development ................................................................................... 36 4.4.6 Development of EA ................................................................................................................. 38 4.4.7 What is Service-Oriented Architecture?................................................................................. 38 4.4.7.1 Benefits of SOA............................................................................................................... 38 4.5 MERGING OF DISCIPLINES ............................................................................................................... 39 4.5.1 SOA and EA ............................................................................................................................ 39 4.5.1.1 The chicken or the egg..................................................................................................... 39 4.5.2 To be or not to be… ................................................................................................................ 40 4.6 PREREQUISITES TO ENTERPRISE ARCHITECTURE.............................................................................. 40 4.6.1 Enterprise Architecture practices........................................................................................... 41 4.6.1.1 Enterprise architecture and business objectives .............................................................. 41 4.6.1.2 Enterprise architecture as a ‘skeleton’............................................................................. 41 4.6.2 Enterprise architecture methodologies................................................................................... 42 4.6.3 The challenges of enterprise architecture .............................................................................. 42 4.7 THE EA PLANNING PROCESS ........................................................................................................... 42 4.7.1 Introduction ............................................................................................................................ 42 4.7.2 Planning an enterprise architecture....................................................................................... 43 4.7.3 Obstacles for successful Enterprise Architecture Planning ................................................... 43 4.7.4 Key Factors to Successful Enterprise Architecture Planning (EAP) ..................................... 45 4.8 EGOVERNMENT MATURITY............................................................................................................. 47 4.8.1 Introduction ............................................................................................................................ 47 58H 327H 59H 328H 60H 329H 61H 30H 62H 31H 63H 32H 64H 3H 65H 34H 6H 35H 67H 36H 68H 37H 69H 38H 70H 39H 71H 340H 72H 341H 73H 342H 74H 34H 75H 34H 76H 345H 7H 346H 78H 347H 79H 348H 80H 349H 81H 350H 82H 351H 83H 352H 84H 35H 85H 354H 86H 35H 87H 356H 8H 357H 89H 90H 358H 359H Page 3 of 112 Enterprise Architecture of public Denmark Master thesis, December 2006 4.8.2 Maturity of the State of Denmark ........................................................................................... 47 4.9 EA MATURITY AND MEASUREMENT ............................................................................................... 49 4.10 ARCHITECTURE FRAMEWORKS ..................................................................................................... 50 3 4.10.1 The EA Cube framework ..................................................................................................... 52 4.10.2 The EA Toolkit IT Framework.............................................................................................. 53 91H 360H 92H 361H 93H 362H 94H 36H 95H 364H 5. DESCRIPTION OF THE CURRENT STATE............................................................................... 56 96H 365H 5.1 INTRODUCTION ............................................................................................................................... 56 5.2 BUSINESS STRATEGY DOCUMENTS .................................................................................................. 56 5.2.1 Vision of the structure reform................................................................................................. 56 5.2.2 Goals....................................................................................................................................... 56 5.2.2.1 Strategy for digital strategy for the municipalities28F ........................................................ 56 5.3 THE HISTORY OF EA IN DENMARK LTD. ......................................................................................... 57 5.3.1 Recommendations ................................................................................................................... 57 5.3.2 Joint Enterprise Architecture Framework.............................................................................. 57 5.3.3 Principles................................................................................................................................ 58 5.3.4 Structure ................................................................................................................................. 59 5.3.5 Guidance................................................................................................................................. 60 5.4 THE BUSINESS DRIVERS ................................................................................................................... 60 5.4.1 Key constraints ....................................................................................................................... 60 5.4.2 The six W’s.............................................................................................................................. 60 5.4.2.1 Who?................................................................................................................................ 60 5.4.2.2 What?............................................................................................................................... 67 5.4.2.4 When? .............................................................................................................................. 69 5.4.2.5 How?................................................................................................................................ 69 5.4.2.6 Why?................................................................................................................................ 75 5.4.2.7 Where?............................................................................................................................. 76 97H 36H 98H 367H 9H 368H 10H 369H 10H 370H 102H 371H 103H 372H 104H 37H 105H 374H 106H 375H 107H 376H 108H 37H 109H 378H 10H 379H 1H 380H 12H 381H 13H 382H 14H 38H 15H 384H 16H 385H 6. ANALYSIS OF THE CURRENT STATE ...................................................................................... 77 17H 386H 6.1 INTRODUCTION ............................................................................................................................... 77 6.2 STRESS POINTS/RISKS ...................................................................................................................... 77 6.3 STRENGTHS AND WEAKNESSES ....................................................................................................... 77 6.3.1 Strengths ................................................................................................................................. 77 6.3.2 Weaknesses ............................................................................................................................. 77 6.4 CHALLENGES .................................................................................................................................. 78 6.5 ENVIRONMENTAL FACTORS............................................................................................................. 79 6.6 GROWTH/COST CONTAINMENT OPPORTUNITIES............................................................................... 79 18H 387H 19H 38H 120H 389H 12H 390H 12H 391H 123H 392H 124H 39H 125H 394H 7. DESCRIPTION OF THE TARGET STATE.................................................................................. 80 126H 395H 7.1 INTRODUCTION ............................................................................................................................... 80 127H 396H 8. ANALYSIS OF THE TARGET STATE ......................................................................................... 81 128H 397H 8.1 INTRODUCTION ............................................................................................................................... 81 8.2 INTEGRATION .................................................................................................................................. 83 129H 398H 130H 39H 9. EA MANAGEMENT PROGRAM .................................................................................................. 84 13H 40H 9.1 INTRODUCTION ............................................................................................................................... 84 132H 401H 10. CONCLUSION, REFLECTIONS, PERSPECTIVES ................................................................. 87 13H 402H Page 4 of 112 Enterprise Architecture of public Denmark Master thesis, December 2006 10.1 CONCLUSION................................................................................................................................. 87 10.2 REFLECTIONS ................................................................................................................................ 87 10.3 PERSPECTIVES ............................................................................................................................... 88 134H 403H 135H 40H 136H 405H REFERENCES ...................................................................................................................................... 90 137H 406H LITERATURE ......................................................................................................................................... 90 INTERVIEWS .......................................................................................................................................... 96 138H 407H 139H 408H APPENDIX............................................................................................................................................. 97 140H 409H APPENDIX 1: THE STUDY SURVEY REPORT .......................................................................................... 97 APPENDIX 2: ZACHMAN FRAMEWORK .................................................................................................. 98 APPENDIX 3: BERNARD’S EA3 CUBE .................................................................................................... 99 APPENDIX 4: FRAMEWORK FOR COMMUNITY MERGENCE BY FLEMMING HALD AND BO KRISTENSEN ........................................................................................................................................................... 100 APPENDIX 5: CHALLENGES FACING THE PUBLIC SECTOR IN THE FUTURE IN DENMARK ....................... 101 APPENDIX 6: CITIZEN SURVEY MADE BY COMPUTERWORLD AND USERNEEDS, DECEMBER 2006 ...... 102 APPENDIX 7: MAP OF THE “NEW DENMARK” AFTER THE STRUCTURE REFORMATION ......................... 104 APPENDIX 8: ENTERPRISE ARCHITECTURE VALUE MEASUREMENT METHODS FRAMEWORK ............. 105 APPENDIX 9: THE RESPONDENTS......................................................................................................... 106 APPENDIX 10: INTERNET QUESTIONNAIRE (HTTP:WWW.FLEMMINGHALD.DK/EA)............................... 107 GLOSSARY .......................................................................................................................................... 112 General terms ................................................................................................................................ 112 Danish terms .................................................................................................................................. 112 14H 410H 142H 41H 143H 412H 14H 413H 145H 41H 146H 415H 147H 416H 148H 417H 149H 418H 150H 419H 15H 420H 152H 421H 153H 42H Page 5 of 112 Enterprise Architecture of public Denmark Master thesis, December 2006 Abstract Enterprise Architecture – often referred to as business oriented use of IT or simply put EA – has been an issue within the public domain at State level for some time now. It is often used in conjunction with another popular acronym, SOA, Service-Oriented Architecture. The intentions of EA in public Denmark has been formulated through a white book and the Ministry of Finances are talking about the strategic use of IT in the public domain. This thesis sets out by analyzing the maturity of the municipalities and the State of this matter. It does so by describing the EA activities within the public domain. These are described based on a comprehensive survey made within the field targeted towards the municipal CIO’s. I reach the conclusion that the municipalities not are at a mature state in regard to the awareness, propagation and use of enterprise architecture. I reach the conclusion that the State is however more mature in this area. But there is something missing in the way the public is structured in order to move Denmark upward the maturity ladder and to support, coordinate and communicate EA efforts throughout the entire public sector. The answer lies in the organizational structure. From my research I propose the establishment of an Enterprise Architecture Committee as a central actor in carrying out all EA initiatives throughout public Denmark. This newly formed committee will be in close connection with already established and well functioning councils and committees. Representatives of the most important actors will be part of this committee thus carrying weight and influence behind its initiatives and suggestions. Page 6 of 112 Enterprise Architecture of public Denmark Master thesis, December 2006 Introduction The Danish Parliament announced just before the summer holidays in 2005 the law package dealing with the task- and structure reformation. This law was passed by June 16, 2005 and will be carried out by January 1, 2007. It suggests the merging of municipalities in Denmark as well as replacing the counties with regions. Another consequence is that many tasks will be reallocated within the public sector in Denmark. The municipalities have responded much differently to the challenges which inevitably will follow. Some municipalities have been visionary and have seen this as an opportunity to also restructure the IT infrastructure and the use thereof and have taken steps toward implementing IT as part of their business strategy. Other municipalities have merely floated along the main stream focusing only on “safe use of IT” with no vision or innovation. We still see each municipality doing what they want to do and the socalled silos are still present in the different municipalities. Even though steps have been taking to ensure standards, interoperability and openness in the public sector we are far away from seeing this realized. "The significant problems we face cannot be solved by the same level of thinking that created them." - Albert Einstein The focus needs to be higher – on enterprise architecture – the organizing logic for core business processes and IT infrastructure reflecting the standardization and integration of a company's operating model. “Therefore enterprise architecture boils down to these two concepts: business process integration and business process standardization. In short, enterprise architecture is not an IT issue - it's a business issue" (Weill & Ross, 2006). The purpose of this thesis is to describe the EA activities in Denmark as well as finding out at what level the municipalities and the State find themselves in, in relation to enterprise architecture, and finally what will the next step be for these governmental bodies embracing enterprise architecture. Page 7 of 112 Enterprise Architecture of public Denmark Master thesis, December 2006 Background The originally starting point for the present study rests on previous research, where problems perceived within Slagelse municipality, a city merging from four totally different cities into one single city, seem to lack an overall IT strategy. Between the different municipalities there was a need, but no consisting method, for information exchange between the municipalities and its citizens. I set out to analyze why this was so, and found a gap between the overall strategy and the use of IT. At that time Bo Kristensen and I found a method to bridge this gap by suggesting a best practice EA framework for merging municipalities (Kristensen & Hald, 2005). Having noticed this problem in other municipalities as well, I will now set out to describe and analyze the awareness and use of EA across the Danish municipalities. This thesis presents the results of my research within this field. Intended audience In order to make this thesis as widely accessible as possible it is written in English. Thus it is written with an international audience in mind. To this end, a glossary of the most common Danish terms can be found at the very end of the thesis. The result of my research is not limited to a so-called Danish model alone, but could universally be adopted by other countries as well with a similar democratic public structure as can be found in Denmark. Structure of the thesis In order to gain a better overview of the structure of this thesis, I have chosen to show this in a graphical view as can be seen from figure 1. This figure indicates eight main stages. The small number in each frame indicates the subject stage. At “ground zero” or stage zero I will pose my research problem as a question with hypothesis. The hypothesis posed is based on prior observations of the subject and will provide the basis for later empirical testing. In stage one, the scope of research will be described, and here I will describe areas of significance and limitations in relation to my research. I will also include the outcome expected of my research as well as the intended deliverables. In stage two I will describe the chosen methodology, or W Scope of research Research problem \ Description of current state Analysis of current state Y X Methodology ] Description of target state ^ Key findings from survey Analysis of target state Z _ Literature Review [ ` EA management program Conclusions, a reflections, perspectives Figure 1. Structure of the thesis. Page 8 of 112 Enterprise Architecture of public Denmark Master thesis, December 2006 the way in which I systematically will address my research problem. This description is two-fold: 1) a description of the literature review in connection to methodology and 2) a description of the methods applied for collecting and analyzing data for my research. Stage three contains the key findings from the survey study report. At this stage I expect to find out the general EA maturity level of the municipalities. Stage four, literature review, constitutes the main theoretically research portion of the thesis. From this research, a common terminology on a number of aspects of EA is decided upon. Among other things an EA framework will be selected for the further work. This stage will also be the input to the development of the Internet based questionnaire – e.g. which EA areas should I include in the survey in order to fully address my research problem. In stage five, the description of the current state of EA in Denmark will be described. This entails the collection of key facts about the business: just the facts…and nothing but the facts. This description of facts will serve as introduction to stage six, analysis of the current state of EA. This stage will analyze the problems and challenges faced by the public sector seen from a number of different criteria prescribed by the framework selected in stage four. A great deal of the content of stages five and six, will originate from the developed study survey report. Once the baseline description of where the public sector is today is completed, I will focus on where it wants to go. Stage seven, description of the target state, basically describes this, and where the business will be if the problems and challenges are resolved. Another way of looking at this stage is seeing the achievement of missions and goals. Stages five and six will be input to stage seven. Stage eight, analysis of target state, is about comparing the ‘analysis of current state’ with the ‘description of target state’ and then I will identify any gaps and opportunities. All this gives us a set of target business opportunities to direct and drive the IT architecture effort. Having accomplished this, stage nine will describe an EA management program. This is often referred to as a transformation program. What this basically means is that it suggests how to move from current state to desired target state taking into consideration an ever changing environment. A summary of this stage will constitute “The next step…” in the study survey report. Finally, in stage ten, I will conclude on the research problem from stage one. I will reflect on the process I have been through during the making of this thesis and the study survey report. At the end of stage ten, I will attempt a bird’s eye view and go beyond EA and provide a perspective on alternative solutions, theories or other practices that might be more suitable in the pursuit of an optimal digital public sector in answer to the research problem. Relationship between the two reports This thesis is made up of two reports: the background report and the study survey report. On one hand, the reports are separate in the sense that they focus on two different target groups, and on the other hand they can be considered as one (as is the case with this thesis) in the sense that they provide useful information for each other, thus creating one whole report. Figure 2 illustrates the structure of the reports as well as their inter-relationship. For the sake of not violating any formal rules of CBS 1 the study survey report will be placed as appendix 1 2. 0F0F 1F1F I have two different target groups in mind with each report. The background report is targeted towards my supervisor and the external examiner as well as those who would like background information of the structure and content of the study survey report. The study survey report is first and foremost targeted towards the municipalities and secondly, towards foreign authorities or agencies with an interest in public EA. 1 2 CBS = Copenhagen Business School, http://www.cbs.dk See appendix 1 Page 9 of 112 Enterprise Architecture of public Denmark Master thesis, December 2006 Study survey report Background report 1. Research problem 2. Scope of research 3. Methodology 4. Key findings from survey 5. Literature review 6. Description of current state 7. Analysis of current state 8. Description of target state 9. Analysis of target state 10. EA management program 11. Conclusions, reflections, perspectives X Y Z [ 1. 2. 3. 4. Introduction EA key results EA in the public sector EA motivation, goals and barriers 5. EA measurement 6. EA process 7. EA framework 8. EA tools 9. EA governance 10. EA assets 11. The next step… Figure 2. The relationship between the two reports Their ongoing inter-relationship is based on four ways of providing input to the other (note the arrows of Figure 2). The first arrow indicates the methodology chapter will provide the necessary input for me to produce a valid and reliable survey instrument. This helps me to know how to formulate the questions, decide on the length of the questionnaire, whom to send out to, when to send out, i.e. all about the survey instrument itself. The second arrow will provide me with the necessary professional knowledge to identify which areas of EA should be addressed in the survey in order to fully address the research problem, i.e. all about which content to put into the instrument. The third arrows going from the study survey report to the background report provide vital input to the main chapters of the background report. The fourth arrow represents an abridged version of the EA management program transferred to the study survey report suggesting the municipalities what to do next, the so-called “Next Step”. Guidance for reading I suggest my supervisor and the external examiner will read the background report first for gaining an understanding of the background of the structure and content of the survey instrument. The municipalities and State actors will most likely only be interested in the study survey report, but can gain further knowledge and insight by studying this background report. Page 10 of 112 Enterprise Architecture of public Denmark Master thesis, December 2006 Research Problem Overall question From the above mentioned purpose of the thesis I have formulated the overall question: What Enterprise Architecture activities are currently applied within the public domain of the municipalities and the State? Hypotheses 1. The awareness, propagation and use of Enterprise Architecture in the Danish municipalities are immature. 2. The awareness, propagation and use of Enterprise Architecture at the national level in Denmark are mature. These hypotheses are based on observations from previous research on the subject of Enterprise Architecture within municipalities merging. It is the aim of this thesis to either validate or falsify this hypothesis. 1. Scope of research 1.1 Areas of significance In order to validate or falsify the hypotheses, EA will be addressed as a discipline with a primary focus on the interrelationship of the municipalities and the relationship between the state and the municipalities in serving the citizens. The view of research is thus mainly of a horizontal nature spanning across the municipalities. Vast information both on the theory part as well as the subject of the merging municipalities exist. In the theory part, I have emphasized two criteria in the selection of my literature: 1) those who favor practical approaches and 2) those generally well known EA advocates others build their theories on in the EA field (see literature review for more detail). For the subject part, I have especially emphasized secondary sources. This entails 1) previous survey and 2) previous research on the matter. 1.2 Areas of limitations It goes beyond the scope of this thesis to deal with the tasks and structure of the new regions, wherefore I will not describe or analyze the regions at all. The reason for this is that I believe they play an inferior role compared to the municipalities and the State in the new structure reform. As far as municipal tasks goes, I will not look upon the internal administrative tasks such as salary, staff, logistics, procurement etc. just as I will not deal with the subject of companies in this thesis. The main focus is the citizens, the national authority tasks and service tasks within the municipalities and the State of Denmark (see chapter 5.4.2.2 for further detail). It is likewise outside of the scope, to make a thorough research comparison with other countries’ municipalities to see what Denmark can learn from these. I will however touch lightly upon this matter in referring to relevant research results produced by the US at the end of the thesis. Even though this study is intended for an international audience, the scope of context of my own research is national, and Page 11 of 112 Enterprise Architecture of public Denmark Master thesis, December 2006 deals exclusively with the State of Denmark and its municipalities. I will only lightly touch base on the topic of Service-Oriented Architecture (SOA). I do believe however that this is a most essential topic wherefore it has been included in relevant places in this thesis where it provides insight to the study question at hand. Another reason for including SOA is that programming simply is entering the era of services, and services are a realization of SOA. There is simply no way around it these days. 1.3 Expected outcome of research The expected outcome of my research will be a proposal of an overall transformation plan for the public sector to use when moving from a current view to a future view of their EA program. There will be focus on the municipalities. In order to substantiate this plan and as mentioned earlier, two reports will be produced, a background report and a study survey report. 1.4 Intended deliverables I intend to deliver a study survey report documenting the propagation of EA in public Denmark as well as a background report forming the basis of the development of the study survey report. This background report also documents and analyzes the findings from the study survey report and describes and analyzes the current and future state of public EA in Denmark. Finally, I will seek to lay out an EA management plan which suggests where the public sector should go from here; this is called “The next step…” and can be found in the Study Survey Report. 1.5 Objective of the thesis The objective of this study is to obtain an overview of current Enterprise Architecture activities in the Danish municipalities and in the State. This overview will form a picture of the current EA state, and will serve as input to answer the study’s main question: What Enterprise Architecture activities are currently applied within the public domain of the municipalities and the State? Figure 3. The main question of the study I do not expect to gain a perfect knowledge of this picture from the study, but I do expect sufficient insight based on my research in order to make an intelligent decision as to validate or falsify the hypotheses in question: 1. The awareness, propagation and use of Enterprise Architecture in the Danish municipalities are immature. 2. The awareness, propagation and use of Enterprise Architecture at the national level in Denmark are mature. Figure 4. Hypotheses of the study 1.5.1 Relation between problem area and the hypothesis 1 In validating and/or falsifying the two hypotheses, I will indirectly address the overall question of the problem area. In case of validation of the first hypothesis, a new proposed EA management program on the matter will be developed and recommended from the synthesis the primary research (the study Page 12 of 112 Enterprise Architecture of public Denmark Master thesis, December 2006 survey report and description/analysis of the current/target state) and the secondary research (literature review) is expected to form. This management program could be considered a best practice and will form the next step for the public sector to take in order to move closer to public EA in Denmark. This will not only answer the overall question of the problem area, but also provide a solution for moving on to the next level. In case of falsification of the hypotheses, the results will be re-analyzed and again the next steps for the public sector is described, now only at a higher, more mature level. Either way the hypotheses will assist in answering the main question of the study. 1.5.2 Relation between problem area and the hypothesis 2 In case of validation of the second hypothesis, the results will be collected again and the next more mature steps for the public sector will be described. In case of falsification, a new proposed EA management program on the matter will be developed and recommended from the synthesis the primary research (the study survey report and description/analysis of the current/target state) and the secondary research (literature review) is expected to form. 1.5.3 Clarification of preliminary concepts Before continuing, I need to clarify the definition of the word ‘mature’ and ‘immature’. The Oxford dictionary defines mature as ‘fully grown or physically developed; adult’. The Merriam-Webster dictionary defines it as ‘having attained a final or desired state’. The Encarta dictionary defines mature as ‘showing qualities gained by development and experience’. I will use the last definition of mature: Showing qualities gained by development and experience. Immature will then be the opposite ‘showing no qualities due to lack of development and experience’. For practical reasons, I set the EA maturity factors equal to the number of 80% or more and 20% or less in determining whether or not the municipalities are mature within an aspect of EA. Everything in-between is semi-mature and cannot be assessed as either or. These are basic assumptions used throughout the thesis in assisting the validation or falsification of my hypotheses. 2. Methodology 2.1 Introduction As stated earlier, this stage deals with the way in which I systematically will address my research problem. Here I will present process areas of two aspects: 1) research design and 2) methods applied for collecting and analyzing data for my research. 2.2 Research Design There are two main categories of research design (Field, 2005; Joppe, 2005) namely 1) exploratory research and 2) conclusive research. Conclusive research can be subdivided into: 1. descriptive research 2. casual research Page 13 of 112 Enterprise Architecture of public Denmark Master thesis, December 2006 Each of these types relies on one or more data collection techniques: 1. Primary research a. Observation techniques b. Direct communication with subjects, e.g. survey technique, interview or projective methods 2. Secondary research a. Literature review b. Data sources collected for other purposes than the study at hand Irrespective of the chosen data collection technique, it is critical for me to analyze it for its validity and reliability. Another critical consideration is the number of subjects to address. Addressing all elements in the population, i.e. all CIO’s in the municipalities, may be ideal, but not very practical and far too costly. Instead with careful guidance from my supervisor, I choose a minimum response sample rate from my survey of 33% of the entire population before closing the survey, thus using the so-called probability sampling technique. Exploratory research is often conducted because a problem has not been clearly defined yet or its real scope is unclear. It is often the first research method to use before any conclusive research is conducted. Exploratory research either allows the researcher to generate hypotheses to be tested or to test concepts before being sent out to the market. Exploratory research can be quite informal relying on secondary research such as review of literature and data or qualitative approaches such as informal discussions with consumers, competitors, or employees or perhaps more formal approaches through in-depth interviews, focus groups, case studies or pilot studies. Descriptive research – sometimes referred to as statistical research – provides data about the population or universe being studied. In its nature it is limited to “only” describe “who, what, when, where and how” of a situation, not what caused it. Therefore this is the preferred method that is as factual and accurate as possible. It provides the number of times something occurs – frequency – thus ideal for statistical calculations. The two most commonly used types of descriptive research designs are: 1. Observation 2. Surveys Both the observation technique and surveys are primary methods of collecting data. When a particular behavior needs to be recorded observation is often the chosen type of research design. Observation is not relevant for my study. When many different types of information needs to be collected, including attitudinal, motivational, behavioral and perspective aspects a questionnaire is often used. It is very popular because it allows for standardization and uniformity both in the questions asked and in the method of approaching the subjects making it much easier to compare and correlate answers by the respondent group. It also ensures higher reliability than many other techniques. There are of course both advantages and disadvantages for conducting such a survey. The most obvious advantages are that it provides an efficient and accurate way of determining information about a given population. In my case this is the municipal CIO’s. Results can also be provided quickly and they are relatively inexpensive. Page 14 of 112 Enterprise Architecture of public Denmark Master thesis, December 2006 Having said this, there are of course also disadvantages. Probably the greatest is that the respondent knows he or she is being watched and this can lead to invalid responses inasmuch as the respondent may want to impress (e.g. by giving the impression that they are better or know more about EA than what is real) or please (e.g. by giving the kind of response they believe the researcher is looking for) the researcher. This is known as response error or bias. The willingness or ability can also cause a problem. If the questions are considered sensitive or intrusive this could keep many away from responding. I have made it very clear that my survey is anonymous, thus hoping all will be willing to “take the risk” in responding to my questions. If the people who refuse really are different from the rest, this is known as non-response error or bias. If an interview is held the interviewer can inadvertently influence the respondent by the way he poses the questions, stresses certain words or his body language. Even facial expressions or the cloths he wears can influence the respondent. This is known as interviewer-error or bias. There are many factors that can influence the response rate: • The chosen method • The length of the questionnaire • The type of questions • The time of day or place • The relevancy of the questions compared to the respondents position There are three types of surveys: • • • Telephone Self-administered Interview I choose to conduct a survey as my preferred descriptive research method type 3. The reason for this is due to the high number of elements in the population of my universe of discourse: 98 municipalities. Among other things, I expect to find out from as many as possible – a minimum 33% – what the knowledge is of Enterprise Architecture in the municipalities, how many uses it, and how much they use it etc. All these questions fall into the category of descriptive research, and the best way to aim as many as possible is through conducting a self-administered survey, despite of the disadvantages herein. I will therefore conduct an Internet based survey in order to find out “what is going on with EA” in the municipalities of Denmark. 2F2F I have not touched upon casual research yet. This is another branch of conclusive research where you try to establish a so-called cause-and-effect relationship between variables. This type of research is often very complex and the underlying methods are experimentation and/or simulation. The researcher can never be sure though if there are no other factors influencing the casual relationship. 2.3 Data collection techniques As mentioned earlier, when doing primary research, data is collected for the study at hand. This can be obtained by having the researcher observing the subject being studied, or by communicating directly or 3 See http://www.flemminghald.dk/ea or Appendix 10 Page 15 of 112 Enterprise Architecture of public Denmark Master thesis, December 2006 indirectly with the subject. Direct communication techniques include qualitative research techniques such as in-depth interview, focus groups and projective techniques, while quantitative techniques include techniques such as telephone, self-administered and interview surveys. 2.4 Research review Knowledge is – as science – cumulative. Therefore before one of the above-mentioned techniques are attempted it is important to commence all research with a review of the related literature or research at hand, and to determine whether any data already exist that can be brought to solve the research problem at hand. This is often referred to as secondary research. Each study of an earlier work will provide the basis of the future work done by others. As far as I know from my present and previous research, there is no description and analysis of EA across the municipalities compared to the State view. Therefore this will be new knowledge brought forth, which other researchers hopefully can benefit from. There are however adjacent research with indirect influence to my study question. These comprise “Analysis of Enterprise Architecture in connection with the merging of municipalities” (Bo Kristensen et al, 2005), “An International Enterprise Architecture survey, trends in governmental Enterprise Architecture on a national level” (Peter Engelund Christiansen, 2006) and “Service Oriented Enterprise Architecture” (Rasmus Knippel, 2005). I will include relevant parts of this previous research in my thesis when relevant. I will not list the all the number of persons quoted in my literature review, but instead present the criteria on which I have based my selection. Having read a great number of books, papers, articles, reviews and commentaries from the enterprise engineering community, I have especially emphasized the following criteria when selecting my literature: 1) those who favor practical approaches (NIST 1989, Armour et al. 1991a, Hasselbring 2000, The Open Group 2002, Buchanan and Soley, 2002, and Heffner 2002) and, 2) those generally well known EA advocates others build their theories on in the EA field such as Zachman (1987), Spewak (1992) and the Open Group (1995). 2.5 Validity Validity determines whether the research really measures that which it was intended to measure or in other words: how truthful are the results? Does the research instrument allow me to hit “the bull’s eye” of my research object? Starting with the research question: What Enterprise Architecture activities are currently applied within the public domain of the municipalities and the State? Can I actually answer this overall research question with the research instrument selected? Are the respondents truly a representation of the entire population? What if a certain type of CIO is not reached through the survey? Setting a high percentage of respondents (33%) diminish the risk of not capturing all types of the respondents’ views. Having this in mind, I believe I can answer the overall question with a database-driven questionnaire that asks for general input on a number of EA aspects substantiated through personal interviews and relevant literature. In order to identify which areas to cover and the wording of the questions I want to review literature and other research projects, so I will be able to produce a more sufficiently valid questionnaire that can more fully help in answering the research question at hand. Page 16 of 112 Enterprise Architecture of public Denmark Master thesis, December 2006 I have a general idea that early in the morning is the best time for me to send out invitations for participating in my survey to the CIO’s. I plan on having the survey run for three weeks and have the invitations sent out Monday of the first week, Tuesday of the second week and Wednesday of the third week in order to reach the “magic 33%” respondents percentage thus securing external validity. I will ask a number of people to help me pre-test the instrument. Some of them know little and some know much about the subject matter; and can help me ensure the questions are clearly worded and easily understood. I will look at other research and its wording in this connection. This I find important when measuring more subjective concepts such as attitudes and motivations of which I have a few in my questionnaire. I will consider asking the same question in different ways or repeat it at a later stage in the questionnaire in order to test for consistency in the responses. This will confirm criterion validity. This I will only do once or twice though, due to the estimated length of the questionnaire. Probing for attitudes usually requires a series of questions that are similar, but not the same. This battery of questions should be answered consistently by the respondent. If it is, the scale items have high internal validity. I will therefore put most of these ‘attitude’ questions close together. All this will increase the validity of my research instrument. 2.6 Reliability The extent to which results are consistent over time and an accurate representation of the total population under study is referred to as reliability. This means that if the results of the study can be reproduced with a similar methodology, then the research instrument is considered to be reliable. If questions can be misunderstood, and therefore is answered differently by respondents, you have low reliability. One way of finding out if this is the case is by running a test-retest, where a respondent would be asked to answer the survey at two different times. This also gives an indicator of the stability of the measurement. If I have a stable measure, then the results should be similar. A high degree of stability indicates a high degree of reliability, since the results are reproduced. The disadvantage of this method is that external factors such as change in attitude can influence the respondents answer and these factors are very difficult to detect. I will not ask my respondents to respond to my questionnaire twice, since first of all I do not have much time at hand, and secondly, the CIO’s probably have less time than I do, being busy with merging activities. Usually reliability is a function of validity. This means that validity often presupposes reliability. The reverse is not always the case however. I can end up proving the research instrument’s repeatability and internal consistency, and therefore reliability, while the instrument itself may not be valid, meaning that it does not measure what the research proposed to determine. 2.7 Data analysis 2.7.1 Pre-test The main reason for pre-testing will be to test three in particular areas involved in writing the questions: • • • Determining the question content, scope and purpose Choosing the response format that I should use for collecting information from the respondent Figuring out how to word the question to get at the issue of interest Page 17 of 112 Enterprise Architecture of public Denmark Master thesis, December 2006 So after having developed the instrument, I will enter my three-loop pre-test phase. In the first phase, I will ask a few acquaintances who know very little about the topic of study, merely to make sure the sentences are readable. In the next pre-test phase, I will invite people in the target group (two CIO’s, one IT strategy person, and one IT-architect) and the chairman for KIT@ (The Association of Municipal CIO’s) to pre-test the instrument in order to ensure its validity and reliability. This phase two will be repeated in phase three as an iterative process. 2.7.2 Measurement and scaling The first question I will need to ask myself is: “What is to be measured?” I wish to measure the awareness, propagation and use of Enterprise Architecture in the Danish municipalities in order to identify an EA maturity level. The survey instrument will not address the national level of EA maturity since this will be dealt with later in chapter 4.8. I would define the maturity mostly in objective closed “either-or” questions; I will however also measure a few key areas with attitudinal questions in particular in relation to the common public citizen portal and the possibility of a future joint municipal IT co-operation. In conclusive research, where I rely on quantitative techniques, the objective is to express in numeric terms the difference in responses. Hence, a scale is used to represent the item being measured in the spectrum of possibilities. There are four basic types of scales: • Nominal • Ordinal • Interval • Ratio Nominal scale indicates the use of a label, e.g. “1” for having an IT-strategy and “2” for not having an IT-strategy. Ordinal scale indicates a classification of items to show if they have more or less of a characteristic, e.g. how would you rate the joint citizen portal? Excellent O Very Good O Good O Fair O Poor O One of the problems with ordinal scales however is the uncertainty attached to the responses. Does the ‘Good’ response by one, really mean ‘Excellent’ by another? Understanding ‘the language’ of the population is here very important. Likert’s ordinal scales are typically a question posing a statement and ask the respondent whether they Strongly Agree – Agree – Undecided – Disagree or Strongly Disagree. His scale is commonly used in attitudinal measurements. Interval scales are similar to the ordinal except for the distance between the adjacent points on the scale are equal, e.g. How much of your business architecture are kept up-to-date? 0%-20% O 20%-40% O 40%60% O 60%-80% O 80%-100% O Finally the ratio scale is like the interval scale, except it has a true zero scale. For example height, weight etc. have a true zero. It makes sense to say that 2 meter is twice as large as 1 meter. The ratio scale is the most sophisticated and incorporates all of the other three scale types. Page 18 of 112 Enterprise Architecture of public Denmark Master thesis, December 2006 The most common measurement methods are: • The mean • The frequency • The mode • The percentile • The median • The range The mean indicates an average number. The frequency indicates the number an item appears in the whole distribution. The mode refers to the most common value in a set of observations. The percentile indicates that when data are skewed and off from a standard deviation, e.g. if the 85% percentile of household income is $60,000, then 85% of households have incomes of $60,000 or less, while the top 15% of households have incomes of $60,000 or more. The median is the most famous percentile. It is called the 50th percentile splitting the data in half – half of the data are above the median; half of the data are below the median. The range simply indicates the highest value minus the lowest value. Mapping these measurement methods to the various types of scales we get Table 1. The nominal (using labels) The mean The frequency The mode The percentile The median The range X X The ordinal The interval The ratio (using classification) (20%-40%) (same as interval with true zero) X X X X X X X X X X X X X X X X Table 1. Comparison of measurement method and types of scales. Source: Own contribution In order for me to answer my hypotheses most of the questions will be on a YES/NO nominal scale as it has no order or distance between them. I will for the greater part need to determine “How many” or “How much”-type of questions. This is the frequency measurement and belongs to a nominal scale. It is vital that the response categories include all possible responses. To be exhaustive in the response categories, I will have to include ‘other’ and/or ‘don’t know’ as an option. I do not find Likert’s ordinal type of scale relevant for my study! Instead I do find the interval scale extremely relevant in seeing the degree of EA aspects used by the municipalities. To sum up I use the interval and nominal scales in my study survey. 2.7.3 Types of questions In general there are two types of questions: open-ended (open) questions and closed-ended (closed) questions. The former are required to respond with their own words, whereas the latter consists of a number of alternative responses. Closed questions are much easier to interpret since they are standardized and can be analyzed analytically. These types of questions are also quicker to complete for the respondent. The disadvantage is that they are more difficult to write since all possible responses must be thought of beforehand. Ultimately, the respondent is being asked to select the response closest to his/her own point of view. Page 19 of 112 Enterprise Architecture of public Denmark Master thesis, December 2006 Open-ended questions are questions that encourage people to talk about whatever is important to them. Referring to students, The Johns Hopkins University in Baltimore suggest that ”Open-ended questions should lead students to think analytically and critically. Ultimately, a good open-ended question should stir discussion and debate in the classroom sparking enthusiasm and energy in your students 4.” This is exactly what I hope my four open-ended (attitudinal) questions in my study survey will give rise to. 3F3F 2.7.3.1 First open-ended question “One of the purposes of the structure- and task reform is for the municipality to be the primary entrance of the citizens’ contact with the public in the future. Yet KL is doing a joint public citizen portal at www.borger.dk. What do you think about that?” 154H 2.7.3.2 Second open-ended question “What could be your municipality’s primary motivation for participating in a joint municipal IT cooperation concerning solution of common tasks after January 1, 2007?” 2.7.3.3 Third open-ended question “What do you see as the greatest obstacle in obtaining this joint IT co-operation?” 2.7.3.4 Fourth open-ended question ”How do you assess the optimal organisation of common solution of common tasks in a joint municipal IT co-operation?” The first open-ended question is purposely written as a leading question with two extreme choices: 1) www.borger.dk is superflous, 2) www.borger.dk is indespensable with the escape option of 3) No opinion. The reason for these two extremes are that I want the CIO’s to take a stand, not just cross off an in-between option such as ’Fairly good’ or ’Relevant’. This does not tell much. And then I want them to substantiate their answer by providing a ’Please-give-a-reason-for-your-reply’ text box for them. 15H 156H The second open-ended question was at first worded as a multiple-choice question, but was later changed to a semi-open question with the word ’primary’ added to the question and a fixed response list consisting of 13 choices and an escape option ’No matter what I will not participate” to choose from. This was done in order to have the municipal CIO’s taking a stand. The third open-ended question underwent similar ”surgery” as the second open-ended question. Only this time the word ’greatest’ was added as well as a list of six choices and the escape option ’Other’. If ’Other’ was chosen, I want them to specify, hence the ’Specify’ textbox. The fourth open-ended question is not quite as complex in its response options. Only three options, including an ‘Other’, are possible. And again, if ‘Other’ is chosen, another ‘Specify’ textbox appears. The reason for producing these long pre-determined lists are it is much easier to make statistic material on selections instead of extracting key words from sentences. The risk is that I do not cover all possible responses, wherefore it will take a long time and analysis to produce this list. Even though open-ended questions certainly have its justification, I will attempt to produce a structured questionnaire with as few open-ended questions as possible. The majority of the questions will most 4 http://www.jhu.edu/gifted/teaching/strategies/analysis/openendedquestions.htm Page 20 of 112 Enterprise Architecture of public Denmark Master thesis, December 2006 likely be closed questions of quantitative nature, since I will need to produce statistical material in order to more fully answer the research question with its attached hypotheses. I will group my questions into categories that are meaningful. A part of the literature review will serve as input in determining these categories (see figure 2). Once I receive a minimum of 33% responses, the data will need to be ‘cleaned’. This means ensuring the data is entered correctly and correcting any errors. I will check for accuracy in a couple of ways: • Double entry: data has been entered twice and any discrepancies are verified against the original questionnaire • Scanning for errors in values based on the original questionnaire, e.g. if only four values are possible there should not be a value ‘5’. Then the data will be ready for tabulation and statistical analysis. I will in this part do the following: • Describe the background of the respondents based on demographic information; • Describe the responses made to each of the questions; • Compare the behavior of various demographic categories to one another to see if the differences are meaningful or simply due to chance; • Determine if there is a relationship between two characteristics as described; and • Predict whether one or more characteristic can explain the difference that occurs in another. The focus will not however be on the respondents, but rather on the direct response made to each of the questions as well as various types of cross references in order to identify any correlation. As stated earlier I will describe the outcome mainly as percentages in a so-called frequency distribution. This will also be done in describing the responses made to each of the questions. In cases of “typical” or “average” response this is sometimes referred to as central tendency. In order to compare the behavior of various demographic categories to one another to see if the differences are meaningful or simply due to chance, I am really determining the statistical significance by tabulating two or more variables against each other in a cross-tabulation (e.g. "There is clear evidence of a relationship between gender and attendance at cultural venues. Attendance by women was statistically higher than men’s"). 157H 158H In determining a relationship between two characteristics I am estimating a correlation. Finally, in trying to predict whether one or more characteristic can explain the difference that occurs in another, I could ask a question such as “Is the geographical area of the municipality linked to the maturity of EA?” 2.7.4 Tools The study survey report will be produced in this manner: I will use SQL to extract the outcome. Then I will transfer these data to Excel where charts will be produced. These I will export to Illustrator to produce quality vector graphics and subsequently import these into InDesign for the graphical layout. Page 21 of 112 Enterprise Architecture of public Denmark Master thesis, December 2006 3. Key findings from the survey 3.1 Background of the respondents Normally one would describe the respondents based on their income, habits, age, gender, education and so forth, but these are most relevant in consumer surveys in order to improve the marketing of products/services. I want to find out what the EA activities within the public domain are. In answering this question, I do not find it relevant to ask for this normal demographic variable input from the respondents, as I believe they are mutually independent of the study of the EA activities at hand. Therefore the only demographic variables 5 included in the questionnaire are • Job function • Geographic location (inferred from the name of municipality). • Type of municipality they belong to (e.g. merging municipalities). 4F4F The majority of the respondents (58%) lives on Zealand; are CIO’s (88%) and belongs to a merging municipality (52%). 3.2 Frequency Distribution The general collection of the frequency distribution of single survey questions can be seen in the produced study survey report. Having the hypothesis in mind in which I state that the awareness, propagation and use of Enterprise Architecture in the Danish municipalities are immature, I will present the areas of which I find the municipalities immature within this type of distribution. As mentioned earlier the 20%/80% assessment indicator of maturity will be used to establish this fact. This is not an absolute truth, since I am aware of the general uncertainty connected to all statistical data, but it gives us a rather good indicator of what is likely to be ‘the truth’. 3.2.1 EA mature areas Given the assessment indicator, the municipalities are considered mature when it comes to having an IT strategy (94%). The same goes for the EA function to support the strategic management level (94%). With respect to organizational behavior, most municipalities are used to having IT staff working in overlapping groups, i.e. where one employee is placed in several working projects (82%). Most CIO’s find themselves in municipalities demanding the use of IT tools (87%). As far as having an attitude of being responsible, most CIO’s agree that a future joint municipal EA program should be governed through current practice (88%). 3.2.2 EA immature areas I will also now use the 20%/80% assessment indicator to establish any immaturity. The number of responses is generally very poor when inquired about an EA framework. The most immature area is revealed in the lack of a published EA framework (87%). Without an EA framework it is very difficult to work structured with IT. It is not just the framework in itself, but what it influences if it is not present: a framework influences all other EA aspects, including the EA process, EA measurement, EA tools, EA documentation etc. (Bernard, 2004). These exact aspects also show up as immature with the municipalities. The number lacking a description of the process of using EA is extremely high (90%) as 5 See appendix 9 Page 22 of 112 Enterprise Architecture of public Denmark Master thesis, December 2006 is the number lacking prescribed guidance for measurement (77%). Few municipalities have its own EA unit (13%). The documentation part is suffering as well. More than half (54%) of the municipalities have below 20% of its business architecture documented and almost half (47%) have below 20% of its information architecture kept up-to-date. There is a serious lack of documentation part in the municipalities again indicating that EA or EA principles are not used. You cannot do EA without documentation. Interestingly, the situation is almost reverse, when it comes to documenting the application and technical architectures. More than a third of all the municipalities have above 60% of its application architecture kept up-to-date, while the same figure for the technical architecture reaches 74%. EA tools cross-cutting different lines of businesses, such as an Identity and Access Management tool (IAM) is a rare tool to find with the Danish municipalities, as 78% do not have one. 3.3 Cross-tabulations Using cross-tabulations is about selecting one or more responses as constants and then compare them to other responses which are considered variables. I have chosen my four open-ended questions as constants and will compare them to other EA aspects to identify any correlation. These questions reflect the attitude of the CIO’s. And attitude often determines the understanding and use of EA. Therefore I believe that determining a possible correlation between open-ended attitude-related EA questions with close-ended hard-fact questions on EA aspects will most likely reveal the level of EA maturity for the municipalities. 3.4 Determining Correlation It is outside the scope of this thesis to introduce complex mathematical methods for calculating statistical significance, such as the chi-square analysis, which tests nominal data where observed and expected frequencies of events are compared. Instead I have used the filter and pivot table function in MS-Excel as a tool in order to identify the following cross-tabulations. 3.4.1 Correlation on first open-ended question The question held constant: “One of the purposes of the structure- and task reform is for the municipality in the future should be the primary entrance of the citizens’ contact with the public. Yet KL is doing a joint public citizen portal at www.borger.dk. What do you think about that?” 159H There are 72% who believe the portal to be indispensable, 22% have no opinion and only 6% look upon it as superfluous. The only correlation between respondents thinking www.borger.dk is indispensable and the rest of the questions is that 26% also have ‘Economies of scale’ as primary motivational factor for entering into a joint municipal IT co-operation. Looking at the 6% who thinks the portal is superfluous however shows some interesting facts: • All have an IT/EA department maintaining a complete overview of services, user interfaces, technical processes and data sources as part of its portfolio • None of the municipalities receive support from external IT/EA architects • All work structured with business oriented IT • All want either ‘Economies of scale’ or ‘Greater independence of KL/KMD’ as their primary motivational factor for a joint municipal IT co-operation 160H Page 23 of 112 Enterprise Architecture of public Denmark • • • • • • • • • Master thesis, December 2006 All have an IT strategy All see ‘Lack of resources’ as the greatest obstacle in obtaining a joint municipal IT cooperation All co-operate already with other municipalities in providing common solutions to common tasks All use ITIL as a tool in the organization All belong to a municipality which demands the use of certain IT tools All belong to a municipality which primary interfaces between core systems are developed by bilateral suppliers All see a potential joint EA program governed by practice None of them have IAM (Identity and Access Management System) None of them has a framework 3.4.2 Correlation on second open-ended question The question held constant: “What could be your municipality’s primary motivation for participating in a joint municipal IT co-operation concerning solution of common tasks after January 1, 2007?” Since there are 13 choices I will only focus on the top 3 mode responses: ‘Economies of Scale’, ‘Synergy’ and ‘Improved citizen service’. 3.4.2.1 Economies of Scale The most apparent attributes describing these municipalities follows: • None, except one, have an IAM implemented • The documentation of the business and information architecture is very poor • 75% find www.borger.dk indispensable 16H 3.4.2.2 Synergy The most apparent attributes describing these municipalities follows: • All have an IT strategy • All have reached concrete results through the use of IT as a part of the municipal business strategy • All are satisfied with the market supply of courses within IT and its use at a strategic plan • All document well the EA assets: the business- (40%-60%), information- (40%-60%), application- (60%-80%) and technical-architecture (80%-100%) 3.4.2.3 Improved citizen service The most apparent attributes describing these municipalities follows: • 67% find www.borger.dk indispensable, 33% have no opinion • All have an IT strategy • Not surprisingly, 67% find that their IT strategy in the future can lead to greater usable citizen service • 83% have their IT staff trained through external courses • 67% see ‘Lack of resources’ as the greatest obstacle in obtaining a joint municipal IT cooperation • 83% do not currently co-operate with other municipalities providing common solutions for common tasks • 83% have not published guidelines describing the process of using IT in the business 162H Page 24 of 112 Enterprise Architecture of public Denmark • Master thesis, December 2006 None have an IAM implemented 3.4.3 Correlation on third open-ended question The question held constant: “What do you see as the greatest obstacle in obtaining this joint IT cooperation?” Since there are seven choices I will only focus on the top two mode responses: ‘Lack of resources’ and ‘cultural barriers’. 3.4.3.1 Lack of resources The most apparent attributes describing these municipalities follows: • 87% have an IT strategy • 73% have their IT staff trained through external courses • 87% do not measure its maturity in relation to the use of IT in the business • 93% have not published guidelines describing the process of using IT in the business • 80% use ITIL in the organization • 93% belong to a municipality which primary interfaces between core systems are developed by bilateral suppliers • 87% have not implemented an IAM • All document well the EA assets: the business- (40%-60%), information- (40%-60%), application- (60%-80%) and technical-architecture (60%-80%) 3.4.3.2 Cultural barriers The most apparent attributes describing these municipalities follows: • 83% belong to a municipality on Zealand • All have an IT strategy • 67% find that their IT strategy in the future can lead to greater usable citizen service • 83% are satisfied with the public supply of IT courses and its use at a strategic level • 83% do not measure its maturity in relation to the use of IT in the business • 83% have IT procurements approved by the EA function 3.4.4 Correlation on fourth open-ended question The question held constant:”How do you assess the optimal organisation of common solution of common tasks in a joint municipal IT co-operation?” Since there are two interesting responses to this question, I will describe both: ‘KL regi’ and ‘between the municipalities’. 3.4.4.1 KL regi The most apparent attributes describing these municipalities follows: • 76% have their IT staff trained through external courses • 71% do not measure the completion of the IT projects • 82% do not measure its maturity in relation to the use of IT in the business • 94% do not have en EA framework • 82% belong to a municipality which primary interfaces between core systems are developed by bilateral suppliers Page 25 of 112 Enterprise Architecture of public Denmark Master thesis, December 2006 3.4.4.2 Between the municipalities The most apparent attributes describing these municipalities follows: • 89% have an IT strategy • 89% belong to a municipality which primary interfaces between core systems are developed by bilateral suppliers • 55% have an EA function/IT at strategic level function • 55% do not measure its maturity in relation to its use of IT in the business 3.4.5 Other findings These are other interesting and relevant findings from the survey in relation to the overall problem question of the thesis. • 6% have an IT strategy but have not yet achieved any results through this. When asked: “How much do you believe your IT strategy in the future will contribute with greater usable citizen service” the response: To a very small degree. • Only 22% measure the maturity of its organization in relation to its use of IT in the business o Of these are 86% municipalities on Zealand o 86% have an IT strategy o 86% have an EA function/IT strategist • 71% that do measure the completion of their IT projects, do not measure their maturity in relation to using IT in the business. • 83% of the municipalities in Jutland find www.borger.dk indispensable, the rest have no opinion. • 58% of the municipalities are inspired by other municipalities when documenting their EA activities. • 67% of the municipalities in Jutland find that KL should be the center in providing common solutions for common tasks. • All municipalities on Funen find www.borger.dk superfluous. 163H 164H 3.5 Drawing Conclusions I will draw conclusions in the true spirit of Likert’s ordinal scale: Very mature, mature, neutral, immature, very immature. In ranking the municipalities’ maturity, I look for the use and implementation of several EA aspects as identified above. The municipalities which think www.borger.dk is superfluous all seem very mature. The municipalities whose primary motivational factor is 'economies of scale' in entering a joint municipal IT co-operation seem immature. The municipalities whose primary motivational factor is 'synergy' in entering a joint municipal IT cooperation seem mature. The municipalities whose primary motivational factor is 'improved citizen service' in entering a joint municipal IT co-operation seem neutral. The municipalities which have 'lack of resources' as the greatest obstacle in obtaining joint municipal IT co-operation seem neutral. Page 26 of 112 Enterprise Architecture of public Denmark Master thesis, December 2006 The municipalities which have 'cultural barriers' as the greatest obstacle in obtaining joint municipal IT co-operation seem mature. The municipalities which see KL as an important player in the optimal organization of this joint IT cooperation seem immature. The municipalities which see the organization is to take place directly between the municipalities, in the optimal organization of this joint IT co-operation seem neutral. In relation to maturity, it is worth concluding that 86% of the municipalities that do measure their maturity in relation to its use of IT in the business also have an IT-strategy and an EA function Likewise is it worth noting that Zealand and Funen seem to be the most mature geographical areas in relation to the need for a common public citizen portal. Municipalities in Jutland seem to be very dependent on the portal (83%). 3.6 Interpreting Results Interpreting the results is not an easy task. It involves asking ‘why’ this result is as it is. EA in the Danish municipalities is overall at a beginner’s stage, or immature. They do have IT strategies all right but do not document these very well. They do work much in projects, but do not work systematically with IT within a framework. This can be seen in that only 13% have its EA function. The municipalities work mostly low-level documenting mainly the application and technical architectures, leaving strategic IT undocumented. The reason for this absence could be what one of the CIO’s told me in an interview, when he said that “one of the great obstacles of EA in Denmark, is to bring strategic EA into the board meetings.” 6 Or it could simply be lack of knowledge of the benefits that EA can give to the municipalities. 5F5F The most mature municipalities in Denmark think the public joint citizen portal is superfluous. This is probably so because they do have their own locale citizen portal. Others think KL is undermining the vision of having the municipality as the primary entry for the citizens by making a public portal. Those municipalities having synergy as primary motivation for joint IT co-operation and those having cultural barriers as the main obstacle in reaching this seem the most EA mature. This is probably so because since these are deep-rooted EA attitudes and signifies a high level of insight in a potential cross IT/business municipal co-operation. According to many (Bernard, 2004; Carbone, 2005) culture is an important element to take into consideration when doing EA. And obtaining synergy is not just a ‘money-centric’ aspect but also incorporates other important aspects such as citizen satisfaction. To illustrate the importance of culture, I believe, that the reason the municipalities on Funen and Jutland seem more mature in relation to their fellow municipalities on Jutland, is probably because of difference in culture. This is not documented, but there is no other correlation that point in any other direction. The municipalities from Jutland just respond differently (read: at a lower level of maturity) to most of the questions. 6 Preben Rasmussen Høj, CIO of Sollerod municipality Page 27 of 112 Enterprise Architecture of public Denmark Master thesis, December 2006 3.7 Summarizing Conclusions The study survey reveals the Danish municipalities for the whole part not are at a mature level in relation to the awareness, propagation and use of enterprise architecture. Even though 65% answered they have an EA function, they do not use it fully. The following witness to this fact: For the whole part there is no EA framework, no EA measurement, no EA process, and no EA documentation. 3.8 Making Recommendations I would recommend more EA pioneer municipalities which would take the first step in order to step up the EA maturity ladder. But they should not do so alone. KL should back them up. Once a few municipalities have success, then it can and most likely will spread around to adjacent municipalities as well, since the culture in knowledge sharing between municipalities in Denmark seems to be very apparent, especially when it comes to the documentation activities. I would recommend a joint municipal strategy in this pioneer effort. But before all this can happen, the organization at the national level has to be in place. I do not yet know if it is in place. Therefore, I will describe and analyze these for the remainder of my thesis in order to verify if the structure at a national level is set up to support these joint municipal IT co-operative initiatives recommended in this chapter. And if they are not set up for it, I will make recommendations for this as well at a later stage. 4. Literature review 4.1 Working towards a common terminology 4.1.1 Introduction Throughout the past 20 years, many have argued and brought about their viewpoint of how Enterprise Architecture (EA) is to be defined. As of today there is no common agreement on the matter of defining what an EA is. I will in this paragraph discuss some of the most common definitions. Before moving on to this discussion, one can perhaps best catch the vision of the need for enterprise architecture by comparing it to what will happen if there is no architecture in the enterprise. A classical example to illustrate the need for architecture is looking at the Winchester “Mystery” House (see figure 5). Here are the facts of this “un-architectured” house: • • • • it took 38 years of construction – 147 builders and 0 architects there are 160 rooms – 40 bedrooms, 6 kitchens, 2 basements, 950 doors there are 65 doors to blank walls, 13 staircases abandoned, 24 skylights in floors and no architectural blueprint exists Figure 5. The Winchester "Mystery" House. Source: John Gotze’s slide Page 28 of 112 Enterprise Architecture of public Denmark Master thesis, December 2006 It does not take an expert to see something is wrong with this picture. The rationale for having architecture in building houses is obvious. It is often less obvious why this is necessary in building companies. So why do we need an architecture in order to build a company or a municipality? Some of the most obvious reasons 7 for having architecture are given here: 6F6F • • • • • • • • IT costs too much Costs of managing complexity Eliminate redundancy Growing IT ecosystem Demanding rate of change Need for info sharing Outsourcing (BPO) Future-proofing These reasons have over time been “transformed” into being the benefits of having enterprise architecture. “If you don’t have strong architecture strategy, everyone does their own thing and you end up with six kinds of servers and (software) platforms … you get silos of everything and that explodes your costs” 8 7F7F 4.1.2 What is enterprise architecture? EA has its roots in the business world. Zachman, the so-called father of EA, was an employee with the college of Business Administration at the University of North Texas 9, EA is the business view of IT and should manage IT as a business 10 and EA is a non-technical discipline that should address the strategic and architectural aspects of IT in the business (Herzum, 2003). 8F8F 9F9F Most people agree that EA originates from Zachman (1987 and 1992) and his originally designed “The Zachman Framework for Enterprise Architectures” (also known just as the Zachman framework). His framework documents how information systems fit into the company by asking very simple, intuitively questions such as WHAT, HOW, WHERE, WHO, WHEN, and WHY. He explained his newly formed “framework” by using an analogy to the process of planning, drafting, and building a new home. 11 In practice it is a schema to help IS architects to systematize the elements of an entire organization and the relationships between the different aspects of the enterprise, including how a change in one element can affect another (Zachman, 2005). The framework is two-dimensional; even though he has designed a three-dimensional EA framework today (we cannot have the founding father of EA not keeping up with the trends of the time). 10F10F Spewak refers to EA as ‘Enterprise Architecture Planning’ and define it as “the process of defining architectures for the use of information in support of the business and the plan for implementing those architectures” (Spewak, 1992). He focuses on the top two layers of Zachman’s framework, the planner view and the owners view. Bernard’s approach comprises a more detailed definition: “Enterprise Architecture is both a management program and a documentation method that together provides an actionable, coordinated view of an enterprise’s strategic direction, business processes, information flows, and resource utilization...it is the 7 Gurpreet S. Pall, Microsoft Architectural Frameworks, 2005, Microsoft Corporation http://www.flashline.com/content/ambler/agile_ent_arch.jsp?sid=1116166268313-1123631162-101#why 8 Andy Miller, VP of Technical Architecture, Corporate Express Carol O’Rourke et al, Enterprise Architecture Using the Zachman framework, Thomsen, 2003 10 Peter Herzum, Applying Enterprise Architecture, 2003 11 See appendix 2 or http://www.zifa.com/ 9 Page 29 of 112 Enterprise Architecture of public Denmark Master thesis, December 2006 analysis and documentation of an enterprise in its current and future state from an integrated strategy, business and technology perspective” (Bernard, 2004). Schekkerman’s view is holistic as well. He sees EA 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, organization 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” (Schekkerman, 2004). Weill & Ross recognizes that IT is tightly embedded in organizational processes and that the critical role of architecture is to ensure the desired level of business process integration (sharing of data across business units) and business process standardization (implementation of the same business processes across business units). From this they proposed their EA definition: The enterprise architecture is the organizing logic for a firm’s core business processes and IT processes reflecting the integration and standardization requirements of a firm’s operating model (Weill & Ross, 2004). John Gotze, one of the pioneers of eGovernance in Denmark and former counselor in the Ministry of Science, Technology and Innovation, defines EA as “Integration of the business strategy planning and the IT strategy” (Gotze, 2004). The US defines EA as a strategic information base, which can be used as a roadmap to achieve certain goals (USA Federal CIO council, 2001). The Open Group, emphasizing open standards and global interoperability, states: “Enterprise Architecture is about understanding all of the different elements that go to make up the enterprise and how those elements interrelate” (Open Group, 2000). Lillehagen & Karlsen is more leaning in the direction of Spewaks’ point of view in that they define EA as “a plan which shows the main features and characteristics of the enterprise and its assets that are to be analyzed, justified and agreed before the detailed technical design” (Lillehagen & Karlsen, 2005). Gartner Vice Presidents Chuck Tucker and Dave Aron see EA as “a management process that translates business strategy into business value. CIO’s with an EA program can use it as a management tool to further their value proposition to the business” (Tucker & Aron, 2005). Wegmann & Preiss’ holistic view defines EA as “an integration between the business and the information technology” (Wegmann & Preiss, 2003). Lankhorst sees EA as a linkage between many aspects. He defines EA as “a coherent set of principles, methods, and models used in design and in the realization of the enterprise’s organizational structure, processes, systems, and infrastructure” (Lankhorst, 2005). A large number of professionals see EA as “an identification of the main components of an organization and interactions” (Armour, Kaisler and Pippin, 2002; Chung & McLeod, 2002; Kaisler, Senate, Armour, Valivullah, 2005). The list of definitions seems endless. So who is right? Perhaps they are all wrong? Or perhaps they are all right depending on the circumstances? One thing is for sure and that is with all these different EA Page 30 of 112 Enterprise Architecture of public Denmark Master thesis, December 2006 views, evidence of a generally agreed terminology by the enterprise engineering community is lacking. By comparison the architectures are overlapping in their approaches and the underlying concepts are not explicitly defined. So the problem of identifying a common EA definition remains unsolved. This has led many advocating EA to the following “profound”, yet obvious statement: “EA has not been defined and agreed upon” (Lillehagen & Karlsen, 2005; Schekkerman, 2004; Ross, 2003; Rodd, 1994). One wonders why such a widespread emerging discipline has not reached consensus on the matter. The more EA is used, the greater the need for a clear definition. But the current similarities and differences between architectures can not be perceived by users; and this creates obstacles for its correct understanding in industry and finally its acceptance and use. The lack of a generally agreed terminology and semantically enriched knowledge corpus in this domain is also a bottleneck for its efficient application (Lillehagen & Karlsen, 2005). Due to this great confusion James Martin (2004) has done more than just observe the absence of a common EA definition. Confronting customer demands, he lists seven requirements to define EA: 1) must be in one sentence; 2) may elaborate from that single sentence to make certain clarifications; 3) must be understandable by executives; 4) must be useful to those who will develop the EA; 5) must be applicable to a government organization; 6) must be put into context of baseline and target EA; and 7) must provide the executives with the proper expectations of what can be delivered to them and what they can use it for. I agree with James Martin’s list of requirements. Therefore with his list in mind, I choose the best fitted EA definition from the above listed definitions. It is difficult to find a definition describing all of his requirements all put together in only one sentence. Scott Bernard’s EA definition seems to be the one closest in fulfilling Martin’s list of requirements with his definition: “Enterprise Architecture is both a management program and a documentation method that together provides an actionable, coordinated view of an enterprise’s strategic direction, business processes, information flows, and resource utilization...it is the analysis and documentation of an enterprise in its current and future state from an integrated strategy, business and technology perspective” (Bernard, 2004). Even though this is a long, on-going sentence, this fits very well Martin’s list and I have therefore chosen this as my working EA definition for the remainder of this thesis. I believe however that EA only adds real value to any enterprise if it provides a roadmap for gradually enabling a company to change from its current operations to the way it wants to do business going forward. Figure 6 illustrates the broad perspective and the many facets one has to consider in order to gain an Figure 6. Enterprise Architecture Program View. Source: overview of Enterprise Architecture 269Hhttp://www.enterprisearchitecture.info/Images/Extended%20Enterprise/Extended%20Enterprise%20Architecture.htm in any domain. As noted earlier the domain of this thesis concerns the public domain of the municipalities and The State. Page 31 of 112 Enterprise Architecture of public Denmark Master thesis, December 2006 I presented the design of my study survey in the research design chapter, but did not include which areas the survey should encompass! I will use figure 6 to extract the questionnaire content. General research design cannot help me here but figure 6 gives me an overview of which aspects my questionnaire should deal with: General aspects, motivation, goals & barriers, EA measurement, EA process, EA tools and methods, EA frameworks, EA governance and EA assets. I believe this figure very well represents the overall EA aspects to be covered in my questionnaire to the municipal CIO’s. 4.2 Defining the Enterprise I will now move on to describe what an enterprise is in this context of study. A good definition of "enterprise" in the context of my study is any collection of organizations that has a common set of goals/principles and/or a single bottom line. In that sense, an enterprise can be a whole corporation, a division of a corporation, a government organization, a single department, or a network of geographically distant organizations linked together by common objectives (Bernard, 2005). There are a variety of enterprise components to take into consideration (see figure 7). This is another way of describing Zachman’s six questions: WHAT, HOW, WHERE, WHO, WHEN, and WHY. Codd’s figure indicates that the external environment provides input to the enterprise AND to the strategy. The strategy influences the “six questions” or EA aspects, just as it guides the use of information and technology. These provide input to the output results. These results could be EA artefacts (documentation of EA), as well as “doing business the EA way” behavior. Note that there is only arrows going to ‘technology’, not from it. This indicates business driven use of IT, where the technology is aligned with the business, not reverse. Finally, Codd sees EA as a process, which he indicates by drawing the ‘Transformations through organizational processes’ arrow going from input to the enterprise to output into the environment. Codd focuses much on the act of ‘doing Enterprise Architecture’. Not just talk about it, plan it or document it, even though these activities of course also are essential. Figure 7. Enterprise components. Source: Codd 1994. In this study the definition of an enterprise depends on the level we look at: the municipal or the state level. At the municipal level an enterprise is all the municipals together. At the state level an enterprise comprise all the different public national authorities within the public sector. Since I believe you cannot Page 32 of 112 Enterprise Architecture of public Denmark Master thesis, December 2006 separate the municipalities and the state, I will treat them as one entity or as one enterprise and call this Denmark Ltd. This means that the customer is the citizen and the products are the services offered. 4.3 Defining the Architecture The architecture of a system is the system’s fundamental organization, embodied in its components, their relationships to each other and to the environment, and the principles guiding its design and evolution. Another view of EA is looking at its contextual usage. Usually, architecture has various meanings depending on its contextual usage: 1) A formal description of a system at component level to guide its implementation, 2) the structure of components, their interrelationships, and the principles and guidelines governing their design and evolution over time and 3) organizational structure of a system or component. To summarize, an EA should generally be organized in a manner that supports reasoning about the structural properties of the system. It should define the different components, which contribute to the overall system, and it should provide a plan from which the system can be developed (Open Group, 2000). CTO at Cap Gemini, Steve Jones, says “a decent architecture would take all the "Enterprise" products and stick them together into something that works.” 4.3.1 Four common viewpoints on architecture For practical approaches, a limited set of architectural dimensions is widely adopted (NIST 1989, Armour et al. 1991a, Hasselbring 2000, The Open Group 2002, Buchanan and Soley 2002, Heffner 2002). The set commonly consists of the following concepts although the terms used may vary: 1. 2. 3. 4. Business/Processes Architecture Information/Data Architecture Logical (Systems/Applications) Architecture Technology Architecture (Application technology and infrastructure) This set of EA dimensions unfortunately lack academic argumentation and is mostly agreed on as practical approaches. The more CEO’s see the rational for an EA, the more needful I think will be an academic approach to this discipline. We have seen this natural evolvement with traditional systems engineering, in OO systems engineering, in component based development and in recent years with Service Oriented Architecture. Why not implement an EA engineering academic approach? Both public and private companies are now adopting EA certification as part of their standard training program, particular in the US. I will not pursue this observation further at this time. Instead I will in the following discuss the arguments and rationale for doing Enterprise Architecture. 4.3.2 Why Enterprise Architecture? Why use enterprise architecture at all? What are the benefits? Most agree that the benefits of EA can be summed up using three words: better, faster, cheaper (Kaisler, 2005; Ambler et al, 2003). Other sees the benefits as a support in the planning process and management decisions (Bernard, 2004; Spewak, 1992). But it is important to realize that these benefits come at a price. You have to be willing to invest in the underlying organizational and cultural structures to support them. You need to recognize the fact Page 33 of 112 Enterprise Architecture of public Denmark Master thesis, December 2006 that these costs exist and ensure the better-faster-cheaper benefits outweigh them. Many examples can be taken to illustrate the justification of using EA. Here is one: US Agencies with enterprise architecture scores less than 3.0 spent 8.2% of their discretionary budgets on IT. Agencies with enterprise architecture scores higher than 3.0, spent 6.6% of their discretionary budgets on IT. Agencies that scored higher than 3.3 on their enterprise architecture assessments, spent only 3.8% of their discretionary budgets on IT. 12 1F1F Some believe return on investment is irrelevant in lieu of net present value, the plethora of payback algorithms, or concepts in real options. But the bottom line is that return on investment is a strategic approach to measure the value of any activity, especially enterprise architecture. David F. Rico 13 has listed his set of principles for successful Return on Investment (ROI) in your enterprise: 12F12F • • • • • • • Use ROI as a success factor: Use ROI to drive EA. The goal of EA is to align an organization’s strategy with its information technology (I do not agree with this goal though. I believe the information technology should be aligned with the business strategy not the other way around). By implication, a strategy cannot be realized without this alignment. Etch the desired benefits in stone: Identify a core set of benefits you wish to realize from EA. Then establish measurable goals for operating efficiency, cost reductions, staff reductions, customer satisfaction, computing budgets, and economic growth. In other words, convert improvements into money. Establish early ROI objectives: Establish ambitious ROI objectives for enterprise architecture based on tangible measures of costs and benefits. Operationalize a core set of metrics: Define a set of clear and measurable, and quantitative economic benefits for enterprise architecture. These could entail people, time, budgets, customers, throughput, volume, bandwidth, computers, and maintenance. Common mistakes to avoid are failing to define metrics, defining qualitative ones, or defining far too many metrics. Continuously measure the payback: Measure the return on investment of enterprise architecture early and frequently. Measure the payback at regular intervals along with normal project management activities, such as cost, time and earned value reporting. Use automated tools to do the work: Use an integrated project management reporting system with built-in return on investment tracking and reporting function. No point in spending a lot of time learning all the payback formulas or hiring a return on investment manager. Standardize ROI reporting: Create a system for measuring and reporting measures for the return on investment of enterprise architecture. The need for enterprise architecture can certainly be justified by the many reports documenting the benefits outweighing the costs. And I strongly agree with David F. Rico’s seven critical set of principles in order to successfully measure the Return on Investment of the enterprise architecture. To be effective, enterprise architecture must be more than models for business, information, and organization. Butler Group recommends that the process encompass both services architecture and the deployment of a services platform. Only by embracing an end-to-end methodology and framework will organizations avoid analysis paralysis and separate islands of knowledge, maximizing the undeniable benefits and cost savings available from the use of Enterprise Architecture. 12 13 Burk, Federal Enterprise Architecture Program Management Office, Sept. 2006 David F. Rico, A Framework for Measuring the ROI of Enterprise Architecture, http://davidrico.com/rico05a.pdf Page 34 of 112 Enterprise Architecture of public Denmark Master thesis, December 2006 In relation to the study at hand with the municipalities merging, a good merging of the IT generates less costs of operation. According to IBM, an IT optimization analysis can help the Danish municipalities merge their IT-organizations, bring down the IT costs, make the operation of IT more effective and optimize the IT infrastructure. This, IBM suggests, is possible by analyzing seven different key areas (see figure 8) 14. 13F13F It is IBM’s experience from dealing with many mergers and structural changes in public regi that in Figure 8. IBM's seven key areas for mergers order to be able to gain the real potentially savings and efficiency benefits the prerequisites are: • The new common IT-organisation is well defined. • The IT strategy and the e-policy for the new municipality must be defined and known. • IT Governance and decision making bodies for the new organization must be well defined and established very early in the process. • An attempt should be made to use a well tested and experience based structure and method in connection with the task of optimization, thus securing that the optimazation initiatives support the IT strategy and that the merging will go through with minimal risk for IT operation. • Consolidation opportunities within data communication, server- and data storage technology as well as telephony will be exploited. I find these prerequisites extremely relevant and important for the merging municipalities. 4.4 Legacy of EA In order for us to understand EA more fully, we have to go back and look at its origin. Zachman is credited with creating enterprise architecture even though it has its foundation in systems analysis principles dating all the way back to the 1960’s. Early systems analysis techniques included flowcharting, structured design, structured analysis, and information engineering. The Zachman framework and the U.S. Department of Defense Architecture Framework (DoDAF) are huge in terms of models. Zachman requires 30 unique models, while DoDAF “only” requires 26. In the US today, over 46 of the more than 100 U.S. federal agencies use enterprise architecture, a wide variety of maturity models to assess their progress and a plethora of never ending tools. 4.4.1 Relationship to systems analysis and design Enterprise architecture can put the system development approaches and embedded documentation techniques in an overarching context and unifying framework. Without this context, systems development efforts throughout an organization run the risk of being disjointed and duplicative, something we have witnessed for the past decades. 14 http://www-304.ibm.com/jct03004c/industries/publicsector/dk/da/efficientit Page 35 of 112 Enterprise Architecture of public Denmark Master thesis, December 2006 4.4.2 Relationship to strategy and business planning In most EA literature there is a clear explanation of the relationship between strategic planning, business planning, and information technology planning. IT resources are increasingly becoming a commodity, and therefore the need to treat IT as a business enabler continues to grow in many public organizations. In recognition of this, EA’s identification of integrated IT solutions organization-wide (crosscutting) and mission-specific (vertical) requirements is one of the most important elements in planning EA in a complex environments such as the public sector. Strategic goals and business requirements should drive IT solutions, and EA’s contribution to this alignment is crucial. 4.4.3 Relationship to component-based and service-oriented architectures The public sector consists of a large and complex structure which operates in horizontal as well as vertical ways trying to fulfill the needs of a complex and ever changing environment. Therefore in choosing an EA framework to support this, it must include loose-coupling and internal standardized integrated elements which support organization-wide (between municipalities) and mission-specific (in one sector, e.g. the environmental sector) requirements. As figure 9 illustrates, Bernard’s EA3 Cube Framework 15 supports exactly that with its “plug-and-play” components – or building blocks – which are increasingly interoperable and integrated due to the so-called standards thread that promotes non-proprietary solutions. 14F14F Figure 9. Bernard's EA3 cube. Source: Bernard, Scott (2004) 4.4.4 Relation to social aspects Traditionally speaking, EA is about aligning the IT-architecture in relation to the enterprise’s business strategy, thus complying with a traditionally top-down view. But sustainable EA must encompass more than that because it is developed, supported and used by people. It is made by people, for the people and to the people within the enterprise. Therefore, the social and cultural aspects of the enterprise have to be a part of the establishment and the sustainability of a successful EA. Hence a bottom-up view. One could go so far as to speak of a social edition of EA as a discipline or SEA: Social Enterprise Architecture. This would certainly add a more holistic view of EA as both the technical and the social aspects are described. One of the systems development approaches which combines the scientific approach with the systems approach in an integrated approach is called the MULTIVIEW methodology. 16 I will not go further into this methodology here, but instead in the next focus in on the prerequisites of starting enterprise architecture. 15F15F 4.4.5 Development of Systems Development Systems development has undergone tremendous changes in recent years. Going back to the 1970’s and 1980’s we saw how structured procedural development was dominant on the market. Later came objectoriented analysis (OOA) and object-oriented design (OOD), Component based development (CBD), and in recent years web services have gained much popularity, often used in connection with service oriented architecture. 15 16 See appendix 3 D.E. Avison and A.T. Wood-Harper, 1990 Page 36 of 112 Enterprise Architecture of public Denmark Master thesis, December 2006 Since 1995, Gartner has used hype cycles to characterize the over-enthusiasm or “hype” and subsequent disappointment which typically happen when introducing new technologies. These hype cycles also show when and how technologies move beyond the hype, offer practical benefits and become widely accepted. According to Word Spy 17, a hype cycle is: 165H 16F16F A sequence of events experienced by an overly-hyped product or technology, including a peak of unrealistic expectations followed by a valley of disappointment when those expectations aren't met. There are five phases of a hype cycle: 1) technology trigger, 2) peak of inflated expectations, 3) trough of disillusionment, 4) slope of enlightenment, and 5) plateau of productivity (see figure 10). The first phase of a hype cycle is the technology trigger or breakthrough where the product is launched, or an event that generates significant interest. The next phase typically covers the publicity and overenthusiasm and unrealistic expectations. There are usually more failures than successful applications of a technology. Technologies enter the next phase, trough of disillusionment, because they fail to meet the expectations and quickly become unfashionable. The press usually avoids the topic and the technology. Although the press does not cover the technology, some businesses still go through the slope of enlightenment and experiment to understand the benefits of the technology. A technology reaches its plateau of productivity as the benefits of it become widely demonstrated and accepted. The final height of the plateau varies according to whether the technology is broadly applicable or pertains only to a niche market. Figure 10. Gartner's hype cycle. Source: http://www.gartner.com/DisplayDocument?doc_cd=130115 16H 17 http://www.wordspy.com/words/hypecycle.asp Page 37 of 112 Enterprise Architecture of public Denmark Master thesis, December 2006 As can be noticed from figure 10, EA is not on the hype cycle at all. If I have to relate it to an adjacent technology, SOA can be compared to EA which is entering the trough of disillusionment and within two to five years will reach its plateau. 4.4.6 Development of EA Enterprise architectures became popular when John Zachman developed his framework for dealing with large information systems (Zachman, 1987). These frameworks originally focused on data processing using mainframe computers, so their emphasis was on the data aspects of a business. Later there was an emphasis on information processing in the business (during the so-called Information Age). During recent years, there has been an increasing interest in “knowledge management” and services, since it has been recognized as a key ingredient in the success of businesses today. However, architecture frameworks still have a focus on the information aspects of the business and little if any treatment of the knowledge aspects. 4.4.7 What is Service-Oriented Architecture? Since I will be using Service-Oriented Architecture (SOA) as a concept, I will state my working definition of it as a part of the ‘Working towards a common terminology’ chapter. Since the primary focus of this thesis is not SOA, I will make this brief. The general perception of a service-oriented architecture is that it is a style of application design that includes a layer of services. A service, from this limited perspective, is just a block of functionality that can be requested by other parts of the system when it is needed. These services have a published set of methods, known as an interface. Usually, each interface will be associated with a particular business or technical domain. So there could be an interface used for authentication and another interface used to create and modify a sales order etc. 18 CBDI 19 defines SOA as: 17F17F 18F18F “Service Oriented Architecture (SOA) is the policies, practices and frameworks that enable application functionality to be provided and requested as sets of services published at a granularity relevant to the service requestor which are abstracted away from the implementation using a single, standards based form of interface”. CBDI’s definition will also be my working definition of SOA throughout this thesis. 4.4.7.1 Benefits of SOA The main benefits of SOA • Loosely coupled applications (change in a service does not affect the application as long as the interface remains intact) • Location transparency (the service can reside anywhere in the world) • Code reuse (easy with use of UDDI, WSDL and XML) • Focused developer roles (assigning specialized developers to specific tasks) • Greater testability (through published interfaces with NUnit) • Parallel development (due to the only interaction between services is through interfaces in the different layers) 167H 18 19 Bruce Johnson, http://objectsharp.com/blogs/bruce/articles/235.aspx David Sprott and Lawrence Wilkes, Understanding SOA, September 2003, CBDI Journal Page 38 of 112 Enterprise Architecture of public Denmark • • Master thesis, December 2006 Better scalability (improved response time for a service without effecting the calling application if placed on web farms) Platform independent (independent of HW and SW) 4.5 Merging of disciplines 4.5.1 SOA and EA Rasmus Knippel took on an evolutionary approach in his own research 20 of SOA and EA. One of the main issues of his research was to describe and analyze the evolution of SOA. A large part of his research entails a comparison of EA artefacts with SOA artefacts, and here he found many similarities. 19F19F Some of his key findings: • The higher level of abstraction of SOA artefacts, the closer the resemblance to EA. • The real value of the artefacts is to be found in the relationship between them. • EA at its most mature state, called Nirvana, equals the definition of SOA. • EA is founded from a business perspective and SOA is founded from a technical perspective. • EA is often seen as a top-down method where SOA is often seen as a bottom-up method. They both show strength and weaknesses but the key is to get the best out of both. • SOA is the nirvana of EA. • SOA and EA share common goals such as creating interoperability, reusability and eliminate duplication. • SOA can make EA operational. • It is a risky business if EA has to fix some of the problems SOA causes! And this can happen if the organization is not mature enough for SOA. 4.5.1.1 The chicken or the egg This is a reference to the causality dilemma which arises from the expression "which came first, the chicken or the egg?" Since both the chicken and the egg create the other in certain circumstances (a chicken emerges from an egg; an egg is laid by a chicken) it is ambiguous which originally gave rise to the other. Compared to EA and SOA, then what comes first: EA or SOA? Or asked more specifically, what drives what? Gurpreet S. Pall puts it this way: “If you don’t do EA, you can’t do SOA”. I believe you can do EA without SOA if doing so in a closed domain, but you cannot, like Gurpreet stated, do SOA without EA. The municipalities and their future IT solutions are not however based on a closed domain, but in an ever changing environment reflecting complex, social structures. And if the municipalities are to cooperate they will need a technology which ensures interoperability and agility, and that is exactly what SOA provides. But still EA has to be the driven factor of the two because it originates from the business view and as stated earlier it has to be the business that drives everything else. This does not mean however that new technology cannot affect business vision and goals and even enable new business opportunities. But IT has been and will always be a tool. IT is only interesting because somewhere in the world people have a need for information that IT can deliver in a very effectively manner, e.g. through web services in a SOA. 20 Rasmus Knippel, SOEA, 2005, http://knippel.org/thesis/SOEA_censored.pdf Page 39 of 112 Enterprise Architecture of public Denmark Master thesis, December 2006 Figure 11. SOEA. Source: Rasmus Knippel, 2005 According to Rasmus Knippel, EA comes first and SOA can be seen as a plug-in to EA as the driving force to achieve interoperability. SOA can, but does not have to, result in EA and vice versa. SOA and EA must be aligned to each other and looked upon as a totally new concept: SOEA (see figure 11 above). This is the next step up the evolutionary ladder according to Knippel, who claims that this alignment of SOA and EA artefacts into a common frame of reference will ensure the continued success of both SOA and EA. 4.5.2 To be or not to be… …that is the question, is probably one of the world’s most used quotes. The German philosopher Schopenhauer commented on Shakespeare’s Hamlet quote by saying that: “The essential purport of the world-famous monologue in Hamlet is, in condensed form, that our state is so wretched that complete non-existence would be decidedly preferable to it. Now if suicide actually offered us this, so that the alternative "to be or not to be" lay before us in the full sense of the words, it could be chosen unconditionally as a highly desirable termination ("a consummation devoutly to be wish'd" [Act III, Sc. I.]). There is something in us, however, which tells us that this is not so, that this is not the end of things, that death is not an absolute annihilation” – Schopenhauer Now what does this have to do with EA? Most municipalities in Denmark do not use EA today as a program. Who said “silver bullet?” I believe if rightly planned and applied it is one silver bullet. Just like SOA is one silver bullet. There is no single silver bullet which takes care of all your problems. In my experience no product will ever solve all your problems. However it might help solve your problems – if used right. Or as Kristian Hjort-Madsen puts it: “The only thing that can make enterprise solutions work is YOU. And what you will probably find is that it is not the product that will be your biggest challenge – your biggest challenge is the organization. Having a tool working across an entire enterprise requires more than the tool, it also requires that it is used in a controlled fashion. An endeavor that requires full organizational support” (Madsen, 2006). The reference to Hamlet is that either we do EA all the way – one step at a time – or we don’t do it at all. But unfortunately it is not all organizations/enterprises that are fit for doing enterprise architecture. The following will discuss these issues. 4.6 Prerequisites to enterprise architecture Some organizational cultures are better suited for EA planning than others. EA planning is well suited to organizations that have long-range goals and plans, a cooperative team approach to management decisions, total quality management programs, and a desire to invest in new products and procedures leading to significant revenue or savings in the future (Spewak, 1992). Conversely, EA planning is not appropriate for an organization that places greatest value on quarter-to-quarter profits, quotas, budget slashing, and short-term projects. EA planning should not be attempted in an unfavorable climate Page 40 of 112 Enterprise Architecture of public Denmark Master thesis, December 2006 (Spewak, 1992). The organizational culture in the merging municipalities seem to support the use of EA planning due to their long-range goals and plans that need to be carried out as part of the merging process. The team approach to management decisions will be one of the most prevalent characteristic features between the new merging municipalities and they will have to invest in new IT products and procedures in order to live up to the government’s vision of providing better service towards the citizens, especially seen in the light that they have to do this at lower costs. On the other hand, one of the benefits of EA is overall cost reduction. In the Danish municipalities there is no demand that they have or will implement EA, but it cannot be excluded that this will come at a later stage, even though the study survey report reveals that more than 90% of the municipal CIO’s would rather have current practices govern IT instead of by legislation. But the Danish municipalities do have to live up to a number of demands regarding eGovernance including eDay1, eDay2, eInvoice etc. It is therefore likely that facets of EA demands will meet the new merging municipalities in the future. 4.6.1 Enterprise Architecture practices 4.6.1.1 Enterprise architecture and business objectives Enterprise architecture does not start with technology. It must begin with a strategic framework, the vision, goals, and the main business activities (Lillehagen et al, 2005). As mentioned earlier, according to Bernard, EA is both a management program and a documentation method. When using EA as a documentation method, it provides four elements: 1) an EA approach modeling the framework and implementation methodology, 2) a current architecture, which gives a view of as-is strategies, processes and resources, 3) a future architecture, which gives a view of to-be strategies, processes and resources and 4) an EA management plan, describing how to move from the current to the future EA. This timebased view of EA in a current and future state has been further elaborated by James Martin (2004): An EA is a specific arrangement of business objectives, features and functions. The purpose of a “shouldbe” (target) EA is to maximize a set of business goals and objectives given a set of constraints, conditions, and challenges. The purpose of “as-is” architecture (baseline) is to document the current arrangement such that a transition to the desired target state (target line) can be determined. Several recent EA scribes advocates for this current-target view (Carbone, 2004; Bernard, 2005). The transition from a current to a future state calls for the need to identify enablers of transformation. 4.6.1.2 Enterprise architecture as a ‘skeleton’ Independently of business goals or strategies, EA is, first of all, the foundation of enterprise systems (Lillehagen et al, 2005). According to ISO 15704 (2000), an architecture is a description of the basic arrangement and connectivity of parts of a system (either a physical or a conceptual object or entity). The software community shares a similar view: EA is the fundamental organization of a system embodied in its components, their relationships to each other and to the environment and the principles guiding its design and evolution (IEEE 1471, 2000). According to Lillehagen et al (2000), an architecture seen from a general perspective must: • • Have properties that can be verified with respect to user needs (ex. open or closed architecture, interoperable or not, centralized or decentralized...). Be simple so that business people can easily understand, check, analyze, discuss as a ‘language’ shared at corporate level. Page 41 of 112 Enterprise Architecture of public Denmark • Master thesis, December 2006 Have a style (by comparison with construction where architecture can represent some particular characteristics of a building such as ‘gothic’, ‘romaine’…). EA should be able to characterize enterprise systems (ex. ‘fractal’, ‘holonic’, or ‘agile’…). 4.6.2 Enterprise architecture methodologies ISO 15704 (2000) suggest that there are only two architectures that deal with enterprise integration: 1) System architectures and 2) Enterprise-reference projects. Enterprise integration deals with the design of the system, e.g. representing the system or subsystems in terms of its structure and behavior of the overall enterprise (this is also sometimes known as “type 1” architectures). Enterprise-reference projects deals with the organization of the development and implementation of a project such as an enterprise integration or other enterprise development program (this is sometimes referred to as “type 2” architectures). Specifically, this deals with framework aiming at structuring activities/tasks necessary to design and build a system. For instance, Zachman’s architecture is type 2 architecture. 4.6.3 The challenges of enterprise architecture Fundamentally, the problem with enterprise architecture is communication (Schekkerman, 2004). Another problem, which could be a part of Schekkerman’s statement, is reaching some level of common understanding of the EA definition. Even experienced EA professionals do not agree on this definition. And maybe never will, until a neutral forum presents a commonly agreed and well tested EA definition, like W3C is for the Internet, it would be nice to have an EAC (Enterprise Architecture Consortium) present. The Open Group is probably the closest consortium in fulfilling this need. Perhaps it is not necessary to have such a consortium? Perhaps every enterprise is responsible for outlining its own EA definition. This may be the case, as we have seen it for a number of years now but it makes it extremely difficult to have common ground in referencing standards and interoperability in the midst of a jungle of definitions and enterprise architecture frameworks. Therefore I will later analyze relevant frameworks and identify which will best fit to the municipalities EA activities and which will best fit to the State EA activities. But before I undertake this analysis, I will address two important factors: EA planning and EA maturity and measurement. 4.7 The EA planning process 4.7.1 Introduction One of the worlds leading experts on personal time management, Alan Lakein once said: “Planning is bringing the future into the present so that you can do something about it now.” 21 Paraphrased a bit this could be relevant on the subject of Enterprise Architecture (EA) as well: Planning an EA is bringing the future state of your enterprise into the present, so that you can do something about it now. 20F20F 21 http://www.brainyquote.com/quotes/authors/a/alan_lakein.html Page 42 of 112 Enterprise Architecture of public Denmark Master thesis, December 2006 4.7.2 Planning an enterprise architecture I believe one of the very first steps is the planning phase. According to Spewak, Enterprise Architecture Planning (EAP) is the process of defining architectures for the use of information in support of the business and the plan for implementing those architectures. There are three keywords in Spewak’s statement: architectures, defining and a plan. Usually EA operates with three architectures: data architecture, applications architecture and technology architecture. The word defining implies a definition of the architecture, not the design of it. EA planning does not design systems, databases, or networks. The design and implementation work is initiated after the EA planning definition process has been completed. The third important word is plan. Generally speaking, the architectures define what is needed, and the supporting plan defines when the architectures will be implemented. Architectures by themselves can provide useful definitions, standards, and ideas. But architectures without plans, no matter how thorough or good technically, usually end up sitting on a shelf gathering dust, never reaching implementation. In other words, in the absence of a thorough plan, “enterprise architecture frequently does not get beyond the end of the runway in many businesses, as it needs more than the odd evangelist within the organization to ensure adoption throughout the whole enterprise” (Butler Group, 2005). People at all organizational levels need information in order to do their job well. When asked the question: “With respect to information, what is needed to fulfill your objectives or do your job?” all responds from the president, vice-president and on down with the same five answers (Spewak, 1992): 1. 2. 3. 4. 5. Access to data in a useful format when and where needed Ability to adapt to changing business needs Accurate and consistent data Share data across the organization Contain costs 5 Success Factors Listed by Executives Access to data when and where needed Ability to adapt to changing business needs Accurate and consistent data Share data across the organization Contain costs I.S. Mission Timely access to needed data Flexible, maintainable systems Data integrity and standards Data/systems integration Cost effectiveness Table 2. Success factors yield I.S. mission. Source: Source: Spewak (1992) 4.7.3 Obstacles for successful Enterprise Architecture Planning The large majority of EAP projects are never completed. 22 In general, there may be three reasons for this: 1) EAP projects may begin on the wrong track by having unreasonable objectives or unrealistic expectations, 2) selecting an approach that will not achieve the desired result in the time allotted and 3) the participants are unfamiliar and inexperienced with EAP. More specifically, I find it especially relevant to find out why this is so. 21F21F According to Spewak, the most apparent obstacles to successful EA planning are the ones seen in table 3. In order to identify these obstacles there are certain symptoms, or statements, which typically 22 Spewak (1992), Enterprise Architecture Planning Page 43 of 112 Enterprise Architecture of public Denmark Master thesis, December 2006 originates from the management – the single most important core supporting EA. A relevant solution is suggested as to what to do in order to overcome the obstacle. An example could be the identification of the second obstacle: “Commitment of resources to enterprise architecture planning.” If management would respond to your EA initiatives with “go ahead with your EAP, but you can only use three people for two months” you know that there is a lack of commitment of resources to enterprise architecture planning. Management’s use of words like “you” and “your” indicate that they do not accept EAP, will distance themselves politically, and by limiting resources, may make it impossible to complete EAP or do it well. The end result then appears to be your fault, not theirs. The solution to overcome this obstacle could be to prepare a sales speech to the top management. Obstacle to overcome Symptoms Solutions 1. Awareness, recognition and acceptance by top management “Why should we do EAP?” or “Are other companies using EAP and what have been their results?” 2. Commitment of resources to enterprise architecture planning “We need to do EAP, but we cannot afford to do it now because...” or “Go ahead with your EAP, but you can only use three people for two months.” “Our company doesn’t believe in strategic planning” or “We only have time to shoot the alligators, not to drain the swamps.” Educational process: Make presentations on EAP concepts to management. External consultants present architecture benefits and opportunities. Provide management with books/published articles on EAP methods and results of planning in other companies – especially competitors. Make a sales pitch to the management. 3. Unfavourable corporate culture 4. Political differences regarding responsibilities for enterprise architecture planning 5. Lack of credibility of planning leaders Multiple departments vying for EAP responsibility. 6. Inexperience with EAP and lack of training “What will be the next step?” or “What is the purpose of this step?” 7. Finding the “best” methodology Lengthy debates over methodologies, tools, consultants, seminars, vendors and products. 8. Educating IS personnel in new technologies Low attendance at internal courses and presentations. Resistance to new products or techniques. “Why do we need EAP when our current applications are operating just fine?” or “There is nothing wrong with the way we’ve been developing systems for the past 20 years.” or “If EA is so beneficial, why did we not do EAP several years ago?” “We should wait until this new suchand-such product is released” or 9. Satisfaction with current application methods 10. Few or inadequate tools “They really don’t understand the way we operate” or “Here come the EA planners again” EAP should not be attempted in an unfavourable climate. If there is only minor amount of adverse culture, try one of two strategies: 1. Avoid selecting team member and leaders who display this arrogance. 2. 2. If no. 1 is not possible, maybe some component of EAP could be useful until a more favourable climate appears. The most effective is to have the ultimate responsibility rest with one single person or department. It could be a temporary department or an existing one. 1. Select respected team members from across the enterprise 2. Use modern EAP methods and tools 3. Place articles about the EAP in an internal newsletter Make an educational program for EAP. 1. Educational seminars taught by experienced practitioners 2. Public seminars and conferences 3. Consultants with EAP experience to make executive overview presentations There is no “best” methodology. Any methodology is better than none. By consensus, select a methodology that is understandable can be accomplished in a reasonable amount of time and can be completed within the budget and then stick with it. Plan an educational awareness program, that will convince IS personnel of the advantages of EAP Focus on the positive impact EAP will have on future systems and not the causes of current ills. Explain EAP is a relatively new process, requires skills heretofore unavailable and that tools and technology now have advanced to the point of supporting EAP. Avoid planning products that claim to “do it for you” Page 44 of 112 Enterprise Architecture of public Denmark 11. Uncertain payback and rate of return; Expecting immediate results “Postpone EAP until the decision as to Business Intelligence products has been made.” “What will EAP do for me this year?” 12. Fear of loss of data control / ownership “...my data...” or “...my files...” 13. Substantial up-front costs; benefits difficult to measure “Why is EAP expensive?” or “What is the payback for EAP?” 14. Inaccessible or uncooperative users Master thesis, December 2006 Point out the following: The architectures produced by EAP are immediately useful. With sufficient resources, an integrated architecture and plans can be developed in four to eight months. New systems developed from the plans can be implemented faster than those without architectures. Explain that data is a shared business resource like the buildings, equipment, furniture and materials. Most people who claim that the benefits of EAP are hard to measure use this as an excuse for deeper-rooted reasons. Find out what these reasons are and deal with these first and this obstacle should disappear. EAP should not be attempted without the full cooperation, support, and involvement of the enterprise areas. Management MUST view EAP as their people producing their plans if it is to be credible. “Do your planning, but don’t involve any of my people” or “submit your plan when it is finished, and we will evaluate it” or “All of our best people are fully committed to other activities, but we recently hired two graduates from the university who are not particularly busy, so use them for EAP.” 15. Delusions “I can do EAP myself” or “I don’t need One should be aware of such impressions and assess them honestly. consultants” or “Though there is little support for EAP, when the architectures are presented, management will see and understand the benefits, accept the architectures and approve the remainder of EAP.” Table 3. Obstacles for Enterprise Architecture Planning. Source: Spewak (1992) With all these obstacles apparent already in the planning phase of enterprise architecture it is no wonder that most EAP efforts, do not succeed. Any management within the municipalities or the State, who seriously want to create plans for enterprise architectures, should examine table 2 and identify which obstacles poses the greatest threat to their domain. 4.7.4 Key Factors to Successful Enterprise Architecture Planning (EAP) In order to complete, implement and maintain successful enterprise architectures and plans, research from several enterprises that has a proven record in the area, clearly indicates 10 essential factors for success. 23 2F2F First, commitment and support from the management is essential. This involves obtaining adequate funding and gaining credibility. A common vision should be reached and the presentations of the plans should include the concepts, vision and mission in a way that virtually assures management commitment and support. Without management commitment of resources, EAP simply cannot succeed. Second, there must be end-user and management participation and cooperation. This involves all the relevant people setting the necessary time aside for interviews, reviews and feedback during the entire 23 Enterprise Architecture Planning, p. 32 Page 45 of 112 Enterprise Architecture of public Denmark Master thesis, December 2006 enterprise survey. At presentations all attend. Realistic and credible plans are developed for the business. Third, there must be an effective project leadership and a work plan. Successful EAP projects have leaders who adopt a methodology, develop a clear and concise work plan that is easy to follow and motivate and guide EAP through to conclusion. Fourth, there is a reasonable balance between the three important factors a) scope and objectives, b) the level of detail and c) the resources and time allotted. The adequate details of the enterprise are described within the constraints of available time and resources. The scope of the enterprise is not too broad to be accomplished or to narrow to exclude the important details of shared data. Fifth, the EAP is carried out by a qualified team and the use of consultants with practical experience. The members of the team are well respected and have extensive experience. Sixth, there must be an effective use and management of tools to support the EAP. These tools assist the EAP process, enable business information to be analyzed, improve the presentations of the architectures and plans to the rest of the organization and enable developers to build from the blueprints. Seventh, EAP is performed and promoted in a manner consistent with the corporate culture, making it easier for all in the organization to support EAP and cooperate with the team. Eight, a high profile of circulating interim documents for review and comments is maintained. This way, the management could monitor the progress of the EAP, business people could provide feedback to secure that the architectures and plans would fulfil their long-term requirements. Ninth, effective presentations are made in order to keep team members fully informed of the progress and to create a positive image about EAP throughout the entire organization. These keep a business orientation. Tenth, the 80/20 rule is followed. This – simply put – state that there is no perfect plan. More specifically, planners cannot afford to get bogged down by “insignificant details.” Detail and accuracy may need to be sacrificed somewhat to formulate the architectures and plans within the allotted time. Eighty percent completeness and accuracy in each phase is considered “good enough” to produce reasonable, feasible architectures and plans. These above-mentioned 10 factors irrevocably impose rhetorical questions any management team should ask themselves in order to succeed with EAP: Can we describe a strategy to put all 10 success factors in place? Have we had any successful planning projects in our organization, and why were they successful? Page 46 of 112 Enterprise Architecture of public Denmark Master thesis, December 2006 4.8 eGovernment Maturity 4.8.1 Introduction An eGovernment maturity model provides us with guidance on how to gain control of our processes for developing and maintaining eGovernment services and how to evolve toward a culture of excellence in providing and managing eGovernment. A maturity model can also guide us in selecting process improvement strategies by determining current process maturity and identifying the few issues that are most critical to eGovernement quality and pocess improvement. eGovernment could be defined as governments providing information about services, as well as the ability to conduct government transactions, via the Internet. 24 23F23F 4.8.2 Maturity of the State of Denmark As concluded in chapter 3.7 the Danish municipalities are not considered to be at a mature level in the awareness, propagation and use of enterprise architecture. But what about the national level in Denmark? At what maturity level is that to be found in? According to figure 12, Denmark is among the top 5 mature e-Governments in the world. This is not bad at all. But what qualifies Denmark for this position? Figure 12. Maturity of eGovernment. Source: Slide from John Gøtze Certainly the way the State has organized itself in a broad manner with participating parties from both the municipal and State domain is one factor (read more about this in chapter 5). Another contributing factor to the assessment of the postion is without doubt the EA activities described at national level (see chapter 5.3). The relationship between the streamlining potential and the technological preconditions can be illustrated as in figure 13. The curve indicates the service level towards the citizens. 24 Accenture, http://www.contactomagazine.com/egovernment0529.htm Page 47 of 112 Enterprise Architecture of public Denmark Master thesis, December 2006 The first level of maturity is a simple website. There are lots of these around in the public sector. This is a static collection of pages, focused on the department or division, perhaps some downloadable forms and some phone numbers. There is not much at this level which changes the nature of a citizen or business interaction with the public. The second level of maturity – online interaction through portals, simple forms, and search engines – is often referred to as online government. The big step up here is the addition of transaction based services in an effort to provide real value to the citizen. The focus is on the department and its business. The third level of maturity – transactions, delimited self-service solutions – is called integrated government. At this level we have moved away from individual, department-based transactions and toward interactions that bring multiple processes together in a meaningful way. The big step up here is the adding of end-to-end electronic transactions which is fully integrated into the back office systems and processes. Figure 13: Maturity of eGovernment in services for citizens and businesses. Source: http://www.oio.dk/files/whitepaper.pdf 168H The fourth level of maturity – integrated online services across organizations – is often referred to as transformed government. At this high level of service the eGovernment processes are operating in ways that change the very nature of how government works. State CIO of Utah, Phillip J. Windley 25, shared the following experience as an example of transformed government: 24F24F For an example of what a level 4 service might look like, imagine a couple--John and Mary-starting a family business. They know that there are a lot of requirements that government places on anyone who starts a business. The problem is that they do not know what these requirements are, let alone have time to meet all of them. One evening after discussing their plans around the dinner table, John and Mary go to their computer and visit the www.utah.gov web site. There they select a life event consistent with their situation, 25 http://www.windley.com/docs/egovernment%20maturity.pdf Page 48 of 112 Enterprise Architecture of public Denmark Master thesis, December 2006 “Starting a Business,” and fill out a series of easy to understand screens that gather all the information necessary to satisfy government’s demands associated with starting a business in Utah. After going through this simple process, the information that John and Mary entered is used to register their business name with the Department of Commerce, get an EIN from the IRS, notify the Tax Commission that they need a sales tax number, sign them up for a business license with their city, set up their unemployment insurance account at the Department of Workforce Services and apprise them of any licensing requirements. Because of the design of the www.utah.gov portal, Mary and John are able complete this transaction in a secure environment choosing from a variety of payment methods. In a few minutes at home, they have taken care of tasks that would have taken days of driving from place to place, filling out the same information on numerous forms. This is a completely new way of interacting with government. They interact with government in an integrated fashion, “online, not in line,” 24 hours a day, seven days a week from the convenience of their homes. Even though this example is taken from the US, it is still useful in order to gain an understanding of how transformed government works. This example goes beyond the State government to include services offered by local government and the federal government. Phillip sums up by saying: “one day these services may even extend to include private services such as banks or real estate”. From the description of these different service levels, I would assess Denmark to be at level three, i.e. having an integrated government. 4.9 EA Maturity and measurement Having established a firm eGovernment maturity level for Denmark, I will now proceed to analyze EA maturity. This will give me an indication of how long an organization is in the process of establishing, operating and/or gaining value from enterprise architecture. While other measures, e.g. effectiveness measures and status measures, is set up to measure specific aspects of enterprise architecture, e.g. the EA documentation, the models, definitions, principles and other artefacts (or assets) making up the EA 26, it is, according to IAC (2005), important to assess the EA program and other areas of how EA is being utilized within eGovernance and decision making. 25F25F Herzum (2003) has identified five maturity levels (see figure 14) which he believes corresponds to an organizations’ ability to deal with EA aspects. He lists explicitly five stages an organization has to go through when working with EA. Herzum also acknowledges that these stages are introduced in simplified form; in reality it is anticipated that it is difficult, if not impossible, to identify maturity stages which 100% corresponds to the complex environment of any organization. In the following are his stages described. 26 See appendix 8 Page 49 of 112 Enterprise Architecture of public Denmark Master thesis, December 2006 Optimization Integration Blueprinting Classification Inception Stages Figure 14. Herzum's maturity stages. Source: Peter Engelund, 2006 The first stage – the inception – involves an organization is recognized by being technology centric but having no knowledge regarding EA benefits and not having a defined EA team. The second stage – classification – involves that an organization will have acknowledged the need of an EA, defined an EA team, identified simple framework, created management support and established simple portfolio modeling, e.g. describing the IT portfolio. The third stage – blueprinting – involves an organization will have established an EA program and a basic governance process describing how projects can assist in the creation of the EA. Furthermore reference architectures are being built and actively used to make what Herzum calls strategic decisions. One of the missing links at this stage is a lack of that the whole organization not yet is working towards the establishment of an EA. The fourth stage – integration – involves having established an EA where alignment between the business, information, technology and applications is created and structured in a usable form. Furthermore, which is believed to be a good point of measurement, the EA should have a quality level to the point of being able to outsource the development of applications. The fifth stage – optimization – involves having a complete EA covering the whole organization, there are plans for the architecture and business goals can be tracked down to individual applications. Obviously, a complete toolbox to support the EA is also present. The public sector of Denmark may be high in eGovernment maturity, but when it comes to enterprise architecture maturity, do not go beyond the first stage, thus being immature in relation to EA. 4.10 Architecture Frameworks In large modern enterprises, a rigorously defined framework is necessary to be able to capture a vision of the “entire organization” in all its dimensions and complexity. To illustrate this, Schekkerman, wrote a book about it and called it: “How to survive in the jungle of Enterprise Architecture” in which he compares 15 different EA frameworks and supporting tools. Zachman points out that one of the most Page 50 of 112 Enterprise Architecture of public Denmark Master thesis, December 2006 misunderstood concepts about his framework is that it is not a methodology. It does not prescribe how to conduct EA. In 1997, he produced a list of six key elements that a framework should support: • Simple to understand • Comprehensive • A language – in the sense that it enables you to consider complex concepts without having to know all the technical terms • A planning tool to aid you in your decision making • A problem-solving tool which gives you the freedom to simplify without loosing the overall picture • Neutral – i.e. independent of tools and methodologies. In selecting the frameworks to analyze, I will first describe my universe of discourse: the Danish municipalities and the State. I hypothesize that the municipalities’ EA activities are not maturity while the same are mature as far as the State goes. I have already concluded from analyzing the input from the study survey report that many municipalities are not very mature in EA aspects. Mapping this universe of discourse to Zachman’s list of key elements, the municipalities’ framework should at least be simple to understand, be comprehensive and be a planning tool to aid the municipalities in their decision making efforts. I believe the best fitted EA framework for this support, is found in Scott Bernard EA3 Cube framework and implementation methodology (see chapter 4.10.1). As far as my other universe of discourse goes, the State, which consists of many actors (see chapter 5.4.2), will need to have a framework tool that basically fulfills Zachman’s all six key elements, but in particular it have to contain a language, which enables all the actors to consider complex concepts without having to know all the technical terms. Each EA is different, reflecting the unique characteristics of the organization and its goals. But according to OMB's definition, all EA’s should have three major components: the "AS/IS", or baseline, architecture, which captures the organization's current architecture; the "TO/BE", or target, architecture, which describes the organization's desired architecture as designed to achieve strategic goals; and a transition plan, which uses a phased approach to get from "AS/IS" to "TO/BE". An organization must also have a structured process for managing change to its EA, which needs to change as the organization changes—in a continuous process. In my search for this, I choose Jane Carbone’s IT architecture Toolkit, as it is easy to synchronize the methodology amongst a team, it’s quick to read and will push the right buttons. Getting the main public actors to read large text books is out of the question. Once everyone grasps the methodology and the desired outputs, it is possible to introduce more complexity to the enterprise architecture/strategic approach as necessary. Figure 15 illustrates how these frameworks can be mapped to the two public domain areas: the municipalities and the State. I will only brief summarize how an optimal framework for merging municipalities could look like based on Bernard’s own framework. This I will do based on my own previous research within the area. From the EA Toolkit, I will deal with the business needs of the State. The architecture framework and an in-depth description of the implementation strategies for the State are beyond the scope of this thesis. Page 51 of 112 Enterprise Architecture of public Denmark Master thesis, December 2006 EA3 Cube framework The municipalities The State Figure 15. Mapping of architectures to my universe of discourses. Source: Own contribution. I will, however, depending on my findings in the business needs, suggest ways to improve the awareness, the propagation and the use of Enterprise Architecture in the State of Denmark through a management program. 3 4.10.1 The EA Cube framework Bernard’s implementation methodology identifies distinct lines of businesses which encompass five sub-architecture levels and three common thread areas (see figure 9). The sub-architecture levels address strategic initiatives, business processes, information flows, systems and services and infrastructure. The three threads entail security, standards and workforce. The EA3 framework not only recognizes the role of early architecture approaches that addressed data, applications and networks but also recognizes newer approaches promoting strategic scenario planning, the value of business supply chains and web-based services. This framework is mapped to the public sector at different levels. The sub-architecture systems and services in particular exemplify how EA can link strategy, business and technology components across the enterprise within a so-called “service bus” that provides a platformindependent common operating environment for IT systems and services. It is the standards thread which ensures interoperability within the service bus by promoting the use of IT systems and services based upon open standards/protocols and non-proprietary solutions. Page 52 of 112 Enterprise Architecture of public Denmark Master thesis, December 2006 Figure 16. EA best practice framework for merging municipalities. Source: Own contribution. As mentioned in the ‘Background of the thesis’, Bo Kristensen and I previously analyzed the merging of the Danish municipalities. As figure 16 illustrates, the end result hereof was a recommendation of a framework in support of the merging municipalities 27. As the reader probably recognizes, this framework is based on Bernard’s EA3 cube but with a few important ratifications. First of all, the starting point is from four different AS/IS views to one TO/BE view. Writing an EA management plan for this is a complex and comprehensive task. Secondly, the TO/BE enterprise (i.e. the municipality) is not only influenced (i.e. dependent) on external environmental factors originating from technical and business oriented trends but also influenced by political decisions and the needs of the citizens. Third, we added an extra functional area: The organizational structure. We summarized by saying: “This structure has to be in place first and must take into consideration the business oriented demands the municipality faces in the future. I would not be surprised to see if the same is the case when introducing EA into the State domain. This I have not analyzed or made research on before, so this area of focus will form the remainder of the study. 26F26F 4.10.2 The EA Toolkit IT Framework In honoring the previous chosen EA definition (see chapter 4.1.2), our working EA definition in the public sector must entail both a current and future state from an integrated strategy, business and technology perspective. Carbone’s EA toolkit business framework (2004) captures this structure very well. The rows represent a snapshot of where the enterprise is at a point in time. Bernard calls this AS/IS and TO/BE. The columns describe the content outputs – data to be captured and addressed in IT architecture (see figure 17). In the following I will describe the current state of EA through various other information sources, such as the public domain by using my own research in the form of the results of my study survey report and the Internet, Interviews and reports. 27 See appendix 4 Page 53 of 112 Enterprise Architecture of public Denmark Content View Current State Target State Master thesis, December 2006 Description Analysis Chapter 5 Chapter 6 Chapter 7 Chapter 8 Figure 17. The EA toolkit business framework. Source: Carbone (2004) I have used Carbone’s EA as a national framework tool because of ease of use and it is applicable in enterprises new to the discipline and concept of EA. Besides, this framework supports large and complex structures, with changing environments, whereas Bernard’s much more precise and stringent framework would be better suited for smaller enterprises such as a single municipality. Since I am treating the whole public sector as one enterprise, I will continue with Carbone’s EA toolkit framework. The description of the current state is a collection of facts. According to Carbone these facts should entail: 1. Business strategy documents capturing the business purpose, e.g. mission statements, visions, and goals 2. The history or culture of the enterprise 3. The business drivers that describe the major themes or motivational forces that impact the behavior of the enterprise 4. Key constraints 5. The six W’s: • What – what does the organization do? (e.g. sell VCR’s) • When – describe any key events or historical changes that have or will have an impact on how the enterprise operates • How – In what ways does the enterprise conduct business? (Online research, retail sales centers etc.) • Who – The organization, its customers, suppliers, partners etc. • Why – problems causing the business to work differently or a change in strategies and business driver (why is this situation not working?) • Where – the location of the enterprise, service departments, branches etc. These six W’s resemble Zachman’s six questions in his two-grid framework (see appendix 2) but puts them into a practical context. Carbone suggests other more general elements to be captured. Of these I have selected those relevant for Denmark Ltd.: • company size in annual revenue, expenses, and number of employees • number and types of customers • locations served and serving • list of products and service, and quantities sold • high level organizational structure and/or process flow • current technology Page 54 of 112 Enterprise Architecture of public Denmark • Master thesis, December 2006 external interfaces The analysis of the current state involves among other methods assessment indicators – factors used to analyze the business current state data as collected in the previous step. Just like a thermometer they provide a way to gauge a temperature of the business. Carbone suggests the following points as assessment indicators: • Stress points/risks • Strengths and weaknesses • Challenges • Environmental factors • Growth/cost containment opportunities The description of the target state is about foreseeing the target state of the enterprise. According to Carbone, there are two approaches to apply in describing this target state: the positive statements approach or the visionary approach. The former includes asking this question: How would the business behave if: • Stress points were relaxed/risks mitigated? • Weaknesses were addressed and strengths fortified? • Challenges were resolved? • Environment changes were accounted for? • Growth/cost containment opportunities were leveraged? The visionary approach allows me to describe the target state in more depth, and takes on an ideal future view. In the ideal future: • How will customers and suppliers interact with the enterprise? • What would the future high-level business function flow look like? • What key business information will flow through the process? • What critical people, plans and skills will be in place? • What critical support processes and structures will be in place? • What key capabilities will enable the desired state? It is a difficult task – and not always realistic – to describe the ideal future. Instead I will to capture all the problems in the current state and see what the future looks like if they are overcome, thus taking on the positive statements approach in describing the target state. The analysis of the target state comprises the identification of significant business opportunities and/or gaps to be addressed by IT architecture. Again, two approaches are suggested: The first approach compares significant stress points, strengths/weaknesses, challenges, environmental factors, and growth opportunities between the current state description and the target state description. The second approach also compares the current and target state, then lists the differences as gaps, and finally reversing the gaps as opportunities. Since this last approach will simplify the translation to infrastructure planning, and it tends to result in less general, more specific opportunities for action, especially when analyzing flows, I will choose the second approach in analyzing the target state of the State domain. I will sum up this business view of the State domain in an integrated approach similar to figure 17, and thus have a working list of key areas to be addressed with architecture. Page 55 of 112 Enterprise Architecture of public Denmark Master thesis, December 2006 5. Description of the Current State 5.1 Introduction The description of the current state contains just the facts. These comprise a business strategy (mission statements, visions, goals etc.), the history or culture of the enterprise, the business drivers that describe the major themes or motivational forces that impact the behavior of the enterprise and six key constraints: 1) what, 2) when, 3) how, 4) who, 5) why and 6) where. 5.2 Business strategy documents This section contains the business strategy documents, such as mission statements, goals and/or vision of EA in the public sector. 5.2.1 Vision of the structure reform First we need to define the vision the Danish politicians have set forth 28. They are the CEO’s of Denmark Ltd. – the managers of “the public business”. The government has not been very open though about declaring its vision and accompanying goals of the structure reform. A vision should be visible and easily accessible to the population, but it is not. I have found a copy of the official agreement document between the political parties of the structure reform, and in sentences extracted the vision of the structure reform: 27F27F The vision of the reform is to maintain and enhance a democratic governed public sector with an established strong foundation for continued development of the Danish welfare society. 5.2.2 Goals The goals for realizing this vision is as follows: • • Create sustainable units with a clear responsibility in delivering welfare services of utmost quality to the Danish population With the future larger municipalities more opportunities arise for improved task solutions and for welfare tasks to be solved by the municipalities themselves. With more tasks placed locally, the democracy will be strengthened due to an increasing number of political decisions made locally. The democracy must be propagated, so the citizens will be actively involved with the decisions. The municipalities must find new ways of involving the citizens and users in these local decisions. 5.2.2.1 Strategy for digital strategy for the municipalities 29 If the vision of a coherent public sector with the municipal as the citizens’ main entrance to the public is to be fulfilled, then this will demand a heretofore unseen co-operation and relationship across the authorities. E-Governance will be the spearhead in this development. 30 28F28F 29F29F 28 http://www.im.dk/imagesupload/dokument/Aftale%20om%20strukturreform%20ny.pdf http://e.gov.dk/uploads/media/Digital_Communication_in_the_Public_Sector_01.pdf 30 http://www.kl.dk/367274/ 29 Page 56 of 112 Enterprise Architecture of public Denmark Master thesis, December 2006 Below is the municipalities’ vision of the digital activities of Denmark. The e-Government vision is to systematically use digital technologies to introduce new ways of thinking and transform organizations and work processes to improve the quality of service and efficiency. The digital goals for realizing this vision have also been set forth: • E-Government should actively contribute to the development of the network society. • The public sector should work and communicate electronically. • The services of the public sector should be delivered in a comprehensive and customer-centric way. • The tasks of the public sector should be carried out where they are handled in the best possible way. 5.3 The history of EA in Denmark Ltd. On June 13 2003, the Danish Ministry of Science, Technology and Innovation published a ‘national white paper 31 on enterprise architecture. After that a handbook on EA implementation 32 was written in 2004 and current EA activities are a virtual EA guide 33, a national EA repository 34 and a range of reference models and patterns 35. The white paper has been prepared by a working group with representatives from the state, the counties and the municipalities, and was commissioned by the Coordinating Information Council. 30F30F 31F31F 169H 32F32F 3F3F 34F34F 5.3.1 Recommendations The main recommendations are: • The public sector – at agency level and at large – should take on a more active responsibility for its own enterprise architecture. • Government should create a joint enterprise architecture framework for the planning of government IT systems with a particular focus on securing interoperability. • A pronounced effort to raise awareness spread knowledge and develops competencies with regard to enterprise architecture, especially around joint government initiatives. This recommendation calls for both a vertical (“at agency level and at large”) and horizontally (“joint enterprise architecture framework” and “joint government initiatives”) focus. 5.3.2 Joint Enterprise Architecture Framework The white paper suggests that the joint enterprise architecture framework at least contains the following: 31 http://www.oio.dk/arkitektur/publikationer/whitepaper http://www.oio.dk/arkitektur/publikationer/haandbog 33 http://ab.oio.dk/arkitekturguide 34 http://ab.oio.dk/arkitekturbibliotek 35 http://ab.oio.dk/referencemodeller-monstre 32 Page 57 of 112 Enterprise Architecture of public Denmark • • • • Master thesis, December 2006 Joint coordination, including the establishing of a National Enterprise Architecture Committee with reference to the Coordinating Information Council. Common methodologies in terms of processes, concepts and description standards for enterprise architecture. Common choices regarding standards and infrastructure, including usage of a common reference profile (e-GIF) and common architectural principles. Common tools, e.g., by using shared databases and libraries of contract models, process descriptions, data definitions, software components and infrastructure patterns. It emphasizes an increased focus on Enterprise Architecture and cross-governmental coordination efforts as essential elements for realizing the visions of eGovernment. 5.3.3 Principles As a common architectural principle, the white paper recommends the Danish government to adopt a service oriented architecture (SOA) model, in which IT-solutions are modularly designed services that have well-defined interfaces to each other and to legacy systems. It is considered a basic principle in SOA to organize components in layers that offers and uses each other’s services. Web services are practical examples of a service-oriented architecture implementation. KL refers to SOA as Lego blocks. For instance IT solutions have to be made up by “Lego blocks”, where each block is equivalent to a well defined part of the overall workflow. An IT solution for pension contains a form, a decision, a payment calculation and a payment to the citizen. The municipalities which want to manage the decision of the case in regard to political issues can replace the ‘Basic Register’ building block with another one and still have a functional overall IT solution. This way of building IT is Figure 18. Illustration of how SOA works. Source: 268Hhttp://www.kl.dk/it-strategi/ what KL – in a popular way – calls Service-Oriented Architecture. In the same terminology – the popular way – KL describes service user interfaces as buds on the Lego block that other IT solutions can hook up to in order to request completion of certain tasks. KL and KMD made an agreement about standardization and access to a number of municipal solutions through service user interfaces into which SAP has been chosen as de facto future technical platform. The process has already begun with reengineering all existing SAP modules to this architecture. So now, more than three years after the Danish Ministry of Science, Technology and Innovation published its white paper on EA, KL has finally come around to focusing in on this architecture as well, thus fulfilling the white papers recommendation for architectural principle use: SOA. One may ask himself why this has taken three years and one can only think of how far the Danish municipalities could have been had the recommended architectural principle been integrated into KL’s IT strategy for the municipalities and put into practice three years ago when it was recommended. Has the technology not been here before? Yes! Has the market, i.e. the municipalities not been ready for it before? Maybe not! Perhaps the need hasn’t been here before? It looks like the need has been here since June 2003 when the white paper recommended its use. Or is this simply an expression of urgency: now the Page 58 of 112 Enterprise Architecture of public Denmark Master thesis, December 2006 municipalities are merging KL has to come up with a digital strategy for the municipalities in order to take the heat of the pressure from the municipalities and the government. Whatever the motive or reason for delay, it looks like SOA is finally here to stay. Since this concept is here to stay, I will distance myself from the popular definition, and instead clarify the concept of services more precisely. Depending on the level, this concept can be thought of differently. At the conceptual level, SOA represents a model of loose-coupled applications working together by exposing services to each other. At the business level, services are expressing data- and function services that one party can offer other parties to use, e.g. businesslike terms. At the technological level, SOA consists of a group of emerging standards that define protocols and creates a loosely couple framework for programmed communication between different systems. At the physical level, web services are a notion that describes a method which enables an application to be invoked by other applications by receiving and sending data in standardized XML. In itself, SOA does not prescribe any particular technical standards, even though vendors offer technical solutions. The standardization process for web services standards takes place in various international organizations like W3C, OASIS etc. I will not at this time pursue SOA and its effects any further as it is beyond the scope of this study. The white paper points out 5 core architectural principles: • Interoperability • Security • Openness • Flexibility • Scalability 5.3.4 Structure The architectural process should embrace the core principles. This process is illustrated in figure 19 with two sequential circles containing: The main architecture process and the implementation process. In the first circle are the enterprise visions used to define business process architecture, then information architecture, and then the technical architecture. This process thus defines the concrete architectural principles, which are used in the second circle. This process consists of portfolio planning, Gap analysis and implementation projects. Figure 19. White Paper Structure. Source: Own contribution Page 59 of 112 Enterprise Architecture of public Denmark Master thesis, December 2006 5.3.5 Guidance A Danish National Enterprise Architecture Competency Community will be established. The National IT and Telecom Agency (NITA) will act as facilitator and advisor, and host a number of municipal services, online and offline. NITA will also serve the National Enterprise Architecture Committee. A National Forum for Enterprise Architects will be established in collaboration with the industry and academia, and will be designed as a community of practice. To push forward the standardization work, NITA will present a first draft of the common reference profile (e-GID, e-Government Interoperability Framework) soon after the white paper is published. NITA will also produce a set of guidelines. 5.4 The business drivers What drives the public sector or what are the motivational forces that impact the behavior of the organization? According to the study survey report, 25% of the municipalities’ primary motivation for participating in a joint municipal IT co-operation is economies of scale, 18,75% have synergy as primary motivational factor while 18,75% have improved citizen service. It is interesting to note that 75% of the ones who have economies of scale as their primary motivation for business also thinks the new joint citizen portal is indispensable. 5.4.1 Key constraints Seen from the municipalities’ point of view they do not have influence on national legislation regulating the use of IT in the public sector. When the OIOXML standard was introduced, all had to adhere to it. However with the reform, the municipalities have a lot more influence on local issues than before. 5.4.2 The six W’s This paragraph describes the ‘who’, ‘what’, ‘when’, ‘how’, ‘why’ and ‘where’ issues of the enterprise. 5.4.2.1 Who? The 13 counties in the country will be replaced by 5 regions. These will be led by a regional council with 41 members. The regions do not have the right to impose taxes and are only allowed to deal with tasks determined by law. As a result of the task- and structure reformation decided by the Danish Parliament the number of municipalities will change from 271 to 98 by January 1, 2007. There are 225 municipalities which are merging with no change in boundary, 32 municipalities with unchanged boundaries and 14 municipalities that split up as a result of merging. 36 35F35F With respect to the management and liberty of action of the municipalities, they will still be led by a city council consisting of 9-31 members depending on the size of the municipality. They have the right to impose taxes and are comprised of the municipal authority. 36 See appendix 7 Page 60 of 112 Enterprise Architecture of public Denmark Master thesis, December 2006 A clear and distinct distribution of the role- and responsibility is crucial for the realization of the vision and the implementation of the EA program. The overall Digital Project E-governance create common frames and support cross-cutting co-operation, but the responsibility for realizing concrete benefits involves and commits the different authorities across sectors and authority levels within the entire public sector. In comparison to the general development a number of fora and authorities have a certain responsibility. These are listed below and split up in the three different areas 1) the municipal domain, 2) the state domain and 3) common fora, for the sake of maintaining an overview of the actors. In some fora where several actors are represented from different places, I find it relevant to identify the meeting frequency and its participants in order to more fully establish the view of the actors. Therefore these two elements have been left out in the more permanent structures such as KL. The municipal domain Actor Domain Purpose KL (The National Municipal Attend to democratic governed municipalities’ common interests Association of the and to be the centre for collecting, developing and distributing Municipalities) knowledge of the Danish municipal government. KL is the municipalities’ principal interestand member organisation of the soon 98 new municipalities in Description Denmark. • Attend to the municipalities’ common interests Tasks • Aid the individual municipalities in counselling and with services • Ensure up-to-date and relevant information to the municipalities Table 4. Municipal EA actor # 1 Actor Domain Purpose Meetings The digitization counsel of the municipalities Municipal Promote the implementation of a whole and coordinated digital governance in the municipalities by participating in carrying out and communication of concrete projects. According to need – usually 3-4 times per year Description Established by KL Participants A number of municipal- and administration CEO’s (at the moment: CEO for KL as chairman, 1 senior manager, 4 city managers, 1 financial manager, 1 manager for the social area, 1 manager for the technical area, 1 vice president of the City of Copenhagen, and 1 IT manager – all but a few from the municipalities • Digital counsellors to the board of management at KL Tasks • Create common municipal standards and promote competition between IT suppliers • Anchor and focus in on working with digitalizing in the municipalities by taking an active part in prioritizing concrete initiatives and projects, and coordinates these, which to a greater extent has focus on the organization, structure and management side than on the technical side of the implementation Table 5. Municipal EA actor # 2 Actor Domain Purpose Kommune Municipal To secure common digital solutions for the municipalities. Holding A/S Description 100% owned by KL. Kommune Holding A/S owns KMD A/S and Kommuneinformation A/S. It was established in 2003 by KL to separate the politics and business aspects and as a linking element between KL and KMD. It was also established because no single enterprise can provide solutions which fulfil all the municipalities’ needs in a multiple supplier environment, and to ensure the free choice for the municipalities. • Ad hoc tasks such as the development and operation of a new BBR register, and standardising of Tasks municipal basic data. Table 6. Municipal EA actor # 3 Page 61 of 112 Enterprise Architecture of public Denmark Actor Domain Kommuneinformation Municipal Master thesis, December 2006 Purpose To produce knowledge and solutions, which create value for the municipalities, so administrative procedures can act effectively, citizen oriented and in accordance with legislation. Description 100% owned by Kommune Holding A/S, which in turn is owned by KL. • Deliver knowledge based solutions, which focus on efficiency of the internal workflows in the Tasks municipalities • Securing that the citizens receive the best and legislative most correct service • Supporting the municipal case workers in establishing an effective dialogue with citizens, politicians and other areas of the governance through graphical and digital solutions. Table 7. Municipal EA actor # 4 Actor Domain KMD Municipal Purpose To deliver IT and consultant services to the private and public sector 100% owned by Kommune Holding A/S, which in turn is owned by KL. Description • Developing self-service portals such as www.netborger.dk and www.e-boks.dk Tasks • To support the employees in the public sector at any time can respond to and manage Table 8. Municipal EA actor # 5 170H Actor Description Domain 17H Purpose Meetings Board of Municipal Govern the IT Contact N/A management Committee Established in order to govern the contact to the IT Contact Committee • Be a governing body of the IT Contact Committee • Be the link between the IT Contact Committee and KL Table 9. Municipal EA actor # 6 Tasks Actor Domain Purpose Meetings IT Contact Municipal To be the linking element between KL and Committee the municipal IT-departments Established as a link between KL and the municipalities Description • Send out information on IT related matters to the municipalities Tasks • Receive feedback from the municipalities • Link between KL and the municipalities Table 10. Municipal EA actor # 7 N/A The State domain Authorities with certain responsibility for e-Governance are listed below. Actor Domain Purpose The Ministry of Finances State N/A Description E-Governance is an integral part of the public administration policy and modernization of the public sector among other things through the governments’ modernization program, which is on of the primary framesets for coordinating initiatives for developing and streamlining the public sector. Tasks • Work mainly with strategic aspects of IT, such as IT-strategy Table 11. State EA actor # 1 Page 62 of 112 Enterprise Architecture of public Denmark Master thesis, December 2006 Actor Domain Purpose The Ministry of Science, Technology and Innovation State N/A Description The Ministry contribute through the governments’ IT policy and the State IT policy to the realization of the government’s policy towards citizens, companies and the public sector. The Ministry is sphere responsible towards the public sector for the technical development of which production of standards and policies as well as the public information policy is a part. Description • Work mainly with technical aspects of IT, such as IT-architecture Table 12. State EA actor # 2 Actor Domain Purpose Meetings The State IT State Set the agenda for an offensive use of IT N/A Council in the public sector Participants All government departments at the level of management with the Ministry of Science, Technology and Innovation with the IT- and Telecom Agency CEO as chairman Tasks • Contribute with initiatives for the governments IT-policy, so that the policy supports the development of Danish society in the best way possible. • The council should discuss State IT-policy and secure co-operation of common problem areas. • Exchange of experiences, guidance and common solutions. • Organizational development and competence development. Table 13. State EA actor # 3 Actor Domain Purpose The National IT and State Ensure an optimal framework for IT and telecommunications and Telecom Agency conditions that will enable citizens, businesses and the public (NITA) sector to realize the network society The agency is part of Ministry of Science, Technology and Innovation. Description Tasks • Develop and implement initiatives within key areas of the Government’s IT policy strategy. • As part of the Ministry, it provides input to the Minister and advises on IT related matters and legislation concerned with telecommunications, communications and information technology. • Assists in drafting policy proposals, bills and executive orders in co-operation with the Ministry’s departments • The agency assists in answering questions from the Danish Parliament and letters from citizens. Table 14. State EA actor # 4 Actor Domain Purpose Meetings IT Architecture State To support a coherent and effective N/A Office at NITA use of public IT. Description This office creates framework for and promote use of public IT architecture. This is realized by listing a number of guidelines for IT system configurations, i.e. concerning user administration, information architecture or demand on the technical infrastructure. It supports the governments IT policy with concrete IT projects and IT-related knowledge and attach bond between the public and the private. This is done for instance through the FESD (The Joint Public Electronic Case- and Document Handling) project. This office further works as a co-operation partner in relation to a number of larger IT projects i.e. the business portals www.virk.dk and www.skat.dk. It is a secretariat to the OIO-IT architecture committee along with responsibility within co-operation with sector standardized committees of IT architecture and IT standardization at sector level. Participants N/A Tasks • Development of IT architecture • E-governance • Operation and development of the FESD standardization, including participation in the Steering group (STS) • The common public standardization catalogue (the OIO catalogue) • Knowledge centre for software Table 15. State EA actor # 5 172H 173H Page 63 of 112 Enterprise Architecture of public Denmark Participants Tasks Actor Domain The State IT forum State Master thesis, December 2006 Purpose Meetings A committee under the State IT counsel Monthly to address technical issues The CIO’s for each government department. The Ministry of Science, Technology and Development give counsel and point out the chairman for the State IT forum. • Discuss technical problem areas originating from the State IT counsel. • Discuss and review cross problem areas regarding the States use of IT starting from technical, organizational and administrative conditions attached to procurement and usability of IT. • Reports to the State IT counsel. Table 16. State EA actor # 6 Common fora Actor Description Participants Domain Purpose Meetings The Common fora STS plays the most central role for carrying out enterprise Steering architecture and e-Governance in Denmark and other joint Once a month Group national initiatives. (STS) The Steering Group plays a very active role in the establishment of the digital task force’s tasks. STS governs Project e-Governance and the digital task force (the ‘Taskforce”). Head of the department of The Ministry of Finance, The Ministry of Science, Technology and Innovation, The Danish Ministry of Economic and Business Affairs, The Danish Ministry of Domestic Affairs and Health, the CEO of KL and TADR (The Association of the Danish Regions). • Tasks Table 17. Common Fora EA actor # 1 Actor Domain Purpose Meetings The digital taskforce Common To promote the switching-over to eN/A (the “Taskforce”) fora Governance across the public sector Description Even though the Taskforce is physically located in the department of Finances, it is organizational subject to STS. Among other projects, the Taskforce has worked with digitizing communication between several public authorities also better known as the ‘e-Days’. This involved a large campaign with the aim to get the Danish population to use the public digital self-service solutions. It acts as a technical secretariat for the Steering Group STS. Participants Consists of approximately 12 people inpatriated from the Danish Ministry of Finances and the municipal organizations (KL and the Danish Regions). Inpatriation takes place from other departments and government agencies according to the need. Tasks • Brings authorities together and act as a catalyst for solutions in transverse coordination problems in the digitalizing process. • The Taskforce must initiate, support and coordinate the development of e-Governance in Denmark. Table 18. Common Fora EA actor # 2 Actor Domain The Coordinating Information Committee Common fora Purpose Meetings Secure a coordination and N/A development of a common IT policy within the public sector Description This committee has been formed by The Ministry of Science, Technology and Innovation. Participants The Ministry of Science, Technology and Development, the digital task force, The Ministry of domestic Affairs and Health, CPR-office, The Ministry of Economic and Business Affairs, KL, County Counsel Association, The national IT and Telecom Agency. Tasks • The committee will together with the digital task force support the implementation of central initiatives decided upon by the board of Project e-Governance • The committee will contribute in securing public development and implementation of standards and tools necessary in realizing the potential in public IT investments Table 19. Common Fora EA actor # 3 Page 64 of 112 Enterprise Architecture of public Denmark Actor Domain Master thesis, December 2006 Purpose Meetings IT-Architecture State Follow-up on the white book on IT N/A Committee architecture Description Technical committee with reference to The Coordinating Information Committee Participants All Ministries are represented at local CIO level. The Ministry of Science, Technology and Innovation is chairman and offer together with The National IT and Telecommunication Agency secretariat aid to the State IT Council. Tasks • The committee coordinates its own activities with the data standardization committee • Secure a context, prioritizing and progression in the work with a common IT architecture framework • Give recommendations on the use of standards • Contribute to the development of joint concepts, principles, methods and tools for IT architecture • Facilitate sharing of knowledge and experiences concerning IT architecture • Provide assistance and counsel to the actors in the decentralized processes concerning IT architecture • Take part in securing access to relevant competences for the authorities Table 20. Common for an EA actor # 4 Actor Domain Purpose Meetings Data Standardization Common fora Follow-up on the white book on data N/A Committee standards Description Technical committee with reference to The Coordinating Information Committee, formerly known as the XML committee. Participants All Ministries are represented at local CIO level. The Ministry of Science, Technology and Innovation is chairman and offer together with The National IT and Telecommunication Agency secretariat aid to the State IT Council. Tasks • The committee coordinates its own activities with the IT-Architecture committee • Give recommendations on the use of data standards • Contribute to the development of joint concepts, principles, methods and tools for data standards • Facilitate sharing of knowledge and experiences concerning data standards • Provide assistance and counsel to the actors in the decentralized processes concerning data standards • Take part in securing access to relevant competences for the authorities Table 21. Common fora EA actor #5 These three different views of the actors, the municipal domain, the common fora and the state domain, can be summarized in figure 20 which gives an overview of the actors on the stage as well as their inter-relationship. To ensure quality and consistency of figure 20, it has been verified several times by Peter Gorm Hansen, CEO of KL, by EA-specialist Kristian Hjort-Madsen 37, as well as by IT-architect Martin Dohn 38. 36F36F 37F37F The Ministry of Finances are closer to the middle than The Ministry of Science, Technology and Innovation. The former work mostly with strategic aspects of IT, such as IT-strategy, whereas the latter mostly work with the more technical issues, such as IT-architecture. According to Martin Dohn, IT architect at the Ministry of Domestic Affairs, when carrying out enterprise architecture and egovernance in Denmark some fora are more relevant than others. STS plays the most central role for this purpose and other joint national initiatives. Other players in this group of central players are the digital task force and The National IT- and Telecom Agency (NITA) with its IT Architecture office. At the other end of the scale, there are “soft” fora which are characterized by being what I call a 37 38 Kristian Hjort-Madsen, Enterprise Architect, The Ministry of Finances Martin Dohn, IT architect, The Ministry of Domestic Affairs Page 65 of 112 Enterprise Architecture of public Denmark Master thesis, December 2006 decentralised player. This involves providing input to other public agencies. These fora comprise the ITA committee and the coordinating information committee. In the process of producing figure 20, I have identified a few problems with the actors. As I said before, some actors are more relevant than others. From several sources, every issue that ends at the “desk” of the Coordinating Information Committee does not go any further. It is stranded here. During interviews with XX and YY who independently of each other described this actor as an extremely passive partner I learned that nothing really goes on in this committee: “Nothing happens here, and if an issue or initiative is brought up from the IT-Architecture committee or Data standardization committee, it stops at the Coordinating Information Committee.” Furthermore STS often just “by-passes” this actor and goes directly to the ITA and Data committees. Besides being very ineffective, this mix of strong and weak actors creates what I call islands in the State. The Coordinating Information Committee does not communicate with STS and vice versa. There is a missing link here. I will deal with this whole issue of common fora much more in phase 9, the EA management program. Commenting on this figure, XX mentioned that Denmark is not geared for EA due to sluggishness Figure 20. E-Governance overview of the three dimensions in Denmark. Source: Own contribution in the public sector. This is exactly what XX municipality also pointed out from the study survey report, when asked what could be the greatest obstacle for joint municipal IT co-operation. Their opinion carries weight into the discussion, being one of the leading EA municipalities of Denmark. Mr. XX Page 66 of 112 Enterprise Architecture of public Denmark Master thesis, December 2006 pointed out that Denmark is known for this wide spectrum in the middle – which I call ‘common fora’ – having participants from both the municipal and State domain. He said: “This is one of our forces and has become known as ‘the Danish model’ in other countries.” This I have indicated in the figure by the horizontal arrow. On the municipal domain side, KL is of the general opinion, that IT solutions must be propagated by making it attractive for the market itself to deliver what the municipalities need. And the municipalities’ needs must be formulated as open standards for digital process flows which several suppliers will be able to fulfill. Normally I will not show these suppliers of IT in figure 20, but since KMD is owned by KL and is one of the main suppliers of IT solutions to the municipalities, it is included. An important problem in the municipal domain have for many years been the development and sustainability of many different systems. This is particularly relevant now, with most of the municipalities merging these years. This has created the so-called silos in the public sector. I will also deal more with this issue in phase 9, the EA management program. As earlier mentioned Denmark is faced with a great restructuring of the entire public sector these years. This will ultimately take effect by January 1, 2007. The structure- and task reformation suggests two overall consequences: 1) restructuring of the physical boundaries of the municipalities and the creation of new regions replacing the old counties and 2) reallocation of tasks between the State, the regions and the municipalities. These tasks will be dealt with in the ‘what’ section of this chapter. 5.4.2.2 What? The ‘What’ defines what the enterprise does? Figure 21 illustrates the three EA dimensions in the public business model of Denmark. This elucidates the processes in the execution of the tasks as well as clarifying the underlying infrastructure that will support these processes. The tasks comprise three different management areas grouped in four task areas. The three management areas are: 1. Customer Relationship Management The management of the contact to citizens and companies. 2. Production Management The management of the production of public goods and services. 3. Administration Management The management of the internal administration in authorities and institutions. The three management areas facilitate four task areas. These four task areas are: 1. Citizen and company contact – this entails Figure 21. EA dimensions of what the organization communicating information of public do. Source: Denmark Ltd., KMD goods and services to and from citizens and companies and an overview of the individual level of involvement in relation to the public domain. 2. National authority production – this entails law-oriented tasks like the social task, employment task etc. These tasks are characterized in that only public authorities can solve these tasks. Page 67 of 112 Enterprise Architecture of public Denmark Master thesis, December 2006 3. Service production – this entails childcare, school, elderly care, roads, parks etc. These are tasks the public authorities to a degree can influence themselves and outsource the tasks to private enterprises. 4. Internal administration – this entails tasks necessary to support the production of public goods and services such as payrolls, staff, economy, procurement, logistics and management information. The internal administration is what Porter 39 refers to as the supporting activities to the primary activities. The division of the production management into the national authority production and the service production reflect how the public business must balance between supply and demand. The national authority production occurs within a centrally agreed framework, i.e. legislation. The service production tries to meet the demand of the citizens. According to Allan Vendelbo 40, CEO of the Association of City Managers and former city manager of Ballerup municipality, the effectiveness benefit is to be found in the Service Production. He talks about efficiency improvement, quality development and competence development as the result of using new technology within the municipals. He gives an example: 38F38F 39F39F “Let’s say I as a leader of the municipal walks up to a social assistant and tells her that I think she is a key worker in our organization and therefore I will empower her with a handheld computer which can make her administrative work easier. Herein lies a recognition and appreciation for her work and this creates motivated employees, who in turn deliver better quality. But we cannot just give this device to her without any introduction and instruction in how to use it. And herein lays the competence development, which in turn gives her satisfaction, thus creating motivation while being very efficient.” I agree with Allan Vendelbo that the efficiency improvement for the municipals mainly is to be found in the Service Production. On the other hand, it is most likely that this improvement for the State is found in the National Authority Production, wherefore I will deal with both sides of the Production Management. To the business model I add the sector levels (the green and red vertical columns). A sector is a group of companies, interest groups, public authorities and institutions contributing to developing and delivering a set of related products and services to the citizen. This could be the educational sector, the labor market sector etc. The tasks in a sector are supported by communication to the citizens, companies, authorities, institutions and internal administrative tasks. This means that some sectors are primarily focused at the National Authority Production, while others primarily focus on the Service Production. This National Authority related means that sectors comprise all three management Sector areas as well as the main four tasks in the business model. 39 40 Service related Sector Porter, Competitive advantage, 1998 Denmark A/S p. 57 Page 68 of 112 Enterprise Architecture of public Denmark Master thesis, December 2006 5.4.2.3 The State tasks The State will continue to manage the overall coordination on a number of areas but will also take upon itself new tasks. From the municipalities the State will take over assessment of taxes. From the counties the upper secondary school, higher preparatory examination and other youth educations, part of the road network and the overall environment and planning tasks. There will be 5 regions established to supervise the municipalities. Besides this, a number of non-concentrated state institutions will be established with the aim to solve the States’ regional tasks concerning taxes, education, employment and environment. Regional tasks The tasks carried out by the regions include the health services, regional development tasks and the operation of certain institutions within the social and health area. Municipal tasks The current tasks of the municipalities involve roughly all tasks close to the citizens. These include daycare institution, public schools, home helper service, rest homes, libraries, culture and leisure time and environment, technical areas and urban planning. The tasks can be divided into those that are few and complex and those which are many and simple as can be seen from figure 22. The few complex tasks Heart-transplantation Forced removal of children Schools for deaf/blinds Integration Public schools Gymnasium Twisted ancles In-home service The many simple tasks Figure 22. Example of simple and complex tasks. Source: KMD 5.4.2.4 When? The ‘when’ indicates any key events or historical changes that have or will have an impact on how the enterprise operates. The most obvious is the current structure- and task reform that will take effect as of January 1, 2007. For some it will have great impact on how the business is run. This is especially relevant for the municipalities merging. All, however, will be affected by it, due to the reallocation of tasks (see the ‘what’ section in this chapter). 5.4.2.5 How? The ‘how’ indicates in what ways the enterprise conduct business, e.g. through online research, retail sales centers etc. One of the primary ways the State conducts its services to the citizen is for the greater part related to online self-service tools on the Internet. Page 69 of 112 Enterprise Architecture of public Denmark Master thesis, December 2006 Denmark.dk is Denmark's official Internet face to the outside world. The portal, which is produced for the Ministry of Foreign Affairs, is hosted by the National IT- and Telecom Agency. Private and public content providers are collaborating on producing the content sections, which are being co-ordinated by editorial staff at the National IT and Telecom Agency. As a part of the structure reformation the two main public portals in Denmark, www.netborger.dk (KL and KMD as developer) and www.danmark.dk (VTU 41 and The National IT and Telecom Agency as developer) will close by January 1, 2007, and will be replaced by www.borger.dk which will then act as the single entry point for the citizens to gain access to public information and services online. The reason for establishing this new portal is due to the fact that many citizens request only one single entry point to the public domain. 174H 175H 40F40F 176H www.netborger.dk The portal www.netborger.dk is owned by KL, The National Association of Communities 42. KMD 43 has developed it and operates the vast spectrum of the portal’s self-service solutions. The portal is known for the latter. Assisted by electronic calculations, intelligent application forms and guides you can save both time and money on this portal, which you would otherwise have spent if you went to the local municipality. The portal creates the connection to the municipality in which the citizen lives. In practice, this means that when a citizen fills out an online form it is redirected to the relevant municipality which subsequently will process the request. 17H 41F41F 42F42F According to KL 44 the portal is only a supplement to the information found on the municipalities’ websites. Therefore you can find ‘Netborger’s solutions on both the municipal website as well as on the shared portal. 43F43F This dual – and redundant – place of taken care of public tasks could stir up confusion among citizens. What is possible to do on www.netborger.dk and what can I do on my municipal website? If I am moving or applying for extra child support where do I go? To the portal or the municipality’s website? And can you do something on the portal that is not possible on the municipality’s website and vice versa? 178H www.danmark.dk The portal www.danmark.dk is owned by The Ministry of Science, Technology and Innovation. The National IT and Telecom Agency has developed it and it currently operates under their supervision. Its object is to ensure that as many citizens as possible have access to utilizing Information- and Communication Technology in a safe and secure way. Denmark.dk consists of seven different editorial sections as shown in table 22. 179H 180H 41 Ministry of Science, Technology and Innovation See ‘Glossary’ 43 KMD: The largest Danish-owned information technology enterprise 44 http://www.netborger.dk/om_netborger.asp 42 Page 70 of 112 Enterprise Architecture of public Denmark Editorial section of www.danmark.dk Master thesis, December 2006 Description 18H Information on IT and telecommunication of interest to Danish citizens. Gives an overview of the different bills and make them easily accessible to all. Updated daily with new laws, bills, departmental orders, circulars etc. Gives an overview of the public Denmark. It contains all public institutions and a number of semi-public and private institutions with a description of contact info. Gives an overview of news from the public domain. It could be latest bills passed in parliament, news from the authorities, distinctions or new public websites Gives access to the same self-service solutions offered by www.netborger.dk from KMD. Link to the different municipalities’ websites. Gives an overview of the different published books, pamphlets and leaflets within the public domain – both on- and offline. Gives an overview of the citizens’ rights and opportunities. Written by specialist from different organizations and authorities. Updated as soon as a new law is passed. IT-citizen The law Authorities News Self-service Publications What you need to know 182H Table 22. Overview of the website: www.denmark.dk. Source: www.denmark.dk 183H 184H So today there are not only two places the citizens can go to when communicating with the public, but actually three: 1) the municipality website, 2) www.netborger.dk and 3) www.danmark.dk. Suspicious of this undesirable spectrum of citizen-based entries to the public, a workgroup was established in the fall of 2004 consisting of representatives from The Ministry of Science, Technology and Innovation, IT- and Telecommunication, The Digital Task Force, The Ministry of Financial Affairs, The County Council Association, KL and the Municipality of Copenhagen with the purpose of elucidating the supply of public digital information and self-service functions towards the citizens and the citizens’ obstacles for using and demanding public digital communication. The outcome was a report called “Digital communication between the public and the citizens 45” from June 2005, which was the foundation of the decision of making one single entry to the public: www.borger.dk. 185H 186H 4F4F 187H www.borger.dk In order to realize the justification of the presence of this newly created citizen-based portal, one have to understand the analysis and the results thereof that led to the decision of implementing this new portal. The respondents were four typical user profiles: 18H 1) 2) 3) 4) “The Uncertain” “The Competent” “The experienced” “The professional” 45 http://videnskabsministeriet.dk/site/forside/publikationer/2005/digital-kommunikation-mellem-det-ofentlige-ogborgerne/kvalitativ_rapp.pdf Page 71 of 112 Enterprise Architecture of public Denmark Master thesis, December 2006 The Experienced and The Professional primarily use the public digital self-service opportunities in a two-way communication environment. The Competent primarily search for information, consequently using one-way communication. The Uncertain has very little knowledge and use of public digital offers. As can be seen from table 23, the strengths represent what could be considered “normal strengths” by using an Internet based means of communication and information, such as always accessible, avoiding lines, relieving human workforce etc. On the other hand the survey revealed that the citizens have a difficult time finding and gaining an overview of the public digital services. Strengths Accessible around the clock Fast – avoid standing in long lines Accurate and updated information Trustworthy information Anonymous/impersonal (The Professional and The Experienced) Extra information – “that you did not look for” Relieves the administrative employee Weaknesses Lack of overview Missing standards (structure/layout) Bad quality with specific public sites or self-service opportunities Inappropriate use of language Too many codes Bad search engine on some sites Too much information about profile and value base Lack of knowledge on digital signature Impersonal – lack of social contact (The Competent and The Uncertain) Unaffectedly Lack of referrals from other media Missing links to other sites (public as well as private) Lack of confirmation on complete tasks Difficult to go back to previous page – and start page Table 23. Strengths and weaknesses by using the public digital offerings. Source: www.borger.dk 189H The citizens requested one single point of entry to the public domain. So we are down to two entry points for the citizens after January 1, 2007: The municipality’s websites and www.borger.dk. 190H It seems like a paradox that on one side the Ministry of Domestic Affairs stresses the fact that the municipalities will be the citizens’ one single entry point to public information and services but on the other hand the Danish Government, KL and The Association of County Authorities decide to establish a common public citizen portal, www.borger.dk, as the first step towards a common public citizen portal which will act as the center of digital communication between the citizen and the entire public domain. 46 19H 45F45F In www.borger.dk’s FAQ it is mentioned that it will not have any effect on the public websites from the different municipalities, but will more act as a supplement to the different public websites. So if it is only a distribution point of information with links to different municipal websites it does not live up to its vision of providing digital communication between the citizen and the public domain. 192H 46 http://borger.dk/portal/page/pr04/borger_infosite/infosite/forside/spoergsmaal%20og%20svar Page 72 of 112 Enterprise Architecture of public Denmark Master thesis, December 2006 The digital online www.borger.dk will be in effect by January 1, 2007 but by January 1, 2008, the citizens will have their own personal page on the portal, called: “My Page”. Here they will have access to personal information such as “My Taxes”, “MySU” and so on. 47 These services will cover public needs across the entire public sector. The goal is to have the joint public citizen portal in effect from 2008 and all public self-service solutions implemented by 2012. 48 193H 46F46F 47F47F So we have two citizen portals: 1) www.borger.dk and 2) the Development Project made by the national steering group STS. Borger.dk is a temporary portal KL and VTU would like to do together. It acts as a forerunner to the Development Project by STS and its presence is justified due to the fact that there has to be a common portal by January 1, 2007, once the merging of the municipalities is a realization. Besides this, a study reveals the citizens prefer one instead of two portals. By contract The National IT- and Telecom Agency owns www.borger.dk. 194H 195H Figure 23. General obstacles for contact with the public through the Internet 2006 49 48F48F Figure 23 reveals the older you are, the greater the need for physical contact with the public consultants which is the number one general obstacle for Internet contact with the public. The lack of immediate and direct response is the second largest obstacle predominantly by citizens aged 20-39 years. The third greatest obstacle constitutes concern of protection and security of information. The fourth highest is “Others” which cannot be inferred further. The two least obstacles for citizens to contact the public through the Internet are the service is not possible online or cannot be found and the use of the Internet is too complex. 47 Telephone interview with Kristian Hjort-Madsen, Enterprise Architect, The Ministry of Finances Telephone interview with Jacob Harder, Consultant, KL 49 http://www.dst.dk/upload/bef2006e_001.pdf 48 Page 73 of 112 Enterprise Architecture of public Denmark Master thesis, December 2006 Among the municipal CIO’s there are different opinions of this new common citizen portal. The majority, 72%, thinks the portal is essential while only 6% think it is superfluous (see figure 24). The latter consists of the more mature municipalities who have their own solutions for the citizens. As a Figure 24. The city CIO's opinion of www.borger.dk. Source: The study survey report (own contribution) 196H surprise there is a whole of 22% who do not have an opinion on the matter. Many respond by saying they have not seen the portal yet or do not know anything about it, indicating that the State – or common fora – has not been effective in communicating the structure and content of this portal to the municipalities or to the citizens. One municipality respond saying: “It is on one hand indispensable that common public citizen solutions are developed and first and foremost standards for exchange of information between the different public services. But on the other hand, it is crazy to try to direct the citizens’ traffic in connection with public contact away from the municipal websites and into a central one. By doing this you undermine the vision for having the municipality as a primary entrance to the public for the citizen. Seen from the citizens’ point of view, it is amazing how many that do not know that this important public joint citizen portal will be launched by January, 2007. A whole of 77% do not know this. A citizen study conducted by Computerworld and Userneeds 50 also reveals that 53% would like to visit this portal once up and running. A whole of 40% don’t know. When asked if they know what the portal contains a whole of 87% answered they did not know. When asked if they miss a central website where they can have access to all their personal information and receive information about the public, 49% responded affirmative to this question. 19% would only like to have access to their personal information while 11% would like to only have access to a central website, where they can find information about the public. A whole of 21% do not miss any of them. This could be interpreted as they don’t care about the new joint citizen portal, since this is what it offers. Finally, when asked: “The goal is to collect all personal information on the joint public citizen portal by 2012. Do you think this is realistic?” a whole of 60% responded ‘Yes’ to this question, 14% ‘No’ and 26% ‘Don’t know’. 49F49F 50 See appendix 6 Page 74 of 112 Enterprise Architecture of public Denmark Master thesis, December 2006 Figure 25. The citizens' awareness of the portal. Source: Computerworld & Userneeds 5.4.2.6 Why? The ‘why’ indicates problems causing the business to work differently or a change in strategies and business drivers. The structure- and task reform certainly will influence the public sector, in particular the municipalities in the form of additional tasks to perform in the future. Future tasks of the municipalities The new tasks of the municipalities involve health in connection with rehabilitation and prevention, institutions within the social area, the environment and nature, special education, traffic and roads, employment and citizen service centers. The task- and structure reformation in Denmark is much more than a reformation of the municipalities. It is a reformation of the entire public sector of Denmark. Roles and relations are changed for all partners – the State, the regions and the municipalities. The goals of the reformation can be comprised into five key elements 51: 1. The quality and the effectiveness within the public service sector are to be secured through larger municipality units with sufficient financial and professional sustainability. 2. The citizen is to be put in the center. The solution of tasks must first meet the needs of the individual citizens instead of the systems’. Coherent tasks must, to the extent possible, be solved by the same authority level. 3. The tasks must be solved at a decentralized level and as close to the citizen as possible. 4. The citizens must have only one entry into the public sector. 5. The local democracy must be strengthened and further developed. 50F50F It is thus in the spirit of the task- and structure reformation that a number of tasks be transferred to the level closest to the citizen: the municipality. 51 http://www.kl.dk/data/1494854/Den%20nye%20offentlige%20sektor%20-%20pjece%20jan.%202006.pdf Page 75 of 112 Enterprise Architecture of public Denmark Master thesis, December 2006 A new start? The structural reformation marks a new start for the municipal governance as the central authority in the public sector. Basically, the municipalities are given four important roles: First of all, the municipalities must solve problems seen from the citizens’ point of view – not from the viewpoint of how the authorities most easily can organize their internal processes. This involves among other things that the municipalities have to perform a completely new task when it comes to serving the citizen. They will be the main entry for the citizens to the public sector and as such they have to guide and serve the citizens, even though another public authority may have the responsibility for the problem the citizens need to solve. This presents new perspectives for the municipalities being the entry point the citizen always can turn to whenever a problem need to be solved or a question arises. Secondly, the municipalities will be the central turning point in the public sector, when it comes to all the tasks and services offered, which are in connection with people’s everyday lives. The responsibility for the welfare policy will to a greater extend be turned over to the municipalities in areas such as health, rehabilitation and special education. This brings the municipalities to the very front of the welfare policy. Third, to a great extent, it is up to the municipalities to realize the intentions of “the citizen in the center”. This is also relevant in relation to the further development of the local democracy. The citizens regard the municipalities in Denmark as the part of the public sector, where influence on political decisions is most easily obtained. With the new conditions for this strengthened municipal governance, it is natural to analyze what the demands and needs modern people claim in relation to citizen involvement. It is an excellent opportunity to reconsider the involvement of the citizens within the different municipalities, formulate a complete strategy for the involvement and build on the many experiences they have already gained in this area. Fourth, the municipalities will play a new role in connection to the new regions. The municipalities will for the first time ever, gain an influence on a number of tasks and questions, which in the future will be decided in each region by a contact committee, consisting of mayors and the chairman of the regional council. With this added influence, the municipalities will get the opportunity to be the driving force and leave important fingerprints on the regional politics. The prerequisite for this to happen is a close coordination of different viewpoints and cooperation between the different municipalities within the region. 5.4.2.7 Where? The ‘where’ indicates the location of the enterprise. Even though a major reform is about to take place in Denmark, most municipal buildings will not be closed, but instead turned into local citizen centers. This is done in order to maintain the high level of service the municipalities are expected to honor in the future. It is interesting to note, that the restructuring part of the reform is taking place in the municipalities. But the State does not change at all. One could expect the State would change correspondingly in order to assist the municipalities in performing their new tasks or in order to streamline the IT initiatives among the greater geographic municipalities. Or as Peter Gorm Hansen, CEO of KL, said it: “The State does not realize that the reform has a lot to do with the State itself”. Page 76 of 112 Enterprise Architecture of public Denmark Master thesis, December 2006 6. Analysis of the Current State 6.1 Introduction Analysis of the current state of EA involves among other methods assessment indicators – factors used to analyze the business’ current state data as collected in the previous step. Just like a thermometer they provide a way to gauge a temperature of the business. Carbone suggests the following points as assessment indicators: • • • • • Stress points/risks Strengths and weaknesses Challenges Environmental factors Growth/cost containment opportunities 6.2 Stress points/risks Some of the stress points/risks signifies what the worries are concerning the current business plan. According to Carbone this could be significant decline or unexpected growth. The process of the municipalities merging will most likely be a long and a slow one, i.e. expensive, because there does not seem to be any support from the State. The state is not set up to support the merging municipalities neither organizationally nor technically. Besides, the State has a serious communication problem with the public: both the municipalities and the citizens. Most of these do not even know what is going on with the new joint public citizen portal. I may have a hypothesis in this thesis stating that the awareness, propagation and use of EA at State level is mature, but not much have been published or communicated since the white paper came out in 2003. A recent study of SOA was just published by the National IT and Telecom Agency. There could be much more focus on the portal and its benefits. Another stress point is the immaturity of the municipalities with EA (see study survey report). Maybe this is not a stress point for the municipal CIO’s but it ought to be! 6.3 Strengths and weaknesses 6.3.1 Strengths One of the strengths which can be seen from the study survey report is that the municipalities learn a lot from each other. This make a good ground for initiating joint municipal co-operations which already has taking place among several municipalities. Another strength is the wide ‘common fora' with its vast number of representatives. 6.3.2 Weaknesses Here are some of the most obvious weaknesses: • Citizens are being more demanding. They want quality and good service. • IT initiatives in the public sector experience sluggishness. Some of the councils on the public stage in common fora are “inactive”. • The awareness of a joint public citizen portal is very limited. • The issue of strategic use of IT is not on the board meetings in the different municipalities. 52 51F51F 52 Mr. Q, CIO for XX municipality Page 77 of 112 Enterprise Architecture of public Denmark Master thesis, December 2006 6.4 Challenges The Danish task force predicts the public sector will face severe pressure 53 from different sources. These more general and overall challenges include: • More elderly and fewer in the active workforce in the society • Limited resources (financials means) available • Increased international competition • Demand of openness and minimal response time 52F52F We are already witnessing some of these challenges today. When writing this thesis I have furthermore discovered the following challenges: • • • Lack of communication from the actors primarily in the State domain and common fora to the municipalities and the citizens Sluggishness with joint public IT projects Lack of proper organization to support the new and larger municipalities’ tasks Unfortunately, these are not the only challenges. Locale and regional politicians are as a whole satisfied with the new local governmental structure, but at the same time they criticize essential parts of its content mainly directed toward financial matters. Their worries are primarily about two areas: 1. Short term: It will be more than difficult to finance the restructure of the Danish local government areas, since no special financial means has been set aside for this enormous task. 2. Long term: There will be an increase in central governance and state control. The chairman of KL, Erik Fabrin, states that it will be more than difficult to budget this year, not because of the contract agreed upon between the Danish Government and KL about the financial situation for the municipalities in the first year of the new municipal structure, but due to three big reforms, taken in effect by January 1, 2007, and which has great consequences for the budget. First, the municipalities take over a number of tasks from the counties, and even though the State covers it, it is difficult to ensure 100% fairness of the distribution of the money, and in some municipalities it is experienced that the amount given does not match the need. Second, the Danish government has passed a resolution of equalization of resources between local authorities redistributing billions of DKK between the municipalities. Some municipalities receive money on this account, others will have to give back money, and then it will be missing in their budget. Third, a harmonization has to take place at different levels of service in the new municipalities. Some citizens will experience some improvements, others a degradation of the service. “These three reforms will have a much greater impact on the individual municipalities’ finances than the financial agreement between KL and the Danish Government. A few numbers will illustrate my point: In the financial agreement it operates with a growth in the service expenses of a just below one billion DKK or just below ½ %. For comparison due to the new tasks in the task reform the 53 See appendix 5 Page 78 of 112 Enterprise Architecture of public Denmark Master thesis, December 2006 municipalities are confronted with new tasks equivalent to approximately 23 billion DKK or a growth of about 15%. 54” 53F53F KL does not have any influence on how the money is distributed between the municipalities in connection with the reforms. But they are joint responsible for the financial agreement for 2007. It is to be kept within the spending policy goals, which changing governments have formulated in the 2010 plan. It is therefore subject to serious spending controls, which for the municipalities’ part only leaves the possibility of maintaining the current level of service of the existing tasks, not leaving any room to fix any discrepancies which the large reforms most likely will induce for the individual municipality. Denmark is moving from a supply governed public sector towards one governed by demand. According to Peter Gorm Hansen, CEO of KL, the reason for this is that “we taught our children in school to be critical. They should be anti-authoritarian, ask questions and be active (Denmark Ltd, 2006). Before, the citizens did not know what they wanted, but the development of the society has had the effect so that the citizens are no longer satisfied with what other people are telling them and how things are. They want freedom to choose. They are in a demanding mode. And if these demands are not met, the citizen will go elsewhere, e.g. to private schools, private doctor’s clinics, private homecare service etc. More than ever before, the municipalities are faced with an increase of demands of delivering high service levels. Why? Because the citizens know what they want and they are demanding mode. But if the State, who is not at close range with the citizens like the municipalities are, continues to run the “Iam-in-charge-here” policy, “a new dinosaur is born. The state has to co-operate with the municipalities. Otherwise things will go wrong (Peter Gorm Hansen, 2006). I totally agree with him on this matter. Cooperation and communication between the State and the municipalities are essential not just in order to survive, but also to create a coherent public sector. This could be why Mr. Q said that “KMD’s new challenge will be to develop IT systems based on citizens’ needs and not anymore on the caseworkers’ need in the municipality. For a very long time KMD has been very good at developing customizable systems which met the exact need of the caseworker in the municipality. Now the focus has changed, and it will be more pertinent than ever before to focus on the citizen.” 55 It will be interesting to see how KMD will cope with this challenge in the new municipalities in the years ahead. 54F54F 6.5 Environmental factors The outcome of legislation regulating the use of EA in the municipalities is unclear. There this will not be dealt with here. 6.6 Growth/cost containment opportunities The State wants to create sustainable units with a clear responsibility in delivering welfare services of utmost quality to the Danish population. It also wants to improve solutions of welfare tasks by placing these with the municipalities, thus strengthening and propagating the democracy. 54 55 http://www.kl.dk/368619/ Interview with Mr. Q, CIO for XX municipality, 2. Nov. 2006 Page 79 of 112 Enterprise Architecture of public Denmark Master thesis, December 2006 7. Description of the Target State 7.1 Introduction The description of the target state is about foreseeing the target state of the enterprise. As mentioned earlier, Carbone suggests two approaches: the positive statements approach and the visionary approach. I will use the positive statements approach, i.e. I will capture the current state problems and see what the future state looks like if the assessment indicators in the ‘Analysis of the Current State’ are removed. The target state thus embodies the achievement of mission and goals. • Stress points were relaxed/risks mitigated? o The municipalities and citizens can in detail read about what to expect from the new joint public citizen portal on the Internet and through produced pamphlets distributed to them. o The State will have a plan for backing up the “weak” municipalities. o The State will organize itself in a manner that meets the needs of the new and larger municipalities. o The State will form a communication strategy towards the municipalities and the citizens e.g. about the new citizen portal. • Weaknesses were addressed and strengths fortified? o Fortify the strength where municipalities learn from each other, by nurturing a learning environment through joint municipal IT co-operative initiatives. The State should be behind this with the aid from KL and others. o Fortify the ‘common fora’ by adding an Enterprise Architecture unit, thus making it possible to streamline EA across the entire public sector and avoiding sluggishness in joint public IT initiatives. o Again the State will create a communication strategy to propagate awareness of the new joint public citizen portal. o The use of strategic IT will be taken up at board meetings as a fixed point on the agenda. • Challenges were resolved? o The entire public sector is streamlined with a well-documented EA and SOA rooted in an Enterprise Architecture Committee supporting long-lasting and sustainable principles. o Again the State will create a communication strategy to propagate awareness of the new joint public citizen portal. o The State will co-operate with the municipalities through an Enterprise Architecture Committee in the ‘common fora’ area with representatives from both the municipalities and the State. • Environment changes were accounted for? o Through legislation, there is a minimum set of requirements of suggested EA tools and processes for the municipalities to work with. A central Enterprise Architecture Committee will assist the municipalities in their EA efforts as needed. Even though this goes against what the municipalities wish for – according to the study survey report – I believe that the only way EA to a certain extent will ever be used in the municipalities is through legislation, as we have seen with the OIOXML data standard implemented. Page 80 of 112 Enterprise Architecture of public Denmark • Master thesis, December 2006 Growth/cost containment opportunities were leveraged? o To ensure utmost quality to the Danish citizens a central Enterprise Architecture Committee will be formed to assist in securing quality to the citizens o To aid the municipalities in finding the right solutions and to ease the carrying out of welfare tasks, an Enterprise Architecture Committee will be established. To comply with these entire challenges one ought to seriously consider aligning the public sector according to the needs of the citizens and companies, in order to gain the great benefits an eGovernance is expected to produce. What we have seen in recent years and still see with the merging of the municipalities is development driven by necessity. Why not be pro-active, starting with having the end in mind, and organize the public sector in a long-lasting sustainable structure supporting the State’s vision and goals to address these challenges in good time, thus avoiding fire extinction. This pressure against the public sector now and in the years to come, calls for an even more integrated implementation and exploitation of EA. 8. Analysis of the Target State 8.1 Introduction This phase comprises the identification of significant business opportunities and/or gaps to be addressed by IT architecture. The approach I use is to compare the current and target state, then lists the differences as gaps, and finally reversing the gaps as opportunities. 1. Compare the current and target states 2. List the difference 3. Reverse gap to opportunity Here are the few gaps I have identified primarily for the State: • • Communication o Current: Neither the municipalities or the citizens know very much about this new joint public citizen portal. o Target: The municipalities and citizens can in detail read about what to expect from the new joint public citizen portal on the Internet and through produced pamphlets distributed to them. o Gap: The level of information to the municipalities and the citizens about the new joint public citizen portal is not satisfactory. o Opportunity: The State will form a communication strategy towards the municipalities and the citizens. State support o Current: Throughout the merging there does not seem to be any support from the State. o Target: The municipal CIO’s have a common place from which they can receive technical and organizational aid through the merging period and beyond. o Gap: There is no one to turn to for technical or organizational aid from the State domain; especially relevant for the “weak” municipalities. Page 81 of 112 Enterprise Architecture of public Denmark Master thesis, December 2006 o Opportunity: The State will organize itself in a manner that meets the needs of the new and larger municipalities. Among other things, this will be done through the establishment of an Enterprise Architecture Committee. • Technical processes o Current: The municipalities are considered immature in relation to the awareness and use of Enterprise Architecture. o Target: The municipalities are supporting Enterprise Architecture as part of their overall IT strategy. o Gap: No relation between IT and the business strategy. o Opportunity: To create an environment supporting municipal issues regarding Enterprise Architecture. • Organization o Current: IT initiatives in the public sector experience sluggishness. Some of the councils on the public stage in common fora are “inactive”. o Target: There is no sluggishness in the public sector but a very streamlined organization adaptable to change. o Gap: Not all IT initiatives in the public sector are given the proper attention. o Opportunity: Fortify the ‘common fora’ by adding an Enterprise Architecture unit, thus making it possible to streamline EA across the entire public sector and avoiding sluggishness in joint public IT initiatives and following through with these public IT initiatives. • Key enabling capabilities o Current: Increased competition from the private sector. o Target: The State will co-operate with the municipalities through an Enterprise Architecture Committee in the ‘common fora’ area with representatives from both the municipalities and the State. o Gap: There is no alignment of service levels in relation to business strategy across the municipalities in serving the citizens. o Opportunity: Create a strategy for service alignment in relation to municipalities’ business strategies through an EA committee. • Citizen-centric development o Current: The suppliers of IT have for many years been used to develop systems for the case worker in the municipality, not for the citizen. o Target: The suppliers of IT are very good at developing customizable systems which meet the exact need of the citizens in the municipalities. o Gap: There is a lack of developing IT systems with the citizens’ needs in mind. o Opportunity: Choose IT suppliers who will develop IT systems with the citizens’ needs in mind. Conduct quality assurance in order to maintain consistency and relevancy in relation to the citizens’ situation. This calls for a need of uniform technical demands of system layout, user interfaces etc. so the citizen will see the same whether he is in the central administration, the citizen centers located in the small villages or on the joint public user portal on the Internet. Page 82 of 112 Enterprise Architecture of public Denmark Master thesis, December 2006 8.2 Integration The ability to relate the output of one cell with the output of other cells is fundamental to Carbone’s Toolkit. I have illustrated this in figure 26 to show how the business framework outputs are interrelated. This presents a working list of key areas to be addressed with architecture. Content View Description Analysis Key facts Assessment Indicators Result No formal mechanism to integrate growth opportunity in integrating EA EA initiatives across the public initiatives and developing citizen-centric sector; not much experience in systems could enhance the maturity of Current State developing systems and services to eGovernment and enhance the service citizens; borger.dk is not very well level offered to the citizens known Reverse Assessment Indicator Target opportunities Citizens can take care of ALL their Establish an Enterprise Architecture Target State needs on the portal; the public Committee to communicate, coordinate domain has a streamlined mature and facilitate EA in the public domain eGovernment setup Figure 26. Interrelationship between output views. Source: Carbone (2004) It is apparent that something is missing in the structure. I will in the following respond to this need with the management program. This is the first issue the management program must deal with. Page 83 of 112 Enterprise Architecture of public Denmark Master thesis, December 2006 9. EA Management program 9.1 Introduction This EA management plan is also sometimes referred to as business transformation or EA implementation. This plan simply states how to move from your current view of EA to the future view. The neXus 56 provides enterprise modeling and knowledge management capabilities to support business innovation and transformation programs as can be seen from figure 27. The colored areas indicate the areas of my focus in working out this thesis as seen from the municipalities and the State’s view. 5F5F Figure 27. Business Transformation Overview (Source: http://www.ndyn.com/) 197H Having described and analyzed the current and target state of the State of Denmark and its municipalities, there is a call for an improved organizational structure supporting the rapid change of environment, which is especially relevant during these years of the municipal reform. I have done some OMB CIOcouncil AIC Figure 28. Extract from EA actors in the US research with foreign government structures which are a little more mature than the Danish one to see how they are structured. I found the US structure very interesting (see figure 28). This has been done to see if there is anything we can learn from them. The Architecture and Infrastructure Committee (AIC) reports to the CIO council. This council reports to the Office of Management and Budget (OMB) department. Representatives of this last department participate in both AIC and the CIO council. The 56 Providing commercial solutions to Knowledge Management, http://www.ndyn.com Page 84 of 112 Enterprise Architecture of public Denmark Master thesis, December 2006 US EA program is a lot more streamlined than the Danish one. This has inspired me to make an important ratification to the existing structure in the ‘common fora’ (see figure 19) domain as can be seen from figure 29. Figure 29. Overview of the "new" public sector. Source: own contribution There is a continued focus on public IT-systems are more interoperable and connected as a whole. The problem is, as I see it, this will not happen BEFORE the organizational structure and will power is present with the State. I will therefore recommend that the Coordinating Information Committee will be replaced with a strong Enterprise Architecture Committee, having people from both “camps” (STS and ITA/Data standardization committee) positioned in this committee. This will create a much more powerful, broad and streamlined organization of the actors within the public domain ready to initiate and sustain enterprise architecture plans for joint municipal IT co-operations as well as across the different sectors. So, instead of having islands in the middle and silos in the municipal domain, a streamlined common forum in the public EA organization aligning services across the entire public sector and municipalities will be present. Page 85 of 112 Enterprise Architecture of public Denmark Master thesis, December 2006 To conclude I would like to specify an actor profile for this new Enterprise Architecture Committee in a similar manner to the ones created earlier (see table 24). Actor Domain Enterprise Architecture Committee Common fora Purpose Meetings Securing and coordinating enterprise N/A architecture activities both vertical and horizontal within the public sector. Description This committee has been formed by The Ministry of Science, Technology and Innovation. Participants Enterprise Architects represented from The Ministry of Science, Technology and Development, the digital task force, The Ministry of Finances, KL and the County Council Association. Tasks • Receive council from ITA Committee and from the Data Standard Committee. • Coordinate joint public EA efforts with STS done both horizontally across the public sector as well as vertically within sectors. • The committee will contribute in securing, that the public – through a joint effort between the administrative levels – develop and implement standards and tools necessary to implement EA • Aid the municipalities in their merging efforts and contribute with technical and organizational expertise. • More as needed… Table 24. New State EA Actor #1. Source: Own contribution. It is important that this new committee is a coordinating and a counseling one in order to function as one of the main actors. It is likewise important that the representatives in this council both have the technical and business aspects of the public sector as well as being some of the “big boys” in the field, i.e. having influence and decision-making power in their own organizations to at least department CIO level. I believe that Denmark with this powerful EA actor will much easier be able to realize the five architectural principles suggested by the national white paper: • • • • • Interoperability Security Openness Flexibility Scalability In fulfilling these principles the public domain will move to the next level of eGovernment structure which in the end will ensure a higher level of service to the citizens. This will beyond doubt – if implemented – increase the awareness, propagation, and use of enterprise architecture in the public domain and will increase the EA maturity of the public domain. Page 86 of 112 Enterprise Architecture of public Denmark Master thesis, December 2006 10. Conclusion, reflections, perspectives 10.1 Conclusion The overall question of this thesis was trying to answer the following question: What Enterprise Architecture activities are currently applied within the public domain of the municipalities and the State? I think I have answered the question to a certain degree. Due to the scope and complexity of the above research question, I have had to balance my view at a certain abstraction level describing the enterprise architecture activities within the public domain, and at the same time not go into any atomic discussion or description of this area, so to loose sight of the issue at hand. As for the municipalities, I have made a study survey report, from which I have analyzed the results and can conclude that the Danish municipalities for the whole part not are at a mature level in relation to the awareness, propagation and use of enterprise architecture. Even though 65% answered they have an EA function, they do not seem to use it fully. The following witness to this fact: For the whole part there is no EA framework, no EA measurement, no EA process, and no EA documentation. As for the State goes, I made description analysis based on Carbone’s views: AS/IS and TO/BE. From this and input from the study survey, I conclude that the EA intentions are present, but the structure is not set up to support a full fledged EA program within the public domain. 10.2 Reflections I have now finished this thesis, and looking back, I must say it has been a learning experience. Two parts I have drawn into my thesis have very much caught the attention of public actors at all levels among the EA actors on the stage: My study survey report and my figure showing the actors on the stage. These two parts have also taken the longest time to produce properly. As for the study survey report goes, I have personally contacted each of the 98 municipalities in order to find out who the new CIO of the new municipality will be after the realization of the merging by January 1, 2007. A name and an email of each have been acquired. This alone was a dragging task. My questionnaire is targeted to the key person of the municipality: The CIO. He/she typically has his feet well grounded in IT aspects and at the same time he is also referring to the management board. That makes him the most competent person to answer any business-driven IT related questions in behalf of his municipality. The questionnaire itself is database driven and all entries are saved in a central database. One of the greatest challenges working with the study survey was to define ‘Enterprise Architecture’ to an audience not familiar with the concept. An iterative process started and having received feedback from several test persons I finally chose to “translate it” into the Danish term: Business-oriented Framework of IT. Since I did not know, if everyone understood this concept, I made sure to describe it in the beginning of the study survey. Page 87 of 112 Enterprise Architecture of public Denmark Master thesis, December 2006 I asked professionals in the area of business-driven IT in the municipalities to assist me in securing the quality and relevancy of the questions in the questionnaire. I have done this to ensure the questions could easily be understood by the CIO’s and are in accordance with the terms and concepts used by the world of CIO’s. These professionals have carefully been selected partly based on guidance from John Gotze and partly through general referral dialogues with municipal CIO’s. These people include: • • • • • Ellen Svenning, chairman of “The Association of Public CIO’s” and CIO of Ringe municipality Hans Lembol, CIO of Slagelse municipality Steen Deth, IT-architect at Gentofte municipality Christina Bouras, consultant of digital strategy and development at Gentofte municipality, also employed with Gentofte municipality Preben Rasmussen Hoej, CIO for Birkeroed municipality Their input has been most valuable. Telephone interviews as well as personal interviews have been conducted with most of the above. As for the ‘Actors on the stage’ figure, this has caught quite a stir among EA professionals. Many of the actors in this figure have responded. Among others, I have emailed back and forth with the CEO of KL, several IT-architects, CIO’s from various public departments as well as with the Ministry of Finances and Ministry of Science, Technology and Innovation. Several told me that this figure is invaluable, and they wonder why this has not been produced before. So do I! 10.3 Perspectives I would like to draw EA, a joint municipal IT co-operation and the survey into different perspectives. Why EA? I claim that one of the best ways to do public IT is doing EA with all the elements this entails. I also believe that EA is one silver bullet and used in conjunction with another silver bullet, SOA, this could be a very powerful tool to reach new heights of EA maturity of the public sector in Denmark, especially if the organization first is in place supporting this infrastructure. Why bother to make a joint municipal IT co-operation effort? Since the municipalities are given a number of similar tasks to carry out with the reform, this joint effort could just be what they need in order to provide greater service for the citizens at a lower cost. This is not something new. Several municipalities are already actively engaged in joint municipal co-operative activities. Why just make a survey to the municipal CIO’s? I have thought about other very relevant surveys: • • • One directed to the City Mayors (Da: borgmester) One directed to the City Managers (Da: Kommunaldirektør) One directed to the national public central actors Conducting a survey for the city mayors would be interesting, since they are the politicians who outline the visions of the municipality, and the visions drive the business which in turn drives IT. The emphasis of the questions would be on which core values they emphasize that lay as foundation for carrying out their policy program. Conducting a survey for the city managers is interesting, since they are the leading public officers interpreting and executing the visions of the business. To exemplify, in response to which is the greatest challenge in carrying out IT plans, CIO of XX and YY municipality, without hesitation notes: “The board of management should have IT on the agenda”. A survey held for all city Page 88 of 112 Enterprise Architecture of public Denmark Master thesis, December 2006 managers would most likely reveal any coincidental responses or if there is a pattern for omitting IT on the agenda at board meetings in the Danish municipalities. Conducting a survey for the national public central actors, will give us a better understanding of where we are heading as well as more in–depth knowledge of joint national initiatives. Page 89 of 112 Enterprise Architecture of public Denmark Master thesis, December 2006 References Literature Accenture, Users interaction with Government Websites: http://www.contactomagazine.com/egovernment0529.htm 198H a|EA, yearly congress 2005, Institute for Enterprise Architecture Developments: http://www.enterprise-architecture.info/Images/Presentaties/NGI%20Congres%202005%20%20Waarde%20Enterprise%20Architectuur.pdf 19H Amadei, Bernard (2004). Department of Civil, Environmental, and Architectural Engineering, University of Colorado, Boulder, Engineering for the Developing World – Challenges and Opportunities, statement by Albert Einstein (slide 28): http://www.ewbjsc.org/Files/Amadei_Presentation.pdf 20H Analysis of the joint public citizen portal performed by KL (June 2006): http://www.kl.dk/_bin/184123ba-dbc8-4711-aea6-b144a8a3186b.pdf 201H Armour, F., Kaisler S., Liu S. (1999). Building an Enterprise Architecture Step by Step, IT Professional 1(4): 31-39, 1999. Armour, Dr. F. Kaisler, Dr. S. Getter, J. Pippin, D. (2002). A UML-driven Enterprise Architecture Case Study. IEEE Proceedings of the 36th Hawaii International Conference on System Sciences. Avison, D. E. and Wood-Harper, A. T. (1990). Multiview: An Exploration in Information Systems Development. New York: McGraw-Hill. Bernard, S. A. (2004). Introduction to Enterprise Architecture, Author House, September 2004, ISBN: 1418498084. Buchanan and Soley 2002, Aligning Enterprise Architecture and IT Investments with Corporate Goals: http://www.bptrends.com/publicationfiles/META%20OMG%20WP%201-15-03.pdf 20H Burk, Federal Enterprise Architecture Program Management Office, Sept. 2006: http://egov.vic.gov.au/index.php?env=-innews/detail:m1113-1-1-8-s:n-723-0-0-203H Carbone, Jane: IT Architecture Toolkit, Prentice Hall (2004), ISBN: 0131473794. Carr, Nicholas G. (2003). IT Doesn’t Matter. Harvard Business Review, May 2003. Carr, Nicholas G. (2003). Does IT Matter? Information Technology and the Corrosion of Competitive Advantage, Harvard Business School Press (April 2004), ISBN: 1591394449. Christiansen, Peter Engelund (2006). IT University of Copenhagen (Master Thesis): http://www.easurvey.org/academicreport.htm 204H Page 90 of 112 Enterprise Architecture of public Denmark Master thesis, December 2006 Chief Information Officers Council (1999). The Federal Enterprise Architecture Framework, Version 1.1. Chief Information Officers Council (2000). Architecture Alignment and Assessment Guide, Chief Information Officer Council. Chief Information Officer Council (2000). Capital Planning and IT Management Committee, Smart Practices in Capital Planning. Chief Information Officer Council (February 2001). Federal Enterprise Architecture Version 1.0, Chief Information Officer Council. Chief Information Officers Council (2001). A Practical Guide to Federal Enterprise Architecture. Chung, H., M., & McLeod, G (2002). Enterprise Architecture Implementation, and Infrastructure Management. Proceedings of the 35th Hawaii International Conference on System Science. Clinger-Cohen Act of 1996 (1996). Public Law 104-106, section 5125, 110 Stat. 684. Denmark Ltd., KMD (2006). A discussion of Denmark as an Ltd company: http://www.kmd.dk/F2FDC4B5-FF9B-42B8-9FAE-57B884F42B4B.W5Doc?id=58EEF799-37D046C4-9AA4-7306AFAF033F 205H E-Governance in DK assessed by KL (2006): http://www.kl.dk/_bin/731f15e5-2984-4697-a214-a42dccd5c02f.pdf 206H Institute For Enterprise Architecture Developments (IFEAD): http://www.enterprise-architecture.info/ 207H Field, A. (2005). Research Methods II – Design a questionnaire: http://www.sussex.ac.uk/Users/andyf/teaching/rm2/projects3.pdf 208H Gartner's hype cycle. Source: Gartner's hype cycle. Source: http://www.gartner.com/DisplayDocument?doc_cd=130115 209H General obstacles for contact with the public through the Internet 2006, Denmark’s Statistics: http://www.dst.dk/upload/bef2006e_001.pdf 210H Gurpreet S. Pall, Microsoft Architectural Frameworks, 2005, Microsoft Corporation: http://download.microsoft.com/documents/australia/MSDN/RAF_2005/GurpreetMicrosoft_Architecture_Frameworks-2.ppt 21H Gøtze, John (2005). Maturity of eGovernment. Slide from John Gøtze’s teaching of EA, Nov. 2005. Handbook on EA implementation: http://www.oio.dk/arkitektur/publikationer/haandbog 21H Hasselbring, W. (2000), "Information system integration", Communications of the ACM, Vol. 43 No.6, pp.33-8. Herzum, Peter (2003). Applying Enterprise Architecture, Executive Report, Vol. 6, No. 3. Page 91 of 112 Enterprise Architecture of public Denmark Master thesis, December 2006 Hirvonen, Ari P. & Pulkkinen, Mirja. (2004). A Practical Approach to EA Planning and Development: The EA management Grid. Business Information Systems, Proceedings of BIS 2004, Poznan, Poland. http://www.titu.jyu.fi/julkaisut/muut/Hirvonen_Pulkkinen_2004.pdf 213H Hjort-Madsen, K. & Ravn (2004). ICA Enterprise Architecture study group – Country survey, National IT and Telecom Agency, Denmark. Hjort-Madsen, K. (2005). Managing and implementing Enterprise Architectures in Government: Understanding Institutional Forces and IS Control, Ph.D. Status Report, August 2005. How SOA works, KL: http://www.kl.dk/_bin/27d196f2-1069-4c4f-9737-cdded2a2b3ee.pdf 214H IBM's seven key areas for mergers: http://www-304.ibm.com/jct03004c/industries/publicsector/dk/da/efficientit 215H IEEE P1471/D5.3: http://standards.ieee.org/db/balloting/ballot.html, 2000 216H Internet based Questionnaire to the municipal CIO’s: http://www.flemminghald.dk/ea 217H INTEROP-ESA ´05, Enterprise Architectures – Survey of Practices and Initiatives, Frank Lillehagen & Dag Karlsen, 2005, Geneva, Switzerland: http://interop-esa05.unige.ch/INTEROP/Proceedings/Industrial/IND1_Lillehagen.pdf 218H ISO 15704: http://www.iso.org/iso/en/CatalogueDetailPage.CatalogueDetail?CSNUMBER=28777, 2000 219H ISO/EN I9439 (2003) - Enterprise Integration – Framework for Enterprise Modeling. IT- og Telestyrelsen: http://www.itst.dk/ 20H Johnson, Bruce. General functionality of SOA: http://objectsharp.com/blogs/bruce/articles/235.aspx 21H Joppe, Dr. Marion (2005). The Research Process: http://www.ryerson.ca/~mjoppe/ResearchProcess/ 2H KL national webpage (The national association of Municipalities): www.kl.dk (responsible for http://netborger.dk) 23H 24H Knippel, Rasmus (2005) Service-Oriented Enterprise Architecture, IT University of Copenhagen (Master Thesis): http://knippel.org/thesis/SOEA_censored.pdf 25H Kristensen, Bo & Hald, Flemming (2005). A paper on Enterprise Architecture, Copenhagen Business School, The Use of Enterprise Architecture in the Merging Danish Municipalities: http://www.flemminghald.dk/references/EA%20Miniprojekt.pdf 26H Kuhn, Thomas S.: The revolutions of Science, Copenhagen (1973). Lakein, Alan. http://www.brainyquote.com/quotes/authors/a/alan_lakein.html 27H Page 92 of 112 Enterprise Architecture of public Denmark Master thesis, December 2006 Lankhorst M. & M. (2005). Enterprise Architecture – the issue of integration. Advanced Engineering Informatics 18 205 – 215. Lillehagen, Frank and Karlsen, Dag (2005). Enterprise Architectures – Survey of practices and Initiatives. Whitepaper: http://interop-esa05.unige.ch/INTEROP/Proceedings/Industrial/IND1_Lillehagen.pdf 28H Lillehagen, Frank (2003a) and Helge Solheim, “The Foundations of AKM Technology,” Concurrent Engineering Conference 2003, Madeira, July 2003. Lillehagen, Frank (2003b) and J. Kostie, S. Tinella, H.G. Solheim, D. Karlsen, “From Enterprise Modeling to Enterprise Visual Scenes,” Concurrent Engineering Conference 2003. Martin, James (1995), The Great Transition: Using the Seven Disciplines of Enterprise Engineering to Align People, Technology, and Strategy (American Management Association 1995), 104. Martin, James (2004), Enterprise architecture - Definition, internal communication note, 2004. Maturity of eGovernment in services for citizens and businesses: http://www.oio.dk/files/whitepaper.pdf 29H McGovern, James; Ambler, Scott; Stevens, Mike; Linn, James; Sharan, Vikas; Jo, Elias K, A Practical Guide to Enterprise Architecture, Prentice Hall PTR, December 2003, ISBN: 0131412752. Miller, Andy (2004). VP of Technical Architecture, Corporate Express, cited in article: “Enterprise Architects clean house” from http://www.zdnetasia.com/news/hardware/0,39042972,39187785,00.htm 230H Ministry of Science, Technology and Development national webpage: www.vtu.dk (responsible for http://danmark.dk) 231H National EA repository: http://ab.oio.dk/arkitekturbibliotek 23H National Institute of Standards and Technology – NIST. (1989): http://www.mel.nist.gov/sc5wg1/arch_fw.htm 23H News Magazine for the Danish municipalities: http://www.dk.kl.dk/ 234H Nexus, Providing Commercial Solutions to Knowledge Management, http://www.ndyn.com 235H Office of Management and Budgetting: http://www.whitehouse.gov/omb/# 236H Open Group (2004). TOGAF Version 8: Enterprise Edition, the Open Group’s official Web version of TOGAF: http://www.opengroup.org/architecture/togaf 237H Open Group, Other Architectures and Architectural Frameworks: http://www.opengroup.org/architecture/togaf7-doc/arch/p4/others/others.htm 238H Open Group (2000), TOGAF: The Open Group Architecture Framework, Document No. 1910, Version 6, December. Page 93 of 112 Enterprise Architecture of public Denmark Master thesis, December 2006 O’Rourke, Carol; Fishman, Neal; and Selkow, Warren: Enterprise Architecture Using the Zachman framework, Thomsen, 2003, ISBN: 0-619-06446-3. Popper, Karl: A Pocket Popper, Oxford (1983). Porter, Michael E: Competitive advantage (1998). ISBN: 978-0684841465 Public Information Online: www.oio.dk 239H Reference Architecture (2006), a range of reference models and patterns on OIO: http://ab.oio.dk/gamle-sektioner/referencearkitektur/referencemodeller-og-monstre/ 240H Rico, David F. A Framework for Measuring the ROI of Enterprise Architecture: http://davidrico.com/rico05a.pdf 241H Rodd, M. (1994). Enterprise Architecture: Definition, content and utility, The Mitre Organization. Ross, J. W. (2003). Creating a strategic IT architecture competency: Learning in stages, MIT Sloan Working Paper No. 4314-03; Center for Information Systems Research Working Paper No. 335. Sprott, David & Wilkes, Lawrence: Understanding SOA, September 2003, CBDI Journal Schekkerman, J. (2003). Trends in Enterprise Architecture, IFEAD. Schekkerman, J. (2004). How to Survive in the Jungle of Enterprise Architecture Frameworks: Creating or choosing an Enterprise Architecture Framework, Trafford Publishing. Schekkerman, J. (2005). Enterprise Architecture Tools: http://www.enterprise-architecture.info/EA_Tools.htm 24H Schombert, James (2006). Department of Physics, University of Oregon, 2006, js@abyss.uoregon.edu http://abyss.uoregon.edu/~js/ 243H 24H Schopenhauer, Arthur: http://en.wikipedia.org/wiki/To_be,_or_not_to_be 245H Spewak, Steven H. (1992). Enterprise Architecture Planning: Developing a Blueprint for Data, Applications and Technology, John Wiley & Sons Inc., New York. Strategy for digital strategy for the municipalities: http://e.gov.dk/uploads/media/Digital_Communication_in_the_Public_Sector_01.pdf 246H The Butler Group, a Data-monitor company: http://butlergroup.com and http://computerwire-butlergroup-reports.com/HTML/BGTC0009_ms.htm 247H 248H The Task Force: http://www.e.gov.dk/ 249H The Ministry of Science, Technology and Development: http://www.videnskabsministeriet.dk/cgi-bin/frontpage.cgi 250H Page 94 of 112 Enterprise Architecture of public Denmark Master thesis, December 2006 The National White Paper: http://www.oio.dk/arkitektur/publikationer/whitepaper 251H The new Danish municipalities: ftp://ftp2.kms.dk/download/pdf/Gamle_og_Nye_Kommuner.pdf 25H The new portal of the citizens of Denmark: http://borger.dk 253H University of Jyväskylä, Information Technology Research Institute (ITRI), Helsinki, Finland, A practical Approach to EA Planning and Development: The EA Management Grid (2004) http://www.titu.jyu.fi/julkaisut/muut/Hirvonen_Pulkkinen_2004.pdf 254H Virtual EA guide: http://ab.oio.dk/arkitekturguide 25H Vision of the Structure Reform: http://www.im.dk/imagesupload/dokument/Aftale%20om%20strukturreform%20ny.pdf 256H Wagner, S. (2005). The Service Oriented Governance – how a successful enterprise architecture is supported in public organizations, IT University of Copenhagen (Master Thesis). Wegmann, A. & Preiss, O. (2003). MDA in Enterprise Architecture? The Living System Theory to the Rescue, Enterprise Distributed Object Computing Conference, 2003. Proceedings, Seventh IEEE International 16-19 Sept. 2003 Pages: 2 – 13 Weill & Ross, IT Governance (2000), Harvard Business School Press. Weill, P. & Ross, J. W. (2004). IT Governance – how top performers manage IT decision rights for superior results, Harvard Business School Press. Zachman, J. A. (1987). A Framework for Information Systems Architecture. IBM Systems Journal Zachman, J. A. (1997). Concepts of the Framework for Enterprise Architecture, Paper: www.ozemail.com.au 257H Page 95 of 112 Enterprise Architecture of public Denmark Master thesis, December 2006 Interviews Bang, Mads; Journalist, ComputerWorld Bouras, Christina; consultant of digital strategy and development at Gentofte municipality, also employed with Gentofte municipality: http://www.gentofte.dk/ 258H Christiansen, Peter Engelund, IT Architect, IT- og Telestyrelsen CIO’s from XX and YY municipality Deth, Steen; IT-architect at Gentofte municipality: http://www.gentofte.dk/ 259H Dohn, Martin; IT architect, The Ministry of Domestic Affairs, http://www.im.dk/im/ 260H Fabrin, Erik; Chairman of KL Hansen, Peter Gorm; CEO of KL Harder, Jacob; Consultant, KL, www.kl.dk 261H Hjort-Madsen, Kristian; Enterprise Architect in the Ministry of Finance, Denmark, http://www.eagov.com/ 26H Hoej, Preben Rasmussen; CIO for Sollerod municipality: http://www.rudersdal.dk/ 263H Jeberg, Henrik; CIO, The Danish Agency for Governmental Management Lembol, Hans; CIO of Slagelse municipality: http://www.slagelse.dk/ 264H Karvø, Michael; founder of Center for e-Governance and former chairman of the E-trade Association Kraglund, Jakob H.; Country Managing Director, Accenture Svenning, Ellen; chairman of “The Association of Public CIO’s” and CIO of Ringe municipality: http://www.faaborgmidtfyn.dk/ 265H Sørensen, Rolf, Department Manager, KMD Vendelbo, Allan; CEO of the Association of City Managers and former city manager for Ballerup municipality Windley, Phillip J.; Professor Brigham Young University, Utah, Former State CIO of Utah, Page 96 of 112 Enterprise Architecture of public Denmark Master thesis, December 2006 Appendix Appendix 1: The Study Survey Report See separate binding Page 97 of 112 Enterprise Architecture of public Denmark Master thesis, December 2006 Appendix 2: Zachman Framework Page 98 of 112 Enterprise Architecture of public Denmark Master thesis, December 2006 Appendix 3: Bernard’s EA3 Cube Page 99 of 112 Enterprise Architecture of public Denmark Master thesis, December 2006 Appendix 4: Framework for Community Mergence by Flemming Hald and Bo Kristensen Page 100 of 112 Enterprise Architecture of public Denmark Master thesis, December 2006 Appendix 5: Challenges facing the public sector in the future in Denmark More elderly in society and less in the working age Increased expectations from citizens and companies Demand on opennes and quick respons Limited resources The public sector Increased international competition Page 101 of 112 Enterprise Architecture of public Denmark Master thesis, December 2006 Appendix 6: Citizen Survey made by Computerworld and Userneeds, December 2006 Page 102 of 112 Enterprise Architecture of public Denmark Master thesis, December 2006 Page 103 of 112 Enterprise Architecture of public Denmark Master thesis, December 2006 Appendix 7: Map of the “New Denmark” after the structure reformation Page 104 of 112 Enterprise Architecture of public Denmark Master thesis, December 2006 Appendix 8: Enterprise Architecture Value Measurement Methods Framework Source: http://www.enterprise-architecture.info/Images/Presentaties/NGI%20Congres%202005%20%20Waarde%20Enterprise%20Architectuur.pdf 26H Page 105 of 112 Enterprise Architecture of public Denmark Master thesis, December 2006 Appendix 9: The respondents Geographic location of respondents Frequency 20 19 15 12 10 5 2 0 0 Zealand Fyn Jutland More Frequency Job position of the repondents 35 30 25 20 15 10 5 0 29 2 CIO 1 1 ITITIT-leader operation architect leader 0 More Frequency Which type of municipality do you live in? 20 13 17 10 3 0 0 Unchanged Merging Split More Page 106 of 112 Enterprise Architecture of public Denmark Master thesis, December 2006 Appendix 10: Internet Questionnaire (http:www.flemminghald.dk/ea) FIO = Forretningsorienteret IT Opbygning, dvs. samspillet mellem forretningsorienterede krav, ITorganisationen og udvikling af IT-systemer som fokuserer på gensidig tilpasning af forretning og IT, og dermed en sikring af en forretningsorienteret IT-udvikling. Feedback vedr. spørgeskemaet kan ske her. 267H Generelle spørgsmål 1. Hvad er din jobfunktion? --> 2. Hvad hedder din kommune efter 1. Januar 2007? Vælg her 3. I forbindelse med strukturreformen, hvilken type kommune tilhører du? 4. En af målene med strukturreformen er at kommunen fremover skal være borgerens primære indgang til det offentlige. Alligevel laver KL en fælles offentlig borgerportal i www.borger.dk. Hvad synes du om det? Vælg her Vælg her borger.dk er overflødig borger.dk er uundværlig Ingen mening 4.1 Begrund venligst dit svar Kommunalt Forretningsorienteret IT Opbygning (herefter FIO) 5. Har din kommune en IT-strategi? 5.1 Hvis ja, i hvor høj grad vurderer du, at jeres IT-strategi fremover kan bidrage til større anvendelig borgerservice? 6. Har din kommune en EA funktion? (fx. en strategisk ITfunktion) 6.1 Hvis ja, hvordan er den forankret? Vælg her Vælg her Vælg her I IT-afdelingen Udskilt i egen enhed Andet 6.1.1 Hvis egen enhed, understøtter denne direkte det strategiske/ledelsesmæssige niveau? Vælg her 6.1.2 Hvilke profiler bemander enheden? Page 107 of 112 Enterprise Architecture of public Denmark 6.1.3 Hvordan træffes beslutninger i denne enhed? Master thesis, December 2006 På central plan udenfor enheden Decentralt i enheden 7. Vedligeholder EA og/eller IT afdelingen en samlet oversigt over de services (servicekatalog), snitflader, tekniske processer og datakilder, som indgår i porteføljen? Vælg her 7.1 Hvis nej, hvem gør så? 8. Arbejder din kommune struktureret med forretningsdrevet IT? Vælg her 9. Hvis ja, hvilke(t) ledelsesniveau deltager i en evt. arbejdsgruppe/projektgruppe vedrørende IT-strategi? Vælg her 9.1 Hvilke kompetencer besidder disse? 10. Arbejder din kommune med organisatorisk overlappende grupper? (fx. en medarbejder sidder i to forskellige projektgrupper) Vælg her 11. Får din kommune støtte fra eksterne EA/IT-arkitekter? Vælg her 11.1 Hvis ja, hvornår benyttes disse? Vælg her 12. Hvordan uddannes IT medarbejderne primært? Vælg her 13. Er I tilfredse med markedsudbuddet af kurser indenfor IT og dens anvendelse på strategisk plan? Vælg her Motivation, mål og mulige barrierer for tværkommunal FIO 14. Har din kommune opnået konkrete resultater gennem anvendelse af IT som en del af den kommunale forretningsstrategi? Vælg her 15. Hvad kunne være din kommunes primære motivation for at At opnå: deltage i et tværkommunalt IT-samarbejde vedrørende løsning Vælg her af ensartede kommunale opgaver efter 1. januar? 16. Hvad ser du som den største barriere for at opnå dette tværkommunale IT-samarbejde? Vælg her 16.1 Hvis andet, hvad? 17. Samarbejder din kommune pt. med andre kommuner om fælles løsning af fælles opgaver? Vælg her 17.1 Hvis ja, hvilke opgaver det drejer sig om? 18. Hvordan vurderer du den optimale organisering af fælles løsning på fælles opgaver i tværkommunalt samarbejde? Vælg her 18.1 Hvis 'I andet fora', uddyb venligst svaret Page 108 of 112 Enterprise Architecture of public Denmark Master thesis, December 2006 Måling af FIO 19. Måler kommunen på sin gennemførelse af IT projekter? Vælg her 20. Måler kommunen på sin modenhed i relation til brug af IT i forretningen? Vælg her 20.1 Hvis ja, hvilken målemetode anvendes da? FIO Processen 21. Har kommunen offentliggjort retningslinjer, som beskriver processen for brug af IT i opbygningen af forretningen? Vælg her 22. Hvad er den største detaljeringsgrad din kommune besidder af disse offentliggjorte retningslinjer? Vælg her 23. Har I ladet jer inspirere af andre ved dokumentation af ovennævnte proces? Vælg her 23.1 Hvis ja, hvem? 24. Abstraktionsniveau af den offentliggjorte FIO proces? Vælg her 25. Hvilke aspekter beskriver den offentliggjorte FIO proces? Vælg her 26. Anvender kommunen specifikke teknikker til at offentliggøre FIO processen? (fx. website, avisartikler etc.) Vælg her 27. Beskriver FIO processen også Styring af FIO på strategisk plan? Vælg her 28. Beskriver FIO processen vejledning for måling? Vælg her 29. Hvor mange områder/afdelinger i kommunen anvender IT som understøttelse til forretningsprocessen? Vælg her FIO Framework 30. Har kommunen et offentliggjort framework for Forretningsorienteret IT Opbygning? Vælg her 30.1 Hvis ja, hvilket framework/person er I blevet inspireret af? Vælg her 31. Hvor detaljeret er den offentliggjorte retningslinje af frameworket? Vælg her 32. Abstraktionsniveau af det offentliggjorte FIO/EA framework? Vælg her 33. Hvilke aspekter omfatter det offentliggjorte FIO/EA framework? Vælg her Anden 34. Hvilke teknikker foreslår FIO/EA frameworket? 35. Foreslår kommunens FIO/EA framework en metamodel? (En metamodel skal forstås som et værktøj der operationaliserer arkitektur-arbejdet) 36. Hvor mange områder/afdelinger i kommunen anvender FIO/EA frameworket? Vælg her Vælg her Vælg her Page 109 of 112 Enterprise Architecture of public Denmark Master thesis, December 2006 FIO Værktøj 37. Stiller kommunen krav om brug af bestemte IT værktøjer? (fx. MS Office, OpenOffice, Open Source værktøjer, ITIL etc.) Vælg her 37.1 Hvis ja, hvilke? 38. Benyttes ITIL som værktøj i organisationen? 39. I hvilket omfang bliver decentrale IT-anskaffelser kvalitetssikret eller ligefrem godkendt af EA funktionen? Vælg her I meget stort omfang (altid) I mellem omfang (engang imellem) I lille omfang (sjældent) I meget lille omfang (aldrig) 40. Hvem udvikler primært snitflader mellem rammesystemer? Uvildige konsulenter Bilateralt mellem leverandørerne Kommunen udvikler det selv Anden 41. Er der implementeret en formaliseret bruger identitetsstyring evt. ved hjælp af fælles platform (IAM)? Ja Nej Nej, men der er planer om det! Ved ikke FIO Styring 42. Hvordan så du gerne et tværkommunalt FIO/EA programmet håndhævet? Gennem lovgivning Gennem gængs praksis På anden vis 42.1 På hvilket niveau? Forvaltningsniveau Afdelingsniveau På tværs i organisationen Alle niveauer Ved ikke 43. Hvilken karakteristik vil du give af den nuværende styringsformen af FIO i din kommune? Vælg her Nuværende FIO aktiver 44. Hvor stor en procentdel af FIO/EA aspekterne, vurderer du er beskrevet og ført up-to-date i din kommune? Forretningsarkitektur? Vælg her Informationsarkitektur? Vælg her Page 110 of 112 Enterprise Architecture of public Denmark Master thesis, December 2006 Applikationsarkitektur? Vælg her Teknisk Arkitektur? Vælg her Anonymitet ønskes! Nulstil Send Tusind tak for at din kommune ville deltage i denne undersøgelse ©2006 KIT@, CBS Page 111 of 112 Enterprise Architecture of public Denmark Master thesis, December 2006 Glossary General terms EA: Enterprise Architecture SOA: Service-Oriented Architecture SOEA: Service-Oriented Enterprise Architecture EAP: Enterprise Architecture Planning IS: Information Systems IT: Information Technology Danish terms KIT@: The National Association of Municipal CIO’s KL: The National Association of Communities KMD: The largest Danish-owned Information Technology enterprise NITA: The National IT- and Telecom Agency STS: Danish National Steering Group for Joint Public Initiatives MST: Ministry of Science, Technology and Innovation TADR: The Association of the Danish Regions ITA: Office of IT Architecture at the NITA FESD (The Joint Public Electronic Case- and Document Handling) Page 112 of 112