Two large projects this fall in the Ministry of Finance will require a blogging break for me. But, I will be back – and I will continue to update my list of publication and links on this website in general.

Ciao to you all... See you here again soon :-))

Even thought my research is descriptive in nature, I have recently defined the seven propositions for EA practitioners listed below.

1. Don’t be blinded. Public organizations are conservative creatures and administrative reform and transformation is not driven by IT or the planning of IT use with EA alone. Fundamental transformation to the tasks performed in public organizations depend on political and institutional determination.

2. Understand the politics of government. The business of government is complex, mandates are often unclear, and the struggle for political support can be tough. Understand the environment, agency programs, and potential ‘obstacles’ before launching EA programs.

3. Don’t follow, lead. Perceived ‘best practices’ are not always the right medicine in a specific context. EA programs must proactively be customized to a specific context if success is to be achieved.

4. Focus on business and leadership, not technical frameworks. EA has a tendency to get very complicated and technically focused. New EA programs must ensure management backing and focus on business process management and change management.

5. Only use EA as a toolbox. EA is a meta-discipline that embraces, supplements, and extends other disciplines like e.g. Business Process Management. EA programs must change over time and become part of a continuous business improvement agenda.

6. Create clear governance structures. Unclear distributions of power, unclear mandates, and a constant struggle for political support will hinder EA success. A clear governance structure across levels and functions of government is key for successful EA adoption.

7. Think big and start small. The need to interact with external partners is especially far-reaching in government. Develop EA programs that can embrace the need for extra-organizational horizontal and vertical linkages.

We discussed my research and EA in Denmark. We also discussed how EA can provide structure to the business of government and component-based IT-architectures. Scott’s great EA-book and his forthcoming book on Coherency Management are must reads for all enterprise architects.

To answer our research question on the purpose and drivers of EA, we used two research approaches: In the first part we gathered two focus groups, one with CIOs and one with chief enterprise architects in the Danish central government. In the second part we interviewed two experts – or “Gurus” – and analyzed official documents, newspapers and official websites.

We found the causal direction reversed from EA being transformative and prescriptive in its nature to EA being reshaped and adopted in step with the institutional forces in public organizations and their macro environment. To be more than just another fashion fad, future EA programs in government must provide a comprehensive and coherent view across business, information, and technology; not just to guide the design of IT systems – but to deliver business change supported and enabled by IT.

Abstract:

Enterprise Architecture (EA) has been promoted as a key tool for transformation and modernization of government. In this paper we study what has driven the use and adoption of the EA concept in the Danish central government. Based on analysis of focus group and ‘guru’ interviews with government CIO’s, enterprise architects, and consultants, as well as extensive document studies, we find that there are two streams in public sector EA programs: a stable element of it-architecture and a fashion driven business architecture element – used in parallel, but with different focus, approach and artifacts. We conclude that EA in government to a large extend is driven by fashion. Finally, we discuss the role of EA in the future and point out that EA can not transform government by itself. Fundamental transformation to the tasks performed in public organizations is only achieved if institutional forces promote transformation.

During the seminar Phil introduced the idea about the ”lazy architect”. The role of the enterprise architect is to ensure that the business and IT are in alignment. And ”ideally”, when an EA program has been well established, the enterprise architect can sit back and just make sure that this alignment is happening.

However, as noted previously on this blog, my practical and academic expertise is that EA is often performed very different in different organizational settings. As Phil and Brian also noted, EA is not a clear-cut movement that can be adopted by any organization with similar results.

EA implementation is context dependent and typically comes with as much frustrations and desperation as accomplishments and joy. Working with many different stakeholders, both leadership and subject matter experts, to build a holistic view of the organization's strategy, processes, information, and information technology assets is not just a walk in the park in most organizations.

EA is still a fairly new discipline, and many organizations have just recently created the role of the architect. Maturity is probably a key word when we want find what Weber would call the ideal type ”lazy architect” – however, in my world the ”lazy architect” is still more vision than reality...

Please let me know how you experience your role as enterprise architect. In my research I try to understand how EA is adopted and your feedback is therefore very valuable to me. Post a note here or drop me an e-mail.

In an entry last year I announced the call for papers and we received a bunch of quality papers – all good candidates for publications. However, in the end we decided to publish the following five papers:

- A Comparative Account of Joined-Up Government Initiatives in Dutch and Belgian Social Security
By Homburg, V. M. F.

- Integration and Enterprise Architecture Challenges in E-Government: A European Perspective
By Weerakkody, V.; Janssen, M.; Hjort-Madsen, K.

- Managing E-Government Application Evolution: A State Government Case
By Kung, H. J.; Tung, H. L.; Case, T.

- E-Mexico: Collaborative Structures in Mexican Public Administration
By Luna-Reyes, L. F.; Gil-Garcia, J. R.; Cruz, C. B.

- The E-Government Development, IT Strategies, and Portals of the Hong Kong SAR Government
By HO, K. K. W.

You can find all the papers here.

It was fun to work with Vishanth and Marijn and a great learning experience for me to edit a special issue in a journal. Hopefully, it will not be the last time I do that.

My first challenge is to reflect on my research question. The blurry question that I am working with these days is “Why and how is enterprise architecture adopted as an information systems planning trend/innovation in the public sector?” It needs to be more focused and linked with my publications.

The goal of my PhD-project is to produce a paper model dissertation that contributes to the scare research carried out in the area of EA in government by conducting various studies in public agencies in Denmark and the USA. So fare, I have a couple of decent publications under my belt. But, I need to produce a plan for 1)which publications to include in my PhD-dissertation and 2)which articles I can/must write to tie it all together.

I am very motivated and will try to keep you all up to date on my progress in the lab.

The idea is to use the wiki to allow my colleagues in the public sector (and their commercial vendors) to comment add, remove, and edit content in version 0.5 of the integration model like a real Web 2.0 tool.

The integration model describes how all public portal services can be integrated with our two national portals for citizens (borger.dk) and businesses (virk.dk). What we are trying to do is to build a kind of “third way” architectural style that enables decentralized autonomy and minimal constraints. We are using a minimal specification of easily applied identifiers, formats, and tools.

I hope the wiki will facilitate collaboration and knowledge sharing between the portals, the public agencies, and all the commercial vendors. I will blog more about my experiences later – stay tuned!

The framework should results in a better understanding of national EA efforts. We hypotheses that an analysis of national EAs should at least encompass five elements, 1) Policies, actors and strategies, 2) Governance 3) Architecture model 4) Architecture principles and standards and 5) Implementations. We test this framework by analyzing the EA efforts of two European countries. Our analysis shows that EA should be framed within the institutional environment and governance aspects determine the adoption and diffusion of EA.

Below, I have inserted our original HICSS abstract. The new version of the paper that we are working on will focus more on the theoretical framework than the national case studies. I think we are on to something interesting here – so stay tuned ;-)

National enterprise architectures (NEA) promise to fill the gap between policy and implementation. NEAs are embedded within an institutional environment consisting of active players capable of responding strategically and innovatively to architectural initiatives, which might complicate NEA adoption. In this paper we analyze the efforts of two European national governments in developing enterprise architecture. Grounded in institutional theory and practice we develop an analytical framework and use this framework to analyze the fforts of two countries, Denmark and the Netherlands. Our framework and analysis draws the attention to the need to take a broader perspective on enterprise architecture, especially governance aspects determine the adoption and diffusion of NEA.

In the Digital taskforce, Prince2 is the de facto standard for project management and I have, therefore, been Prince2 certified. It was tough to take the exam. But, there are some great tools in Prince2 and I am trying to figure out how EA can be integrated better with the Project Initiation Document (PID). The PID is used to define the project, form the basis for its management and the assessment of overall success. Therefore, we need to work on a "standard" PID for EA program management. I know that some private enterprises in Denmark are working on this link and I am continuously working on this missing link. I will be back with more news when things calm down in the Ministry... Cheers!

My job there will be too give (EA) input too the national e-government strategy and assist different projects with concrete IT/EA architectural thinking. It will be a huge and exiting challenge too be part of the “real” work in the Ministry of Finance - and too see how/if my thoughts will influence the national EA work. Communicating the value of EA will be one of my key challenges. I have spent the last couple of years preaching how fantastic a tool EA is. The interesting question will be: Will the dog eat the dog food? I will try too keep you all posted…