Managing Integration in a Federated Architecture Environment
John Zachman is the originator of the Zachman Framework for Enterprise Architecture. At a recent Intervista Institute Enterprise Architecture course in Washington DC, Michael Kull spoke to Mr. Zachman about how organizations manage federated architectures.

As government agencies struggle to integrate their information systems horizontally and vertically, having everyone on the same page in terms of the organization’s strategy and enterprise architecture is key. An enterprise architecture is blueprint of how an organization’s systems should interoperate in the fulfillment of the mission and business objectives of the organization.

Adopted by many government agencies, departments, and ministries in the United States, Canada and throughout the world, the Zachman Framework for Enterprise Architecture provides a common classification scheme for descriptive models of an enterprise. The framework is adopted for integration efforts because it provides a comprehensive view of business domains and their information characteristics. Based on the six interrogatives of language, the Zachman Framework offers a "common tongue" for what otherwise is a morass of different models of reality. The columns in the framework represent the interrogatives: What (data and entities), How (process or function), Where (location and network), Who (people), When (time), and Why (motivation). The rows of the framework describe the different perspectives of the managers of the enterprise: Scope, Business Model, System Model, Technology Model and Detailed Representations. The Zachman Framework may be viewed here.

The main integration issue for managers reflects the inherent problem of developing local solutions for local problems. ?Integration does not happen by accident,? says John Zachman. Lacking a unifying framework, complex organizations may develop their own architectures that may or may not integrate. Since it remains a problem in large agencies to build according to a common framework, one strategy that emerges is to connect multiple frameworks into a federated architecture. According to Zachman, in adopting this approach it is all the more critical to be clear about the definitions and models that multiple frameworks should share.

“You have to be definitive about what you want in common across multiple frameworks.” Multiple frameworks, also called peer frameworks, reside at the department level and result from an evolution of local information systems. In other words, without an overarching framework, most agencies and departments are stuck with systems that serve only their specific needs. This is the state of things at the very time when current administrations are putting pressure on agencies and government departments to get their act together to better interoperate, reduce redundancies, and improve service.

A case in point is the new Department of Homeland Security for the US government. Is enterprise architecture an important need for the new Department of Homeland Security? John Zachman responds: “This is precisely the issue. They’re going to put together a lot of agencies under one person. Now, that’s really positive, because there is somebody in that case who cares about integration beyond the boundaries of any one of those agencies who can leverage or force the integration. Agency by agency - they don’t care about integration. They’d just as well leave things disintegrated. In fact, that’s the evidence of where we are right now. They are disintegrated and there is no incentive for them to get integrated, until someone says, ‘get your act together and get integrated!’ So putting them under one department head is a profoundly good idea.”

Managing in a federated architecture environment means going through the work of defining what knowledge is important to share and how that differs across various architectures. “What you mean when you say the word ‘terrorist,’ for example, is going to have to be consistent from framework to framework or all your implementations, manual or automated, aren’t going to talk to each other. Someone has to define the integration if you want integrated frameworks.” Zachman argues that while having a common architecture defined at an excruciating level of detail would be the ideal, the reality is that managers may not have the time or resources to undertake such large-scale change. “You don’t want to make them the same if they’re different, but where they’re the same you want to leverage sameness.”

Another important issue is governance. It’s not only adequate for architects to develop peer architectures that look similar, but that there are also rules for commonality that guides each development, that can be checked against larger goals. “If you’re going to have a federated set of frameworks, you don’t just say to everyone ‘go out and do enterprise architecture’ and you’re done. That’s just the beginning.” Ensuring that the results of architecture development meet the goals of the chief architect relies on a meta-framework – a framework for specifying what constitutes good modeling for every peer framework. “Integration has to be engineered. If you go out and try to build a framework for every department, and then try to integrate them, you’re into scrap and rework. You’ll end up having to reengineer things.” And who can forget the joys of reengineering?

John Zachman and Michael Kull are faculty members at the Intervista Institute, Inc.
© Copyright 2003 by the Intervista Institute, Inc.