Implementation Overview

This section covers the process used in implementing a solution with Amazolve. The flowchart below shows the high level steps that are a part of the process, however, the steps do not necessarily need to be done serially and the process is iterative. It is important to note that the words description and definition are used throughout and have distinctly different meanings. A description is a written scenario or story that describes a constraint or objective in human terms. A definition is an actual configuration - be it a file or API call.

Throughout this guide, references are made to Amazolve's Problem Definition, or PD. This is the actual configuration (JSON file, for example) of the atoms, objective, constraints and supporting arrays that create the specific solution. In addition, the PD file can also be a "markdown file" (MD) with JSON islands contained therein. When a PD is constructed as a MD file, the "description" and "definition" reside within a single file that can communicate to all stakeholders as well as potentially outside compliance actors. (A PD as MD will be discussed in greater detail in the "Compliance" section of this guide.)

In addition, the following are roles that are part of the process.

Stakeholders are familiar with the business problem, or need, and the high level requirements.
Analysts generally are familiar with the data and/or mathematics involved in describing the business requirements.
IT is responsible for the technical implementation of the Amazolve product - the configuration of both data and problem in the PD.

Note that it is absolutely the case that all of the above roles could be the responsibility of one person, or roles could be shared amongst several people.

Problem Definition Process

Step: Problem Description

Roles: Stakeholders, Analysts, IT
Actions: At this step, the fundamental problem is described. For example, a delivery route that needs to be optimized given certain time and resource constraints, or a schedule that must be created given certain employee availablity or job requirement constraints. The atom array is defined at this point as it forms the basis for the entire solution - what will be the resource rows, time columns and what states are in each atom.

The atom array defines how the solution answer, or the "output" is defined as this will be consumed by whatever upstream system is trying to integrate the results.

In addition, it is important at this point to describe the frequency, latency or data flow needs of the solution. For example, the solution may need to run nightly, hourly, or on demand. This will also start to highlight where and how the data for the solution (e.g., employee lists, capabilities, resource availability, orders, etc.) may be acquired and prepared for the solution.

Step: Constraint Description

Roles: Stakeholders, Analysts, IT
Actions: Constraint description is broken out from Problem description to show that a few constraints at a time can be tackled rather than all at once. Most solutions have many constraints (a dozen or so is normal) and many are discovered as the process moves along. Therefore, it is recommended a few (or one) constraint(s) are chosen for initial implementation.

For example, for a routing application, just the objective function to minimize distance would be a logical place to start. For an employee scheduling application, the maximum number of days each employee can take off during a time period. Describing the constraints at this step lead naturally into the next step.

Step: Data Source Identification

Roles: Analysts, IT
Actions: This step identifies what data sources will supply the required data for the constraints described int the prior step. For example, employee information may come from an HR system, or sales or work order information may reside in an ERP. This data may be easily available via a CSV file, or a database, but will ultimately need to be accessed or generated based on the frequency of use of the solution described in the first step. Additionally, the same source(s) may be used for multiple constraints, just with additional data points (fields) added so the data source identification should be flexible during implementation.

Step: Data Source Translation

Roles: IT
Actions: In order to use the raw data identified in the previous step, it must be converted into an standard json array of up to four dimensions. Arrays are used in two ways within a PD:
- Lookup: An array can be a 2 or 3 dimensional lookup table (in essence). For a routing application, for example, this may hold the distance between all locations. When used as a lookup, the last dimension can optionally act as a set of fields (see, ldimFields).
- Iterable, or Set: An array can also be used for iteration within a sum - in this case the array must be 2D and can be thought of as a "table" (in the classic RDBMS sense) or a "set" (in the algebraic sense).
For example, in the formula below, \(cost(r_a,s_a)\) is an array with \((r_a,s_a)\) indexing into the returned value, \(\psi\) is an array with \(\left(r,s\right)\) being the fields r and s of each row of the 2D array.

\(C = \sum_{\left(r,s\right)\in\psi}cost(r_a,s_a)\)

Regardless of how the array is being used, they are defined physically as JSON files that are referred to by the PD.Therefore, "translation" involves converting the raw data sources into either an array JSON file that can be consumed by the constraints in the PD.

Step: Constraint Definition

Roles: Analysts, IT
Actions: In this step, constraints are implemented within the PD. The translated data sources and constraint descriptions are combined to formulate the constraint definitions themselves. For example, taking the previous objective function...

\(C = \sum_{\left(r,s\right)\in\psi}cost(r_a,s_a)\)

..and converting it into the PD definition...
```
{
  "constraint": {
    "CID": "C",
    "sumIter": "iterArray",
    "arrayName": "psi",
    "iterVars": [
      "r",
      "s"
    ],
    "exprMain": "cost(At(r), At(s))"
  }
}
```

Step: Testing

Roles: Stakeholders, Analysts, IT
Actions: In this step, the constraints (and objectives) that have been implemented thus far are tested. It is important to not only test the basic functionality using a static data set, but also to test the raw data pipeline by using new raw data and running through the translation process, running an solver session, then verifying the returned atom array is consumed correctly in the upstream system or displayed as desired to an end user.

Keyboard shortcuts