Row ThreeNetwork (and the Other Columns)

Team-Fly    

 
Requirements Analysis: From Business Views to Architecture
By David C. Hay
Table of Contents
Chapter 6.  Column Three: Locations


Row ThreeNetwork (and the Other Columns )

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.

Column One: Where Are Data Created? Where Are They Used?

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.

Column Two: Which Functions Are Where?

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.

Column Four: Which Roles Are Where?

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.

Column Five: What Events Are Where?

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 eventswhere one activity triggers another activityare 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 twoone for the part that takes place at each facility.

Column Six: Which Business Rules Are Where?

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.


Team-Fly    
Top
 


Requirements Analysis. From Business Views to Architecture
Requirements Analysis: From Business Views to Architecture
ISBN: 0132762005
EAN: 2147483647
Year: 2001
Pages: 129
Authors: David C. Hay

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net