High level overview of the Kwantu Platform

The Kwantu platform is a online SAAS platform that enables the configuration of apps through declarative documents and the adoption and use of apps into communities within the platform.

Two main contexts

The Kwantu platform has two main operational contexts

1. Application generation context allowing analysts to configure apps. Configuration of apps are through editing declarative xml and json documents. (A graphical user interface is planned for the future)
2. Application execution context that provides a runtime environment to execute the configured apps. The runtime environment is mobile offline first in design, and allows for three operational modes out of the box: Online, Connected (local data on the device only but still online for use in poor network environments), Offline (local and no internet connection).

Application Generation

The core applications are configured using 3 basic sets of tools:

Standalone Data Objects [SDO]

Data objects are configured independently of any object and is modeled on a key business area. It is a datacentric application design pattern in which each data object can exist and function independent of any application. The data object is in effect a micro application that is generated from a configuration file (in xml at the moment). From this configuration file that contains all the business logic for the data object, a transformer tool generates the following items that together comprise the SDO

1. SetId uniquely defining the SDO globally, with a version number indicating version changes for the content.
2. Data model placed in a generic wrapper extended from the traditional atom feed standard, but with typed content associated with the SetId.
3. Schema for the data model associated with the setId and the version.
4. Set of business and validation rules for the SDO associated with thet setId and version
5. Set of user interfaces to the data object, that may be called independently to render and or manipulate data in the SDO

Application configuration file

A standard json file that provides a globally unique uuid for the application, and maps the SDO's, together with taxonomies and searches required by the SDOs to the application.

Aggregated workflow definition

A standard json file that holds a list of all the standard processes required by the application, and all the individual workflows associated with each process (called subProcesses) that manages all the aspects of the application.

Application Execution

The core operating concept in the execution platform is that communities adopt applications. The platform allows for multiple communities, and users are external to individual communities.

Root community concept

In the Kwantu platform, there is a root community that acts as a controlling community for all the communities in the platform. This community runs and manages the application and data object registries, as well as the user registration allowing users to access various communities from a single sign-on environment. Provision is made for application developers to access the application generation tools from within the root community. Application adoption is the process in the root community by which any community may adopt an application of a given version and make it available to its users, ie. the users from the platform that has been given access to the specific community.

Three level application execution context

The application execution context therefore operates at three levels:

1. The first level is the Root community which manages the creation of data objects, and applications as well as the registration of user accounts. The root community is also a community, and there are certain applications that have only been adopted by this community. The most important one is the ability to generate new communities. From the root community perspective each community is a single end user. In essence this level is the level that defines or generates apps, or that makes the tools to do so available to application developers.
2. The second level is the Community level which defines an organisation or business that uses the platform. Note that some organisations have themselves got multiple communities as members. The community is the core level of operation within the application execution context. Only communities may adopt applications. Only communities may provide access to applications to end users. This is generally referred to as the adoption level in the platform execution context. Communities may adopt apps, and make them available to their members as end users. No end user may access an app except through a community that adopted it as an application adopter.
3. The third level is the end user or app level. Here users access apps given the rights and permissions defined in the apps, and allocated to specific users. The bulk of day to day operations take place at this level.

Database and Technical Architecture

In this second section we are summarizing the technical and database architecture of the Kwantu platform.

Couchdb databases

The bulk of database operations are in a number of couchdb databases. They are constituted as follows:

1. The data registry and application registry is stored in one shared database, the configuration database.
2. Global taxonomies are stored in a shared taxonomies database. This is shared with all communities.
3. Each community has a primary data store as a separate database call the kwantu_apps database. There is one per community.
4. Each community has a notificaitons database that manages shared notifications and scheduled actions for the community
5. Each user has their own notifications database that contains user notifications and in process data.

Global indexing and querying

The rnewson implementation of the lucene index for databases have been implement to use in searches accross large data sets where flexible search parameters are needed.

Reporting

The Kwantu Platform has a custom developed reporting engine that extracts the application metadata models from the SDO configuration files, and presents that through a simple UI to users to generate reports. The reporting engine currently uses couchdb views for primary database querying, and an custom developed engine to join searches into views. This can be done recursively to join data for reporting. A custom implementation of Jasper reports engine drives the report presentation.

Transactions engine

The Kwantu platform has implemented a custom developed transactions engine using the redis database engine.

Dashboards

It is anticipated that the elasticsearch and Kibana engines will be integrated for dashboarding capabilities. But the couchbase analytics tools should also be considered.

Encryption

This is invisaged for the near future.