|
David C. Hay |
|
The book Data Model Patterns: Conventions of Thought presents a set of standard data models describing standard business situations. These model "patterns" can be used in a variety of businesses in a large number of industries, for the simple reason that all businesses are in fact structured in very similar ways. The personnel function, accounting, and order processing are similar, regardless of who is doing them. For this reason, it is possible to develop a generic pattern and then apply it to many companies.
For example, Figure 1 shows a model of an order. Any sales or purchase order for any company must look like this. Note that instead of entities for "customer" or "vendor", you have here party. A party is simply any person or organization that is of interest to the enterprise. Here each is playing the role of customer or vendor. Specifically, "each party may be a buyer in one or more orders," and "each party may be a seller in one or more orders." If the seller is one of our own departments, the order is (to us) a sales order. If the buyer is one of our own departments, it is (also to us) a purchase order.
The model also shows that each order must be composed of one or more line items, where each line item must be for the purchase of one and only one commodity type.
Rapid Applications Development (known these days as "RAD") is a wish. The applications development process is composed of so many steps that we want to believe that some are unnecessary. If we could limit ourselves to doing just the necessary ones, perhaps we could significantly cut the amount of time to develop systems.
To be sure, many tools have been developed recently to speed up the process. In addition to CASE tools for strategic planning and analysis, there are tools which allow program code to be produced so quickly that if the result isn’t quite what was desired, it can be redone equally quickly.
This latter development has encouraged developers to think that perhaps the time spent planning and designing systems could be short-circuited and all we would have to do is a series of pilot developments and corrections. A system would be built by evolution, rather than design. This also has the advantage of involving the user in the process in a direct and tangible way.
For a relatively simple system, this approach can work. Indeed, for creating something as complex as a human being, evolution by natural selection can work – if you have billions of years available. For the average industrial strength application, however, skipping analysis and design will have the effect of lengthening the overall time to produce a viable system rather than shortening it.
All right, then, what can we do to shorten the time required to build a system? If we cannot eliminate strategy, analysis and design, can we at least reduce the length of time they require? The answer is yes – at least in some kinds of situations.
The time required to develop a set of strategic data models in an organization can be saved by using standard models at a high level. It is still useful to interview the main players to determine priorities, objectives, and constraints, and it is also a good idea to feed the models back to these people to ensure that they understand and agree to the general concepts. But if you don’t have to build the models from scratch and (if there are no unusual circumstances) you might be able to outline of a strategic study in less than a month. You may even be able to establish a framework for the analysis project in less than a week.
When doing detailed analysis, using the standard models as a starting point will save many weeks of modeling effort. Using these models is also protection if a strategy study was not done. If you are addressing order processing without addressing manufacturing, for example, it is comforting to know that the standard order processing model is basically compatible with standard manufacturing environments.
As for the analysis itself, the standard models are sufficient that you could begin the project with a feedback session, although a few key interviews up front are useful for establishing the basic parameters of the operation and its interests.
These models are not inviolate. From the feedback session and the follow-up interviews, lots of variations may be called for. Figure 2, for example, shows an elaboration on the model for a particular client.
This is an international client, so the first change was to recognize that each order must be in terms of one and only one currency. Then it turns out that this company hedges currency, since the product may be delivered and paid for many months in the future. A kind of order then, may be a currency hedge which is for the purchase of, not a commodity type, but a currency at a future date. Thus a currency hedge (order) may be in terms of Bahraini Dinars, for the purchase of Japanese Yen in four months.
Note that the basic structure survived, but with a twist. Similarly, a material hedge may be added, which is the purchase of raw materials at a guaranteed price at some point in the future.
A more esoteric variation is for a letter of credit or some other kind of bank guarantee. (See Figure 3.) While this is an exotic extension, even this has the same structure as the sales order whose payment is being guaranteed. Indeed one of the application constraints is to guarantee that (since each letter of credit must be to guarantee one and only one sales order) the terms and attributes of the letter of credit are identical to those of the order.
Note that, by starting with a standard model, the discussion immediately focuses on that which is unique to the organization. It is not necessary to reinvent the models from scratch. Moreover, even when dealing with ostensibly new things, it is often possible to take standard structures and extend them to cover them.
The time required to produce a function model can also be reduced, if you recognize that the structure of many functions reflects the structure of the data. There are two kinds of functions: data maintenance and constraints. The data maintenance functions, implemented by data entry and retrieval modules, reflect the structure of the data base. Standardization of data structures can, to a large extent, have the effect of standardizing these functions.
Constraints, reflecting business rules, will have to be implemented by modules attached to the database or to the data entry structures. It remains to be seen whether there exist anything like "constraint patterns." There may be such patterns, but they remain to be discovered. There is nothing in the nature of data model patterns themselves that can make dealing with and implementing constraints any easier. But there is nothing else in RAD to do so either.
Every project is different, and it is impossible to say definitively how much time can be saved by using patterns, but based on the author’s experience, it is not unreasonable to expect that strategy studies, the modeling for which could take three to four months, could be done in a month or less. Similarly, analysis projects, which would otherwise be of the magnitude of four to six months could be reduced to one to two months.
The time for design is not shortened by the use of patterns, although CASE tools are effective at quickly translating models to designs. In fact, after the initial prototype, design could be lengthened as designers make decisions to convert generic entities to more concrete tables. (The order entity, for example, becomes separate PURCHASE ORDERS and SALES ORDERS tables.)
So, if you want to develop systems rapidly, don’t leave important steps out. Just do them faster. RAD at the expense of thoughtful design is a bad bargain.