Oracle should teach Siebel CRM about location and money

Not long ago I posted on the need to understand common concepts well. My example then concerned the need to understand time well enough to answer a question like, “How much did IBM’s earnings increase last quarter?”. Recently, in contemplating some training issues related to the integration of Haley Authority within Siebel, I came across examples phrasings from the documentation on Siebel’s web site, including:

  • if an account’s location contains “CA” then add 50000 in “USD” for the account
  • if an account’s location contains “CA” then add 70000 in “USD” on today for the account

Two things are immediately obvious.

  1. Oracle does not understand location.
  2. Oracle has an interesting, but nonetheless poor understanding of money.

Of course, I am intimately familiar with Authority’s understanding of money. However, Siebel needs more than Authority understands.

Location

Since I am most interested in money here, let me dismiss location for the time being. Oracle is treating location as a string. For example, consider the following additional example from their web site:

  • if an account’s location contains “Germany” then add 700000 in “DEM” on 2006/03/01 for the account

These examples mean (and should be understood as!):

  1. if an account’s location is in CA…
  2. if an account’s location is in California…
  3. if an account’s location is in Germany…

To understand this, an ontology of place would be required. Unfortunately, Haley does not ship one with Authority! This ontology should cover the following:

  • a place may be within another place
  • an address indicates a place that is located within a nation
  • The United States and Germany are nations.
  • an address in the United States indicates a place in a state
  • California is a state in the United States
  • CA is an abbreviation for California

Given this, I would prefer to express the prior 3 sentences as:

  1. if an account is located within California…
  2. if an account is located within Germany…

But it would be even more practical if Oracle (not Haley) defined:

  • an account that is located within a place is in that place

In which case, Siebel users could simply say:

  1. if an account in California…
  2. if an account in Germany…

Unfortunately, Siebel users need to say silly things like this suggestion:

  • if an account’s location contains “US” then set “Description” of the account to “This account is in the US”

We can cure these ills for Siebel customers, but that is not the point of this article.

Currencies

Let’s look at a few references to money from Oracle:

  • if … then add 50000 in “USD” for the account
  • if … then add 70000 in “USD” on today for the account
  • if … then add 700000 in “DEM” on 2006/03/01 for the account

What’s going on here?

First, it bothers me that there is not a comma in numbers like “50000” or “70000”. Second, it bothers me that there are quote signs around USD. Why are these needed?

Haley and Oracle should get this straight! It should look more like:

  • if … then add 50,000 USD for the account
  • if … then add 70,000 USD on today for the account
  • if … then add 70,000 DEM on 2006/03/01 for the account

Or, perhaps if the locale is the United States the first could be rendered or entered as:

  • if … then add $50,000 for the account

The fact that currencies are enclosed in quotes indicates that Haley and Siebel are treating them as strings (see “Germany” and the use of the verb ‘contains’ above). This makes the resulting rules brittle. What happens if the string is not a valid 3-letter ISO 4217 currency code? Does it have to be? Will “DM” work as it typically does in text?

Amounts of money

Authority has built in concepts for amounts. An amount is a quantity that can be measured. More technically, an amount is always an amount of some stuff. Stuff, of course, is a mass noun. Stuff cannot be counted. It can only be measured. Measuring involves units (see the sections on partitives and counting here).

Authority has a built-in ontology covering 6 out of 7 base units in the International System of Units, including time, distance, mass (slightly confused with weight), temperature, luminosity, and charge or current.. Most of the physical world can then be understood in terms of these units, including speed, momentum, energy, power, area, volume, etc. And Authority understands that units that measure the same kind of stuff can be related to one another by precise or approximate fractions or decimal numbers.

In addition to physical units of measure, Authority’s ontology of amounts includes money. Money does not measure any physical quantity. Perhaps money can measure quality, but more precisely, money measures value as perceived by parties to a transaction at the time of the transaction.

An amount of money is typically measured using a currency, such as the United States Dollar. Authority understands that the same amount of money may also be measured using a second currency, such as the Deutsche Mark. But Authority has an inadequate understanding of how many DM there are in a US$ and vice-versa.

Exchange Rates

An application that supports multiple currencies has to choose between:

  1. representing every amount of money in the same currency
  2. representing every amount of money as two values, the number and the currency

At any instant in time, ignoring transaction costs, any amount of one currency can be converted into another currency, perhaps by some theoretically derivable ratio. Underlying assumptions, including predictable and negligible transaction costs, liquid markets, and solvent governments all come into play, however. For these and other practical reasons, most multi-currency systems provide for some or all amounts of money to be stored in two parts.

This explains the currency in the following, but why the date?

  • if … then add 70000 in “USD” on today for the account
  • if … then add 700000 in “DEM” on 2006/03/01 for the account

Whew! Those quotes are annoying (and I don’t like the “in”, either).

Exchange markets

The fact is that $1 US buys a different number of € (Euro) than it did a year ago. Exchange rates change over time (generally speaking). So if you are holding dollars in New York and want Euros in Paris, how many you land up with will depend on when you perform the exchange.

An amount of money measured in one currency cannot be converted into the same amount of money measured in another currency without knowing the exchange rate.

Siebel handles this by storing each amount of money with not only as measured by a specific currency but also as of a date. Then, to convert any amount of money into any currency, use the exchange rates (and transaction costs, if appropriate) as of that date.

Now it turns out that Siebel makes this requirement ubiquitously, which means that the following are entirely equivalent:

  • if … then add $70,000 US for the account
  • if … then add 70,000 USD on today for the account

Notice that I’ve fixed the comma and dropped the “in” and the quotes, but I am still wondering what “add an amount of money for an account” means.

Arithmetic with units

Presumably, these nonsense sentences from Siebel are intended only to demonstrate the functionality we are discussing here:

  • If 100 in “USD” plus 100 in “KRW” is more than 200 in “USD” then …

Rather than simply compare

  • if $1 US is more than 1 KRW then…

but this would not have demonstrate that addition and subtraction of amounts works when using different units, provided that they agree (i.e., that the measure the same kind of stuff).

The following nonsensical examples from Siebel demonstrate how multiplication and division preserve or eliminate units:

  • If 100000 in “USD” times 12 is less than an account’s annual revenue then…
  • If 1000000 in “USD” minus an account’s annual revenue is less than 0 in “USD” then …
  • If an account’s annual revenue divided by 1000000 in “USD” is more than 1 then …

Although these might be better if Authority could handle “$100k US” and reduce “less than” or “more than” to “<” or “>”, respectively.

Inflation and Real Money

Sentences like the following demonstrate that Siebel not only handles currency exchange rates over time but that it also considers inflation and real value of a currency over time.

  • if 100 in “USD” on 2005/03/01 divided by 100 in “USD” on 2006/03/01 is more than 1 then …
  • If 100 in “USD” on today minus 100 in “USD” on yesterday is equal to 0 in “USD” then …

This is great stuff and puts Siebel far ahead of Authority and any other BRMS with regard to a practical consideration of money for financial applications.

Regrettably, Siebel did not extend Authority as necessary to make this convenient and as intelligent as many in financial services would appreciate.

For example, I would prefer that the preceding could be stated:

  • if the USD inflated in the year ending March 1st, 2006 then…
  • if the USD has been flat since yesterday then…

but Siebel’s examples do not motivate an understanding of inflation directly. Better examples might be:

  • o if the USD has inflated by more than 1% over the last quarter
  • o when the 7 day moving average of the USD versus the Euro turns positive …

Regrettably, Siebel and Haley have not modeled exchange rates or inflation directly. In effect, it is up to rule authors to understand the implementation under Siebel’s hood.

We work on such ontologies and linguistics in order to make the resulting policies more human and less programmatic. Perhaps Siebel and Haley will get around to it.

Ontological wrap-up

BRMS users and vendors should take lessons from the Siebel phrasings and contemplate the ontologies they need to incorporate in order to make it easy for users to articulate policies and manage business processes, especially where time, addresses or money is involved.

We have previously discussed the need for a strong ontology of time in many if not most applications. The same is true of location, including addresses and geography (e.g., countries, states, territories, or provinces, counties, etc.). Many applications are also concerned with jurisdiction, which meshes with geography into geopolitics, currencies, exchange rates, and more. But most enterprise applications that involve finance need to be concerned with amounts of money, currencies, exchange rates and inflation.

Unfortunately for BRMS customers, these ontologies are not provided by vendors or understood in their authoring metaphors.

One Reply to “Oracle should teach Siebel CRM about location and money”

Comments are closed.