Author: administrator

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 US FEAPMO recently launched the OMB Enterprise Architecture Assessment v1.0. Also available:Excel Format v1.0 and FAQs.
• GAO (US General Accounting Office) has developed A Framework for Assessing and Improving Enterprise Architecture Management (Version 1.1) and reviewed the US federal government in the report named Leadership Remains Key to Agencies Making Progress on Enterprise Architecture Efforts. I’ve found two presentations of the maturity model (see also this GAO presentation about IT investments).
• NASCIO (National Association of State Chief Information Officers) has developed the Enterprise Architecture Maturity Model (Version 1.3), which is popular with state CIO’s. NASCIO has also made a validation model, which is used for self-assessments (more) in the states.
• The Extended Enterprise Architecture Maturity Model from IFEAD is describing the different levels of maturity of an Enterprise Organisation. Different viewpoints are used to describe the E2A maturity, for example: Business Technology Strategy Linkage; Extended Enterprise Involvement; Top-Management Involvement; Operating Units Participation; Enterprise Architecture Program Definition; Enterprise Architecture Development; Enterprise Architecture Communication; Strategic Governance; Enterprise Program Management; Holistic Enterprise Architecture and Business & IT investments and Procurement strategy.
• The COSM (Component Oriented Software Manufacturing) Maturity Model,
  an ‘architecture-centric comprehensive maturity model’ from Herzum Software.
• IAC (US Industry Advisory Council) Enterprise Architecture SIG has written up some useful guidelines for Advancing Enterprise Architecture Maturity. IAC also offers a number of other good whitepapers.
• Maturity assessment services can be bought from META Group or Gartner. Both companies have established proprietary models.

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).

The message to the US Congress is that the US federal enterprise architecture program and agency enterprise architecture initiatives are beginning to achieve strong results, but still, significant work remains to achieve the full potential existing with the federal enterprise architecture. Karen Evans and others sound optimistic, others don’t.

Mark Forman, the former US federal CIO, also argues that the Federal Enterprise Architecture “needs to move to a service-oriented architecture and away from one that focuses on symmetrical multiprocessor concepts”. To get to service-oriented architecture, Forman says that agencies must do the following:

• Use commodity instead of proprietary hardware and software.
• Move from silo to shared resources where agencies build for component reuse and integration.
• Stop building monolithic applications and apply the shared service approach.
• Automate more IT services to improve their quality.

This is very much in line with the Danish strategy.

Last week, FCW quoted one of my bosses:

In Denmark, nonelectronic and e-government services are designed to be provided governmentwide. Officials are even changing their political structure to provide better service, said Mikkel Hemmingsen, deputy director general of the Danish Ministry of Science, Technology and Innovation. He spoke last week at the META Group Inc.’s Government Enterprise Architectures Conference in Arlington, Va.

The country has 14 counties and 274 municipalities of varying sizes, but a wide-scale reform effort will include consolidating those to five counties and 100 municipalities. Once that reform is complete, the goal is to “have a political structure that is suited to the services we want to deliver,” Hemmingsen said.

Denmark’s enterprise architecture process, which focuses on everything from Extensible Markup Language to document management systems, is designed to include input from the private sector on every issue, he said. Although citizens are not involved, this process ensures that no government technology or IT policy goes forward without public input, he said.

Tim Bray writes about WS-Good Practices and WS-Theory and concludes:

I think somebody needs to stand up and start waving a flag that’s labeled ‘WS-Simplification’ or ‘Real Web Services’ or something, that’s all about building applications with what’s here today and what works today: XML, HTTP, URIs, SOAP, WSDL, and that’s about it.

Tim, here is a flag:

The Reference Profile is the Danish e-Government Interoperability Framework. Though the framework covers more than WS-technologies, these are an important part of the framework.

We have lots of XML – 32 out of the 107 included standards are XML-related – and of course we have HTTP. We acknowledge SOAP and WSDL as mature enough for “real” usage, and do also hold UDDI on “yellow”. Hmm. URIs – where do these go as far as being “standards”?

Tim Bray also writes about HTTP over SOAP ?!?!?, about the new W3C Working Draft on SOAP Resource Representation Header, where he reveals the secret of Australian sheep counters, who can glance at a gaggle of hundreds or even thousands of sheep and in an instant tell you the exact count: “The trick is, they count the legs and divide by four.”

The reference profile has been in a public hearing which has just ended (although we are not strict with the deadline, so if you want to submit a comment, do so anytime).

We have received comments from a variety of public and private organisations – from the Danish DoD over IBM to the local Linux user group. I am yet to dig deeper into them, but a quick scan shows that we have successfully delivered a much-requested deliverable. Expectedly, there are a number of “issues”, but almost none that surprised me and weren’t on my to-do list already. That list is pretty long, however.

We are now gathering a strong team who will join forces on making the reference profile even better. The final verison 1 should be ready before the summer. We will approve it in the National ITA Committee on 10 June.

Interested in joining our team? We have a half-year replacement position open in NITA. Ideal for a newly graduated. Get in touch, if you are interested.

Successful and mature e-government can only be achieved through a process of building organisational infrastructures that enable innovative action strategies to thrive in the culture of interoperability.
Architecture, not technology, should be the main driver in the modernisation of government. Enterprise Architecture is about integrating business strategy planning and IT strategy. Basically, the message is that we must focus less on IT, per se, and more on the process of organising and managing IT across government agencies.

From ‘Enterprise Architecture for e-government’, John G�tze in IDA Report 21 – March 2004 (download PDF) and IDA eGovernment Newsletter n�7 – March 2004

I want to follow up a bit on this idea of a culture of interoperability in eGovernment. Interoperability is, perhaps especially in Europe, a burning issue everywhere (at least everywhere I go …).

In the European Interoperability Framework, we say that there are three important aspects we need to tackle: organisational, semantic and technical interoperability.

Organisational interoperability is concerned with defining business goals, modelling business processes and bringing about the collaboration of administrations that wish to exchange information, but that may have a different internal organisation and structure for their operations. Moreover, organisational interoperability aims at addressing the requirements of the user community by making services available, findable, accessible and user-oriented.

Semantic interoperability is concerned with ensuring that the precise meaning of exchanged information is understandable by any other application not initially developed for this purpose. Semantic interoperability enables systems to combine received information with other information resources and to process it in a meaningful manner.

Technical interoperability covers the technical issues of linking up computer systems and services. This includes key aspects such as open interfaces, interconnection services, data integration and middleware, data presentation and exchange, accessibility and security services.

These aspects of the issue can be taken further, it occurs to me. In our white paper, we talk about five important principles interoperability, openness, security, flexibility and scalability – for an enterprise architecture. We have been trying to consolidate these principles for a while, and have good support for this, but keep meeting requests for more explanation and direction signals. So here is an idea. For each of these principles, we look at the same three important aspects that we need to tackle:

• organisational, semantic and technical interoperability
• organisational, semantic and technical openness
• organisational, semantic and technical security
• organisational, semantic and technical flexibility
• organisational, semantic and technical scalability

Does this work? I think so:
– organisational openness: transparency, democratic openness
– semantic openness: use of open data definitions, access to data issues
– technical openness: use of open standards for data access, access to source code, etc
– etc

My PhD-student Kristian is working on an interesting model about interoperability. So far, the model is two-dimensional, but it might soon become three-dimensional 😉