Gotze.eu

Category: Enterprise Architecture

  • ICA Enterprise Architecture Study Group Survey

    We have launched the ICA Enterprise Architecture Study Group Survey:

    The survey is intended to gather basic information about ICA countries’ work with government Enterprise Architecture. The study group wants to emphasise that all ICA member countries are invited to reply to the survey, whether their work is called Enterprise Architecture or not.

    The objective of collecting data through this survey is to get a comprehensive overview of activites in the EA field in ICA countries. Such overview does not exist today, at least not in the public domain, and it is found that the survey would be welcomed by the international community.

    Everyone working with enterprise architecture in government should consider responding to the survey.

  • Connecting the dots?

    Brian Kane’s thesis from ITU (this ITU) about Danish public IT strategy, Connecting The Dots – Why Danish IT architecture does not result in interoperability is a critical analysis of our work.
    Download (big PDF), Executive summary.

    Brian’s core findings include:

    • Both the general standards and recommendations and the specific case of the FESD project reflect an understanding of interoperability as being the exchange of business documents.
    • Guidance on how to expose systems as services following the concept of service oriented architecture is vague at best. Specifications are too broad and unspecific to be implemented in a consistent manner.
    • There is no coherent way of resolving the physical or semantic problems when two domains of control meet.
    • Most relevant standards are authorized for use, some overlapping and conflicting, but no guidelines are in place for when to use which standards and how.
    • Towards the goal of service oriented architecture, a sound underlying, perhaps publicly controlled, integration infrastructure is needed.
    • There is a need for a long-term roadmap covering IT architectural efforts in the decades to come. The roadmap should clearly describe the current IT architectural situation, and include an explicit statement of strategic goals and operationalized milestones.

    Conclusion:

    While important work is being done at data model level, the task of moving data from application to application is only vaguely described. In conclusion, Danish IT architectural work can currently best be described as initial, informal and ad-hoc.

    Thank you, Brian, for such an impressive contribution to the on-going dialogues and deliberations about architecture for e-government.

  • Standard standards

    ZDNet: When standards don’t apply is an interesting article by David Becker about standards and standardisation processes. Examples used are MS Office, PDF, Flash and RSS. Quotes Perens, Bray, etc.

    Our new definition of open standards, confirmed by the national IT Architecture Committee, is:

    A completely open standard has the following properties:
    – It is accessible and free of charge to all
    – It remains accessible and free of charge
    – It is accessible free of charge and documented in all its details

    This definition is inspired by Perens’ definition of open standards.

    How do you define open standards?

  • Interoperability Architecture

    Sean McGrath on E-Government Interoperability and Enterprise Architecture. Sean has worked with the European Public Administration Network‘s eGovernment Working Group on a report called Key Principles of an Interoperability Architecture.

    The working group has adopted the “threee interoperabilities” (organisational, semantic and technical) from the European Interoperability Framework, but adds two layers in defining an interoperability architecture:

    • Structured Customer Contact and Support
    • Organisational Interoperability
    • Semantic Interoperability
    • Technical Interoperability
    • Governance of Interoperability

    The report defines principles in each of these areas, and suggests a roadmap for how to implement the principles. Definately an interesting read.

    Today’s word in the EA Glossary is Interoperability.

  • Conway’s Law

    Conway’s Law, formulated in 1968, is today’s entry in The EA Glossary.

    Conway is pinpointing our challenge as architects. It is all about communication, but at many levels. Communication is power. Knowledge is power. Architecture is power.

    Conway’s law is also expressed as:
    In any organization there is one person who knows what is going on. That person must be fired.

    That person would be the architect. Or maybe the receptionist.

    Phil Windley also twists Conway in subtitling his blog: Organizations Get the IT They Deserve (SM)

  • Framework

    You know one when you see one, but what is it??

    What is a Framework? [The EA Glossary]

  • Principles and politics

    Today’s word in The EA Glossary is Principle. I’ve collected a number of central definitions, which should be worth looking at.

    One of my ideas with the glossary blog is of course to create a glossary feed, which would be a decent way to syndicate the content. While I pretty much stick with a standard Typepad setup for the blog, which includes default RSS 1.0 and Atom feeds, I find the default exclusion (or, non-inclusion) of a RSS 2.0 feed wrong, and have added one, so the content is also available in
    RSS 2.0     (full content).

    Actually, when speaking of principles, and especially architectural such, it is interesting to note how important architectural decisions, such as the choice of syndication format standards – which are directly impacting the customers – seems to be driven by a complex set of principles, but also by pure politics and people/power games.

    Ruth Malan and Dana Bredemeyer talks about three guiding principles for enterprise erchitects: the Minimalist Architecture Principle, the Decisions With Teeth Principle, and Connect-the-Dots Principle:

    With a minimalist architecture, and connected dots, we can turn to the governance process to provide the teeth that will make the architecture stick.

    Did SixApart connect the dots when deciding to exclude RSS 2.0? Did Google show teeth when choosing Atom?

  • EA concept of the day

    I’ve been looking a enterprise architecture glossaries. I need one, and thought it shouldn’t be necessary to reinvent the wheel. Thought there must be something out there I can steal …

    I found a good number of glossaries:

    I am sure there are more out there. Please send links.

    Now there is one more: The EA Glossary. I created this (a blog) because I thought it would be handy and maybe even useful, for example, I thought of using it as a “word of the day/week” service. So far, it has only one entry: Line of Sight.

    If a few of us working with EA got together, this might fly! It could become a very nice resource, if we could get it going. Let me know if you want to become involved.

  • EA survey

    I’m the chair of the ICA study group on enterprise architecture. We’ve just finished our third workshop, which I hosted here in Copenhagen with attendees from Canada, US, UK, Netherlands, Korea and Japan. Thanks everyone for making the workshop a success!

    We are going to make a survey about EA in government. The target group for this survey will be government officials working with EA (“ourselves”), but we might open up for all interested, or make more surveys.

    I have installed phpESP which looks very promising as a survey tool. It allows for quite complex surveys, and seems ideal for our survey.

    I have created a basic, open survey:

    Survey: Enterprise Architecture in Government.

    I invite everyone to respond to the survey, which has two purposes. First, to test the survey tool – so please report any problems faced. Second, to enable registration for future surveys. If you are a government official, you will be invited to respond to the ICA survey.

  • Maturity model for EA

    How do we know how well we are doing in our EA work? One solution is to use maturity models. There are a number of these out there:

    The field of maturity models has long been dominated by Carnegie Mellon University’s SEI and their capability maturity models CMM and CMMI. CMMI’s focus is on four areas: systems engineering, software engineering, Integrated Product and Process Development, and supplier sourcing. CMMI is based on some sound principles, but the “waterfall-ish” CMM heritage scares me a bit.

    In comparison to other IT frameworks, such as ITIL (the IT Infrastructure Library from the UK Office of Government Commerce, OGC) and their self-assessment tool, and CobiT (Control Objectives for Information and Related Technology), CMMI is in many ways closer to EA than the more strictly IT-related ITIL and CobiT, but is still clearly something for the IT organisation. I suppose all these models might be embraced in an EA maturity framework. Heck, even stuff like Six Sigma could be considered, although other alternatives might be more effective, such as agile methods. Lee Copeland’s sarcastically suggests using a Maturity Maturity Model (M3).