Managing M x N Vs. M + N, Market-Driven Economies, and Other eCommerce Issues (Part 1)
Several organizations have recently asked us to apply our business rule methodology, BRSolutions, to the relatively new area of web content management. You might think that the problems we diagnosed were essentially new ones, and therefore that our solutions would be new ones as well. Not unreasonable -- but nonetheless dead wrong.
The first thing we discovered was a classic case of out-of-control bridges and interfaces. I say "classic" because this problem has been recognized as a fundamental problem in business information systems for at least a quarter century. (For example, it is discussed in my book Database Systems: Design, Implementation and Management, published in 1978, which was based on an even earlier series of articles.) The web environment does put a new face on the problem -- but underneath, it's the same as ever.
The basic problem is not that hard to understand. Suppose you have a large number of different data sources, and a significant number of applications that use them. Typically, these data sources and applications will have accrued one-by one in largely unplanned fashion over a number of years. I say 'years' because that is how long it used to take -- in webtime, it can now take only months or even weeks.
In such an unplanned environment, each application typically has its own interface to each data source that it uses. In the worst case, this means that if there are 'm' number of data sources, and 'n' number of applications, you must manage 'm times n' number of interfaces. As the following sample numbers suggest, this m x n total can spiral out of control very quickly as the environment grows over time!
|
|
|
|
1 |
1 |
1 |
|
2 |
3 |
6 |
|
5 |
15 |
75 |
|
10 |
25 |
250 |
|
etc. |
etc. |
etc. |
Each interface is something that must be managed. As these sample numbers suggest, the overhead associated with simply managing the interfaces can escalate rapidly. So too can the opportunities for misinterpreting and misusing the source data. Making changes in data definition also become increasingly more difficult since such changes must be propagated faithfully across the ever-growing number of interfaces. In a word, this approach simply does not scale.
This is why the business rule approach puts such an emphasis on integrating and sharing data. In the ideal case, this reduces the number of data sources to m = 1. Now, the growth factor is simply additive -- each time you add a new application, the number of interfaces is simply n + 1, rather than m x n.
Unfortunately, in the real world (yes, that includes the web), things are usually not that simple, and m cannot be reduced to the minimum m = 1. A common solution is to provide an intermediate staging area -- a database or repository into which the data from the m sources is imported and consolidated.
For m data sources, this approach means creating m "import" interfaces. An "export" interface is still also needed for each of the n applications. (Now these n "export" interfaces are from the staging area rather than from the original data sources.) Consequently, the total number of interfaces to be managed is m + n, instead of m times n. Each new data source or application means simply m + n + 1 interfaces to manage. As the following sample numbers indicate, this becomes more and more significant as the number of data sources grows. In other words, this is an approach that will scale.
|
|
|
|
|
1 |
1 |
1 |
2 |
|
2 |
3 |
6 |
5 |
|
5 |
15 |
75 |
20 |
|
10 |
25 |
250 |
35 |
|
etc. |
etc. |
etc. |
etc. |
How does this discussion apply to the web environment? Many companies are beginning to realize that they have a problem with content management. ("Content" is used here in the sense of what information web pages hold -- i.e., their content.) Often, there are a significant number of sources for this content (say "m"), and an ever-expanding number of web applications (say "n") that use it. In webtime, the 'm x n' factor can spiral out of control almost before you know it.
The remedy, of course, is to create an intermediate staging area -- something you might call a universal content repository. As before, this brings the 'm x n' interface total back to the more manageable 'm + n' case. This is an old solution applied to a "new" problem, but as they say, sometimes the more things change, the more they stay the same!
Part 2 of this two-part series will discuss how the business rule approach can be used to establish an effective environment for highly dynamic web content management.
# # #
About our Contributor:
Online Interactive Training Series
In response to a great many requests, Business Rule Solutions now offers at-a-distance learning options. No travel, no backlogs, no hassles. Same great instructors, but with schedules, content and pricing designed to meet the special needs of busy professionals.
How to Define Business Terms in Plain English: A Primer
How to Use DecisionSpeak™ and Question Charts (Q-Charts™)
Decision Tables - A Primer: How to Use TableSpeak™
Tabulation of Lists in RuleSpeak®: A Primer - Using "The Following" Clause
Business Agility Manifesto
Business Rules Manifesto
Business Motivation Model
Decision Vocabulary
[Download]
[Download]
Semantics of Business Vocabulary and Business Rules