ADML Overview

Overview

The analytics design process underpinning ADML we describe as the “Analytics Heliosphere”. The Analytics Heliosphere is a dynamic interconnected system that responds to changing business conditions. As data products at its core mature and generate more “charge”, it in turn grows in its magnetic force and extends out further into the organisation.

The Analytics Heliosphere is broken down into the following core components:

• Four “waves”: themes that are emitted by an organisation and can be harnessed into the design of a data product;
• Four design “rituals” that solicit a set of attributes to describe the needs of a data product; and
• The data product that is produced and continuously enhanced as a result of the design process.

Data Product Overview

At the core of the Analytics Heliosphere is the data product. Specifying and developing it is the central purpose of all design rituals. We define a data product as an analytics asset that is consumed by an end user or as a component of an application that is in turn used by an end user.

Methodology Introduction

To ensure consistency of the design process, ADML dictates a set of “rituals”: a sequence of activities with an array of structured questions to inform the design lifecycle.

It can be *very* tempting to be skip steps to placate stakeholders or to “expedite” an outcome. We urge you to trust the process and the benefits that each stage brings to:

• Articulate implicit knowledge and assumptions
• Bring consensus between a wide variety of stakeholders on priorities and business rules
• Consolidate a view of what is needed and what is possible across different parts of the organisation
• Anticipate obstacles based on data limitations
• Mitigate wasted time building assets that are not adopted

For a detailed explanation of the design methodology make sure you download our white paper.

Information Design

The purpose of this ritual is to define the semantics of a business area, identifying the information needs to support monitoring of performance and descriptive analytics. The primary “wave” that this ritual is concerned with are the business needs that elude measurement.

Hypothesis Design

The purpose of this ritual is to define the levers and constraints of a particular business issue, identifying the needs to support data-driven intervention, often associated with the practice of statistical analysis, machine learning and prescriptive analytics.

The primary “wave” that this ritual is concerned with are the business issues that the organisation wishes to influence. As opposed to information design, which is concerned with driving visibility and accountability for the “what”, hypothesis design is focused on the “so what” using scientific method to build an understanding of causality which can drive improvement in performance. It identifies the actions and interventions that an organisation can take and relates them to the anticipated outcomes that result from making them. In this way, it captures a set of assumptions that can be tested with data.

Data Readiness

The purpose of this design ritual is to validate whether data exists in a form that will support the analytics objectives. The primary “wave” that this ritual is concerned with are the resources that capture or record data.

Before a data product can be built, the feasibility of fulfilling stakeholder expectations needs to be validated. Based on the information design and hypothesis design, sources of data need to be identified and tested for its completeness and utility.

It is critical to the success of any analytics initiative that stakeholders take an active interest in the limitations of an organisation’s data resources to support their analytics needs, and understand what compromises may be required to produce a short-term output.

Learning

The purpose of this design ritual is to evaluate the performance of a data product. The primary “wave” that this ritual is concerned with are the outcomes that can be related to a data product.

A key reason for this design ritual is to ensure corporate memory of why the data product was developed in the first place, and what challenges were faced and overcome in the past. This knowledge can be used to refine assumptions, update expected benefits and inform future decisions.

It also helps to understand whether the data product continues to provide value in the way that it was intended and hence understand when the data product should be adjusted, when it should be redeveloped and when it should be retired.

Implementation of ADML Schema

To ensure that the details collected through the design process we’ve outlined is easily consolidated in a central hub, we developed the ADML schema. The ADML schema is a conformed data structure defined in a JSON format.

Components

To implement the ADML schema you will need the following:

• A data capture system that collects the data elements in the JSON schema;
• A process to output the data into the JSON format files; and
• A system to accumulate the JSON files and display them in a catalogue.

Schema Definition

ADML is defined as a JSON schema that can be implemented in a range of platforms.

The core concepts in the JSON schema are:

• Objects,
• Attributes,
• Relationships; and
• Bridges

For a complete technical guide to the JSON schema refer to https://admlguide.github.io