From a business perspective, all IT systems can be broadly divided into two major groups:

• Operational systems, which support day‑to‑day business activities, and

• Analytical systems, which—like a time machine—preserve the history of what has happened and provide the foundation for deciding what should happen next.

This analytical capability is what we now commonly refer to as Business Intelligence (BI). Although BI as a concept spans the entire spectrum of a company’s activities, it is generally understood to have two areas of focus: operational and analytical.

AMS was created from a strong belief in what the analytical component of BI should be and how it should be organised. At the heart of every analytical system lies its historical data. Operational data becomes historical data almost instantly, and the value of an analytical system depends heavily on how that historical data is captured, stored, and made available for analysis.

A common assumption in the industry is that modern BI tools and technologies provide powerful capabilities for analysing distributed historical data. While these tools are indeed sophisticated, the real challenge lies not in the analytical layer itself, but in the organisation, preparation, and integration of historical data so that it can be analysed reliably and consistently.

We believe that concentrating historical data—rather than scattering it across multiple systems—creates a far richer and more powerful analytical foundation. This principle aligns with what we call the Pyramid Concept, where all the hard work of data preparation, integration, validation, and organisation is performed before Data Mining or analytical tools come into play. Although this approach requires more effort upfront, it pays off significantly in the long run by providing cleaner, more reliable, and more accessible data for advanced analytics.

The diagram on the right illustrates the role of AMS within the broader BI landscape.

AMS provides the framework, modular structure, workflow organisation, and governance (monitoring and control) for all application building blocks and ETL components. This structured foundation enables organisations to build a long‑term, stable platform that supports the final analytical layer of the system—where complex activities such as Data Mining, Reporting, and advanced analytics take place.

For the Data Mining and Reporting layer, we recommend low‑cost or no‑cost open‑source tools such as MicroStrategy, Jasper, KNIME, Intetics, and similar platforms. These tools integrate well with the structured, high‑quality data environment that AMS helps create.

A simplified analytical system can be viewed as having three fundamental components:

1. Collecting data

2. Storing data in a structure designed to support analytical use

3. Using the stored data for reporting, analysis, and decision‑making

In practical terms, these components translate into the core responsibilities of AMS:

• Extract data

• Transform data

• Load data

These three steps—commonly known as ETL—form the backbone of any analytical environment. AMS was designed specifically to manage these tasks in a structured, reliable, and repeatable way, ensuring that operational data is captured, organised, and made available for analytical use as efficiently as possible.

The most common way to organise data for analytical use is through a Relational Database. AMS recommends proven, no‑cost relational technologies such as MySQL and PostgreSQL, which provide excellent performance, stability, and flexibility for analytical workloads.

The diagram on the right illustrates several methods commonly used in the physical implementation of this analytical concept.

At the core of any ETL process are three functional elements: Extract, Transform, and Load. From the perspective of the transformation step, the Extract phase represents the input, while the Load phase represents the output. Transformation sits between these two, shaping, validating, and preparing the data so that it becomes suitable for analytical storage and use

The Input to an analytical system can originate from three major types of sources:

1. Files

These may come in a wide variety of types and formats, including CSV, XML, JSON, Excel, fixed‑width text, and many others.

2. Databases

AMS supports virtually all common database technologies, with relational databases being the most frequently used due to their structure, reliability, and analytical suitability.

3. Data Streams

Increasingly, data arrives in real time through APIs, most commonly in JSON format. AMS can consume and process these streaming inputs as part of the ETL workflow.

The Transformation component has the capability to convert data from A to B according to predefined business rules. These rules determine how the input is interpreted, validated, enriched, corrected, or restructured before it becomes suitable for analytical use.

The result of the Transformation can be written to a wide range of output types and formats, depending on the requirements of the downstream processes or storage structures.

To complete the picture, we must also add the time dimension, which defines when processing occurs and how often it is repeated. Timing conditions and execution frequency are essential elements of any analytical system, ensuring that data is refreshed, validated, and made available in a controlled and predictable manner.

In reality, data processing is often far more complex than the simple Extract–Transform–Load model suggests. For this reason, it is good practice to break the overall workflow into smaller, manageable application building blocks. In AMS, these building blocks are organised into four structural levels:

1. Task

2. Procedure

3. Phase

4. System

A Task is the only executable object in AMS. It represents anything that can be executed on the platform—from a single command to a collection of complex programs. Tasks may accept arguments, allowing the same executable logic to be reused with different inputs. AMS also allows each task to be selected or unselected for execution, giving developers and operators fine‑grained control over how a workflow behaves at runtime.

A Procedure is a collection of Tasks arranged in a specific sequence that determines the order in which those Tasks are executed.

A Phase is a collection of Procedures. Procedures within a Phase may be independent or mutually dependent. The conditions under which one Procedure is allowed to execute relative to another are defined through dependencies. A Procedure may depend on one or more other Procedures, or it may have no dependencies at all.

In the diagram on the right, for example, Procedure 4 depends on Procedures 2 and 3, while Procedure 1 has no dependencies.

A System is the highest grouping level, representing a collection of one or more Phases.