Other practitioners and researchers often quote my research to highlight enterprise architecture adoption challenges. In my practical work and research, I see EA as a toolbox that embraces, supplements, and extends other disciplines. I think that the jungle of commercial EA frameworks and methods available are often too difficult to translate into actionable business results. In the Ministry of Finance, I have championed the introduction of EA reference models. And we are working on other tools for national IT-portfolio planning, e.g. via business cases. Adoption is difficult, but if we apply EA with a natural skepticism we might succeed…
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.
I have just returned from a great dinner with Dr. Scott Bernard. Scott is the editor for JEA and founder of a|EA International, and he has become a good friend and colleague of mine.
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.
This blog entry roughly outlines the status of EA in the Danish public sector based on a framework I developed with Marijn Janssen in 2005. Other researchers have used our framework to compare national EA programs – you can download the original article here.
Policies, actors, and structures:
The main vision for Denmark’s EA efforts was formulated in a white paper published by the National IT and Telecom Agency in 2003. Today, the IT and Telecom Agency heads the cross-public sector IT-architecture committee where most nationwide technical standards and IT-architecture principles are coined.
Local Government Denmark (the municipal cooperation) participates in the IT-architecture committee and (by and large) endorses the decisions made here.
The Digital Taskforce in the Ministry of Finance also participates in the IT-architecture committee and work with reference models, mandatory business cases, and IT-investment principles in general.
Governance:
The EA governance setup in Denmark is largely driven by incentives, i.e. there is no legislation or regulations governing standards and principles for EA development in the Danish government. Thus, the adoption of EA is largely based on voluntarism and it is up to each public organization to assess their need for an EA and decisions related to it.
At the state level a business case model for large IT-projects was made mandatory by the Ministry of Finance in 2008. Reference models are included here.
Architecture frameworks and methodologies:
Since the publication of the EA white paper in 2003, a handbook on EA implementation has been published by the National IT and Telecom Agency. The handbook defines a generic architectural process for EA development similar to e.g. the Federal Enterprise Architecture Framework. The handbook also includes an EA framework based on the Zachman Framework.
A business reference model was developed in 2007 for the entire public sector (see more details here). A service and technology reference model is under development.
Architecture principles and standards:
The EA process model deals with non-mandatory principles and the selection of standards. In the white paper published in 2003 five categories of principles were suggested: interoperability, security, openness, flexibility and scalability. A new set of IT-architecture principles are under development.
The National IT and Telecom Agency is also responsible for national technical standards and data-standards.
Implementation:
As the Danish EA governance model is based on incentives rather than laws and regulations, the implementation of EA in Denmark’s public agencies is still rather fragmented. My prediction is that this will change in 2009 
Together with Professor Jan Pries-Heje I have just had an article accepted for the 42th Hawaii International Conference on System Sciences in January 2009.
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.
Let me know if you want further details.
Cisco IBSG just released a case study about Denmark’s business architecture program. My boss (Denmark’s version of a public sector CIO) and my self are quoted in the case study. A good read I think 
) Download here – or find here.
I recently attended a Gartner EA seminar in London. Hosted by the EA gurus Philip Allegra and Brian Burke, the seminar outlined the ”ideal” planning and implementation of an enterprise architecture program (great seminar – try to attend if you can some time).
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.
Clearing ones desk before the summer Holidays can be a rewarding experience. I just found my physical copy of the special issue on E-government Process Integration and Enterprise Architecture that I guest edited in the International Journal of Cases on Electronic Commerce with Vishanth Weerakkody and Marijn Janssen. Now I can show my wife that all the late hours that I spend editing the issue also materialized in something tangible.
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.
The next three weeks I am working on my PhD (more about academic life here). Buried in books at the IT-University of Copenhagen, I will try to get my hands around my research question, my publications and the red thread in my research.
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.
Accroding to Computerworld.dk, our wiki is the first ever public sector wiki… Read the article here.
I have just pressed the ”publish” button on an national wiki about the integration model that I have been working on for the past eight months in the Digital Task Force. You can find the wiki at oim.modernisering.dk (in Danish).
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!
