SOA and the Zachman Framework
As companies increasingly dive into the complexities of Service-Oriented Architecture (SOA), they need to consider an expanding set of criteria for what must go into the architectures they design. As IT architecture broadly speaking is still relatively immature as a practice, SOA is only now coming into its own as a discipline. Companies are looking for a model to understand the scope of their SOA initiatives so that they can build robust architectures that can withstand the ever-changing landscape of technologies, organizations, and methodologies. One increasingly popular approach for an organization to wrap their arms around the complexity that architecture represents is to use one of the most popular models for understanding Enterprise Architecture (EA) and its role in the business: The Zachman Framework, created by John A. Zachman.
Zachman’s key insight was to consider the problem of EA in two dimensions. The first dimension is the various levels of abstraction that businesses rely upon, including models of the technology in an enterprise, the systems that compose that technology, and the business that uses the systems. The second dimension consists of “W” questions: what, how, where, who, when, and why (how only ends with W, but you get the picture). For an enterprise, the what represents the information that flows through the organization and its extended enterprise; the how represents the functions and capabilities of the various parts of the organization, including the business processes; the where consists of the network that pulls together the information and functions, both in the technical sense as well as in the business sense of a network of business relationships; the who is the people or the organization itself; the when includes all scheduling and timing issues throughout the company; and the why represents the motivations of the business to take the actions it does–in other words, the business strategy. It is the sum total of all of these views that together comprises EA. Zachman represented these dimensions into a well-known chart, shown below. Click here for a larger version.
The way an enterprise architect uses the Framework is as a guide for the models their team might use to represent the elements of the architecture implementation. For example, let’s look at the box at the bottom of the column under “Time,” which represents the temporal context of the business, for example, the master schedule for the entire organization. The enterprise architect is responsible for using this model to drive the best practices for the business’s scheduling efforts, in coordination with all of the other best practices represented by the other 29 models in the Framework.
Notice that the Zachman Framework covers the gamut from purely business models, like business strategy, business locations, and the organizational hierarchy, all the way to deeply technical models, including detailed network, security, and data specifications. The Framework also serves to organize and promote the different points of view of an enterprise that different people will hold. Some people will have a more data-centric perspective, while others focus on the management hierarchy; some individuals live among the nitty gritty details, while others seek the big picture. The Zachman Framework points out that all such views — and many more — are every bit as important as all the others in obtaining a complete view of the workings of the enterprise.
Sound complicated? Well, the Zachman Framework has a little secret: few if any enterprises are able to flesh out more than a small handful of the 30 models associated with the boxes in the Framework. Instead, the Framework represents a best case, providing guidance for enterprise architects to tackle different aspects of their organization as the business needs dictate. There is no one correct path through the Zachman Framework; instead, enterprise architects must find their own paths, and implement those pieces that can have the most strategic impact on their businesses today. This iterative approach to EA implementation is a best practice that ZapThink frequently discusses in its research and advisory into how companies can move to Service Orientation.
How the Zachman Framework maps to SOA
The Zachman Framework helps companies organize and prioritize the various perspectives on EA, and this organization and prioritization applies just as well when the EA is SOA. Some people, after all, construe SOA narrowly as a form of application architecture, while other people think of SOA more broadly as EA. This argument is less a disagreement over terminology than a realization that there are multiple points of view for SOA. Understanding the relationships among those perspectives, fortunately, is a key strength of the Zachman Framework. Therefore, in order to be of use to enterprises trying to make sense of SOA, we need to tailor the Zachman Framework to the specifics of SOA. Or probably more accurately, put SOA in the context of the overall Zachman Framework
The logical starting point for applying the Framework to SOA is the Application Architecture portion at the intersection of the “Function” column and “Logical System Model” row. After all, we’re representing IT assets as Services to tackle the problems of integration, asset reuse, and loose coupling of systems. However, SOA is more than simply an architectural approach for dealing with the functional aspects of systems. We also represent business processes as compositions of Services, and in turn expose processes as Services so as to enable agility and loose coupling. Furthermore, SOA impacts the way that organizations share and represent information (via semantic and logical data models) as well as how the network deals with applications. Indeed, SOA blurs the line between network-aware applications and application-aware networks. As a result, the Framework indicates the next iteration of SOA beyond Application Architecture should deal with the eight neighboring squares, as shown in the figure below:
Leveraging Zachman to extend SOA to the Enterprise
In our book Service Orient or Be Doomed! we emphasize that Service Orientation (SO) is a business movement, where organizations are better able to leverage information technology (IT) in agile ways to meet ever-changing business needs. For SOA to be the architecture that enables such broad agility and change in organizations, it’s essential for architects to eventually apply the entire Zachman Framework to SOA. Where the Framework includes general terms such as “Time” and “Motivation,” SOA provides more specific terminology that fleshes out the relationship between business and IT that our book focuses on. Here, then, is an explanation of Zachman’s language as applied to SOA:
| Zachman Framework Concept | SOA Interpretation |
|---|---|
| Data (“what”) | Both the data themselves as well as the information flowing through the enterprise Services and processes (which are Services in their own right) |
| Function (“how”) | Services and processes (which are Services in their own right) |
| Network (“where”) | The network, both literally in terms of IP networks, and more broadly, in terms of networks of people |
| People (“who”) | User interfaces, Service consumers, and Service-Oriented Business Applications with rich interfaces (aka mashups) |
| Time (“when”) | Events |
| Motivation (“why”) | Policies and governance |
By applying the Zachman Framework to SOA, therefore, the SO architect has a framework for understanding the relationships among the various elements of a successful SOA, and also has a way of rising above squabbles over terminology to create a productive roadmap toward a successful implementation. For example, if an architecture team is squabbling over whether events belong in SOA or not, the Zachman Framework shows that an EA perspective on SOA will unite the view of SOA construed as application architecture, which belongs in the function column, with the ideas of event-driven architecture, which falls largely in the time column. Thus the Zachman Framework shows that an EA perspective on SOA broadens the reach of SOA and doesn’t require us to consider an overly narrow view of SOA, such as the “SOA 2.0” nonsense currently proposed by some analysts and vendors. Enterprise architecture and the Zachman Framework bring together these points of view with others to create a complete picture of the architecture moving forward.
The ZapThink Take
The Zachman Framework helps organize SOA, but Service Orientation represents an organizing principle that can help guide organizations through the labyrinth of EA as well. Zachman laid out the overall map, but didn’t provide a guide for prioritizing your route through the Framework, or a way for determining which parts of the Framework are more important to you than others. After all, companies are all different, and thus have different strengths and priorities that would affect their best approach to enterprise architecture. The iterative approach to SOA offers enterprise architects an architectural roadmap that tells them where to start, what’s important, and which way to go. Applying the Zachman Framework to SOA, therefore, can help architects develop techniques for organizing IT and people’s relationship to it so that the organization can respond to change, and leverage change for competitive advantage.