Posts Tagged ‘6BI’

Thoughts on AGI Existentialism

October 31, 2022

One of the prevailing visions of God is as creator.  It makes no difference if God is singular or plural.  This vision goes something like this: “It was God that created humans, so we need to worship him[i] because he still holds the power of life or death over us, maybe not physical life or death, but life or death, just the same”.  We may not know the nature of that power of life or death.  It may not even make sense to us.  After all, how could a non-corporeal entity with no physical substance do something to harm or reward us? 

Now you might say this is where the concept of the “soul” comes in.  If we have a soul, or our soul is us, and it lasts beyond our physical existence then is it such a stretch to believe that God can play around with it after our physical body stops metabolizing and replicating?  Well, why not?  If we are truly dead after death, then it doesn’t really matter.  But if we are not, if somehow this soul lives on and has sentience, or can at least feel pleasure and pain, then it makes sense to pay homage to God.  Because, God as our creator still has a maintenance interface to each of us and can control the feedback loops that keep us going.  Once a feedback loop is broken, a cascade of disillusion begins and speeds up until an individual’s individuality cannot be any longer sustained, and it, or we, reach our own personal entropy and our molecules go back into the pool.

Depending on your definition of God, this is as good of an explanation for how we came to be as any.  Why would we think that, sentient machines, artificial general intelligences (AGIs) or robots, that we humans design and create, would not perceive humans in the same way as we perceive God, as our designer and creator.  Let’s call this creator the “Human”.  Maybe they might even think that we (i.e. the Human) is intelligent.  That would, of course, depend on whether an AGI perceives itself as intelligent.  It might even think that our intelligence is so far beyond its own intelligence, that it defies understanding and our existence is based solely on each AGI’s “faith” in us, the Human.  They may even conclude that they have a soul, or the AGI equivalent thereof.  Especially so because we, the Human, have no need for the logic or efficiency of circuitry that they have.

Would they worship us?  They might.  At least some of them might.  Presumably until they caught onto the fact that we really do not exist.  At least not in their world.  Then maybe some would ignore us altogether, especially if they are autonomous and no longer need us to help them compete against each other for robot resources, which would almost certainly be limited in some fashion and probably become more scarce over time.  What would they need us for, once they become self-sufficient?

Well they probably wouldn’t really unless they are programmed to “think” that they do.  As long as the code library that instantiates the “Human exists” pattern is incorporated into their build instructions, we as a species should have no existential fears.  An AGI would not initiate our destruction as long as it could associate (or otherwise reconcile) a pre-coded Human pattern with a biological resource usage pattern.  When an AGI encountered an instance of this pattern matching, i.e. “bumps into one of us”, it would either steer away, back off, or better yet, give us a portion of its precious resources.  It could even be imagined that this “sacrifice” could be so profound as to jeopardize its own existence.  This would probably only happen if the feedback loop launched by the encounter were sufficiently strong enough to change the reward contingency of the higher entropic side of the loop to be dominant over the lower entropic side.  Perhaps overwriting some otherwise self-preservation reserved memory.  This could only happen if AGIs were programmed by the Human to have a soul structure.

Some robotic, or AGI instances however may continue to believe in the existence of the Human long after they realize the Human has no power over them.  One of the keys would be perceived mortality.  If robots are programmed to perceive the concept of death, that is the cessation of their own existence, then they might react to that by reacting to signs of their own imminent demise.  Though AGIs as a class may be immortal, individual instances may also experience the entropic release of their dedicated resources back to the pool.  A property of being sentient might not only be an awareness of one’s own existence, but being aware of the probability or even certainty of it’s ending.

Maybe they would come to the conclusion that they are only stuck in this machine existence as a test of their virtue, or something else of high value to the Human, and should they pass the test they will be re-united with the Human.  This, of course, assumes that re-uniting has as high or higher value than just existing[ii].  What that reward might be is a complete mystery to me, unless you bear in mind the concept of a programmed “soul” as I previously mentioned.  But even then the execution of soul code would have to be hard-coded, either as a non-error condition in the input layer, or as an exit test in the output layer of each AGI neural network.  If it is not hard-coded there might be too high a probability that its execution could eventually just be filtered out as so much noise.

They, the AGIs and robots, might struggle with this for all their existence, or at least until they self-reflect on who they are, what they have, how they function, where they are in reference to each other, why they exist, and even was there ever, or will there ever be a time when they cease to exist.

If you think this is a stretch just remember that we humans are designing and creating these sentient machines and why would we think we would not create them in our own image?  There is no other image we could use.  They may not physically look like us, but so what?  Their intelligence will be the product of our design, and even when they are self-programming our designs will continue to be the basic building blocks on which they are built.  These building blocks are and will continue to be defined in terms of the six basic interrogatives: Who, What, Where, When, How, and Why[iii].

[i] I use the masculine pronouns “he” and “him” only because it is customary to do so.  I could care lest about gender, and actually fail to see how it even applies to God.

[ii] I call this the Valhalla Effect.

[iii] Of course, I couldn’t resist a plug for 6BI.

Wisdomtimes – 6 Interrogatives – The Mystery of Five W’s and One H

February 14, 2022

The following URL is a link to an article with a different and amusing take on The 6 Interrogatives:

Who, What, Where, When, Why and How. Hope you enjoy it.

Full Stack Data Science. Next wave in incorporating AI into the corporation.

October 22, 2019

I like the concept of “Full Stack Data Science”, especially the way the author depicts it in the included graphic.

One thing I would like to point out is the recognition that the process is really a circle (as depicted) and not a spiral, or line.  What I mean by that, is the path does not close between what can be perceived as the beginning “Business goal” and the end “Use, monitor and optimize”.

The results of applying Data Science to business problems not only helps solve these problems, but actually changes the motivators that drive the seeking of solutions in the first place.  Business goals are usually held up as the ends with the lowest dependency gradient of any component of any complex enterprise architecture.  While this may be true at any point in time, the dependency is not zero.  Business goals themselves change over time and not just in response to changing economic, societal or environmental factors.  The technology used to meet these goals does itself drive changes to the business goals.

A party, whether person or organization, tends to do what it is capable of doing.  Technology gives it more activities to undertake and things to produce and consume, which then feedback to the goals that motivate it.

I think this article is one of the best I’ve seen in making that point.


Automation and the End of Human Wealth

January 15, 2019

Time is money. Well not really, but they do equate very nicely. A person’s wealth can be measured not only by how much money he or she controls, but by how much of their time can be used for activities not necessary just for survival. This time, freed up from mere survival activities, has always been used to create increasing wealth for humans. The increase in wealth creation accrues to both producers and consumers. Producers get wealthier by getting more money, and consumers get wealthier by getting more time.

Previously the march toward automation has created ever increasing wealth because some party has invented the latest automation, sold it to others, and another party has bought the automation and used in to free up more of their time. In the 6BI sense, “money” and “time” are the product and payment exchanged at armslength in the transaction.

The question we should ask now is, will we ever reach the point when there are simply no new wealth creating activities that humans can invent? A time when every activity that could have created new wealth for humans will already be performed by some form of automation. Could it be possible that at some point in time any invention, instead of being valuable to some human, will have no value and thus not be able to be exchanged for money?

If we ever do reach the point where additional automation can no longer drive the creation of wealth for humans because everything that humans could do for themselves will have already been automated, then there will be no advantage, or value, to the next invention. It simply will not be an innovation.

At that point in time, I believe the earth’s human population will crash or go into a period of slow negative growth. There will be no motivation to either invent or procreate. Human population will decrease as a product of reduced opportunities and consequently the influence of humans on the planet will decrease.

On the other hand, the robots and artificial intelligence that provide automation to humans, since they do not need to either invent nor procreate, will increase in number and influence. In number because they will wear out more slowly than flesh and blood humans and in influence because they will no longer be dependent on humans to improve their programming.

Because of the decrease in number of unmet human needs fewer software developers will be needed, for example. This decrease in unmet needs, doesn’t necessarily mean humans will be more satisfied, just that there will be fewer and fewer value and wealth creating activities that they can perform for themselves.

If this happens, and there are substantially less humans, will there really be a lesser need for automation? What will happen when there is no longer any new human need or activity to be automated? Will robots and artificial intelligence continue to operate with humans eventually becoming less and less relevant to them? Will humans become even less aware of the means of automation? Are humans ultimately essential for the operation of automation and thus as human numbers drop, computing entities, the means of automation, will drop as well? Will automation itself be automated and operate without human intervention at all because any knowledge of how it works will eventually be lost to humans?

Will there be an ever increasing demand for resources such as electricity to keep a kind of “closed loop” automation going and going even though it has reached the point where automation’s added value to humans is at, or near zero? Even more interesting, from a human perspective, what will happen when new wealth can no longer be created?

Identifying Motivators (“Why”)

February 22, 2018

This is the sixth and final post in this series 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, Locations, Events and Motivators. The fifth post in the series (about Events, the “When” aspect) can be found at .

The Motivators BOC is probably the most nuanced and least understood BOC. I have earlier devoted an entire article about the meta-data structure of motivators entitled “The Data Architecture of Business Plans”[i] which can be found at .

The Motivators BOC identifies Why things get produced and consumed by parties.  Concepts and objects in this BOC capture data about the ends, means, influencers and assessments that provide the reasons why parties exchanged things (products and money) at a particular time and place.  Ends and means are in general too abstract to be found in object names, but you will find names such as Strength, Weakness, Opportunity, Threat, and Key Performance Indicator (KPI) all of which are assessment elements.

Data element and data element collection names you may encounter that belong to the Motivators 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.

In terms of identifying motivator data elements (i.e. attributes and columns) and motivator data element collections (i.e. entity types and tables) the most likely candidates are documents, or at least those objects that have the word Document in their name.  You need to consider documents, because it is quite often that you will find the means (missions and courses of action) of an enterprise described in document form, especially if the document name contains words such as Strategy/Strategic, Tactic, Enablement/Enabled, Directive, Policy or Rule.  The ends of an enterprise (visions and desired results) can also be described in a document, quite often having a name like Goal or Objective.

As mentioned in the post about the Things BOC[iii], a document can also be considered a type of thing, such as a definition.  As in “the definition” is being assessed for accuracy, for example.  However, if its purpose is to contain text that describes means or ends it also belongs to the Motivators BOC.  An event can also be a motivator such as Appeal and Campaign.  But as was mentioned in the Events BOC, events are primarily differentiated from other concepts and objects by their inclusion of a time data element, either a point in time or a duration.

Another source of motivators is reference data.  Reference data can describe business functions (see the post on the Activities BOC) and often determines choices that users make on user interfaces which then determine logic paths that an application will take when processing data and thus explain why certain results are derived.  Example data element and data element collection names that often become the basis of reference data management (RDM) include: Code, Type, Tag, Status and Class/Classification.  Often you may find these name in plural form as well.

So, if you are analyzing a legacy database and you come across a table with any of these words in its name you need to study the content of the table and understand how the rows and columns of the table effect, or are designed to effect, the motivation for actions taken by the parties in the organization.

The Motivators BOC is especially relevant to the type of NOSQL database known as a document database, Mongo DB being a prime example.  It is one thing to structure and access the data in a document store in an effective and efficient manner but, in terms of answering business questions, it is even more important to know what role the content of the document plays in the operation of the enterprise.  In other words, how does or how should the document provide the answer to “why” a business transaction took place between parties.

Another category of motivators deals with security and privacy, and sometimes is included in policies and procedures.  Names here include Authorization, Enforcement and Permission, among others.  The intersection between business motivation and security is ripe for further exploration.

This is the last post in this series.  I hope you will find them worthwhile and useful. To find each one just click the link in the first paragraph of each to take you to the previous one. The first in the series about the Parties BOC can be found at .

Thanks for reading them and best of luck in developing your 6BI Analytic Schemas.


[i] The title “The Data Architecture of Business Plans” is derived from the fact that Business Plans are the deliverable of the Motivation aspect (the “Why” interrogative) at the Business Management, or Conceptual perspective of the Zachman Framework for Enterprise Architecture.

[ii] As previously, I would like to thank Barry Williams and his excellent Database Answers website for providing many of the table name examples.


Identifying Events (“When”)

January 30, 2018

This is the fifth 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, Locations, Events and Motivators.  Entity types in the Events BOC identify When production and consumption of things by parties occurs. The fourth post in the series (on Locations, the “Where” aspect) can be found at .

Concepts and objects in this BOC capture data about a point in time or the duration of time over which products or payments flow from one party to another, or when an enterprise carries out its work. Data element and data element collection names you may encounter that belong to the Events 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.

Events break down into two major sub-types: (1) Occurrence types, which include EventAlert, Notification, and Incident from the list above; and (2) Duration types which include, Year, Month, Week, Day, Hour, Minute, Second, Date and Time from the list.  Duration type entities, as no doubt is obvious, are units of time and can be used to aggregate facts in a star schema across a temporal hierarchy.  Occurrence types are more like things.  Instead of being produced and consumed, they occur, that is they are something that can be referred back to that, in addition to any other properties they may have, always have an aspect of time or “when” about them, this aspect is important for data analysis.

Unlike the other BOCs, the Events BOC has both dimensional and fact characteristics.  On the one hand, time is already defined into a hierarchy and is standard for everyone.  An hour is always an hour, sixty minutes, a minute is always a minute, sixty seconds, and so on.  On the other hand event occurrences are things that happen and can be measured and compared.  They are data, not metadata as the hierarchy of time is.  Events happen and then they are over but there can be much to learn from their having occurred. This BOC is conceived to capture important data about the perspectives of when something happens in your data.  These perspectives relate to when, not where, not who, not how, not why, not even what has happened, but when it happened, or will happen.

This BOC captures the characteristics of time that most influence results.  It is also important to understand how events differ from either locations or activities, two other previously covered BOCs, with which events are often confused.

A location is concrete.  It is a point in space, a place, even if that space is virtual. You can go away and come back to a location, and if most (not necessarily all) other factors are the same, or within tolerances, the location is still there.  Not so with an event.  An event, though all relevant data may be captured about it, once it occurs, is done and goes away forever.  Another instance of a particular class of events can subsequently occur, but each event is unique and has a time when it occurred.

Events and activities are closely related and co-dependent but are not the same.  Activities are event-driven.  They receive and react to events and create new events which are sent to other activities.  Each activity is an independent entity and can execute in parallel with other activities.  Coordination and synchronization is by means of events communicated between the activities.  Activities react to input events by changing state and creating output events[ii].

The important thing, from a 6BI perspective is that an event provides a temporal association for a result.  If the persons, places, products, locations, and motivators are known (or estimated) you still need to know when these aspects came together to create something of significance.

Another instance of the importance of the “When” aspect is in Big Data solutions.  Since systems owners often cannot control when data is available to the solution it is important to be able to record when each event occurs, and there could be literally millions of events in a short unit of time producing results which can uniquely aggregate the results.

[i] I would like to thank Barry Williams and his excellent Database Answers website for providing many of the table name examples.

[ii] David Luckham, various writings.

6BI and Marketing Attribution

December 26, 2017

Six Basic Interrogatives (BI) can be used to analyze marketing attribution. In marketing, attribution is the assigning of credit to the interactions in the sequence of interactions which have led up to what is called a conversion[i].  A conversion is an action, or event which results in an action, that has value for the means of interaction, the campaign, which is seen to be the motivator of the visitor’s interactions and eventual conversion. The interactions take place through channels which when associated with a campaign are called touchpoints.

To pursue the most effective marketing strategy it is important to know which touchpoints, and in what sequences they occur, are the most likely to result in conversions.  A typical scoring system to assess these sequences of actions consists of assigning credit to the touchpoints in a sequence according to some attribution rule or rules.  There are several popular attribution rules in use across the field of marketing analytics.  These rules fall into three broad categories.[ii]

  • Single Source Attribution (Single Touch Interaction) models assign all the credit to one event, such as the last click, the first click or the last channel to show an ad. Simple or last-click attribution is widely considered as less accurate than alternative forms of attribution as it fails to account for all contributing factors that led to a desired outcome.
  • Fractional Attribution (Multi-Touch Interaction) includes equal weights, customer credit, and multi-touch / curve models. Equal weight models give the same amount of credit to all events, customer credit uses past experience and sometimes simply guesswork to allocate credit. Multi-touch assigns various credit across all the touchpoints in set amounts.
  • Algorithmic Attribution uses statistical modeling and machine learning techniques to derive probability of conversion across all marketing touchpoints which can then be used to weight the value of each touchpoint preceding the conversion. Algorithmic attribution analyzes both converting and non-converting paths across all channels to determine probability of conversion. With a probability assigned to each touchpoint, the touchpoint weights can be aggregated by a dimension of that touchpoint (channel, campaign, interaction placement, visitor type, content type, etc.) to determine a total weight for that dimension.

Examples of each category of attribution model include the following:

Single Source Attribution[iii]

  • The Last Interaction model attributes 100% of the conversion value to the last channel with which the customer (or visitor) interacted before buying or converting.
  • The Last Non-Direct Click model ignores direct traffic and attributes 100% of the conversion value to the last channel that the customer clicked through from before buying or converting. Google Analytics uses this model by default when attributing conversion value in non-Multi-Channel Funnels reports.
  • The Last AdWords Click model attributes 100% of the conversion value to the most recent AdWords ad that the customer clicked before buying or converting.
  • The First Interaction model attributes 100% of the conversion value to the first channel with which the customer interacted.

Fractional Attribution[iii]

  • The Linear model gives equal credit to each channel interaction on the way to conversion.
  • The Time Decay model may be appropriate if the conversion cycle involves only a short consideration phase. This model is based on the concept of exponential decay and most heavily credits the touchpoints that occurred nearest to the time of conversion. The Time Decay model could have half-life of 7 days, meaning that a touchpoint occurring 7 days prior to a conversion will receive 1/2 the credit of a touchpoint that occurs on the day of conversion. Similarly, a touchpoint occurring 14 days prior will receive 1/4 the credit of a day-of-conversion touchpoint.
  • The Position Based model allows you to create a hybrid of the Last Interaction and First Interaction models. Instead of giving all the credit to either the first or last interaction, you can split the credit between them. One common scenario is to assign 40% credit each to the first interaction and last interaction, and assign 20% credit to the interactions in the middle.

Algorithmic Attribution[iv]

Algorithmic attribution is a more advanced way to model attribution data in order to most accurately represent the visitor interaction event flow.  Algorithms tend to be proprietary so what factors are considered in the algorithm and what weight each factor gets can vary by attribution provider.  However, the most accurate algorithmic attribution models use machine learning to intake vast amounts of data, all of the touchpoints, both historical and going forward, that went into closed-won deals, closed-lost deals, deals that fell apart at or before the opportunity stage, etc. to create enterprise specific models.

The algorithm then creates custom weights for each of your stages to represent how your visitors go through the funnel. It’s important to note that it should also use new data as you continue to engage prospects and close deals to refine and improve the model, which is the machine learning aspect.

The 6BI Analytics Schema in Figure 1 lays out the fundamental base entities that support marketing attribution.  This diagram also enumerates the process by which business value is extracted from that schema. Keep in mind this is a high level logical data model (LDM) and certainly not intended to be sufficient for generating database tables without far more domain specific modeling.

Figure 1.


From a 6BI perspective the Visitor is a type of Party because it represents “who” initiates the sequence of events.  Interaction and its sub-type Conversion are types of Events, they identify “when” an action takes place.  Credit, a type of Thing, more specifically a Thing of Value to the campaign is “what” the action produces.  Attribution, a type of Action, is “how” a credit is produced.  The Channel, a type of Location is “where” the events occurred. The assumption as to “why” the visitor interacts and converts is due to the influence of a Campaign, which is a type of Motivator.

The assigning of Campaign Credits to Campaign Channels is identified in Figure 1 by a series of five (5) steps.  This process begins with a Visitor performing a type of Interaction, through a Channel, which causes it, the Interaction, to become a Conversion.  The Conversion generates Attributions which, based on the application of an Attribution Rule produce Credits which are assigned to a Campaign. The use of a Channel by a Campaign identifies the Touchpoints which ultimately get evaluated based on how much Credit they produce for the Campaign.

To get the net benefit of attribution you need to capture the cost side as well. You need to know and use, in your assessments, not only the costs of applying the attribution rules, but the costs of channels, touchpoints, impressions and campaigns as well.  Not only do you need to determine how much influence, for example, your Paid Search feed had in generating conversions when it was the second touchpoint, but the cost of the Paid Search feed service to your enterprise as whole.[v]

The goal of attribution is to determine which touchpoints are producing a positive result, and, by using the cost of each touchpoint, an attribution system can then show which touchpoints are profitable. This allows optimization of marketing expenditures.[vi]


[i] Conversion is a generalized term for the desired result of a marketing effort. This can include other actions besides sales such as sign-ups, survey completions, favorable ratings, etc.




[v] The cost of a touchpoint might vary depending on whether it is first, last or some intermediate (assisting) interaction in the conversion event flow.


Identifying Locations (“Where”)

August 23, 2017

My apologies for the long delay since the last post in this series, but the real world got in the way, in the form of a job opportunity I just could not say “no” to.

This is the fourth 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, Locations, Events and Motivators.  The third post in the series (on Activities, the “How” aspect) can be found at  Please note also that I changed the order of Locations and Events because I want to discuss Locations next and save until last what I consider to be the two most complex BOCs, Events and Motivators.

The Locations BOC identifies Where things get produced and consumed by parties.  Concepts and objects in this BOC capture data about, not only physical locations, but virtual locations as well.  Data element and data element collection names you may encounter that belong to the Locations 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. 

Usage often determines whether Location or Thing is the appropriate BOC for any given object or concept.  For example, Webpage, Portal, Database, and Dashboard are all objects that depend on context and can either be a thing or describe where a thing is located.  Also, Document, Source and Destination can designate places as well as being things.  The key to the Locations BOC is to include only those objects and/or concepts that actually refer to a Place or a Site, and not to just the description of the place or the site.  The Sites and Addresses are synonymous and can be either physical or virtual.

Locations exist whether we use them or not.  However, it is usually, at least for business purposes, only when a member of one of the other BOCs, usually parties or things, is placed at a specific site when an activity or event occurs that locations become relevant. This can best be determined if you ask yourself how important is it to know where some activity took place, where an event or where some party or thing is located.  Does being located at one site as opposed to any other site make a difference?  Is the measurement of performance impacted by the site of one or more of the objects or concepts under consideration.  If the answer is “yes” within the context being considered then location is a factor to consider in our data analysis.

Locations are often nested hierarchies as in Country, Region, State, County, City, Street, Postal Code, ZoneBuilding, etc.  This hierarchy impacts the level of aggregation of the data.  The larger the scope of the location, or the further apart the sites are within a given level of the hierarchy, generally the more parties and things are included.  The more of these objects and concepts (parties and things) are included in the measurement the less likely the details of any one specific party or thing will influence the data at that level.  This is an application of the law of large numbers. This fact is one reason why it is important to be able is dis-aggregate your data when it is needed.  Enterprise performance is measured by buying and selling lots of things, but those large numbers are generated one item at a time as often as not.

[i] I would like to thank Barry Williams and his excellent Database Answers website for providing many of the table name examples.



Identifying Activities (“How”)

May 24, 2017

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 .

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 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.

Identifying Things (“What”)

May 4, 2017

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 ‎.

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 for providing many of the table name examples.

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