The excellent European eGovernment Observatory publishes an eGovernment Newsletter, “A quarterly report providing insight on the most relevant developments of the last months”. I have just accepted an invitation to write an article about our work on enterprise architecture for the newsletter, thanking the editor for considering our work “most relevant developments of the last months”. So, if you don’t already subscribe to the newsletter, do so now 🙂
I don’t quite know how much time I have to finish the article, but I have been asked to write about:
– What is Enterprise Architecture and is why is it important for e-government success?
– Is it possible to simply transpose EA concepts and tools from the private sector to government, or are there some public sector specificities that make EA slightly different in government than in private corporations?
– Most European governments have worked out interoperability frameworks and government-wide service delivery infrastructures before starting to work on EA. Wouldn’t it be more efficient to work out an EA framework first?
– What has been done in Denmark and what can be learned from the Danish experience?
– What are other governments doing in the field of EA, in the US but especially in Europe?
OK. Some quick thoughts:
– EA is basically about bringing sense into our e-government work. IT does matter, but it is our “business”, or mission, that counts.
– Compared to the private sector: “slightly different”, you bet. I think EA makes a lot of sense to any enterprise. In a private enterprise, where the boundaries are well-defined, it makes immediate sense. But for government, what is the enterprise? The whole of government? A sector (health, environment, etc)? A domain (e.g. “medication at home”, which crosses over between health and social affairs)? A ministry? An agency? A major challenge to EA in government is to define the boundaries of the enterprise for which you’re doing architecture.
– framework first? Maybe, but you can’t really look at things like that. But yes, EA should be all-inclusive, and too many projects running ahead without coordination can be dangerous.
