1.17. Piccadilly’s New Environment

“As you know,” Stamford explains, “our main reason for having a new computer system is to maximize our revenue from selling airtime. We want to make it easier for our sales executives to develop campaigns that suit the agencies’ requirements. The current system uses manual modeling, which makes it very difficult for the executives to consider all the implications when they select spots for a campaign. We want to replace the old breakchart with a central computer system so that the executives can have on-line links. This way, they can look at all the available time and model their advertising campaigns before making suggestions to the agency.

“The Commercial Booking Department will also need to be on-line so that the people can add new breaks and programmes to the computerized breakchart. We hope you can also provide the Research Department with some facilities for modeling their predicted ratings. It’s a very time-intensive task at the moment, and the predictions are not as accurate as they could be.

“We have decided that the Programme Transmission Department will not be linked to the central computer. Instead, the Commercial Booking and Research departments will continue to communicate with the Programme Transmission Department by phone, at meetings, and with printed reports. We’ll be installing fax machines, so that every evening, Commercial Booking will fax the next day’s break transmission schedule to Programme Transmission. This is an improvement on the method that we currently use.

“Every day, the Programme Transmission Department will fax the transmission log to the new Accounting Department. Accounting will be responsible for entering the actual transmission times into the computer system. Also, all the invoices will be printed in the Accounting Department, and the people there can take care of sending them to the agencies every day.

“Piccadilly management would like the new system to provide an up-to-the-minute analysis of our airtime sales. This will replace the weekly revenue report that is produced by the current computer system. However, the managers still want to retain some of their weekly summary reports. Management will also continue to have daily sales target meetings with the sales executives.

“Here’s a guide to the number of workstations we think is appropriate for each department or area:

“Most important of all, we must be sure that all of the essential requirements are implemented exactly as you have specified them. We’re looking forward to hearing your ideas for the implementation.”

• Build a system environment model of the part of the organization affected by the new system.

• For each event,

Design the external and internal views.

Annotate the event-response models with the design decisions about how the essential processes and data are allocated to processors and data carriers.

Summarize the design decisions on the implementation model.

The first step in applying the design strategy to Piccadilly is building a system environment model to define the technology available for the new system.

The next step is to identify all the processors that will be available to implement the requirements. The interview with Stamford Brook mentions a central computer and a total of 34 workstations at various locations. This is a fairly high-level model of the system, so you can treat each of the locations as a processor. Figure 1.17.1 shows the known terminators and processors.

Figure 1.17.1: The first step in building the system environment model is to identify the processors that will carry out the essential requirements. The terminators are other systems that will communicate with the system.

Having identified the processors, you need to consider how they will communicate with each other and with the other systems outside the context of your study (the terminators). For each of the terminators in the system environment model, consider what technology is both available and appropriate to carry data between the terminator and the processors inside your system. For instance, what technology is available to carry data between Piccadilly’s Programme Transmission Department and the programme suppliers? If the answer is phone and mail, then add these two data carriers to your system environment model.

You also must consider whether the system has an existing arrangement about technology to communicate data to and from a terminator. (The current physical model will be very helpful here.) For example, Piccadilly expects to receive commercials from the production companies on automatic cassette recordings (ACRs). While there are other technologies available for commercial recordings, this is the one used by the network of independent television stations. There does not appear to be a case for changing it, so ACRs and an accompanying letter can be added to the system environment model.

You also know that the Piccadilly management terminator will have two workstations installed. So there will be an interactive dialogue flow between management and the central computer. Also, since management wants weekly summary reports, there will be a one-way reports flow to the management terminator. Another less obvious technological flow is the daily meeting between management and the Sales Department. If you view a meeting as a way of transferring data, it is just as much a part of the system’s technology as an interactive dialogue that is implemented on a computer.

A guide for naming the data carrier flows on the system environment model is to use the method of carrying the data. For example, PHONE, MAIL, and INTERACTIVE DIALOGUE are all reasonable names. Sometimes, adding the expected frequency makes the system environment model more specific to a particular environment. A REPORT PM FAX flow between the Commercial Booking Department and the Programme Transmission Department emphasizes that there will be a fax transmission each afternoon.

The objective is to allocate each of the fragments of processing and data to the processors and data carriers on the system environment model. You allocate by first looking at the event-response from an external, or user-oriented, view. However, the users’ vision of how the event-response should behave might not be possible with the allocated computer technology. Therefore, before the allocation is final, you must take an internal, or developer-oriented, view of the event-response.

Let’s see how this works using event 1 Agency wants to run a campaign as an example. Figure 1.17.3 shows the response to this event.

Figure 1.17.2: The system environment model augmented by the data carriers. It summarizes the proposed technology that is available for the implementation of the Piccadilly system.

Figure 1.17.3: The essential event-response process model for event 1 Agency wants to run a campaign. The essential requirements must be fitted into the environment as specified by the system environment model.

There are three components of the event-response model that must be allocated to the processors and data carriers in the model:

• the essential data stores

• the essential data flows

• the essential processing policy

We will organize the allocation around these components.

Before finalizing our choice for the essential data stores, we need to consider both the external and internal views. The solution shown in Figure 1.17.4 satisfies Stamford Brook’s external view of the data storage. He wants the executives to use centralized breakchart information. However, consider the internal view of this allocation. Does the data storage facility have the capacity to store the expected volume of data? Can the database management system provide a suitable response time for Stamford and the executives? Is it feasible to provide the requested kind of modeling facilities on a centralized basis?

Figure 1.17.4: A boundary line drawn to indicate that all of the essential data stores for this event have been allocated to the central computer.

Naturally, at any stage of the allocation, if you find for some reason that the internal view of the system will not support the external view, you will need to renegotiate the allocation.

• Which processor or terminator produces the data?

• Which processor or terminator receives the data?

• How are the data carried?

Let’s say that the data flow SUGGESTED CAMPAIGN is produced by the Sales Department, and is received by the advertising agencies. The system environment model (Figure 1.17.2) shows that a mail, phone, or fax data carrier is available. So we can have a SUGGESTED CAMPAIGN PHONE/MAIL data carrier. It isn’t necessary to spend any time worrying about the internal and external views for this flow. The data content of SUGGESTED CAMPAIGN is defined in the data dictionary, and the telephone and mail services are well established and well understood by the people involved. This would not be the case if we had chosen, say, a microwave link via satellite.

CAMPAIGN REQUIREMENTS is another data flow in our event-response model. Let’s say that the advertising agencies send this flow to the Sales Department by mail or telephone. However, the flow does not stop in the Sales Department. Knowing the sales executive wants to model the campaign using the central computer, you must provide a data carrier to carry CAMPAIGN REQUIREMENTS from Sales into the computer system. Because the sales executives want on-line workstations, you need a CAMPAIGN REQUIREMENTS DIALOGUE to record the campaign requirements in the central computer. This data carrier is capable of fragmenting data and hence supporting more varied behavior patterns than phones and the mail. Now you will have to spend some time working on the internal and external behavior of this data flow.

The users (that is, the sales executives) probably have expectations and questions about how the dialogue should work. For example, “Will there be a menu for choosing the campaign requirements screen? Will it matter if we enter the product name or agency name first? Will there be a screen that links to other campaigns being run by this agency? What other historical information is useful to the executives entering the campaign requirements?”

You can model the external behavior, including the displayed data, using either transaction synchronization models developed on paper, or prototypes built with an automated prototyping tool, or both. As a starting point you can build a transaction synchronization model, to plan the communication between the sales executives and the system while the campaign requirements are being entered. Campaign requirements is one of the most vital interfaces in the system so you can bring it to life even more effectively by using your transaction synchronization model as the input to building a working model or prototype. Your aim, whatever approach you use, is to simulate the interface with the users so that they can agree on the interface behavior before the system is implemented.

Once the external behavior of the data flow is established, you should examine the internal technology of the central computer and the workstation to verify the users’ expectations can be met.

At the center of Figure 1.17.5, you can see that the essential processes and the data flows between them are not yet allocated. That is our next task.

Figure 1.17.5: The event-response model after allocating the essential data stores to the central computer and the essential data flows to data carriers. Some interfaces between the Sales Department and the central computer are also identified.

Figure 1.17.6: Every component of the essential event-response model has been allocated to the appropriate processor, and each of the interprocessor data carriers has been defined.

All of the processes SELECT SUITABLE TIME and PRICE THE TIME have been allocated to the central computer. However, the boundary through CREATE SUGGESTED CAMPAIGN indicates that some of the policy is allocated to the Sales Department and some to the central computer. The mini specification for this process says that the selection of suitable time depends on the experience of the sales executive. In other words, some of the policy is subjective and is not feasible to be automated.

The CAMPAIGN MODELING DIALOGUE between the Sales Department and the central computer indicates that the sales executive will be able to interactively model a campaign before suggesting it to the agency. In this case, you build a model that synchronizes the system’s pattern of behavior during the time that the CREATE SUGGESTED CAMPAIGN processing is active. Call this behavioral model CAMPAIGN REQUIREMENT AND CAMPAIGN MODELING DIALOGUE. Such a model provides a cross-reference between the allocated event-response model and the behavioral model. Chapter 2.14 New Physical Viewpoint discusses a variety of behavioral modeling techniques.

So far, we’ve talked about just one event-response. Naturally, you will follow the same procedure for each of the events in the system, though it gets easier as you go on. Some events will be so alike that one allocation can serve as a pattern for others. Similarly, once the internal view of some interfaces is designed, you can use the same design for other events.

Figure 1.17.7: The beginning of the implementation model for the Piccadilly system. The design decisions for event 1 Agency wants to run a campaign have been added to this model.

The implementation model is a project management tool that summarizes your design decisions. (The design details are contained in the collection of allocated event-response models.) The model can be used to coordinate the work of people concerned with the internal design.