Row Two: The Business Owner's View As stated before, Row Two of the Architecture Framework is about what business owners see. These include business events and the business activities that are performed in response to them. Schedules Temporal events are caused by the passage of time. Ongoing events are the cyclical passage of the beginning of a day, the first day of a month, the first day of a year, and so on. Often activities are defined to be performed in response to these. Scheduled events occur at specified dates and times. Ongoing events may be defined as part of the normal activities of the business. Accounting is an area where these are important. The "monthly close", for example is a series of activities to be done at the end of each month, in order to account for the expenses and revenues of that month. The development of schedules, in turn , requires a structured approach to the work flow and activities of the organization. "First you . . . ", "Then you . . . ", and so on. In addition, the development of a schedule may itself be in response to temporal or other events. For example, an annual temporal event (such as "October 1") may trigger creation of the annual budget, and this can include a schedule of events for next year's sales, purchases, and production. Over the course of the budget process, budgetary requirements are analyzed and then translated into specific timed goals, targets, and constraints on departments. Once the budget and annual plan are approved, the company must then live with in the budgetary and timing constraintsunless exceptional circumstances permit otherwise . An annual plan does not necessarily specify when things are to happen during the upcoming year, but it could. Typically, it simply determines how much money is available each month. A master production schedule, on the other hand, is a very different kind of schedule. It defines specifically what to do and when. Here, the schedule puts specific constraints on what can be done in the manufacturing process. This schedule is a set of instructions as to what to buy and when, as well as what to manufacture and when. Since it has a smaller scope, it is developed much more quickly and more frequently than an annual budget. With the help of computers, its development can be an interactive process, with changes in response to circumstances being made almost continuously, with their implications being determined immediately. As an alternative, its creation may be triggered by an ongoing temporal event, say, Monday. Keep in mind that the events we discuss here are business changes. These are things that happen in the world. We are not concerned here with system events, like clicking on a mouse button. Events and States A non-temporal business event is something that happens in the world, requiring the enterprise to react . Business events might include, for example: Note that in each of these cases, there are business functions that the enterprise must perform in response to the event. When an order is received, for example, the enterprise sets out to fulfil it. When a shipment is received, it is either applied to an open order or added to inventory. When someone applies for a job, steps are taken to determine both the qualifications and appropriate opportunities for that person. When an inventory balance is recognized as incorrect, it must be checked and corrected. Moreover, steps may also be taken to prevent the error from happening again. Note that the events described in this chapter are intimately connected to the activities (described in Chapter 4) which are performed in response to them. Besides triggering activities, a business event may affect the state of one or more entity types. When a request for products is received, a Sales Order is created and put into the state "pending". When the last products are shipped, this order is changed to the state "complete". When a machine is turned on, its state goes from "off" to "standby", and then when it is put into gear, it goes from "standby" to "operational". State/Transition Diagram One way to represent the link between events and entity types (or object classes) is a state/transition diagram , a representation of the states an entity type passes through in response to events. It is described in many works, including Richard Barker's and Cliff Longman's 1992 CASE Method: Function and Process Models . The UML version of this is described in most UML texts , including the 1999 The Unified Modeling Language User Guide and Martin Fowler's 2000 version of his UML Distilled . A state/transition diagram shows the sequence of states an entity type goes through as it responds to events. Figure 7.2 shows a sample state/transition diagram. This describes the state of a PURCHASE ORDER . Here it is in terms of a Row Two (business) perspective, but more than most of the diagramming techniques presented in this book, it is also a good basis for a Row Three view as well. State/transition diagrams can represent both Row Two and Row Three events and states. Figure 7.2. A State/Transition Diagram.  The solid dots represent the initial and final states of the entity type. Once a purchase order is issued, it begins its life in the "Pending" state. Receipt of the last delivery moves it to "Complete". (Receipt of a delivery before the last one does not change the state of the purchase order.) If the order is in the state "Complete", finding something unsatisfactory causes the ordered product to be returned to the vendor. This event (and its resulting activity) then changes the status of the order back to "Pending". When the last physical asset to be returned has been returned, if it is determined that the physical asset will not be replaced , the purchase-order state is changed back to "Complete". In this particular example (and this varies from company to company), we will assume that there is a specific process for closing a purchase order, once all materials have been received (or returned). The explicit decision to close the order is required to change the state from "Complete" to "Closed". Note that while the order is still "Pending" it is possible that the material ordered is no longer needed, resulting in cancellation of the order. This determination changes the status from "Pending" to "Cancelled". | 
