Britain's GovTalk is analogous to the US Federal Enterprise Architecture PMO. They publish eGIF, the eGovernment Interoperability Framework. The document is a set of standards that agencies of the British government must comply with. The document comes in two parts. Part 1 is framework that contains high level policy statements, management, implementation and compliance requirements. Part 2 is the actual technical policies and specifications. There are five major categories:

• Interconnection - policies for connecting system together
• Data integration - XML standards
• Content management metadata - Metadata standards
• Access - What types of devices should be supported
• Business areas - business specific XML standards

To give you an idea of what it looks like, this is a few of the policy statements from section 4 on interoperability:

4.1.1 departments are to interconnect using IPv4 and plan for migration to IPv6 in due course. See notes on migration to IPv6 below
4.1.2 interfaces for e-mail systems are to conform to the SMTP/MIME for message transport and POP3 for mailbox retrieval. Within government, the norm will be to use the intrinsic security provided by the GSI to ensure e- mail confidentiality Outside the GSI and other secure government networks, S/MIME V3 should be used for secure messaging security unless security requirements dictate otherwise

Elsewhere in the section are tables that specify, for example, that HTTP will follow RFC 2616.

This kind of standards process is essential to eGovernment. Without it, there is no hope of cooperation. Perhaps the most important thing a public sector CIO can do is establish a governance process for creating standards that everyone can live with and pushing it forward to create usable standards.

When I left Utah government, we were pushing for more of a framework approach to standards. We published a IT Product Standards guide and a stardards review matrix as first steps. There hasn't been much standards work in Utah this year, at least as far as published standards are concerned.

The Zachman Framework has done most of the hard part of creating the framework. Organizations need to localize it to their individual needs. I like the matrix because it gives you a field of play, so to speak. I imagine that if you study it, you'll find two, three, five, or ten of these squares you think you have a pretty good handle on. That tells you where to concentrate you focus and gives you some context. One of the tough parts of enterprise architecture as defined by the federal EA project management office or the state CIOs at NASCIO is that there was so little context that people have a tough time finding a hand hold and figuring it out. There's lots of places in the Zachman framework to grab on and get started.