In John Zachman's original framework there were only three columns: data, function, and location. In 1989, the elements that concerned developers were primarily data and processes, although the implications of distributed systems were significant as well, and it was clear that any requirements analysis project would have to address them. Location was easily as important as data and processes. Only later did Mr. Zachman realize that there were three other columns as well.
The problem is that location is not really another column: It is a third dimension. That is, each of the other columns has a location dimension to it. It's as though the real Architecture Framework were as shown in Figure 6.1, with “Location” as a distinct dimension. We want to know the location of the data, the location of the activities, and so on.
Thus, more than any other column, location is intimately associated with the other columns, and it cannot be examined in isolation. Indeed, its relationships with the other columns can be very complex.
The only graphic modeling technique for this column (both Rows Two and Three) is the trusty map. In the business owner's view (Row Two), one can lay out the geography of the city, state, country, or Earth, and place offices, warehouses, and plants on it.
In the architect's view (Row Three), these sites may be shown on a map as well, but the important thing is to document all the other columns for each site. This is a kind of network map, with the aesthetics left up to the mapmaker. In whatever way it is represented, though, in Row Three this network must be linked to the information in the other five columns.
Ultimately, the business owner's view of location is geographic. Where do we do business? How do we communicate among these locations? What is the business content of those communications?
Obviously, this is less of a concern if a company's entire operation is in one location, although the locations of customers and communications with them keep the issue of geography relevant.
The issue of location has become more complex since the early 1980s. Before 1980, all data processing was done in centralized locations. This was because the economics of computing were such that it was cheaper to do it all on large, central computers. In about 1980, those economics changed radically. Mini-computers and personal computers made it reasonable for divisions to have their own computing facilities. Corporate information systems management resisted this, of course, because it threatened control that it had always exercised. As it happened, corporate management lost the battle, because the new economics were too persuasive. The issue remained, however, that some information still had to be communicated to management for business purposes. Now that economics didn't place that information there in the first place, it was necessary to define the business requirement for these communications. This was a new kind of problem.
Now, with better understanding of the whole idea of system requirements and of the options for decentralization, it should be possible to conduct a more rational dialogue. Indeed, we are now in a position to ask the question previously ignored: What communications are required among offices to address the true functions of the business?
The viable system considerations from Chapter 5 are important here. In examining a company's locations, it is important to ask the question: How much System One work is being done here? System Two?—and so forth. The answers will have a profound influence on the kinds of systems and communications that should be built.
Note, by the way, the difference between the concept of “location” and that of “site”. A location (or “geographic area”) is simply a place on the earth, like Cleveland, or Death Valley. It has a boundary, defined in terms of specific points. A site (also called a facility) is a place with a purpose, such as a house, office building, factory, or ware house. One characteristic of a site, of course, is its location (although sometimes that can change), but site and location are not the same thing. (See page 119 for the data model of SITE and GEOGRAPHIC AREA.)
In requirements analysis, we are primarily concerned with sites, but in describing them, we will make generous use of our knowledge of geography.
There are many possible configurations of companies, reflecting the fact that there are many kinds of companies. Some of the general configurations of sites are:
Specific sites where the enterprise does business might include:
Offices
Kiosks
Toll booths
Archeological digs
Oil wells
There are variations on this theme, as described below, but ultimately the question of communications among sites is about the relationship of headquarters to its outlying sites. The nature of these communications can be understood in terms of Stafford Beer's viable system (described in Chapter 5). Systems Three, Four, and Five are typically in an enterprise's headquarters. They control the operational elements in the field—Systems One and Two. The operational elements deal with the outside world and respond accordingly, feeding data about their performance back to the controlling units. If the data show an aberration, then the controlling system issues instructions to correct their efforts. Communication is essential for the feedback loop to work.
If the headquarters and field offices are in the same place, this problem is nothing other than the set of management issues described in Chapter 5. If not, the communications links must be explicitly addressed in more detail.
It is important to make sure that communication between the field and headquarters contains the information (variety) necessary for headquarters to evaluate the field facilities' performance. More often than not, these are in the form of financial reports, but they may also include other kinds of performance statistics. Similarly, communications from the headquarters to the field may contain some direct instructions, but more often they consist of policies, constraints, and operating conditions. These establish what in process control are called “set points” against which the operating elements' performance will be judged.
The pre-1980 practice of also sending information to headquarters to be processed was for economic reasons (only headquarters could afford a computer) and not relevant to the viable system model.
In the specific case where manufacturing takes place in several facilities, communication among those facilities is essential. In terms of Mr. Beer's viable system, this is largely the province of System Two—coordinating the flow of resources to various places—but System Three comes into play as well, in that communications are required for the overall management of the operation.
System Two's role in production is to make sure that each production step is aware of the production demands from the next operation upstream, and that its requirements in turn are properly communicated downstream. At the sales point, there are forecasts of expected sales, which are translated into production requirements for the finished products. These in turn must be translated into demand for the first level of subassemblies. These then are translated into requirements that generate demand for the next level of subassemblies, and so forth. Where it is done well, this entire calculation typically is performed in a central materials management site, and the resulting production schedules are then communicated to the sites involved. This permits balanced use of inventory. The calculation is the same whether the production is all in one building or worldwide. Components that are in multiple sites, however, raise implications for the communication networks that will be required.
For example, one pharmaceutical company had five major plants producing bulk pharmaceuticals and 26 plants packaging finished products—scattered all over the world. The logistics of bulk supply had to be managed centrally, with the instructions transmitted to all sites.
The System Three requirement is about management's making a set of plants more productive by examining the way each plant is working and then recommending changes in appropriate policies, constraints, or operating principles.
For example, a special case of a production network is an oil field. Numerous wells are scattered over the landscape, with both primitive and sophisticated means for monitoring them. Specifically, instruments may be attached to wells that are connected electronically to a central controlling computer, or alternatively, a worker may simply visit each well in his pickup truck and make observations. Either way, the data must be brought to the field office and analyzed, with proper steps then being taken to respond to circumstances.
Requirements for communication among nodes of a product distribution network are similar to those for a production network. Again, System Two makes sure that supply and demand are coordinated, while System Three ensures that the inventory of the set is optimal, even if this means that the inventory in one site may not be.
In one pharmaceutical company, new compounds are identified and research is planned at corporate headquarters in the American Midwest. The actual research, however, is conducted via clinical trials held at subsidiaries all over the world. This, of course, means extensive communication of research protocols (instructions as to how to carry out the research) to the field. Data are collected at each site, and initial reviews of the data are conducted there. Some research is conducted centrally, as well, with data that are collected and reviewed there. From the outset headquarters wants to be able to see the data for preliminary analysis, but the volume required is such that the data don't have to reside there. At a specific point in the process, however, use of the data in the field diminishes, and serious analysis begins at headquarters. Remote sites still have access to the data, so that they can respond when questions arise.
When a project was defined to address these requirements in the late 1980s, the economics of database management systems at the time suggested that the data be captured in the field with remote access to them being available from headquarters. Then, for the second part of a study, the data were physically moved to headquarters, with remote access then being provided to field sites. The economics could change in the future, requiring changes to the physical architecture of the system. The requirements for access would not change, however.
It is common for an enterprise to have to keep track of its customer locations. Maps are a useful mechanism for this. A company may be concerned with locations outside its operational offices. For example, an automobile insurer must keep track of the locations where accidents happen. This might mean recording accidents on a map. The Los Angeles Film Board, as another example, issues permits to production companies, allowing them to make movies, commercials, and the like on the streets of Los Angeles. This requires extensive mapping facilities to define the exact territory for each permit.
All of these examples show that the set of sites where the enterprise operates is significant in defining the nature of that operation. The last pair of examples, by the way, shows that site may be an issue not only for placement of future systems, but also for the content of these systems.
The business owner's view of facilities is concerned simply with what operations are where. The architect's view, however, is concerned with the relationship between sites and each of the other columns. It is not very meaningful, in an architectural sense, to say simply, “Where are we located?” The questions are, “Where do we perform various functions?” “Where do people work?” “Where are the data?”—and so forth.
There have always been two issues when one sets out to build a distributed database: Where should the data reside? Where are they to be used? This is one case, however, where technology is rapidly rendering these questions less important.
In recent years, database management systems have made it possible to define distributed databases such that the person making an inquiry need not know anything about where the data are stored. The system simply goes to get the results of the inquiry, wherever they might be. There are, of course, performance considerations when the bulk of data most people require is from distant sites, but as communications speeds increase, these are also becoming less important. During requirements analysis, however, it behooves the analyst to estimate the volume of communications that may be required between each pair of sites.
Also, previously it was important to know where users were, so facilities could be provided to allow them to access data. If a new system is to be implemented using client/server technology, this is still important. If the World Wide Web is to be used, however, all potential users already have the required tools on their desktops, so nothing need be done but to design and implement web sites that are, upon completion, accessible worldwide.
Examining the function hierarchy or the essential data flow diagrams from Chapter 4, we can look at each function and ask, “Where does it take place?” This is especially significant if our model is a variation on a data flow diagram, where the processes communicate with each other. Two processes that must communicate between different facilities have profound implications on the kinds of systems that can be built to support them.
Each activity diagram (in whatever form), should be annotated as to the location or site where the activity takes place. Grouping activities by site is a useful way to understand the geographic architecture of any prospective system. The swim lanes in a process model or a UML activity diagram, for example, could be used to represent either sites or geographic locations.
Where people are significantly influences the way Systems One through Five described in Chapter 5 work. Each person is in a particular location, and the roles each plays may be for different locations. It is incumbent on management of an organization to place the people who must communicate most extensively in the same location. The extent to which they are in disparate places will affect the quality and nature of the communications channels that can and must be built among them.
An important aspect of defining essential activities, as described in Chapters 4 and 7, is the definition of “external event”. If an entire enterprise is in one facility, this is clearly an event from the world outside the enterprise. The whole process of developing an essential data flow diagram presupposes that internal events—where one activity triggers another activity—are not included. On the other hand, if one activity is in Cleveland and it triggers an activity in Los Angeles, it is hard for the folks in Los Angeles not to consider this an “external” event. None of the data flow diagramming techniques (including IDEF0 and use cases) provides a very good way of dealing with this.
Ultimately, this means that business decisions about what should happen where are significant to the overall efficiency of an organization. It would have been nice, when such decisions were made, if the company looked at events and the activities required to respond to them and then placed all the activities responding to one business event in the same place.
This may not have happened. If it did not, the event of communications between plants must be taken into account during the requirements analysis project, and the activity models must reflect this, even if the results are not tidy. What otherwise would have been a single essential activity may have to be broken into two—one for the part that takes place at each facility.
Ideally, a single set of business rules applies to the entire enterprise. In reality, however, it may be necessary to vary the rules by facility. Different locations may be run differently, may have different customs, or may be subject to different laws. For example, different offices of a car rental agency may have different rules for late return of a car, depending on when they are open. Office hours might be different in different sites, and different legal systems may apply.
The Row Two deliverable could be as simple as a map showing the enterprise's various locations, with different icons showing the kinds of facilities in each.
Ultimately, however, the analysis project should deliver a location dimension for all its other deliverables:
For each entity, where are the data collected, and where are they used?
For each activity, where is it performed?
What is the volume of data to be communicated from one location to another?
For each organization, where is it located, and with what other organizations in what other sites does it interact?
For each event, where does it take place, and what is the location of each response to that event?
For each business rule or business policy, which sites are affected?