Enterprise Architecture has for some years now been a well respected buzzword signifying some of the best in large-scale information systems planning and design. Perhaps the most famous brand label in this area is the "Zachman Framework", the brainchild of John A. Zachman, that over the last twenty years or so has followed the classic concept-development lifecycle from pioneer's vision through research into mainstream IS thinking backed by training and consultancy services. Of course, Enterprise Architecture thinking does not begin or end with Zachman, however his Framework provides a convenient reference point for this paper, and stands here as a typical representative of the highly evolved strategies and methods that have emerged from two decades of corporate information systems engineering. A similar approach to interoperability is possible within other comprehensive approaches to enterprise systems, and I hope that readers working within other frameworks will find that the ideas presented here can be transplanted without much pain.

The virtues of the Zachman framework are well summed up by John Zachman himself as follows: "The Framework as it applies to Enterprises is simply a logical structure for classifying and organizing the descriptive representations of an Enterprise that are significant to the management of the Enterprise as well as to the development of the Enterprise's systems". Layers of modelling from business context and conceptual models through to physical implementation, together with viewpoints ranging from business objectives through to data items and network connections, provide a comprehensive and well integrated view of the enterprise and its information systems. Although copyright restrictions have prevented my including the classic diagram in this paper, it is easy for readers to find it for reference [The Zachman Framework], and the later sections of this paper should be read with a copy of the diagram to hand.

Alongside the original analytical framework, there is by now a well developed body of practice for planning and implementing enterprise architecture, for example as described in [Spewak & Hill]. The central characteristic of Enterprise Architecture Planning (e-GIF) practice is a structured programme involving stakeholders and decision makers from all affected parts of the organization, to develop and implement clear designs and plans using the viewpoints and layers in the Framework. Those parts of EAP that concern gaining organizational buy-in through stakeholder involvement and support from senior managers do not become any less important when interoperability is added. In fact, they become even more important and are likely to involve more people - however, this paper concentrates on the requisite context for appropriate implementation of the more technical aspects, so I will not be dealing further with planning and implementation processes.

So, back to the Framework. Why does such a well respected and well founded thing need to change? The answer is the ever intensifying complexity of business relationships supported by IT networks. Government organizations of all kinds face a double challenge: they must operate their internal information systems effectively and efficiently in fulfilling their assigned goals, and in order to achieve this, they must also interoperate electronically with a growing range of individuals, businesses and other organizations, nationally and internationally. The growing importance of networks and electronic business in public administration is well known, and has led to the development of policies, frameworks and standards for interoperability such as the UK e-Government Interoperability Framework (e-GIF).

The e-GIF takes an approach to interoperability based on policies and standards. It is "the Government’s technical policies and standards for achieving Interoperability and Information System coherence across the public sector... a fundamental Framework Policy for the e-Government strategy". The key aspects of e-GIF compliance are a combination of policy and standards compliance criteria:

The standards conformance aspect is backed up by a list of industry standards that are under review, recommended or adopted for use within e-GIF compliant e-services and systems.

In addition to these policy and standards conformance criteria, there are rigorous high level functional criteria expressed from the point of view of system and service users and owners. The user-level criterion is the coherent exchange of information and services between systems. The owner-referenced criterion is that it must be possible for any component or product used within an interface to be replaced by another of a similar specification without loss of functionality (and implicitly, acceptable performance).

The US federal government's Federal Enterprise Architecture Programme (e-GIF)[The Federal Enterprise Architecture Programme ] is a well developed layered enterprise architecture that pays particular attention to interoperability and interoperability standards within its Technical Reference Model.

The FEAPTechnical Reference Model (e-GIF) appears as the lowest level in a stack of co-oordinated reference models, rising up through a Data Reference Model, Performance Reference Model, Service Component Reference Model to the Business Reference Model at the top of the stack. The purpose of the TRM is expressed as follows:

The TRM is based on a service oriented technical architecture. Widely used and industry standard technologies (with an understandable bias towards US suppliers) are grouped into categories that are functionally related to the service oriented architecture, and listed with short descriptions and references to further information. A number of standards are included, however the style of presentation makes it clear that these are considered as technologies of the same kind as widely used operating systems.

I would have no hesitation in recommending the TRM and the e-GIF as useful references to anyone responsible for the architecture of a new e-Government service, or responsible for maintaining and developing an IT facility in the public sector. However, even within these insightful and comprehensive approaches, an essential dimension is missing. The e-GIF concentrates on interfaces; the FEAP on a layered architecture of functional processes and services. The central thesis of this paper is that these approaches can be fruitfully combined within an additional dimension of the Zachman Framework, to provide a in-depth organizational and technical framework for interoperability, and that this approach provides the appropriate decision making space in which to consider and plan the adoption of industry standards such as ebXML [ebXML] and HL7[HL7] .

The Zachman Framework [The Zachman Framework] organizes information about an enterprise into viewpoints characterized by What, How, Where, Who, When & Why. This works pretty well for analysis within an enterprise, and includes ("Who") the people who interact directly with the enterprise. To extend the scope of the Framework to interoperability, an additional dimension is required, that can be characterized as "With Whom?". This additional dimension would appear as an extra column in the 2-D matrix of the classic diagram, and I would put it alongside "Where?", that refers to locations at which the enterprise operates, and "Who?" that refers to people that undertake functions and play roles in the enterprise. The rest of this section assumes that this new column has been added to the matrix diagram, and works step by step down the vertical layers of Scope, Business Model, System Model, Technology Model, Detailed Representations & Functioning Enterprise, before finally considering what an Interoperability Architecture would look like.

There is a groundswell of realization at this time that standards and interoperability - and XML as their key technology - cannot be left just to technologists, and I hope that this has been a constructive contribution to that debate. In this paper, it has only been possible to offer a brief outline of the extension of EAP to incorporate the interoperability perspective. I hope to present a further stage of this work to you at some future date.