Posts Tagged ‘6BI’

6BI and Aggregate-Orientation, Part 2

September 15, 2016

This is the second part of a two-part post. The first part can be found at https://waynekurtz.wordpress.com/2016/09/06/introduction-to-6bi-and-aggregate-orientation/.

To transform a 6BI (“Six Basic Interrogatives”) derived logical data model into an aggregate-oriented data model there are several steps that need to be taken. We will use the logical business data model shown in Figure 3 as our example to show this transformation. It’s very simplified but fairly typical of certain types for commercial enterprises.

ldm-clean-9-9-2016-2-36-43-pm

Figure 3. A Business Data Model Example.

Semantically we can say the following about our business data model. A Customer can have many Contacts, and a Contact can have many Customers. The Customer_Contact entity[i] resolves this by linking a Customer to its Contacts through the “has contact” relationship and a Contact to its Customers through the “has customer” relationship. A Customer “places” Orders, “receives” Order_Invoices, and “makes” Order_Payments. A Provider “receives” Orders. An Order “contains” Order_Items and a Product “identifies” Order_Items. An Order_Invoice “is paid for by” Order_Payments and a Payment “is applied to” an Order_Payment.

Unlike data modeling where the outcome, as mentioned in Part 1, is typically the creation of tables which separately store instances of entity types linked together by key-based references, the outcome of an aggregate-oriented data model is the creation of aggregates. An aggregate is a complex data structure based on a “root entity”. The root is determined by the business requirements and is identified as an entity type in an LDM. This entity is often derived from a 6BI BOC (“Business Object Category”). Aggregates are stored as a nested collection of entity instances whose relationship to the root is also determined by business requirements. How deeply an entity type is nested within the aggregate structure is determined by where it is placed along a dependency gradient.

Dependency Gradients

A dependency gradient is a continuum of degrees of dependency where the amount of dependency flows from a higher concentration to a lower concentration. It flows from entities that have a greater number of dependencies, both direct and indirect, to entities with a lesser number of dependencies. An entity that consumes no other entity’s identifier (i.e. it has no foreign keys) is referred to as the “apex entity” of the continuum and has the least dependency. An entity whose identifier is not consumed by any other entity along the continuum is referred to as the “base entity”. The relationship between a base entity and an apex entity could be direct, however there are often many potential intermediate entities between the base and the apex entities.

Figure 4 shows two dependency gradients that flow from the same Base Entity Order_Payment (a type of Exchange).

  • Dependency Gradient-01 flows through the relationship “is applied to” directly to Apex Entity-01 Payment (a type of Thing).
  • Dependency Gradient-02 flows through the relationships “is paid for by” to Order_Invoice (a type of Exchange), “is billed thru” to Order (a type of Exchange), and finally “places” indirectly to Apex Entity-02 Customer (a type of Party).

dep-grad-9-13-2016-14-40-20-am

Figure 4. Dependency gradients flowing from Order_Payment.

Dependency gradients form dependency trees when the flow from base to apex takes more than one path. The term gradient[ii] is used to indicate the relative degree and direction of dependency along a tree. Dependency always flows from a higher concentration (more foreign keys) to a lower concentration. Aggregates in an aggregate-oriented data model are based on dependency trees.

Steps for Transforming the LDM

The following ordered set of steps are required for transforming a LDM into an aggregate-oriented data model.

  • Select the root entity for each aggregate.
  • Identify relationships to be eliminated by “rolling down” parent entity attributes into the child entity.
  • Identify relationships to be collapsed by “rolling up” child entity attributes into the parent entity.
  • Eliminate unneeded apex entities by rolling down their attributes to an entity higher on the dependency gradient.
  • Roll up attributes from base entities in the direction of the root entity along selected dependency gradients.
  • Create the aggregate-oriented data model.

Select the Root Entity for each Aggregate

The root entity of an aggregate, identified by the ROOT operator, can occur anywhere along the dependency gradient and is independent of the relational association (i.e. relationship) between itself and any other entity along the gradient. The other entities in a dependency tree, called aggregate participants, are embedded into the aggregate root entity instance. The embedding of participant entity attributes into the aggregate root occurs regardless of whether the participant is in the direction of the apex or in the direction of the base relative to the root. Identification of the root entity will influence which relationships get eliminated and to a greater extent determine which relationships get collapsed.

Identify Relationships to be Eliminated

Relationships to be eliminated are tagged with the REFI[iii] tag. To identify each individual action triggered by the REFI tag the tags are numbered starting with REFI-01. In eliminated relationships the parent entity is removed and all or some of its attributes are rolled down into the child entity.

Which attributes to roll down is determined by how normalized the entity is. In cases where an entity has attributes that are not part of one of the dependency gradients being aggregated the non-dependent attributes would not be rolled down, however the relationship is still eliminated in transforming the logical data model into aggregate-orientated data model.

Figure 5 shows the relationship between Product and Order Item named “identifies” tagged as REFI-03. In this case it was decided this relationship would be eliminated and the parent (Product) attributes were rolled down into the child (Order Item) entity eliminating the relationship and its parent entity.

refi03-9-10-2016-1-00-40-pm

Figure 5. A relationship tagged for elimination.

Identify Relationships to be Collapsed

This step requires modelers to take an entity, like Order in our example data model, which has other entities that refer to it and roll up the attributes of its selected child entities into the parent entity. Order and its dependent entities, Order_Item through the “contains” relationship, and Order_Invoice through the “is billed thru” relationship are shown in Figure 6. Only the relationship with Order_Item is tagged as EMBED-02. The relationship with Order_Invoice does not need to be tagged for this transformation because Order_Invoice has a separate relationship with Customer named “receives” and its attributes are rolled up along that dependency gradient (see Figure 7).

ldm-embed-tag-9-10-2016-1-38-40-pm

Figure 6. A relationship tagged for collapse.

Figure 7 shows the whole example model tagged in preparation for transforming it into an aggregate-oriented data model with Customer as its root entity.

ldm-tagged-9-10-2016-1-17-36-pm

Figure 7. A logical data model tagged for transformation.

Eliminate Unneeded Apex Entities

Figure 8 shows what the physical data model (PDM) looks like after certain relationships, and their parent entities, are eliminated. In this model we have eliminated the relationship “has customer” rolling Contact into Customer_Contact (REFI-01), “receives” rolling Provider into Order (REFI-02), and “identifies” rolling Product into Order_Item (REFI-03)[iv]. Please note that in the roll downs we have included the parent primary keys (now as non-key attributes). Strictly speaking we would not always need to do this. If we were to implement this data model in a relational database management system (RDBMS) the entity Provider would become a table and its attributes columns.

Again this is actually more of a business decision than strictly a technical decision, though I suspect it is rarely considered so. This is another reason why I say selection of a NOSQL database is at least as much of a business decision as a technical decision.

pdm-rel-9-9-2016-2-40-24-pm

Figure 8. Our example data model after eliminating unneeded apex entities.

Create the Aggregate-Oriented Data Model

Figure 9[v] shows an aggregate-oriented data model based on Customer as its root entity. All the attributes of the entities that survive the roll down are rolled up along dependency gradients and collapsed into the Customer_Aggregate forming the nested collection of entity instances, which is called an aggregate.

We have the same issue here that we had in the previous section. What do we do with the entity identifiers (i.e. primary keys)? One identifier that we have to keep of course is the primary key of the root entity, Customer_Aggregate.customer_id. It is the identifier of the aggregate. The answer for an aggregate is not the same as the answer for a table. In a RDBMS we are optimizing the design of tables, in a NOSQL database we do not have tables. All the attributes of all entity types included in creation of the aggregate are considered attributes of the aggregate and no longer “stand alone” entities or entity instances. The identifiers of all aggregate participants are removed from the model.

cust-agg-9-13-2016-3-23-47-pm

Figure 9. Aggregate-oriented data model.

Not having tables as your “modeling target artifacts” may be a difficult and even disturbing concept for data modelers experienced in identifying and normalizing entities. For this reason an aggregate-oriented data model is a new type of data model. It is not a logical model, but it is also not a physical model in the strict sense that it can be used to generate pre-defined database schema structures (e.g. tables). It is used to relate the entity types and relationships designed in a logical data model, and the business requirements they represent, to the chosen type of NOSQL database (e.g. key-value, column family, document, and others) and the unique metadata structures each type of NOSQL database has.

A final transformation is required to create code for the construction of the appropriate aggregate-oriented NOSQL database structures. Because we typically see NOSQL data structures expressed as a mixed meta-data and data structure such as a JSON string it is easy to forget that JSON still has a schema. That schema is often maintained in the application code and not in the database engine. The advantage of this is more flexibility in application development but the cost is often a lack of the uniform constraints needed to maintain the re-useable data structures required for non-deterministic query construction and compliance to data governance standards.

In summary the steps needed to transform a LDM into an aggregate-oriented data model are the following. First, identify the root entity for the aggregate in the LDM, identify non-root parent entities to be eliminated by rolling down their attributes into their child entities, and finally identify child entities to be collapsed by rolling up their attributes into the root entity along dependency gradients that have the aggregate root as apex entity.

In a future paper I will describe how the concepts in this article can be applied to data targeted to be stored in popular NOSQL databases.

[i] It’s conventional for data modeling tools to call the rectangles in LDMs “entities”. They can also be called “types” or “entity types”. The physical form should be called an “entity instance”. In this paper I will use “entity” and “entity type” interchangeably because most of the paper deals with logical data modeling and most of the tools used for logical data modeling call them tables. Where I refer to physical modeling I use either “entity instance” of if entity is understood just “instance”.

[ii] In physics “gradient” is defined as an increase or decrease in the magnitude of a property, the change of which can usually be measured. The word seemed appropriate to name the concept of increasing or decreasing dependency.

[iii] The REFI and EMBED tags were identified by Jovanovic and Benson. Their usage in this article is derived from the paper but may differ slightly from the original meaning, including the numbering of each instance of a tag type for easier identification of each individual roll-up and roll-down action.

[iv] It is important to understand that the three eliminated entities are not removed from the data model, neither logically or physically. They are simply not part of the aggregate-oriented data model.

[v] Any reader familiar with the Erwin Data Modeler tool will recognize that I’ve used the symbol for a View to represent the aggregate. This is not to say that an aggregate is the same as a view. Erwin, nor any other data modeling tool I am familiar with yet supports aggregate oriented modeling. The COMN data modeling technique introduced by Theodore Hills is the closest I’ve seen to actually recognizing and describing a methodology for doing so. Please see http://www.tewdur.com .

Introduction to 6BI and Aggregate-Orientation

September 6, 2016

I wrote this article after reading NoSQL Distilled, A Brief Guide to the Emerging World of Polyglot Persistence by Pramod J. Sadalage and Martin Fowler in the summer of 2016. I was incented to read the book after seeing Martin Fowler give a presentation on NoSQL at a 2013 GoTo Conference presentation, which can be viewed at https://www.youtube.com/watch?v=ASiU89Gl0F0.

Up to that point the whole concept of “NoSQL” was very fuzzy to me, but after experiencing his presentation and reading the book I realized that the “lynchpin” that held RDBMS and NoSQL together was a concept that many SQL database architects have been working with for years, the common de-normalized data structure. One problem (among several) with de-normalization has always been how do you systematically de-normalize data so that two de-normalized data-sets can be compared to each other in a consistent and repeatable manner to assure reliable analysis by different parties, over time and in different locations.  In other words how do we maintain the old “apples-to-apples” and “oranges-to-orange” paradigm.

————————————————————————————————————

Six Basic Interrogatives, or 6BI for short, provides an approach for organizing and understanding the context of data used to support business decision making.  I first wrote about 6BI back in the 2004-2005 time frame when I was working full time as a Business Intelligence Data Architect and needed a quick way to get started analyzing existing data in order to organize it to answer business questions.  Since that time I’ve had other opportunities to put 6BI to use in situations not normally identified as business intelligence, certainly not the traditional type which focuses on a central RDBMS based data warehouse.  I have found it holds up well, as I thought it would, in various scenarios and has versatility and applicability in just about all the computing situations that I have found myself in.

With the increased popularity of distributed computing, fueled mostly by the overwhelming up take of mobile devices both for business as well as personal use, new highly scalable technologies for persisting data have been developed.  These technologies tend to rely more on an expanding network of smaller computing units as they grow by scaling out to more units, as opposed to a small number of large and ever growing computing units which grow capacity by scaling up.  Scaling out is most often referred to as “horizontal scaling” while scaling up is referred to as “vertical scaling”.  There is no doubt that horizontal scaling is more popular today than vertical scaling.  Going hand-in-hand with the horizontal scaling trend has been the introduction of alternative data stores now collectively known as NOSQL databases.

Three types of NOSQL databases that are designed to store a rich structure of closely related data that is accessed as a unit were identified by (Sadalage and Fowler 2013)[i].  They call this type of database an aggregate-oriented database because its basic storage structure is conceptualized differently from that of a traditional relational database management system (RDBMS).  An RDBMS stores its data in tables, or more precisely in relations.  Relations allow data to be normalized into units (tables) which contain data that is dependent only upon the primary key of the entity.  From a logical perspective we can say that each set of attributes (i.e. a row in a table) describes one and only one instance of an entity which in turn is differentiated from all other instances of all other entities by its unique identifier. The columns of the table store the attribute values of the entity instance where its row intersects with its columns.

In practice this results quite often in data about customers stored in a Customer table, data about products in a Product table, data about Orders in an Order table, and so forth.  This is a very powerful design because it does not pre-suppose any fixed relationship between Customers, Products and Orders, but it let’s designers and developers link them together in any way that meets business requirements even when these requirements might not necessarily be known in advance.  This ad hoc linking is made possible by the SQL language[ii].

NOSQL databases, in order to provide more performance across distributed data stores, even when the nodes are distributed globally, were conceptualized and built with a different set of priorities.  Non-deterministic query structure was not a priority, but instead just capturing and persisting the data as quickly as possible was the top priority.  There was no need to build SQL language interpreters into the architecture of these “new age” data stores.  As a result NOSQL databases end up sacrificing some of the flexibility needed to support non-deterministic query construction in favor of higher performance access in a distributed landscape, or cluster.

Inevitably this trade-off has lead to the need for designers to know or predict, in advance, how the data will be accessed, which entities will need to be joined, and in what order to answer their business questions.  The loss of the luxury of not needing to know in advance exactly how your data will be accessed is the price that is paid for better performance.  Fair enough!  Nothing comes without its cost, especially in the world of computing. The important thing to remember is that there will always be a trade off[iii].

There are three aggregate-oriented NOSQL database categories that have emerged over the last several years:  Key-Value, Document, and Column Family.  Each is different but they share a conceptually similar data storage unit called an aggregate[iv].  A data modeler (or developer modeling an application’s data) using these new types of models needs to start thinking about how the data will be accessed earlier in the design and development process than ever before.  As (Sadalage and Fowler 2013) state, aggregate awareness needs to be made part of the design of the data model[v].  I can see how this could be the case when there is a lack of clarity between the role of database design and that of database development.  With the advent of aggregates and aggregate-orientation the job of a business intelligence data modeler has changed from being able to concentrate on business requirements to needing to be more aware of how the data will be accessed and stored.  This challenge is stated succinctly by (Jovanovic and Benson 2013) when they say NoSQL databases have opened a new non-trivial problem area for data modelers[vi].

If we do the aggregate data modeling at a level independent of the style of the data store (i.e. Key Value, Document or Column Family) however we can create implementation neutral and re-useable data models that reflect the requirements of the business as much as they reflect the requirements of the technology used to implement it.  Data organized with an aggregate-orientation needs to be modeled at a logical level just as much as data organized with a relational orientation ever did.  In both cases we need to start with the basic entities that describe business value for persisting and manipulating data.  The need for an organizing framework for data still exists.  We still need to know which real world entities (regardless of how they are instantiated in the data store) the business cares about and how these entities relate to each other.

Business Object Categories

6BI is built on a framework of six universal and re-usable Business Object Categories (BOCs).  Each BOC represents a non-overlapping category of business data.  Each category corresponds to one of the six basic interrogatives: Who, What, Where, When, How and Why.  Figure 1 shows the six basic interrogatives and the business object category which is derived from each including example sub-categories which will be used in subsequent business data model examples.

Basic Interrogative Business Object Category
Who produces the data used to measure performance? Parties[vii] (e.g. Customer and Provider)
What is being manipulated or exchanged to produce measurable performance? Things[viii] (e.g. Product and Payment)
How are the data values that measure performance produced? Activities (e.g. Exchange and Process)
When does the activity take place or for how long is the performance measured? Events (e.g. Point in Time and Period of Time)
Where does the activity used to measure performance take place? Locations (e.g. Address and Placement)
Why does the data actually measure performance? Motivators[ix] (e.g. End and Means

Figure 1. Six Basic Interrogatives and Business Object Categories.

In the 6BI Framework, Parties and Things have no direct association with each other.  It is only through the other four Business Object Categories (Activities, Events, Locations, and Motivators) that Parties and Things are associated.  The left side of Figure 2 shows the relationship of Parties to Activities, Events, Locations and Motivators.  The right side shows the relationship of Things to the same four BOCs.  This makes sense because only when parties engage in activities, exchanging and manipulating things between them, do events get generated at certain locations and reasons why become relevant.  Figure 2 illustrates the relationships between business object categories, both direct and indirect.

6bi-party-product-assocs-20160826

Figure 2. The indirect association of Parties to Things.

These business object categories provide the framework and starting point for classifying data that are need for non-deterministic query structure.  This design allows enough flexibility to support ad hoc reporting by focusing on the basic questions that all decision support data structures need to support, while not requiring a strictly relational storage structure underneath.

In the next part of this article we will show a method for transforming a 6BI derived logical data model into an aggregate-oriented data model.

 

[i] Pramod J. Saladage and Martin Fowler, NOSQL Distilled, A Brief Guide to the Emerging World of Polyglot Persistence, Addison-Wesley, 2013. Sadalage and Fowler identify four (4) types of NOSQL databases. The fourth being Graph databases which we will not be discussing in this article.

[ii] SQL is not the first relational database language.  In the 1980s each relational database product had its own language, each of which did pretty much the same thing.  SQL simply won the “database language war”.  It is often criticized for being, among other short comings, “less than perfect”. But like the human communication vehicles known as “natural languages” it too has evolved to fit its purpose and become widely accepted as a result.

[iii] This is the reason why the choice of using a NOSQL style database is, or should be, as much a business decision as a technical decision.  What needs to always be taken into consideration are the possible hidden costs of implementing a database solution that does not support SQL. Especially in light of the fact that SQL has become a virtual “lingua franca” of data analysis and business intelligence. These costs may be hidden from the group making the NOSQL database decision since it is quite likely they are not the  same group that uses SQL to answer business questions.

[iv] Sadalage and Fowler, page.13.

[v] Sadalage and Fowler, page.17.

[vi] Vladan Jovanovic and Steven Benson, Aggregate Data Modeling Style, Proceedings of the Southern Association for Information Systems Conference, Savannah, GA, USA March 8th–9th, 2013, page 75.

[vii] Parties are often first specialized into “Persons” and “Organizations” but whether a party is only one or a group is not relevant to our discussion here.  Instead I used a sub-categorization that is more reflective of the role that a party plays in an exchange.

[viii] In earlier articles on 6BI the term “Product” as the name of the 1st level BOC that corresponds with the “what” interrogative was used. Product however is not universal enough.  For lack of a better term I use “Thing” to include Money along with Goods and Services.

[ix] In earlier articles on 6BI the terms “Plans” and “Rules” were used as BOCs that correspond with the “why” interrogative. But these are only Means, not Ends, and “Why” needs to include both Ends and Means.

The Data Architecture of Business Plans Part 2 – Key Performance Indicators

November 9, 2013

In the first part of this article about the data architecture of business plans https://waynekurtz.wordpress.com/2013/09/28/the-data-architecture-of-business-plans-part-1-an-overview/, we discussed an industry standard meta-model for modeling business motivation[i].  We started with the four core elements of business plans: End, Means, Influencer, and Assessment.  We identified Desired Result as the type of End that an enterprise intends to maintain, and Goal and Objective as two types of Desired Result.  We also included Measurement as an expression of an Objective. On the Means side we identified Course of Action which represents the approach or plan for configuring some aspect of the enterprise, Strategy as the essential Course of Action for carrying out the enterprise’s plan, and Tactic as the means to implement the Strategy.

An Assessment, we’ve seen, is a judgment about the impact of Influencers on the enterprise’s Desired Results and Courses of Action[ii].  Assessment Elements are the components of an Assessment that link it to individual Desired Results and Courses of Action.  The net effect of an Assessment Element is the identification of a measured Potential Impact[iii].

A Key Performance Indicator (KPI) is a type of Assessment that is a judgment about the impact of the difference between two measurements, the Target Expression, associated with a Desired Result and the Result Expression, associated with a Course of Action.

Desired Results

Figure 10 illustrates the relationship between a Desired Result and a Key Performance Indicator.  A Key Performance Indicator has exactly one Target Expression which is based on one and only one Objective which quantifies one and only one Goal.  As we’ve already observed, both Goal and Objective are types of Desired Result.  If the Desired Result is a Goal it may be quantified by one or more Objectives.  Each Objective may be the basis of one or more Target Expressions.  Each Target Expression is a part of one and only one KPI.

Figure 10.  Desired Results and Target Expressions.

2.1-10 Desired Results & KPIs

However, not all Goals are stated in a way that makes them easily quantifiable by an Objective.  When a Goal cannot be quantified by a set of Objectives one of two things is bound to happen.  Either the Goal becomes more or less irrelevant to the operation, productivity or culture of the enterprise and thus its significance is eventually deprecated, or Objectives that quantify it are eventually defined, vetted and socialized.  There is a thin line between Goals and Objectives, as we’ve seen they are really just two types of the same thing, Desired Results.  The difference between them is driven by the fact that we need a way to differentiate between Desired Results that can be measured and those that cannot.  For purposes of performance management we ignore those that cannot be measured.

Courses of Action and Result Expressions

Figure 11 illustrates the relationship between a Course of Action and a Key Performance Indicator.  A Key Performance Indicator has exactly one Result Expression which is based on one and only one Actual Result which is produced by one and only one Business Process which may employ one or more Efforts.  Each Effort is invoked by one and only one Course of Action.  However, a Course of Action may be invoked via one or more Efforts, each of which is used by one and only one Business Process.  Each Business Process may produce one or more Actual Results, each  which may be the basis of one or more Result Expressions. A Result Expression is a part of one and only one KPI.

Figure 11.  Courses of Action and Result Expressions.

2.1-11 Courses of Action & KPIs

It is assumed that the Potential Impact of a KPI can be judged, usually in discrete intervals, along a continuum from very positive or very negative.  What constitutes positive or negative for any KPI is determined by the requirements of the business and is subject to change over time.  This fact is why configuration management of KPIs is important. Without configuration management, the ability to compare not just KPI status and trend values from period to period, but the evolution of the method by which they were calculated can be tracked.  This becomes more important as organizations begin to not only use KPIs to do assessments and influence behavior, but also to judge the effectiveness of the KPIs themselves, their relevance to changing business patterns and their effectiveness in bringing attention to areas that need it.  In this article however we are primarily interested in the design and construction of KPIs and not as much in how they potentially impact and are impacted by various influencers.

The Role of Effort

Figure 12 illustrates the central role that Effort plays in the meta-model of the data architecture of business plans.  A Course of Action, as we saw in Figure 11, may be invoked via one or more Efforts.  The figure also shows that a Desired Result may be supported via one or more Efforts. It shows that a Business Process may employ one or more Efforts.   Finally, a Party, which is either a Person or an Organization, may be a player of one or more Party Roles, one of which then may perform one or more Efforts.

From the perspective of an Effort it is invoked by one and only one Course of Action, in order to achieve one and only one Desired Result.  It is also used by one and only one Business Process while it is performed by one and only one Party Role.

Figure 12. The central role of Effort in the business plans meta-model.

2.1-12 Central Role of Effort

As stated earlier an Influencer is anything that can produce an effect on the enterprise without apparent exertion of tangible force or direct exercise of command[iv].  As depicted in Figure 13 we see that an Effort may be assessed by one or more Key Performance Indicators in the same way that an Influencer may be assessed by one or more Assessments. Correspondingly, a KPI assesses one and only one Effort, as an Assessment of which it is a subtype, assesses one and only one Influencer.

Figure 13. Key Performance Indicators and Influencers.

2.1-13 KPI & Influencers

Key Performance Indicators

There are many different perspectives from which an organization’s performance can be viewed.  There are also many different aspects in which each perspective on performance can be viewed.  One aspect is that of motivation, or “why” has the performance turned out as it has and how can the organization improve its performance.  At each perspective of the Motivation aspect[v] “why” type questions need to be answered.  Answers to these questions are aided greatly by the assessments of the measurements that indicate the performance of the organization.  These indicators are called performance indicators, and most organizations have a large number of them.  Many of these are recorded because they “always have been” and others simply because they are relatively easy to produce.  In order to provide decision makers with just the right set of performance indicators at the right time, the concept of the Key Performance Indicator (KPI) was developed.  A KPI is not only an indicator of some aspect of performance but it is critical to improving that aspect of performance.  It is also “key” because it can be clearly associated with a perspective of the enterprise.  For example, there are KPIs that assess performance at the Planner perspective, at the Owner perspective, at the Designer or Architect perspective, at the Builder perspective, at the Subcontractor perspective, and even at the Functioning Enterprise perspective[vi].  The higher the perspective is in the enterprise architecture, the more strategic its assessments tend to be.

There are many business performance oriented books and articles that describe techniques for determining which performance indicators are Key Performance Indicators, and a study of how to select the best KPIs is beyond the scope of this article.  Suffice it to say that the process is very specific to both the organization and its industry.  There can be almost an unlimited number of performance indicators in any good sized enterprise.  Not all performance indicators are of equal importance when it comes to assessing the performance of an enterprise.  A performance indicator is said to be “key”, and thus a Key Performance Indicator when it can be demonstrated through measurements, that it is an indicator of the enterprise’s ability to accomplish its goals and objectives through the carrying out of its mission by strategic, tactical and operational means.

In this article we are interested in the data architecture of KPIs.  Figure 14 illustrates the structure of a Key Performance Indicator. Since KPIs are Assessments of Effort and an Effort may be composed of other Efforts, a Key Performance Indicator may also be composed of other Key Performance Indicators.

Figure 14. The Key Performance Indicator meta-model.

2.1-14 KPI Metamodel-A

In the meta-model of the business plans data architecture a Key Performance Indicator always has one each of three (3) expression elements.  These are:

  • Target Expression (aka Target) which is part of one and only one KPI and is based on one and only one Objective.  An Objective may be the basis of more than one Target Expressions however, and thus may be used in more than one KPI.
  • Result Expression (aka Result) which is part of one and only one KPI and is based on one and only one Actual Result.  An Actual Result may be the basis of more than one Result Expressions however, and thus may be used in more than one KPI.
  • Status Expression (aka Score) which is part of one and only one KPI and is used to indicate how the Result Expression compares to the Target Expression.  It uses one  Result Expression and one Target Expression.  Each of which is used in exactly one Status Expression.  It can take the following forms:
    • A Score expressed as a percentage where the Result Expression is divided by the Target Expression, or
    • A Function that returns a normalized value between -1 and 1 where 1 is interpreted as “Result is very good” and -1 is interpreted as “Result is very bad

The Status Expression is often expressed graphically as an indicator using a set of color-coded graphic icons.  For example: red, yellow or green icons to represent the different judgments made by the KPI.  The specific indicator associated with the different states of the Status Expression is determined according to some Scoring Pattern and Banding Method combination, as we shall see shortly.

Figure 14 also shows the other four (4) optional elements of a KPI.  These include:

  • Trend Expression (Trend) which shows the directional change in the Status Expression.  It can either show the change period over period, or be derived by a formula that returns a normalized value between -1 and 1 where 1 is interpreted as “Status is getting a lot better” and -1 is interpreted as “Status is getting a lot worse”.
  • Weight Expression (Weight) which returns the relative weight of the KPI.  If a KPI has a parent KPI you can define the weight to control the contribution of a KPI to its parent. For example, if there are two child KPIs, one weighted at 60% and the other at 40%, the parent KPI would be more influenced by the former than the latter.
  • Time Expression which returns the current time dimension member that is relevant for the KPI.  For example, time can be expressed either as a Point in Time indicating the KPI assesses the performance of an Event, or a duration, the difference between two points in time, to indicate performance assessment over a period of time.
  • Responsible Party who is typically the person or organization responsible for the KPI.  This responsibility can be for maintenance such as changing and updating any of the expression elements of the KPI.  The responsibility can also be accountability for the performance of the enterprise underlying the KPI.  These two responsibilities may or may not belong to the same Party.  If it is the same party then issues of conflict of interest may arise.  Over time, maintenance of KPIs and the Measurements on which they are based is very important.  If KPIs are expected to continue to be relevant and return value to the enterprise they must be adjusted to reflect changing business conditions.

KPI Scoring and Banding

Probably the most common scoring and banding combination for Key Performance Indicators is illustrated by the example in Figures 15 and 16[vii].  This technique is referred to as “Increasing is Better – Actual Values”.   In this method the higher the Score the better, with the Score determined by dividing the actual Result value by the actual Target value and expressing it as a percentage.  Quite often a maximum Score value is set.  Figure 15 illustrates this technique with five (5) component measurements rolled up into one composite measurement.  The composite Score (119.95%) is simply the sum of the component Scores divided by the number of component KPIs (listed under “Measure” in the example below).

Figure 15. An example of an “Increasing is Better – Actual Values” type composite KPI.

2.1-15 Scorecard BAR-02+Comp measure

As illustrated in Figure 16, threshold values are determined for the scoring bands of the KPI (three in this case) labeled “Good”, “Average” and “Poor”.  If the Score is equal to or greater than 100%, it is assessed as “Good” and the Status indicator is a green square, if the Score is less than 100% but equal to or greater than 90% it is assessed as “Average” and the Status indicator is a yellow triangle, and finally if the Score is less than 90% it is assessed as “Poor” and the Status indicator is a red circle. KPIs for which there is no score are shown as white circles.

Trend is calculated by taking the difference between the current period Score and some previous period Score (in this case the previous month).  If the difference is positive, an upward pointing “arrow in a circle” icon is displayed, if the difference is negative the arrow points downward, and if there is no change the circle icon has no arrow.  Each KPI has a name, in this case “Administration” and a description (not shown).  They are grouped into both Program and Strategic Scorecards which can then be incorporated into operational, tactical and strategic dashboards.

Figure 16. An example of a Scorecard with KPI scoring bands.

2.1-16 Scorecard BAR-01

For performance assessment problems requiring more complex calculations, expressions are used instead of raw values when comparing the Result value to the Target value.  This is a technique available in many BI and enterprise performance management (EPM) tools today.  Rather than using the raw Target and Result values to calculate a Score, the results of a Target Expression and a Result Expression are factors in the calculation of a Status Expression.  The two KPIs in Figure 17, though more simple in appearance, are intuitive in design and actually represent more complex calculations than the previous example.

The challenge here is to assess the performance of an institution in reducing criminal assaults cumulatively over a number of years.  The top KPI represents performance for 2006 and the bottom for 2007.  The Desired Result is stated in terms of the number of assaults per population of 1,000, the strategic Goal is to reduce assaults by 5% over a four year period, so the tactical Objective is to decrease the percentage by 1.25% each year.  A Target Expression is used to calculate the Target value (labeled as “Goal”) applying each year’s percentage reduction to the previous year’s Target value thus producing a progressively aggressive Target.

The Actual Result produced by the Business Process is calculated by a Result Expression and expressed as a Result value (labeled “Value”).  For 2006 the Result is 0.9892 and the Target is 0.9875, which is 1.25% less than the Target for 2005.  This performance is assessed as “Average” by the Status Expression and banded with a yellow Status indicator (the middle yellow segment of the dial icon).  The Trend is downward, i.e. there were fewer assaults in 2006 than in 2005, and thus the Trend indicator (the arrow) is pointed downward, and this is better than the previous period (2005) so the Trend indicator arrow is green.  This is an example of a “Decreasing is Better – Actual Values” type of KPI.

In 2007 the Target is decreased to 0.9765 per 1,000 population, making the criteria for the “Good” and “Average” performance bands more stringent to meet.  In the bottom KPI we see that the Actual value is 1.0648 thus pushing the Status indicator into the “Poor” band (the right-hand red segment of the dial icon) and causing the Trend indicator to point upward, because of the increase in Actual value and turn red because of the increase in percentage, calculated by the Result Expression, over the 2006 percentage.

Figure 17. An example of a “Decreasing is Better – Actual Values” type of complex KPI.

2.1-17 Complex KPI together

The Trend icon is an example of the use of one graphic icon to display two measurements.  The direction of the arrow indicates the direction of the Trend, up or down, and the color indicates the judgment of that direction expressed, green for “Good” and red for “Poor”.  This can be confusing if not explained.  Also the use of color alone to indicate a state of performance means that about 10% of the adult population cannot discern its meaning because of color blindness.  The example above is used to illustrate a concept not necessarily to indicate best KPI display practices.

Scoring Patterns and Banding Methods

The Scoring Pattern of a KPI (as seen above) indicates whether it is better to have a Result that is increasing, decreasing, or as close to the Target as possible, without being either higher or lower.  The table below describes the three KPI Scoring Patterns.

Scoring Pattern

Assessment Criteria

Increasing is Better In general, the greater the value of the Result the better.  Usually if the Result is greater than the Target it is considered to be a positive condition.  For example, under most circumstances it is considered better to have increasing revenue.  KPIs assessing revenue topics are generally banded as “Increasing is Better”.
Decreasing is Better In general, the less the value of the Result the better.  Usually if the Result is less than the Target it is considered to be a positive condition.  For example, under most circumstances it is considered better to have decreasing costs.  KPIs assessing cost topics are generally banded as “Decreasing is Better”.
Closer to Target is Better In general, the closer the Result is to the Target the better.  Usually if the Result is exactly the same value as the Target it is considered to be a positive condition.  For example, under most circumstances meeting headcount targets as close as possible in a given period is considered better than either hiring too few people or hiring too many people.

The Banding Method determines if actual values, normalized scale values or some other method is to be used to arrive at the Result value and Target value.  Banding Method however does not determine how many bands are used.  Many KPIs use three scoring bands because it is the simplest way to convey the relationship between a Target Expression and a Result Expression.  The table below describes three KPI Banding Methods.

Banding Methods

Assessment Criteria

Actual Values Banding is done using the quotient of the Actual value divided by the Target value which is referred to as the Score.
Normalized Actual over Target Banding is done using a Function that returns a normalized value between -1 and 1 where 1 is interpreted as “Result is very good” and -1 is interpreted as “Result is very bad”.
Stated Score An advanced technique where stated scores may be systematically substituted for Actual and Target values.

Summary

In this article we have attempted to show a way to extend the data architecture of business plans from the Ends and Means of the Business Motivation Model[viii] all the way to the Key Performance Indicator, a widely used Assessment tool for determining the success or failure of those plans.


[i]  “Business Motivation Model, Version 1.0” published in August 2008 by the Object Management Group (OMG). For more refer to http://www.omg.org/ .

[ii] Influencers can have an impact on other types of Ends such as the enterprise’s Vision, and other types of Means like Mission and Directive as well.

[iii] Hay, Page 187.

[iv] Hay, page 187.

[v] The Zachman Framework for Enterprise Architecture.

[vi] See earlier references to the Perspectives of the Zachman Framework for Enterprise Architecture.

[vii] Courtesy of  the “Boston About Results” program, Boston, MA, USA.

[viii] The Business Motivation Model, Business Governance in a Volatile World, The Business Rules Group, Copyright 2007, The Business Rules Group.

The Data Architecture of Business Plans, Part 1 – An Overview

September 28, 2013

This article was first published August 1, 2010 on The Data Administration Newsletter (TDAN) website but is no longer available there.  It is the first of a two-part series presenting a simple model for capturing the structure of the “why” aspect of the Zachman Framework.

 

In this article about the data architecture of business plans we will look at a standard meta-model for modeling business motivation.  From an enterprise architecture prospective a business plan is the type of artifact produced at the intersection of the Business Model perspective (row two) and the Motivation aspect (column six) of the Zachman Framework, one of the most widely recognized and referenced frameworks for enterprise architecture [i].  Since models of business motivation are of most importance to business owners, this perspective is also referred to as the Business Owner perspective and the corresponding standard meta-model as the Business Motivation Model[ii].

We will explore how the standard meta-model can be extended to support the data architecture of key performance indicators (KPIs) which are popular assessors of the measurements of business performance.  These measurements are often assessed in reference to the goals and objectives of the enterprise.  KPIs are widely used tools in enterprise performance management (EPM) scorecards, which are in turn ubiquitous components of all three types of performance dashboards:  Strategic, Tactical and Operational[iii].

The Motivation aspect addresses the question of why certain courses of action are chosen or should be chosen, why certain types of persons and organizations are important, why certain products should be more heavily invested in and why corrective actions need to be taken for others, why certain events are important, and why some locations are preferred over others.  We will take a look at the structure of the data that describe the Motivation aspect of the enterprise from the perspective of the Business Owner.  The data we will model in this article describe the entities and relationships of the data content that describes the “real world” motivations of an enterprise and thus we refer to it as metadata and the models used to understand it as meta-models.

From a Six Basic Interrogatives or 6BI[iv] point of view, when we are creating or vetting the design of a software application intended to support decision making, we seek answers to questions that will tell us “why” our client makes or should make certain business decisions and not others and “why” it is worth making the investment necessary to build (or buy) the solution we are proposing and not take another course of action.  These “why” questions are just as important to ask as questions such as “what” information do we need to make the application a reality; “who” will use the application, and “how” do we measure our success.

Business Motivation Modeling

There are three business architecture models that address the Motivation aspect of the Business Owner’s perspective of an enterprise.  These models are high level views that do not depend on any particular technology.  In developing an enterprise performance management solution we will usually begin with one or more of the following business motivation models:

  • Business Goals Hierarchy (BGH)
  • Business Opportunities Hierarchy (BOH)
  • Business Problems Hierarchy (BPH)

These are business architecture models designed to show details of the business vision and strategy of an enterprise.  In practice the level-of-detail will vary with the scope of the engagement.  If we are engaged at the top executive level then the scope is enterprise-wide.  If we are engaged at the departmental or business unit level of an organization then the level-of-detail will need to be aligned with the scope of the sponsoring department or business unit in order to deliver value to the client.  The scope of the goals, opportunities or problems determines the scope of the strategy.  There are no well defined, hard and fast criteria for differentiating one level-of-detail from another.  The levels are there as guidance to help us think more architecturally about the aspects of the business of an enterprise.

Each model depicts, in a hierarchical fashion, a different type of motivator.  Each of the business motivation models is composed of a hierarchical set of “is a kind of” relationships. One approach is to start at the top with what is sometimes referred to as the apex motivator of the organization.  For example, what is the organization’s single most important goal.  This is most often a financial goal, but with the emerging interest in sustainability and the “triple bottom-line” may now incorporate environmental and social objectives as well.

In each model, the types of motivators depicted become more specific, finer grained, and less abstract as one progresses down the hierarchy, until reaching the “leaf node” of each branch.  Another approach is to start as close to the leaf level as possible and to progress up, across and down the hierarchy all at more or less the same time.  Many business analysts advocate, for reasons we need not discuss here, that this is the only practical way to actually make progress in a constrained time frame.  In either case a hierarchy of motivators is created.

The apex business goal is the highest level, most abstract and most all-encompassing of all the business goals in the subject area of the BGH (Business Goals Hierarchy).  The apex business opportunity is the highest level business opportunity in the BOH (Business Opportunities Hierarchy) and similarly with the Business Problems Hierarchy (BPH).

Though the three models, BGH, BOH and BPH, have virtually identical structures, goals tend to be more strategic in nature, while opportunities and problems, which are more immediate in nature, tend to be more tactical or operational.  In this article we will use the Business Goals Hierarchy to illustrate the concepts behind the data architecture of business plans.

Core Business Plan Elements

Figure 1 presents the core elements of the meta-model for business plans.  Business motivation is fundamentally about four things: Ends, Means, Influencers, and Assessments.  Anecdotally, Ends are where we want to get, Means are how we get there, Influencers are people, processes and technology that can influence getting there, and Assessments are how we measure if we got there.

Figure 1. Core elements of the Business Plans meta-model.

1.1-01 Core Elements Model

Correspondingly, in our meta-model, an End is something that an enterprise sets out to accomplish.  A Means is any capability that can be called on, activated, or enforced by the enterprise to achieve an End [v].  An Influencer is anything that can produce an effect on the enterprise without apparent exertion of tangible force or direct exercise of command[vi].  The effect of Influencers on Means and Ends is determined by one or more Assessments.  An Assessment is a judgment about the implications of the Influencer either with respect to one or more Means or with respect to one or more Ends.  Since an Assessment can have multiple implications, each Assessment must be composed of one or more Assessment Elements. Each of these Assessment Elements then must exist with respect to either one Means or one End [vii].

In other words, the metadata describing the data architecture of business plans also describes a re-useable template for building data models to analyze, compare and improve those plans.  Architecturally business plans must include data elements that represent the answers to the basic interrogatives that the plans are created to address.  These basic interrogatives will include: “What is the objective that is intended to be accomplished?” – the End; “How does the process work that will get the end accomplished?” – the Means; “Who are the people and organizations that influence the process?” and “What are the technologies and other processes that will get it accomplished?” – the Influencers; and, “When was or will it be accomplished, and “How closely to expectations did it turn out to be?” – the Assessments.  These are the meta-dimensions[viii] of the problem space.

Data elements that support the “When” interrogative, though not explicit in Figure 1, are very important as well, because we can accomplish our Ends through our planned Means, taking advantage of the appropriate Influencers and still fail our Assessment because the goals were not accomplished on a timely basis.

Ends

Figure 2 expands the business plans meta-model into two types of End: the Vision, which is the primary End that the enterprise sets out to accomplish, and the Desired Result, which is a state or target the enterprise intends to maintain[ix].

There are two types of Desired Result: Goals and Objectives. A Goal is a Desired Result that is a specific statement about a state or condition of the enterprise to be brought about or sustained through appropriate Means[x].  A Goal is an implementer of a Vision.  That is, where a Vision describes a future state of the enterprise in general, Goals define the steps to be taken to accomplish that Vision.  A Goal, by definition, is more narrow than a Vision.  A Vision is a broader or grander end state and cannot be specifically measured by Objectives, as a Goal can.

Figure 2. The Ends subject area in the Business Plans meta-model.

1.1-02 Ends Types Model

An Objective, on the other hand, is a statement of an attainable time-targeted and measurable Desired Result that the enterprise seeks to meet in order to directly achieve its Goals and through these, its Vision[xi].  An Objective, since it is measureable, quantifies a Goal. A Goal can be quantified by one or more Objectives, but an Objective can measure one and only one Goal.  A Measurement is a specific value expressing one state of an Objective.  An Objective can be expressed, usually serially over time, by one or more Measurements, but a Measurement expresses one and only one Objective.

Note from Figure 2 that a Desired Result can be composed of other Desired Results, thus creating a hierarchical structure.  Since Goals and Objectives are types of Desired Result, they too can have a hierarchical structure[xii].  This is the basis for the hierarchical structure of business goals in the Business Goals Hierarchy where higher level goal instances are composed of successively lower level goal instances until we reach the leaf level of atomic goals.  It should be noted that Measurements can be associated with any level of Objective and through this to any level in the hierarchy.

Business Goals Hierarchy

The Business Goals Hierarchy in Figure 3 describes Goals which the enterprise must achieve in order to accomplish its Vision.  In the BGH, Goals and Measurements are shown in the same model.  Typically Goals are depicted as orange “corner clipped” rectangles, and Measurements are depicted in the same model as yellow “corner clipped” rectangles[xiii].

Figure 3. A Business Goals Hierarchy (BGH).

BGH example

The fact that a Measurement measures one and only one Goal is an important quality control factor and provides a clear assessment vehicle for performance indicators, as we will see.  If a single Measurement is allowed to express more than one Objective and thus more than one Goal, there is no way to unambiguously trace a performance indicator using that Measurement back to the Vision of the enterprise and thus determine if it is a “key” performance indicator or not.

Of the three business motivation models (BGH, BOH and BPH) it is often advisable to start with the BGH first.  Identifying a set of business goals as the first deliverable of a workshop establishes the scope early in the process and helps assure that the client receives value for their investment from the start by identifying the Ends that the client wishes to accomplish.  It is the purpose of the BGH to capture and organize the Goals that will implement these Ends.  However it is critically important that the goals be attainable, that measurable Objectives be set for them, and that they are vetted by the organization.  There is sometimes the temptation to get the BGH over with quickly and get on with more tangible elements, but this would be a mistake.  The BGH helps us to stay on track and solve the right problems for the enterprise.  As other artifacts are developed it is always useful to go back to the BGH and ask yourself  “Does what I am doing now help to accomplish the business goals?”

Starting with the BGH can mean either discovering the business goals, through interviews, documents, or other information gathering methods, separately or in combination.  Or it could mean recording Goals that the enterprise has already identified and organizing them hierarchically.

One challenge in this process is getting participants to think “hierarchically” about business goals.  Quite often business goals are not tied together in people’s minds nor in documentation in such a way that they easily roll up to higher level business goals or roll down to lower level business goals.  Also, quite often business goals and objectives are not differentiated.  In order to facilitate an architectural approach to business we need to often disambiguate terms that are used interchangeably.  Business goals and objectives are examples of terms that need to be disambiguated in order to produce clear and executable business plans.

Means

There are three types of Means depicted in Figure 4, another portion of the business plans meta-model.  There is the Mission which is the primary Means by which the enterprise plans to make its Vision operative; the Course of Action which is an approach or plan for configuring some aspect of the enterprise; and the Directive which is a specification that governs or constrains a Course of Action[xiv].

Figure 4. The Means subject area in the Business Plans meta-model.

1.1-04 Means Types Model

A Course of Action must be either a Strategy or a Tactic[xv].  A Strategy is the essential Course of Action attempted to carry out an enterprise’s Mission.  The enterprise Mission, being the ultimate Means, can sometimes, though rarely, be carried out by more than one Strategy, especially for enterprises as vast as national governments or international corporations.  For that same reason it is impossible for a Strategy to carry out more than one Mission[xvi].  A Tactic is a Course of Action that implements a Strategy by representing one or more details of that Strategy[xvii].  A Strategy can be implemented by one or more Tactics, but a Tactic is the implementer of one and only one Strategy.

A Course of Action can be composed of one or more other Courses of Action.  However this compositional parent-child relationship does not cross Course of Action types.  In other words, one Strategy may be a part of another Strategy, and one Tactic may be a part of another Tactic.  But Tactics are separate element types from Strategies, they are implementers of Strategy, not parts of a Strategy.

The third type of Means, the Directive must be either a Business Policy or a Business Rule.  A Business Policy is a non-actionable Directive that guides the activities of the enterprise or governs them in a general way.  It “governs”, it does not control or shape Courses of Action[xviii].  A Business Rule is a more specific and actionable constraint on the enterprise.  In particular, based on a Business Policy, it imposes a constraint on a fact or fact type[xix]. A complete look at business policies and rules includes elements that describe enforcement levels, implementations of the enforcement levels, invocations of the consequences that are the result of the enforcement level implementations, and how enforcement levels and consequences are affected by tactics.  All of which are outside the scope of this article.

A Course of Action can also enable one or more other Courses of Action.  Enabling is not the same as implementing.  For example, a tactical Course of Action of an enterprise might be “Provide unified communication capabilities (i.e. integrated voice, email, instant messaging and video conferencing) to all employees”.  This Tactic may enable the Tactic “Reduce intra-company communication delays”, which may in turn enable the Strategy “Improve company responsiveness”.  Figure 5 shows the meta-model of this relationship.  In it, the element Enablement implements a composite relationship between two Courses of Action.  One Course of Action is the enabler of the relationship, while the other Course of Action is enabled by the relationship.

Figure 5. Enablement of Courses of Action.

1.1-05 Enablement Model

Strategies and Goals

The link between an enterprise’s Ends and Means is characterized as the relationship between its Vision and Mission.  A Vision may be made operative by one or more Missions, and a Mission makes operative one and only one Vision[xx].   However most business planning activity takes place at the strategic level rather than at the mission level.   In making strategic decisions, an enterprise’s mission is often considered a constant set of values that the strategy must carry out.  With this in mind it makes sense to model the relationship between a Strategy, which is a type of Course of Action, and the Desired Results that describe it. Figure 6 illustrates this relationship. In it a Strategy may be described in terms of one or more Desired Results, each of which is either a Goal or an Objective.

Figure 6. Strategies and Desired Results.

1.1-06 Strategy & Desired Results

On the other hand a Goal, which is a type of Desired Result, may be the target of one or more Courses of Action, each of which is either a Strategy or a Tactic.  This relationship is illustrated in Figure 7.

Figure 7. Goals and Courses of Action.

1.1-07 Goal & Courses Actions

The basic takeaway here is that Courses of Action can be traced directly back to the Desired Results that motivate them.

Influencers and Assessments

To fully understand the meta-model of the data architecture of business plans it is necessary to understand not just its Ends and Means, but also with the real world things that influence them.  These we call Influencers, where an Influencer is anything that can produce an effect on the enterprise without apparent exertion of tangible force or direct exercise of command[xxi].

The effect of Influencers on Ends and Means is determined by one or more Assessments, where an Assessment is a judgment about the implications of the Influencer either with respect to one or more Means (such as a particular Course of Action) or with respect to one or more Ends (such as a particular Desired Result)[xxii].

Figure 8 shows that portion of the meta-model that represents Influencers and Assessments.  We can see that an Influencer is an example of one and only one Influencer Type.  These types can be as basic as “Internal Influencer” and “External Influencer”, which tell us very little about this element, or all the way to a full taxonomy of Influencer Types, which can include all aspects of an enterprise.  Influencer Types can also be nested in a supertype-subtype generalization hierarchy.  A full analysis of influencers is well beyond the scope of this article.  We also see that while an Assessment assesses one and only one Influencer, each Assessment must be composed of one or more Assessment Elements.  Each Assessment Element, as was observed earlier, in Figure 1, must exist with respect to either one Means or one End.  

Figure 8. Influencers and Assessments.

1.1-08 Influencers Assessments

It is the Assessment Element and the fact that it may be revealed by one or more Potential Impacts on the enterprise that is the basis for the Key Performance Indicator (KPI).  Figure 9 introduces the KPI into the meta-model as a type of Assessment.  Because a KPI can be composed of other KPIs it has a reflexive parent-child relationship with itself.  Each Assessment has its own types of Assessment Elements.  Frequently encountered Assessment Elements include those used in “SWOT” analysis, such as Strengths, Weaknesses, Opportunities and Threats.

Every KPI must have at least three Assessment Elements.  Target Expression, Actual Expression, and Status Expression are each a mandatory part of a KPI.  In addition it can have other Assessment Elements which are optional.  We will discuss these and other aspects of the data architecture and meta-model of KPIs in the second part of this article.

Figure 9. Assessments and KPIs.

1.1-09 Assessments & KPIs

Conclusion

The data architecture of business plans, also known as the Business Motivation Model, is important because it can be used to trace the results produced by Assessment Elements like Key Performance Indicators back all the way to the core motivational elements of an enterprise, its Ends and its Means.  If the chain of traceable associations from Assessments like KPIs is unbroken, it is possible to architecturally trace back to the Desired Results that motivate an enterprise’s Courses of Action to understand the rationale for the Measurements used in the Assessment Elements of Key Performance Indicators that provide the most relevant picture of an enterprise’s performance.  A refrain often heard in EPM projects is “Are we measuring the things that really matter?”  “What are the things that will make the most difference to the enterprise?” With this two part article we will show that you can verify and validate these important associations through traceability all the way to the enterprise’s Ends and Means.  In the second part of the article we will discuss how KPIs, Scorecards and Dashboards tie these elements together.


[i] I am referring to the co-ordinates of the Zachman Framework for Enterprise Architecture, first discussed in 1987, and extended in “Extending and Formalizing the Framework for Information Systems Architecture”, J.F. Sowa and J. A. Zachman, IBM Systems Journal, vol. 31, no. 3, 1992. IBM Publication G321-5488.   For more on the Zachman Framework please refer to the website http://www.zifa.com/ .

[ii] Concepts in this article are based on the publications: “The Business Motivation Model, Business Governance in a Volatile World”, The Business Rules Group, Copyright 2007, The Business Rules Group, For more information refer to http://www.BusinessRulesGroup.org.  This publication has since been replaced by the “Business Motivation Model, Version 1.0” published in August 2008 by the Object Management Group (OMG). For more refer to http://www.omg.org/ .

[iii] The view that there are three types of performance dashboards comes primarily from: Performance Dashboards: Measuring, Monitoring, and Managing Your Business, Wayne Eckerson, John Wiley and Son, October 2005. For more information see http://www.wiley.com/WileyCDA/WileyTitle/productCd-0471757659.html.

[iv] “Six Basic Interrogatives – Parts 1, 2 and 3, http://www.datawarehouse.com/article/?articleId=5140 .

[v] Data Model Patterns: A Metadata Map, David C. Hay, The Morgan Kaufmann Series in Data Management Systems, Morgan Kaufmann, 2006.  Page 277.

[vi] Hay, Page 284.

[vii] Hay, Page 287.

[viii] Please forgive me for introducing yet another term into our ever growing business and IT vocabularies, but the metamodel of a dimensional database design would contain “meta-dimensions”, would it not?

[ix] Hay, Page 277.

[x] Hay, Page 277.

[xi] Hay, Page 277.

[xii] In object oriented terminology we would say that “Goal” is a sub-type of “Desired Result” and inherits its properties, including its relationships.  In this case the relationship is an aggregation, or “part of “ relationship, with itself, creating a reflexive relationship.

[xiii] The color and symbol are arbitrary of course, but standard representations enhance readability and give the same type of artifact consistency across projects giving a type of “human resource” re-usability. After all if a consistent symbol is always used to represent the same type of thing less re-learning, is required. This also a principle of good data display, always use the same color to represent the same thing.

[xiv] Hay, Page 278.

[xv] Hay, Page 278.

[xvi] As a comment I would add  that it is often when an enterprise attempts to use a strategy to accomplish more than one mission that it loses sight of the original mission of the strategy and adds unnecessary and dangerous ambiguity to that mission.

[xvii] Hay, Page 278.

[xviii] Hay, Page 280.

[xix] Hay, Page 280.

[xx] Hay, Page 276.

[xxi] Hay, Page 284.

[xxii] Hay, Page 285.

Six Basic Interrogatives – Part 3, 6BI and Business Performance Management

August 29, 2010

In this concluding part of the article about 6BI, I will develop its analysis potential further, show how it compares with architecture frameworks, and cover how it can be utilized for traceability back to the enterprise’s mission statements in order to lend credibility to business performance management (BPM) reporting.

This part was first published in February 2005 under the title “Six Basic Interrogatives – Part 3, 6BI and Business Performance Management ” on the no longer existing Datawarehouse.com website.

Six Basic Interrogatives – Part 3

In two previous articles published in DataWarehouse.com, I described the Six Basic Interrogatives (6BI) Design Framework.  In the first article, 6BI was described as an approach to designing databases that support business intelligence applications.  In the second article I gave a very simplified example of a scenario and how instances of the business object categories can be identified, as well as introduced my color scheme.  In this article I will develop the analysis potential of 6BI further, show how it compares with the Zachman Framework and other architecture frameworks, and cover how 6BI can be utilized for traceability back to the enterprise’s mission statements in order to lend credibility to BPM reporting.

The 6BI Design Framework is a pattern for designing data warehouse dimensions, but it is more than that.  It abstracts all dimensions of business intelligence into the six categories of questions that a BI application user might ask. Combinations of questions from these six categories make up the requirements for the models and reports needed by management, analysts, and others within an organization to support decision making.  As such, 6BI is an approach that can be used to gather and analyze requirements, and perform gap analysis between “as is” and “to be” models, as well as design the solutions to meet those requirements and close the gaps.

The six categories of the 6BI Design Framework align with the columns of the Zachman Framework for Enterprise Architecture.  The Zachman Framework has been widely accepted throughout private industry and has been adopted as a basic building block for major enterprise architecture initiatives within the U.S. Federal Government.  Two of these initiatives, in response to the Clinger-Cohen Act of 1996, are the Federal Enterprise Architecture Framework (FEAF) and the Department of Defense Architecture Framework (DoDAF)[1].

The first three rows of the Zachman Framework are Scope, Business Model, and System Model, and represent the Planner’s view, Owner’s view, and Designer’s view of the enterprise respectively[2].  Though originally developed for private sector enterprise information systems, the framework can be (and is) applied to the DoDAF as well, where Scope aligns with Mission Statement, Business Model with Operational Architecture (OA) View, and System Model with Systems Architecture (SA) View, see Figure 1 below.  I am going to show how the 6BI Design Framework aligns with both the Zachman Framework and the DoDAF, through the six basic interrogatives.  This alignment shows how 6BI can be used to analyze requirements and design solutions as part of both operational architectures and systems architectures that are in synch with an enterprise’s mission.

Figure 1. Zachman Framework and DoDAF alignment.

View Zachman Framework DoDAF
Planner Scope Mission Statement
Owner Business Model Operational Architecture View
Designer System Model System Architecture View

The applicability of 6BI to requirements analysis and solution design is especially true in the area of Business Performance Management (BPM).  It is true whether the business is a for-profit enterprise, a not-for-profit organization, or a government agency.  The six basic interrogatives and their corresponding business object categories define the context for aligning an enterprise’s Mission Statement with its OA and subsequently with its SA.

Figure 2 shows the six basic interrogatives and the business object categories to which each corresponds.  However unlike the Zachman Framework, the order of the interrogatives is significant.  It has been my experience that beginning requirements activities by identifying who are the participants (animate and inanimate) that make things happen provides a sound starting point, so I typically begin with the “Who” interrogative.  It is not absolutely essential that you identify all of the classes of objects in each category the first time through the framework.  The initial pass is a sorting exercise[3] to categorize all of the data elements, classes, and objects to begin to discover common attributes and characteristics among and between them.  It is these common elements that enable reuse at a level of abstraction above the purely technical.

Normalization across domains in shared spaces is also enhanced in this way.  This means that 6BI gives you a high-level set of classifications in which to group definitions from different systems that describe common object classes.  Typically I create a spreadsheet for each business object category (Parties, Products, Activities, etc.), color code[4] them so I can see at a glance which ones I am dealing with at any point, and add or remove rows as I go along.  A spreadsheet can generally load most textual data with just a little manipulation and gives you a convenient way to sort and shuffle the entries.  This is a working document and usually does not become a permanent artifact of the project.

Figure 2. Six Basic Interrogatives and Business Object Categories.

This is also the point at which you begin to identify the types of numbers, that is the measures and facts, that would most likely be described by the columns (or fields) of the tables you have categorized.  For Parties, for example, depending on the business context, you might want to capture and aggregate numbers that derive from activities in which the parties participated, events that are responded to or initiated by the parties, locations where parties operate, or motivators that parties plan or react to.  These, of course, are simple two-dimensional analyses but they form the building blocks for more complex queries which make use of more detailed or finer grained levels within each business object category in increasingly complex combinations.  Remember the idea here is to provide a starting point for analyzing the source data.

In the 6BI Design Framework, Parties and Products have no direct association with each other.  It is only through the other four business object categories (Activities, Events, Locations, and Motivators) that Parties and Products are associated.  The left side of Figure 3 shows the relationship of Parties to Activities, Events, Locations and Motivators.  The right side shows the relationship of Products to the same four business object categories.  This makes sense because only when people engage in activities, exchanging and manipulating things, do frequencies, quantities, monetary amounts, metrics, and other measurements get created.

Figure 3. The indirect association of Parties to Products.

Zachman and DoDAF

Figure 4 is a view of how the corresponding concepts of the Zachman Framework and the DoDAF align with each other and with the six basic interrogatives on which the 6BI Design Framework is based.

Figure 4.  Six Basic Interrogatives, Zachman Framework and DoDAF.

Basic Interrogative  Zachman Framework DoDAF
Who produces the data we are going to use to measure performance? Business Model –Organizational Units and Work Products  Operational Architecture –Roles and their Means to Perform Activities
System Model – Roles and Deliverables  Systems Architecture –Systems and Sub-systems
What is being manipulated or exchanged to produce the measurable performance? Business Model –Business Entities and Relationships Operational Architecture –Information Items Input and Output through Activities
System Model –Data Entity and Relationships Systems Architecture –Data Elements Input and Output through Functions
How are the data values that measure performance produced? Business Model –Business Processes and their Resources Inputs and Outputs Operational Architecture –Node-to-node Information Exchange Activities
System Model –Application Functions and User Views of Input and Output Systems Architecture –System-to-system Data Transaction Functions 
When does the activity take place and for how long is the performance measured? Business Model –Business Events and Business Cycles Operational Architecture –Timing and Sequencing of Activities
System Model –System Events and Processing Cycles Systems Architecture – Timing and Sequencing of System Events
Where does the activity used to measure performance take place? Business Model –Business Locations and Linkages Operational Architecture –Operational Nodes
System Model –System Components and Links Systems Architecture – System Nodes
Why do we believe the data we are using actually measure performance? Business Model –Business Objectives and Strategies Operational Architecture –Concept of Operations
System Model –Structural and Action Assertions Systems Architecture – Design Strategy and Rules

Though rarely are all six interrogatives expressed in a Mission Statement, they are expressed in the OA and the SA.  It is at the operational and systems level that BPM report consumers, decision makers at different levels of an organization, need to understand the numbers they are looking at.  The types of  questions that need to be answered include:

Who is responsible (persons, organizations, systems, etc.) for the numbers?  Who are the parties (consumers, payers, providers, sellers, agents, etc.) among whom the exchange is made?  Who else (competitors, partners, etc.) participates in this exchange?  What is their affinity (participant, observer, etc.) to the market place?  Who (government agency, media, etc.) influences the market place in which we exchange products?  Who (sellers, producers, managers, others, etc.) need to, or want to, know this information?  What is their affiliation (internal party or external party) with me, the first party?

What products (goods or services) are exchanged (bought, sold, produced or consumed) that produce the numbers I am looking at?  What type of work effort participated in the exchange? What events influence the exchange?  What are the data elements (out of all that are collected and stored) that give me the most relevant information, at the lowest cost, in the least amount of time?

How do the activities (sales, purchases, production runs, case work, intelligence gathering, analytical activity, etc.) engaged in by parties produce the results?  How does the exchange take place?  What are the functions and activities engaged in?  How do activities produce events that influence the numbers?  How do events spawn activities that influence the numbers?

When do the events that influence the numbers take place?   Which events (contact, proposal, closing, order, delivery, support call, payment, etc.) influence the numbers?  Which do not?  At what points in time do the influencing events take place?  What events take place at given points in time?  How long is the time duration of an event?  How long between events?  What events outside of our control correlate with the numbers?  What events cause a particular event?  What particular event causes other events?

Where (geographic locations, virtual addresses, etc.) did the events or activities take place?  Where is the location of the events that produce the numbers?  Where is the placement of the production assets?  Where are the participants? What is the spatial relationship between nodes?  Between nodes and other dimensions?

Why are particular pieces of information relevant?  Why do particular combinations of events and activities produce the results they do?  How are ends associated with means?  What are the motivators (strategy, tactics, programs, initiatives, rules, etc.) that correlate with the resultant numbers?

Each of the six basic interrogatives addresses an independent category of characteristics about the problem space, yet the categories are inter-related.  In fact there are specific associations between each pair of business object categories.  These associations can be expressed as a set of one-to-many relationships (see Figure 3) where the “one” side is a specific business object category (e.g. Parties) and the “many” side consists of one or more of the other business object categories that depend on it (i.e. Activities, Events, Locations, and/or Motivators), but not Products.  In a 6BI design, Parties and Products are associated only through a linkage with one or more of the other dimensions.

Traceability

6BI is also an approach to designing and building solutions that can be traced back to the characteristics and scope of the problem domain and the mission of the organization.  If the use cases and requirements are based on the six basic interrogatives, and the classes, workflows, and events that constitute the design of the component parts of the solution (i.e. the System Architecture) are constructed to address those interrogatives, a clear path from the problem space to the solution space can be described.  This path takes guidance from the context of the organization’s scope and mission as also defined in terms of the six basic interrogatives.  This can be a basis for validity checking the business use cases used to trace business scenarios.

In other words, the characteristics of the business and the problems that it needs to solve define how the solution needs to be constructed.  Each category of the problem is addressed by specific capabilities and components of the solution.  Each problem category, and combination of the categories, can be scripted in testing scenarios to exercise those features of the solution designed and constructed to address those specific categories and combinations.  Requirements compliance can be traced throughout the lifecycle of a project.

When new requirements need to be met the analyst asks herself, in the discovery activities of the requirements workflow, “Have I accounted for all six of the basic interrogative categories”?  If the answer is “yes” she then knows she has a comprehensive and useful framework for going forward and digging deeper for answers and solutions.  The possible impact of changes on each business object category can be traced separately or together.

This type of thinking about requirements applies whether the implementation is a custom development or a packaged analytical application.  As a matter of fact, 6BI can be the basis of a robust subject matter coverage analysis when evaluating commercial off-the-shelf (COTS) software.

Because business intelligence, especially designing the data stores for data warehouses and other analytical and decision support systems, has progressed over the last decade and a half to where it is a mature discipline, many data architects no longer actually create uniquely designed databases directly from requirements.  With the emphasis on design patterns and the availability of domain specific templates and examples, the emphasis is now on gap analysis.  Gap analysis is the process of closing the gap between a given design, which can be either an industry standard, a generic model, or built into a product, and the acknowledged data requirements of the problem at hand.

The 6B Design Framework can actually provide a very thorough vehicle to facilitate this gap analysis.  6BI is a way to organize your thinking and help you to know what types of questions to ask in order to “cover all the bases” or make sure no gaps remain in the requirements analysis process.  This gap analysis is especially critical in designing databases to support modern business intelligence technologies such as Business Activity Monitoring (BAM) where visibility into business processes and the atomic activities that make them up is critical.  It is critical because different sets of events and activities are important to individuals and groups at different levels of an organization.  The wider the scope of responsibility of an individual or group, the more aggregated and wider their reporting needs become.  In order to aggregate data from more atomic and concrete levels to broader and more abstract levels, the aggregation must take place along one or more dimensions of the data.  It is also critical that this visibility into the business processes be as independent of the implementation technology as possible.

The 6BI approach helps to identify these dimensions by grouping them is six distinct categories, each of which is aligned with a type of question an end user might ask about the nature of the information that they need.  As questions become more and more detailed and precise within each interrogative category, a 6BI designed system allows the user to drill-down through combinations of dimensions that correspond with the types of questions asked.  6BI identifies the six fundamental business object categories that identify the dimensions of the answers to operational questions about an enterprise, its parties, its products, its activities, its events, its locations, and its motivators.

 References

“A framework for information systems architecture” by John Zachman, IBM Systems Journal, Vol 26, No 3, 1987

“Zachman Framework Extensions: An Update” and “Rules for the Zachman Framework Architecture”, Database Newsletter, Vol 19, No. 4, July/August 1991

“DoD Architecture Framework Version 1.0”, U.S. Department of Defense Architecture Framework Working Group, 9 February 2004


[1] I like to think of this object sorting process as analogous to the Sorting Hat process that each first year student at the Hogwarts School of Witchcraft and Wizardry must go through in the Harry Potter books.

[2] The choice of colors is purely arbitrary but I typically use red for “who”, blue for “what”, green for “how”, aqua for “when”, maroon for “where”, and violet for “why”. Proforma ProVision, used for business vision, operations and process modeling, for example, uses a completely different color scheme.

[3] DoDAF was originally called the Command, Control, Communications, Computers, Intelligence, Surveillance, and Reconnaissance (C4ISR) Architecture Framework.  It has recently undergone an update and standardization process, in response to user feedback and an executive mandate to provide common standards to improve information sharing, thus the name change.

[4] The additional Zachman Framework rows, Technology Model, Detailed Representation, and Functioning Enterprise, representing the Builder’s view, the Subcontractor’s view, and the Actual System view are not discussed in this article. The Technology Model aligns with the Technical Standards Architecture (TA) View in the DoDAF.

Six Basic Interrogatives – Part 1, 6BI Overview

August 29, 2010

This article is the first of a three part series that introduces a method for analyzing the data sources for a business intelligence solution in a framework that classifies the data entities into six (6) basic categories, sometimes called business object classes, but that I call the “Six Basic Interrogatives” or “6BI”, a term taken from journalism. Obviously a play on the common abbreviation for business intelligence, BI, as well. It is based on the familiar Zachman Framework for Enterprise Architecture, and thus acts as a bridge between the disciplines of Business Intelligence and Enterprise Architecture, EA. These categories are the aspects (vertical columns) of the Zachman Framework; “Who”, “What”, “Where”, “When”, “Why”, and “How”.

The article was first published in January 2004 on Datawarehouse.com, a website that no longer exists, under the title “Six Basic Interrogatives – Part 1, 6BI Overview”. The article owes much not only to John Zachman, but also Dan Tasker and Len Silverston, from whom much inspiration was gained and hopefully refined in the process.

Six Basic Interrogatives – Part 1

One of the most difficult and yet most critical activities to get right when embarking on a new Business Intelligence / Data Warehousing (BI/DW) project is organizing and presenting the data requirements in such a way that they make sense to the persons responsible for designing and building the database that will support the decision support application. Two aspects of this activity make it very important.

First, when a significant amount of analytical ad hoc reporting is required, the database cannot be tuned to enhance the performance of any specific query. In ad hoc environments all the details of all queries are not known in advance (if they were it would not be ad hoc and probably of limited analytical value). Second, the people who design and build the database may not have personally participated in the often intense and sometimes contentious requirements gathering and analysis process. These two skill sets (business requirements analysis and database design) are often found in persons with different learning styles, experiences and motivation, so are quite frequently done by different individuals.

The required business performance measurements need to be identified, agreed upon and the algorithm for each defined. The available data sources that support these measurements must also be identified. Ideally the activity to identify candidate data sources will be performed in parallel with that of identifying business performance measurements. Once both of these “identifying” activities have reached an agreed upon state of completeness we then need to match the performance measurements to the data sources. That is, we need to know what are the data elements which, when combined algorithmically, produce the required performance measurements. We need to answer these questions:

Who produces the data we are going to use to measure performance?
What task, item or service is producing the measurable performance?
Where does the activity used to measure performance take place?
When and for how long is the performance of the task, item or service measured?
Why do we believe the data we are using actually measure performance?
How are the data values that measure performance produced?

These questions, or others very similar to them, form what I call the “Six Basic Interrogatives” or 6BI approach to database design for business intelligence. I use this term, borrowed from journalism, to describe a framework for thinking about what needs to go into the database to support decision making and ad hoc reporting. Which is, after all, what needs to come out of a data warehouse or decision support application for it to be useful. In other words we need to know all the factors that influence the data we use to measure performance.

To answer these questions, the structures within a business intelligence database must be designed to hold information about certain categories of business objects. These categories include:

Parties (Persons and Organizations) who produce the data we are going to use to measure performance.
Products (Goods and Services) that are represented by the data used to measure performance.
Locations (and Means of Communication) that facilitate the Goods and Services represented by the data used to measure performance.
Points in Time when the data is produced that is used to measure performance, and Durations over which the performance measures are produced.
Initiatives and Programs designed and executed to influence the data used to measure performance.
Contracts, Exchanges and Actions that represent the activities (participated in by the Parties) that produce the data used to measure performance.

These business object categories then provide the starting point for classifying the dimensions of a data warehouse database design. The design needs to allow enough flexibility to support ad hoc reporting by focusing on the basic questions that all decision support data structures need to support. However, good dimensional design also needs to address the unique decision making environment of the specific enterprise for which it is being built.

The next challenge, of course, is determining the actual measurements of performance themselves. These make up the facts or measures in the fact table that the dimensions describe. These are the data elements that, when combined algorithmically, produce the required performance measurements.

The 6BI design framework provides an approach for organizing and understanding the context of business intelligence and provides a way of classifying legacy data and meta data so that it makes sense and can be built upon. It can not and should not be followed slavishly and there are quite often data structures which simply cannot be easily classified. However, if a place to get started with your database design is what you need it can provide a platform to build upon.

In future articles I plan to discuss each of the 6BI business object categories in more detail, what you look for to identify how to classify data elements and examples from my own work experience. As the database administrator (DBA) function evolves from solely a technical expertise to more of a partner with business domain experts we will all need to quickly and effectively transform business requirements into working software solutions.

Six Basic Interrogatives – Part 2, 6BI Design Framework

August 29, 2010

This is the second part of the original three part article about the “Six Basic Interrogatives” or “6BI” for analyzing the source data for business intelligence solutions. I this part an example of how to apply the method is given.

This part was first published in March 2004 under the title “Six Basic Interrogatives – Part 2, 6BI Design Framework” on the no longer existing Datawarehouse.com website.

Six Basic Interrogatives – Part 2

In a previous article I discussed a conceptual framework for designing and building databases that support business intelligence and data warehousing applications. In the article I mentioned the six basic interrogatives, borrowed from journalism, that are the basis for our thinking and subsequent design work in building databases that support the performance measurement and decision support processes. An interrogative is of course a question and our goal is to answer questions.

Six corresponding categories of business objects were identified that align with these six interrogatives. These business object categories identify the dimensions of the answers to our business questions. Our answers come from algorithms based on combinations of measurements set in a context of these business objects.

Each business object category contributes to the production of performance measuring data. All the categories together provide the different aspects one uses to analyze business performance. These business object categories therefore form the ‘6BI Design Framework’ that can be used in designing and building databases for business intelligence.

Figure 1 shows the six basic interrogatives and the business object categories they correspond to:

Figure 1. Six Basic Interrogatives and Business Object Categories.

Let’s look at a simple scenario. Alpha Corporation receives an order on 30 October 2003 on their website, for 100 units of Alpha Super Stuff from Bravo Enterprises. On 5 November 2003 the fulfillment of the 100 units is made. The payment of $1,000 USD is made on 15 November 2003, via an electronic funds transfer. Carol Daniels, the customer representative, who covers the sales territory is responsible for writing the contract for the sales process. She worked on it for one week. The activities took place in the fourth quarter of 2003. The business transaction is associated in time with an advertising campaign for Alpha Super Stuff.

Using the 6BI approach we can classify the business objects, each underlined and color-coded in the scenario above, into the categories that form the 6BI Design Framework. Let’s see how we do this:

First, Alpha Corporation and Bravo Enterprises are Organizations, a type of Party. Carol Daniels is a Person, another type of Party. This tells us who produces the data we are going to use for our performance measurements. If we are measuring performance from the perspective of Alpha Corporation we call it the first party in our example. To accommodate who produces the data we need to create dimensional entities and attributes that describe persons and organizations in our decision support data models.

Second, Alpha Super Stuff is a Product, in this case the Goods which were exchanged between Alpha Corporation and Bravo Enterprises, the second party in our example. It answers the question of what produced the measurement data. But Carol Daniels’ Work Effort also produced the data so we need to include that here as well. To describe what is produced we need to create entities and attributes that describe goods and services in our dimensional data models.

Third, the website tells us the Location of where the process was initiated, in this case in virtual space. The sales territory tells us where to Place the exchange geographically. We need to create dimensional entities and attributes to describe where the exchange occurred.

Fourth, the dates above record the Events occurring at different points in time that tell us when the exchange that produces the data occurred. The fact that Carol Daniels worked on it for one week in the fourth quarter of 2003 tells us the Duration over which some of the data is relevant. In our decision support data models we need to create dimensional entities and attributes that describe points in time and periods of time.

Fifth, the sales process (including the order, fulfillment and payment) is an Exchange between the parties and tells us how the data that we are going to use for our measurements were actually produced. The contract between Alpha Corporation and Bravo Enterprises gives us the means by which the data was produced. To accommodate this we need to create dimensional entities and attributes that describe business processes.

Sixth, the advertising campaign which is a Program, gives us an idea of perhaps why the measurement data was produced. To accommodate this we need to create dimensional entities and attributes that describe motivators in our business intelligence data models.

Lastly, the bolded items in the scenario above (100 units, $1,000 USD) are, of course, instances of the measurements themselves. In future articles I will discuss measures and how they fit into the dimensional context we have outlined by the 6BI approach. I will also discuss color coding and how it helps to document the 6BI Design Framework.

Perspective

At the logical level the 6BI Design Framework forms the basis for the reuse of entities, attributes, value domains, relationships and other logical objects in our data warehouse designs. When actually implemented in software the 6BI Design Framework is instantiated as tables, columns, constraints, references and other database objects with common features across implementations and across business domains.

This ability to reuse our decision support database objects as widely as possible across many areas of business intelligence reduces the amount of discovery work that is needed for each effort. It also frees up valuable human resources to concentrate on specializing these objects to meet the requirements of specific business domains. It is, after all, the problems of specific business domains that we need to solve with our business intelligence applications, and not theoretical or conceptual problems. Our business intelligence applications can then become more and more aligned with the goals of the enterprise and produce better results faster and more economically.