Gamification is well established and is sometimes considered controversial when applied in a corporate setting.  Our objective in providing this example is not to cover topics more appropriately addressed through corporate policy and governance but rather to describe a type of system designed to fill in gaps of knowledge for analytics sake by being deployed with or integrated “alongside” operational systems.  Hybrid Transactional / Analytic Processing solutions by way of Temporal Linked Data® (TLD), lend themselves to these kinds of considerations.

In addition to providing a reference implementation for HTAP by way of TLD, our example of Agile Gamification is provided to extrapolate to any corporate domain where corporate leadership line-of-site into its business may be untrusted, untimely, incomplete, opaque, or is simply providing inexplicable results that need to be clarified.

Agile Gamification recognizes the invaluable information available in Application Lifecycle Management (ALM), Quality Assurance (QA), build pipeline (CI/CD), and source code management (SCM) systems to assess activity and identify communities and their attributes when subjected to analytic processing.  These technologies are invaluable to the day-to-day management of project, product, and portfolio activities.  But, from an analytic perspective, the events generated likely miss the nuance attributable to your most valuable asset: your people.  They do not tell the whole story and can result in learning the wrong lessons and rewarding the wrong behavior.

The reality of healthy agile organizations is that teams are fluid, forming for release cycles and spikes and dissolving and reforming according to the forces facing the business as people come and go.  These dynamic environments require aggregate knowledge shared by individuals that know the answer when it is needed and where it is needed.  Often, those individuals most valuable to team success are not the ones making the most frequent pull requests and commits or taking on the most tasks, but are serving as coach, technical advisor, and pair programmer, and doing so in a highly responsive, educational, and respectful manner.  

These intangibles are both invaluable and difficult to objectively quantify.  Gamification is one way to accomplish this by providing a single place to collect both the platform generated as well as the collegial input for realtime (game score), milestone (sprints and releases), and longitudinal (inter-game, inter-epoch) analysis.  HTAP by way of TLD with projections into graph database analytics provides an effective solution to all three dimensions of the problem.

In ordinary optical light, UGC 1382 was believed to be an ordinary elliptical galaxy. When augmented with ultraviolet light and deep optical data, and then incorporating low-density hydrogen gas, 1382 turned out to be a gigantic galaxy where its outside is older than its inside—the Frankenstein galaxy.
(Image credit: NASA/JPL/Caltech/SDSS/NRAO)

The next post will discuss what it means to auto-generate the backend from an RDF data model.

The purpose of this weblog post is to introduce a Temporal Linked Data® (TLD) data model by way of a generic gamification model.  To visualize the model’s vertices (TLD Aggregates) and edges (TLD Links) we will use the Visual Notation for OWL Ontologies (VOWL) plugin within Protege.  Each TLD Aggregate is comprised of OWL Datatype Properties (literal values represented by XSD base types) and OWL Object Properties (URIs that reference another TLD Aggregate, or other RDF Resource).  Each TLD Aggregate keeps the current value for each property as well as all changes applied to the aggregate over time, making them temporal data structures.

A well bounded context. TLD links aggregates that comprise a solution, trusting that it can link to other solutions as required, along the way, rather than ahead of time. (Image credit: NOAA/NASA GOES Project)

Let us assume that this Agile Gamification capability is a hosted service provided by a third party Organization, such as BRSG.  The idea would be that each team member would be an Individual known to the multi-tenant service provider.   Further, “Agile Gamification” would be an instance of a Game made available through an Organization, such as BRSG, but owned by the Organization that has a Subscription for the Game.  The Game is a BRSG Product made available as a Service at a public URI.  Each Individual is invited to play the Game and does so through their Game Ledger which has a special journaling data type called a Debit-Credit that keeps a running tally of their score by receiving “debit” and “credit” events described in the Agile Gamification weblog post.  Let’s look at these TLD aggregate models using VOWL.

The Organization depicted here is comprised of eight OWL Datatype Properties to identify, describe, name, associate, and track each organization instance.  Likewise, Organization contains six OWL Object Properties that link it to its’ external site, personnel, subscription, products, and services.  These RDF Properties, taken together, comprise the organization aggregate model.

Example “Organization” aggregate comprised of eight Datatype Properties, and six Object Properties. (Image credit: Protegy VOWL Plugin)

The Individual depicted here is comprised of 15 OWL Datatype Properties and seven OWL Object Properties that serve the same purpose as they do for Organization.

Example “Individual” aggregate comprised of 15 Datatype Properties, and seven Object Properties. (Image credit: Protegy VOWL Plugin)

Each individual TLD aggregate is modeled in this manner, both decoupled from each other while also cohesive in their overall structure and purpose.  When taken together, this network of TLD aggregate models are represented by a graph and can be directly projected into a third-generation graph database such as TigerGraph or an RDF-oriented Knowledge Graph such as ReactiveCore.  The following is a non-temporal representation of the TLD data model in TigerGraph (we will provide the temporal version of the TigerGraph schema when we get to the analytics posts).

TigerGraph graph model of gamification sans temporality. (Image credit: TigerGraph Graph Studio)

The next post will discuss how gamification can augment operational data for clarity, validation, timeliness, and additional perspective.

This series of weblogs will use an example from our agile software development background to describe Hybrid Transactional / Analytic Processing with Temporal Linked Data®. 

Specifically, we will discuss:

• Agile Gamification—a description of the example application.
• Agile Gamification Model—what this model looks like as Temporal Linked Data® as well as its corollary TigerGraph graph database schema.
• Augmenting Operational Data with Gamification — why this example may be useful and how gamification can augment our understanding of existing operational data.
• Auto-Generated Backend — what is required to fully auto-generate an enterprise backend.
• Temporal Linked Data® as TigerGraph Schema with Temporality.
• The Value of Temporal Data, Transactionally and Analytically.
• Reasonable Conclusions about HTAP and Temporal Linked Data®.

Artist rendering of Dawn spacecraft orbiting Ceres. Analytics is like that, it benefits from having an “expectation” against which reality can be compared. (Image credit: NASA/JPL-Caltech)

Let’s imagine that yours’ is an agile software development organization comprised of 10 teams of three to eight developers plus all of the other roles each agile team requires.  Our objective is to continually assess the effectiveness of software development personnel against known delivery and quality performance on an epoch by epoch basic, where epoch corresponds to spikes, sprints, and releases.  

Let’s further imagine that your Application Lifecycle Management (ALM), Quality Assurance (QA), build pipeline (CI/CD), and source code management (SCM) platforms are able to provide events on configurable business activities that result from team member activity.  Specifically, let’s say that we are currently interested in the following business events by individual.

ALM) From Application Lifecycle Management we want to know when the following occurs: 1) Task Defined, 2) Task Assigned, 3) Task Completion, 4) Task Rework Assigned, 5) Daily Task Remaining, 6) Feature Suggestion, and 7) Feature Acceptance.

CI/CD) From the build pipeline we want to know: 1) Build Broken, 2) Build Fixed. 

QA) From Quality Assurance we want to know when: 1) Bug Reported, and 2) Bug Fixed.

SCM) From source code management we want to know when there is a: 1) Pull Request, 2) Push, 3) Pair Programming Contributor, and 4) Commit Reviewer.

From these system generated events we can readily glean activity and community traits related to ALM, CI/CD, QA, and SCM.  But that does not tell the whole story.

Intangibles for which there is insufficient information might include identification of individuals: 1) most vested in helping others to succeed, 2) willingness to share knowledge, 3) responsive to other’s requests, 4) pleasant to work with or that positively contributes to quality of work-life.  These intangibles and others like them are what gamification can contribute to the data available from ALM, QA, BP, and SCM.  

We can understand these intangibles by allowing the team to provide information such as the following about their colleagues at task completion and end-of-day junctures: 1) Helpful, 2) Pleasant Experience, 3) Responsive, 4) Positive Observation, 5) Peer Feature Suggestion Like, 6) Unhelpful, 7) Unpleasant Experience, 8) Unresponsive, and 9) Negative Observation.  These observations land on the ledger of the person that they are about.  Each negative observation (6-8) is accompanied by a “Negative Observation” (9) observation attributed to the person making the observation, but the person making the observation is not otherwise logged so as to provide anonymity as well as to minimize negative observations being made.

For each auto-generated and manually contributed event type, the game administrator assigns “debit” points for positive activities and “credit” points for negative activities, according to what the organization values.  

For example, the game administrator might give the following values to a few of the above mentioned events.  “Task Defined” debits (positive value) the user’s game journal by one, where, “Task Rework Assigned” would credit (negative value) the user’s game journal by one.  Each of the events can be reassigned value for each game played.

The gamification model will keep a running total for each individual as well as each change so as to be able to explain what comprises the total.  An instance of the game runs for each team in alignment with spikes, sprints, and releases.  Refinements can be made in the configuration of each game.  Analytics can be run within and across games.

The next post will discuss the TLD model to support Agile Gamification.

Magnified Hubble image of Abell 1689 (a dense cluster of galaxies as it was 2.2 billion years ago) to research dark matter in an effort to better understand dark energy—finding creative ways to fill in the gaps of what we do not yet know. (Image credit: NASA/ESA/JPL-Caltech/Yale/CNRS)