3e. Establish credibility by offering outbound links. Challenges + Answers-- Web Writing that Works

For many years our programming tools have limited our understanding of the business. Starting with COBOL, and continuing to the present, we have conceived of data as resting like raw materials on shelf after shelf of some industrial warehouse, until ready to be worked over by applications, which act somewhat like factories, bringing the data in, manipulating it, and then placing the finished data back on the right shelves. With this model—all that we could imagine, given our languages, back in the early 1960’s—we have spent decades decomposing the data into smaller and smaller pieces, each group in its own little database, with its own application. But the business doesn’t run that way. Now we can model the real business of the organization. Because we have object-oriented languages, we can begin to see that our business model needs to change, and can change. The first step in that direction is to develop business rules that reflect the way the business actually runs—who does what, with what objects—postponing any concerns about implementation. We need to be able to describe the business the way our users see it. And, because the process itself is likely to change during business process reengineering, we also need to distinguish between the purpose of an activity (what it does) and the current process (how it’s done), as pointed out by Dijkstra.

Quotes from pages you could link to, at other sites, if you rewrite the original passage. (To form a link here, just put the number of the site in brackets in your text).

1) On the separation between "what it does" and "how it works."

It is apparently essential for each level to make a clear separation between "what it does" and "how it works."—E.W. Dijkstra, The Structure of the THE Multiprogramming System, Communications of the ACM, Vol. 11, No. 5, 1968.

2) On modeling the real business of the organization, rather than the computer’s architecture.

Only in the last few years have business people experienced the insight of working with analysts who model the real business of the business … . From the get-go, many of us were taught to conform the business to computer-based models … . We learned that applications controlled the data—so today businesses are spending billions of dollars trying to reassemble into shared structures the very business data that we spent several decades decomposing into separate and disjoint islands.

—Robert Shelton, From the Editor, Hotline on Object-Oriented Technology, November 1992.

3) On specifying the business rules independent of their implementation in a computer system.

By specifying the business rules independent of their implementation in a computer system, the information model preserves the "business of the business," that is, it does not hide or distort the properties of the enterprise that are of interest to the user.

—Haim Kilov and James Ross, Information Modeling: An Object-Oriented Approach, PTR Prentice-Hall, 1994.

Answer

For many years our programming tools have limited our understanding of the business.

Starting with COBOL, and continuing to the present, we have conceived of data as resting like raw materials on shelf after shelf of some industrial warehouse, until ready to be worked over by applications, which act somewhat like factories, bringing the data in, manipulating it, and then placing the finished data back on the right shelves.

With this model—all that we could imagine, given our languages, back in the early 1960’s—we have spent decades decomposing the data into smaller and smaller pieces, each group in its own little database, with its own application.

But the business doesn’t run that way.

Now we can model the real business of the organization(2). Because we have object-oriented languages, we can begin to see that our business model needs to change, and can change.

The first step in that direction is to develop business rules that reflect the way the business actually runs—who does what, with what objects—postponing any concerns about implementation (3).

We need to be able to describe the business the way our users see it.

And, because the process itself is likely to change during business process reengineering, we also need to distinguish between the purpose of an activity (what it does) and the current process (how it’s done), as pointed out by Dijkstra(1).