Birkdale Computing

This is the third in a series of posts about how to identify entities in data sources that can readily be classified as belonging to each of the 6BI Business Object Categories (BOCs): Parties, Things, Activities, Events, Locations and Motivators.  The second post in the series (on Things, the “What” aspect) can be found at https://birkdalecomputing.com/2017/05/04/identifying-things/ .

The Activities BOC identifies How things get produced and consumed by parties. Concepts and objects in this BOC capture data about the means by which products or payments flow from one party to another, or how an enterprise carries out its work[i].  Data element and data element collection names you may encounter that belong to the Activities BOC include, but are not limited to, names in the following table[ii].  The list gives you a hint of what kind of names to look for in putting together a 6BI Analytic Schema for enabling your data to answer business questions.

An Activity is the most general super-type, in this BOC, encompassing Function and Process[iii].  Functions are intended to describe how an organization’s mission is planned to be carried out, and Processes describe how the mission is made real.  In the design of the Analytic Schema, data that identify and describe functions is almost always used in the source system as a type of reference data and will typically be brought into the Analytic Schema as text data in dimension members.  The maintenance of this data should be under the control of Data Governance.  The governance of data is itself both a function and a process and as such its performance can also be measured.  If one were to design a schema for measuring the performance of the Data Governance function a hierarchical collection of its sub-functions would be identified.  As we will see, functions also play a significant role in the Motivators BOC, but that will come later.

In data modeling, I have observed that we will more often model processes than functions.  A process can be either a Business_Process or a System_Process, but in either case the “process” is how something gets done.  This is accomplished by transforming either concepts or objects (or both) into different states.  It is the contribution of this transformation toward some goal that we need to measure.  Keep in mind it is “how” something gets done that we are measuring here, not “what” gets done.  This is vitally important to analytics and business intelligence because there is a lot of potential gain in improving how something is done, even if  what is produced (or consumed) remains unchanged.  For example, decreasing processing time, reducing waste and realigning responses to demand are all readily actionable.  For marketing purposes, how a product is produced or provided [iv] disappears into the product itself, and so is quite often overlooked as a separate factor in measurement.  In business systems quite often the names we look for to identify activities contain the word Transaction in some way.

Another feature of a process is that it transforms things, and these transformations usually take place via some Mechanism.  Mechanisms include Sales, Purchases, Receiving and Shipments.  A process can also be represented by a document such as a Request, an Order, an Invoice, a Manifest, or a Receipt.  It is the data about the transformation, perhaps recorded in a document, or perhaps not, that we want to measure.  We measure the impact on the parties and things participating in the transformation and not the parties and things themselves.  This is a subtle but important difference.  An activity’s quantities, values and description are the record of “How” the process produced a result.

An activity is often the source of one or more events, and an event is often the source of one or more activities, but activities and events are not exactly the same thing, and are not interchangeable. We will visit the Events BOC in a future post.

[i] David C. Hay, Data Model Patterns, A Metadata Map, 2006.

[ii] I would like to thank Barry Williams and his excellent Database Answers website http://www.databaseanswers.org/data_models/ for providing many of the table name examples.

[iii] David C. Hay, Data Model Patterns, A Metadata Map, 2006.

[iv]  The distinction between “produced” and “provided” is made to distinguish between, for example, manufacturing and retailing.

This is the second post in a series of posts about how to identify entities in data sources that can readily be classified as belonging to each of the 6BI Business Object Categories (BOCs): Parties, Things, Activities, Events, Locations and Motivators.  The first post in the series (on Parties, the “Who” aspect) can be found at   https://birkdalecomputing.com/2017/04/26/identifying-parties/ ‎.

The Things BOC identifies What the concepts and objects are that are produced and consumed by parties.  Data element and data element collection names you may encounter that belong to the Things BOC include but are not limited to names in the following table[i].  The list gives you a hint of what kind of names to look for in putting together a 6BI Analytic Schema for enabling your data to answer business questions.

For the purposes of 6BI the first decomposition of Things is between Product and Payment.  Products are also further decomposed into Good and Service.  Goods are tangible material products for which consumers make payments, and services are products provided primarily by human or human-like labor.  Products are also quite often hierarchical and the names used for each level are Things BOC names in their own right.  These names can be logical such as Class, Category, and Type for example. Or can be physical such as Assembly, Component, and Container.  Look for these words, or ones like them, in conjunction with other words that more clearly designate them as classification levels of a product, such as Asset_Type or Vehicle_Assembly.  Products and Payments represent what is exchanged in a transaction and are differentiated by the direction in which they flow.  Products flow from provider to consumer, and Payments flow from consumer to provider.  Quite often the difference between a Product and a Payment is obvious, but sometimes it’s not.  This is especially true when transactions are “in kind” and it is not obvious which, if either thing, represents the “money”.  One rule of thumb is to always remember who the “first party”[ii] in your analysis and which side of their ledger you are analyzing.  The first party is for “whom” the analysis is done or “who” the analysis is intended to benefit.  If you are analyzing their receivables side then the inflow is always a payment and the outflow a product.  If you are analyzing their payables side then the opposite is true, inflows are product types and outflows are payment types.

Potentially the Things BOC can be identified by more data store names than any other BOC because we as humans often designate all phenomena as things.  In information systems however it is always more useful to refer to the instances of the Things BOC as products or payments.  We use the term “Things” for this category of business objects so that we remember to look at both sides of “what” is being exchanged in a transaction, and not be content to only consider the product alone.  There are simply so many things in the real world but we must concentrate on “how” (see the Activities BOC post) they flow if we need to measure their value to a party and assess a party’s contribution to that value.

A Definition can also be a product. This is true when used to represent the meaning of that which parties (individuals and organizations) produce or consume.  It doesn’t matter what is defined.  It can be a party, a location, an activity, an event, a motivator or anything.  If the definition itself is manipulated (i.e. produced or consumed by a party) then it is a product, and thus a thing.  We can speak about the “Definition of the customer” for example.  Customer is clearly a member of the Parties BOC when it comes to analyzing data content for understanding performance for example.  But the definition itself (i.e. What a customer is) is a product of a metadata system.  If you need to analyze, normalize and rationalize the consistency of various definitions of customer you need to treat these definitions as things and not as parties.  That is, they are products of the system associated with a provider and a consumer.

The customer can have multiple definitions, but each separate definition must be associated with the customer through some unique combination of location, event, activity and/or motivator.  Those for whom the consistency checking and improving is performed are the parties. However, and this is critical, the definition of what a customer is, so that it can be used consistently to mean the same role played by a party depending on some unique combination of activity, location, event, product, and motivator is itself a product.  As a product, its quality can be controlled and monitored, its accuracy and integrity assessed and its use measured.

[i]  I would like to thank Barry Williams and his excellent Database Answers website http://www.databaseanswers.org/data_models/ for providing many of the table name examples.

[ii] The party from whose perspective the measurements are taken.