Blog: Dan E. Linstedt

« May 2008 | Main | July 2008 »

June 30, 2008

Design: Subject Oriented Versus Function Oriented

For a long time Dr Ralph Kimball has spoken about subject oriented design. Many have made a living off of producing subject based data marts. One of the problems this has lead to is a series of loosely coupled stove-piped answer sets that are then "discussed" in the light of an enterprise data warehouse. I've been teaching, talking and writing about (over the last 10 years at least) a notion called Functionally Oriented Design. In this entry I will briefly introduce my notions of these concepts.

When we examine subject oriented design patterns we discover that the true nature of this design is to meet the needs of a specific group of people, furthermore - performing a very specific task or attempting to answer a highly specified business question. In fact when we do additional research around "subject-oriented design" we find a number of interesting facts:

"Feature-based
Decompose problem vertically into separate features, perhaps with a distinguished base feature containing common functionality; design and implement each of these features separately; then compose feature implementations to produce a complete system."
"Staged
Define the problem and design the system. Then decompose the design horizontally into implementation stage’s each of which extends its predecessor. Implement these stages successively, extending system through composition. "
http://www.research.ibm.com/sop/papers/position96.htm

What does this mean?
Well, if it's used as a design paradigm for an enterprise - this usually means that the enterprise should be broken in to lines of business, and then further broken in to specific feature-based activities. I can easily see where we would get our notions of facts for a specific feature set, that is: facts at a specific grain, designed to answer a very specific set of questions.

What about the staging or re-composition?
Interestingly enough this is what conformed dimensions attempt to do, along with Junk and Helper tables... Once decomposed, then the next step is to "stage" the problem - horizontally along the implementation to extend it's predecessor. This might be related to additional aggregate fact tables, and even more conformed dimensions _at a different grain_. However this usually doesn't extend itself beyond a single line of business. Which is why, when we examine Dr Kimball's enterprise Service Bus, a line has been drawn around the loosely coupled subject oriented data marts and "assigned the term" of data warehouse.

The image seen here, is one representation of many that Dr Kimball has subscribed to over the years. http://www.dwmantra.com/concept_index.html

As Bill Inmon states: "A school of minnows (swimming in close proximity) doesn't equal a whale." At the same time, the original definition of data warehousing includes "subject-oriented" in it's purpose.

Lately (for the past 15 years or so) I've been experimenting with Functionally Oriented Designs. Why? Because the business process is very important to the enterprise data warehouses that I've been building.

The nature of functional design is to couple form and function together to solve a problem. In this case, the form is the data model, and the function is the business process. By doing so, we solve different types of problems for the enterprise data warehouse. Don't get me wrong, I believe in Star Schemas for end-user access, cleansed and organized data, but I do _not_ subscribe to their use as an enterprise data warehouse. More on that later.

Functionally Oriented Design has taught me that it is possible to build a system based on business rules and to maintain it as quickly and easily as the business changes. More to the point, if we design our enterprise data warehouse properly, we can actually store the history of _some_ of the business rule changes within the structure of the enterprise warehouse as well. Thereby opening up new territory for "comparative design analytics" in review of "what have we changed business wise, and was it a good decision..."

Functionally oriented design is focused on the business process, and therefore the business keys that drive through the business processes. Because of this notion, the design actually runs horizontally (instead of vertically by line of business) across the entire enterprise. The design focuses on tracking and tracing all information by business key from the time it first enters the business to the time of delivery of the goods or services.

The Data Vault modeling paradigm is based on functionally oriented design views, we'll discuss more in the next entry. For now, if you have a different view on Subject Oriented Design I'd love to hear it.

Thanks,
Dan Linstedt

Share: