Introducing the Dynamic Nuchwezi Architecture Platform

A novel software engineering platform called the Dynamic Nuchwezi Architecture Platform is introduced, specified and its novelties explained. The unique features of this platform are explained and several new concepts and abstractions upon which its implementation, usage and analysis are hinged also elaborately discussed. The motivations for this new approach to building especially tools used in data engineering are spelled out and the platform is contrasted against other existing technologies of a similar kind. Finally, it is shown what known limitations DNAP suffers, as well as what room for further research and improvement there is in this field.


Introduction
First conceptualized in 2016, Dynamic Nuchwezi Architecture Platform or simply "DNAP", was originally inspired by a growing demand in the business sector, of an otherwise scarce software skill -the ability to design and deploy dynamic data collection and analysis solutions accessible to anyone in an organization, on-demand and at low cost. These skills we call data engineering skills, and we found that many businesses already owned some off-shelf or custom-made software that to some degree allowed for data engineering, but also that extension of these tools to new data types -such as data via OCR, Barcodes or GPS or capabilities such as being able to work offline was not so easy, and in some instances wasn't even supported.Further, we found that the combination of data acquisition and data dissemination in the same tool, as might be required in certain contexts was not readily possible without turning to a full-fledged general purpose programming language. We found these problems to be surmountable with new approaches, new solutions to an otherwise old problem in the data engineering and business intelligence domains and that is how DNAP came to be.
We also realized that if the method of building new software or extending existing software with new functionality were made so simple and readily accessible to those without expert knowledge of general purpose programming languages, then the unavoidable increase in demand for data engineering skills in today's increasingly automated society would readily be satisfiable. This would boost and make very affordable the automation of many business and personal processes than is currently possible.
The key objective of our research then, was to design and implement a new approach to software construction and extension that would readily be applicable to the identified gap in data engineering and business intelligence. This meant that the approach to be developed would have to be accessible to those with low or no experience using standard solutions such as general purpose programming languages.
More specifically, the research focused on the implementation of a software engineering platform spanning the web and mobile, and which platform would allow the design and implementation of simple programs for data engineering especially, without requiring that users know or learn to write code by hand. The idea was to ensure that this platform would make possible the following at minimum: • Building basic data acquisition apps in the form of survey tools • Building information dissemination apps with media-capabilities • Building live documents with both input and output capabilities • Making the extension of existing mobile and web software easy using embeddable components • Making the construction of and access to data APIs from such tools direct and configuration-free Work on the solution started in 2016 at the Nuchwezi ICT Research Lab, as part of a project originally called "Project Okot" or simply "Project O". This work went through several engineering and architectural upgrades since then, and the result is what is now called Dynamic Nuchwezi Architecture Platform .
In the rest of this paper, we illustrate and explain what exactly this newly realized approach to software development and extension is, and how it gets to fill the identified gap in data engineering first of all. We shall particularly be concerned with understanding the architecture of DNAP as used to realize this new approach,and we shall see how it can be applied in practice. Lastly, we shall call out what remains to be done, as well as challenges introduced by this new approach to software and data engineering.

Mobile and Web Embedables
In this paper though, we don't try to expound on each of the above. Instead, we call out how other similar technologies compare to DNAP in terms of completeness based on the above categories, and then only go in-depth for a few of these, with the aim of focusing on what makes DNAP ideal for data engineering today.
There are several proprietary and open-source technology platforms mentioned in the literature and community reviews, that are similar to DNAP in the context of data engineering platforms, but which either target a different kind of user or which only span one or only a few of the categories listed above. This is important, as each category calls out a capability, and so, tells us about the applicability -in the case of those platforms supporting it, or the limitations -for those which lack it, of a technology platform in the domain of data engineering as we present them hereafter.
We particularly chose the following technology platforms as a fair sample of the state-of-the-art in data engineering solutions that support a Data Tool Development capability at minimum.  From this table, we can see that the closest contender to DNAP is Google Forms, which especially lags due to not supporting offline use, but also which doesn't allow for auto-discovery of tools or datasets generated over the platform, and which also doesn't readily generate or expose data APIs ideal for chaining data tools or quickening data engineering automation tasks.
On the other hand, we find that solutions such as Kinto's Form builder offer only the most minimal set of features -basically a means to craft an online hosted data collection tool, the data collection interface and not much else. The DNAP on the other hand set out to cover as much ground as possible, and in the following sections, we shall especially see how this is realized, as well as what novelties we introduce.

The Architecture
In the two diagrams - Figure 1 and 2 below, are highlighted the key components of the Dynamic Nuchwezi Architecture Platform . However, to fully understand DNAP's structure, it is important to first gain a familiarity with and an understanding of the terminology used to describe its components as well as gaining The following sections introduce each key component, and explain its role and relevance within DNAP, in detail.

Persona
DNAP is first of all a data acquisition, storage and analysis platform. However, in the context of DNAP, "data" refers to a kind of structured data we call "Acts", and whose structure is defined by specific schemas. These schemas, specified using JavaScript Object Notation -JSON [1] and adopting some of the ideas of JSON Schema [6] -which is a standard for annotating and validating JSON data, enable a mechanism for defining or specifying a new kind of application that we refer to as a Persona Applet. Definition 2: Persona Applet: A data application running on the DNAP as either a mobile or web app, and whose behavior and looks are derived from its associated persona.

The Studio
Having seen what a "Persona" is in the previous section, we can then formally define the "Studio" as:  Knowing that personas can describe classical data collection tools such surveys, polls, questionnaires and the like -also known as "forms" or "data tools", it makes sense to contrast the studio with what other technologies do similar work.
Ignoring the rest of the DNAP and only focusing on this component, the closest technology in terms of intent, is Google Forms [10], which one researcher described as a Web application that allows users to create surveys and polls that can be distributed to authorized users [4]. However, unlike Google Forms, the studio does more than just allow the authoring of data acquisition tools; persona applets can do more than just collect data; you shall see by inspecting what field types are supported (see Table 2), that the studio also enables the design of information dissemination tools such as basic media players (audio and video), e-zines (mixed media) and the like.
The process of designing and publishing a tool though, remains somewhat similar; the Integrated Development Environment, IDE, is web-based, and is typically best used from a large view-port such as a laptop, desktop or tablet, though, in practice, we have managed to author some tools via the reference implementation studio, on a constrained smartphone's web-browser without trouble. Also note that the core feature of this IDE is to allow visual as opposed to textual coding or programming.
As of this moment, the reference studio implementation's interface looks like this: Using the studio interface, a typical approach to developing a persona might proceed like this: 1. Given a problem for which you wish to collect or share information, determine the set of fields that need to be presented to the user, for purposes of collecting or sharing information as part of the desired solution.
2. Then, for each field thus chosen, determine the kind of field-type best suited for it on the target app. The following

URL
• same as for field-type "Text" • Useful when capturing links to websites, documents or just web addresses of any kind.

Email
• same as for field-type "Text" • Useful in capturing valid email addresses.

File
• same as for field-type "Text" • Has a "Mime Type" parameter to help constrain input files to only specified types • Useful in attaching and submitting files alongside other data.

Take Photo
• same as for field-type "Text" • Useful in capturing an Image using the camera on the device where the histrion is run.

Scan Code
• same as for field-type "Text" • Allows scanning barcodes and qrcodes at runtime, as an input method.

Device GPS
• Has only one field, "Field Name" used to name the parameter in which GPS coordinates in the form Lat,Lng are to be stored when the Persona runs.
• Useful in geo-tagging data captured on the move, especially via mobile devices.
• Holds the most recent GPS reading registered by the device while the data entry session runs.

Device ID
• Has only one field, "Field Name" used to name the parameter in which a device GUID is to be stored when the Persona runs.
• Useful in uniquely identifying data posted from a specific device, and for evaluating how many distinct devices engaged in a given data collection exercise • Also helps with associating devices with users, thus improving in auditing -e.g. where users post data using similar usernames session runs.

Show Image
• "Label" field specifies title of the image • Use "Paste URL to Image" to specify a direct URL to an image file • Useful in linking to and thus displaying online images via the target persona -E.g. one can display the logo of a company at the top of their survey or add an image to an e-magazine persona.

Play Audio
• "Label" field specifies title of the audio file • Use "Paste URL to Audio" to specify a direct URL to an audio file • Useful in linking to and thus displaying online images via the target persona -E.g. one can display the logo of a company at the top of their survey or add an image to an e-magazine persona.

Device ID
• Has only one field, "Field Name" used to name the parameter in which a device GUID is to be stored when the Persona runs.
• Useful in uniquely identifying data posted from a specific device, and for evaluating how many distinct devices engaged in a given data collection exercise (and many other types...) Table 2: Data Type Specification on DNAP 3. Drag-and-drop the field type onto the canvas, at the position where you wish the target field to be rendered on the final app. Note that only single-column views are currently supported.
4. Go ahead and configure the field; specifying the label, description and other parameters as required (see Table 2 above) 5. Continue doing the above for all fields needed on the app -it is acceptable to add the same field type multiple times when designing your persona, as the studio assigns unique ids ("CIDs") to each field. 6. Once the app's fields are fully specified, you can then specify the few app-specific parameters: • App Name -name of the app (or rather, name of the Persona) • App Description -one or more sentences explaining the purpose and usage guidelines for the persona • Transport Mode -how the data from the persona should be submitted to the backend (options include HTTP POST, HTTP GET, SMS and EMAIL) -Note that SMS and EMAIL only make sense where the persona is expected to be used on a mobile histrion (refer to Definition 3) -such that captured data is encoded as text and submitted to either a target phone number or email address (see "Theatre Address" below) 7. Theatre Address: for each designed persona that is expected to be used for data capturing, it is required to specify where the data is to be submitted. By default, The studio will pre-fill the "Theatre Address" field with a default destination -typically a URL to the reference DNAP theatre implementation (chwezi.tech), but this value can be overridden as needed, at design time.
• Note: when the "Transport Mode" is SMS, the Theatre Address is expected to be a fully-qualified phone number -including country code that is, and where it is EMAIL, this parameter expects a valid email address.
8. App Color: The studio also allows the persona designer to specify a base theme color, which would then be used to generate a multi-color palette with which the final persona applet and its fields are styled during their rendering so as to readily distinguish the persona applet from others and to help communicate the applet's intended purpose or brand for example.
9. Persona Channel: The Studio also offers a means to publish one or more personas via a "Channel" (see Definition 4). This feature is intended to help logically group related personas on the DNAP, and also to make it easy for end users to subscribe to one or more channels, so as to have any personas published under those channels get automatically fetched and installed on their devices. The channel can be a simple string such as "ACCOUNTS" -so for example in an organization using DNAP, tools meant for M&E in the accounts department are separately discoverable and deployable without confusing them with those for the sales department, which can alternately have theirs published under a conveniently named "SALES" channel. 10. Once all necessary app parameters are finalized, the persona can then be published via the studio, by clicking on the "Publish the Persona" button. Note that persona publication does the following: (a) The persona specification (the persona script defining it that is), is lexically verified on the studio (b) Once validated, the persona specification is then submitted to the theatre for storage.
(c) On the theatre, this persona is assigned an App UUID that is expected to be globally unique.
(d) If the persona specified a channel, that channel will be created if it does not already exist.
(e) On the theatre, the published persona gets added to the list of available, active personas, such that DNAP clients (histrions, diviners, etc.) can start to reference the persona via its UUID for various purposes.
(f) After processing the persona, and submitting the results back to the studio, a special QRcode is generated, that is then displayed on the studio. This code can be downloaded, printed or used as is, to help fetch and install the target persona on a compatible mobile device running a compatible histrion or other DNAP-compatible app, without the need to explicitly quote or know the associated persona UUID or its online location.
11. Alternatively, instead of publication, once the persona is designed, it can merely be downloaded from the studio, as a "persona file" -*.persona. This is done by clicking on the "Download the Persona" button on the studio. This persona file can then be used to distribute the persona online or offline, and can later be installed in histrions via the "Install from File" feature for example.

The Histrion
Once a persona has been developed -via the studio, or by hand, a means to turn it into an app that someone can then interact with is necessary. The "Histrion", which is available both as a mobile and web app as of this writing, is what plays this role in the DNAP architecture. It is the "front-end" of the DNAP, and precisely specified, is: Definition 5: Histrion: A general purpose app that can parse and interpret persona source code from which it then renders persona applets.
In a sense, a histrion is akin to a web-browser, only that instead of HTML, CSS and JavaScript, the Histrion processes a special JSON encoded document called a persona, and instead of mere web pages, it outputs persona applets (see Definitions 1 and Definition 2).
In a sense, a histrion is akin to a web-browser, only that instead of HTML, CSS and JavaScript, the Histrion processes a special JSON encoded document called a persona, and instead of mere web pages, it outputs persona applets (see Definitions 1 and Definition 5).
As its name implies, this technology behaves more like an actor in a theatre; capable of assuming new roles and looks on-demand, based on the currently active script -in our case, the "script" being the "persona script" introduced earlier on. Looked at this way, it could be argued that most (if not all) existing web-browsers are a kind of histrion -in which case a persona script is analogous to a document written in markup language, but that's where the similarity stops.
As of this moment, there exist two reference implementations of a Histrion -one for Android mobile devices [9] and the web [8]. Both of these can take a persona and output a compatible persona applet that a user can interact with, though currently, the mobile implementation of the Histrion surpasses the web version in terms of feature completeness -for example, the web histrion does not yet support the "Show Video", "Play Audio" or "Device GPS" field types, though, it supports enough of the other basic types to serve its purpose as a platform for the implementation of surveys, polls and basic data acquisition and data dissemination tools.
To get an appreciation of what the Histrion does, here's a simplified architecture of the Reference Implementation ("RI") Histrion.

Figure 4: RI Histrion Architecture
The key highlights of a histrion include: 1. It is a standalone app, but whose purpose is to load and run other appsthe personas.
2. It can load personas from a local (file) or remote source (URL) 3. It renders a persona as a native app depending on where the histrion is running -mobile or web 4. It allows a user to capture or view data 5. It can cache a previously loaded persona, so that once loaded, user can run the persona even if offline 6. It can allow offline data collection -data records collected known as "acts" (see Definition 6) 7. Personas published via a compatible Theatre (such as chwezi.tech) can be discovered and can be locally cached via user-configured subscriptions to "Channels" (see Definition 4).
In addition to these core features, the current mobile implementation of the Histrion citeLutalo2019 allows for basic user identification and taggingat installation time and or via the default histrion settings; the user specifies a name and contact, which information is automatically included in each and every act, so that later, it becomes possible to distinguish and attribute data submissions from multiple devices to their respective owners/authors -what in information security is known as "non-repudiation", a very important factor in data security.
To see what a histrion loaded with a persona looks like, refer to Appendix 2 and Appendix 3 -for an example of how the Persona specified in Appendix 1 looks like on the web and mobile histrions respectively. Otherwise, you can see a blank, "vanilla" histrion by installing the reference mobile histrion [9] or the web histrion [8].

Acts
As we have already seen, the key purpose of the DNAP is to collect structured data via compatible histrions. In this regard, when a persona is used to capture some set of pre-defined data fields via a histrion, the resulting data recordwhich is encoded using JSON, is what is called an "Act". Definition 6: Act: A data record whose structure is a flat JSON document with keys corresponding to fields on a persona, and the values holding data recorded against each field during a data collection session, typically via a histrion.
Thus we know that given an act, we expect there to exist a persona specifying its data semantics. In general, an act has the following structure: The extra fields not labeled <FIELD ID> are "meta fields", that help to classify or track certain aspects of the data collection session that produced the data held in the <FIELD VALUE> entries.
For example, given a persona such as "NJURA" (refer to Appendix 1), the following is a valid act: You will note that this JSON instance is not readily decipherable without proper context or extra information -say, access to the specification of the persona applet -the persona, via which this act was generated.
Definition 7: Canonical Act: An act in which the data is referenced using keys that are ids corresponding to fields on the parent persona, and which also contains a "UUID" record among its "meta records" that points to the DNAP Persona UUID that can uniquely identify this parent persona. Definition 8: Annotated Act: An act in which the data is referenced using keys that are human-readable labels corresponding to fields on the parent persona, and which might or might not contain any "meta records".
Note that in canonical form, an act does not make it immediately obvious what the data means. Thus, to interpret the data held in such an act, it would be necessary to consult the parent persona specification -which one can obtain by fetching the persona referenced in the contained Persona UUID of a valid act.
Given such a Persona UUID, one can retrieve the necessary specification via a standard API call in which the UUID is used to tell the theatre to fetch the persona with the specified UUID value. An example of this is depicted in Appendix 1 for the UUID c6e47f79-afd9-4ebc-8753-3da5aa5f4cd7.
In some cases though, an act can be depicted in an annotated form (as opposed to the above "canonical form"), in which case, the Field IDs are replaced by the actual labels or names of the fields associated with each value in the original persona. This annotated form is for example what one sees when they access the Act Cache via the web (see Appendix 4) or mobile (see Appendix 5). Below is an example of the above canonical act as an annotated act:

The Theatre
This is the backbone or rather backend engine of the DNAP. More formally; Definition 9: Theatre: Any web server that satisfies the following requirements: 1. It can accept and store personas published via a studio, using a REST API 2. It can allow such published personas to be accessed or referenced from a compatible histrion using a REST API 3. It can accept and store canonical acts associated with these published personas via a REST API 4. It can accept and serve requests for canonical or annotated acts for known published personas when given the associated persona UUID, via a REST API.
As you can tell from the above definition, the theatre acts as the "glue" that ties together the other components of the DNAP. It is possible to use the studio and histrion without a theatre -for example, one could design a persona, and instead of publishing it, merely download and manually load it into a compatible histrion. But without a theatre, management and security of the tools and data thus generated becomes a nightmare! The key role of the theatre in the DNAP is to make management of tools, data and the users that operate on them much more easy and straight-forward, and all this, done securely and via standard protocols.
As you shall see in the typical DNAP workflow (Figure 5), once a persona has been designed via the studio, one has the option to first publish it onto a theatre, before they use it. This is the recommended approach and highlights the first role played by the theatre on the DNAP.
Once a persona has been published -to a theatre that is, it is associated with a globally unique identifier, the "Persona UUID", which the theatre will know about, and using which, one can then fetch the persona specification by URL, so as to load it into a compatible histrion as a persona applet (see Figure  4). Such access is possible via a standard API of the form: URL-1: https://<THEATRE FQDN>/api/persona/<PERSONA UUID>/ The above URL, which is accessible using HTTP GET, returns a JSON document that is the specification of the persona referenced by the specified PERSONA UUID. An example of such a specification is in Appendix 1.
The third core role of a theatre is that it allows data captured via these personas, on compatible histrions, to be collected and stored in one place for later use or reference. This is the reason there is a "theatre address" parameter on each persona specification; at design time, the author of a persona needs to specify how data acquired via the persona shall be transported (the reason there is a "transport mode" parameter) and where that data shall be submitted to -the theatre address, which for the typical case (in which acts are submitted using HTTP POST), is the URL of a REST endpoint on a compatible theatre. For example, in the reference implementation of the DNAP, the default Theatre Address for personas built via the reference studio implementation is of the form: URL-2: https://<THEATRE FQDN>/api/act/create/ Where <THEATRE FQDN>is 'chwezi.tech' by default. But it is important to note that not all personas need specify a URL for a theatre address; where the transport mode parameter is specified as "EMAIL" or "SMS" for example, this parameter expects an email address or phone number respectively. In this case, we can expect these to be specified as valid URIs using the "mailto:" or "tel:" schemes respectively -though, in the default implementation of the histrion, the scheme part can be eliminated, so that this parameter merely takes in a URN [11].
Finally, the theatre should be able to accept HTTP GET requests for, and serve any data submitted to it for the specified persona, given the persona UUID. In general, such a request involves making a call to a REST endpoint on the theatre, using a URL of the form: URL-3: https://<THEATRE FQDN>/api/persona/<PERSONA UUID>/acts/ Which returns all currently stored data for the persona specified using PER-SONA UUID as annotated acts. Alternatively, there is URL-4: https://<THEATRE FQDN>/api/persona/<PERSONA UUID>/racts/ which returns the same, but as canonical acts. Note than in either case, the result of performing such a request on the theatre returns a JSON array, whose only contents are the acts or which is empty -in the case where no data exists yet for the given persona or where access to the act stream is restricted without proper authentication.
This mechanism allows data acquired via the DNAP to be immediately consumable from almost any standard data processing interface -web-browsers; text-editors; command line tools such as wget, curl or jq; spread-sheet programs such as Microsoft's Excel or Google's Sheets, or even professional data analysis and business intelligence platforms such as PowerBI, Tableau and others.
By requiring that the theatre conform to the above specification, it then makes building of data acquisition and data sharing tools via the DNAP much more straight forward, and standardizes such a process, so that once a tool is published, it is immediately and readily obvious how data clients shall reference and or access data associated with the tool, and that this data-access interface can be relied upon without worrying about how or where the actual data storage happens.
The theatre REST API abstracts the underlying web and database technologies required to actually implement a robust data storage and retrieval platform, and given that these features come straight out of the box for those using a standard DNAP instance, developing and utilizing data apps becomes so simple, even for non-technical users or those with no experience building client-server, web-based or database-powered software. This later point is one of the original key motivations for the DNAP -making access to and sharing of data from apps very simple and reliable for most users and use cases.
In relation to the above, it is important to note that for purpose of keeping things simple, the DNAP further standardizes how access to the data acquisition and data analytics interfaces of a given persona are to be done. This is especially true for the web-based scenarios. Thus, once published to a theatre, and once the persona UUID is known, then access to the web histrion and diviner of the associated persona is possible via the standard URI forms: URL-4: https://<THEATRE FQDN>/persona/<PERSONA UUID>/histrion/ URL-4: https://<THEATRE FQDN>/persona/<PERSONA UUID>/diviner/ For the histrion and diviner respectively. The histrion has already been discussed in the previous sections. Next, we shall consider the diviner.

The Diviner
Definition 10: Diviner: A general purpose app that can parse and interpret persona source code from which it then renders act stream analytics applets.
With reference to this definition, we note that like the histrion, the diviner is a general-purpose app, except that instead of rendering data acquisition interfaces, it renders data analysis interfaces for the associated persona.
The motivation for the diviner is simple; for the typical use case, a user wants to collect data to later analyze it. Thus, instead of merely offering the user a means to collect and share data -which the histrion and theatre does, the diviner further offers them a means to immediately be able to analyze data collected via those mechanisms, in the simplest way possible.
As of this writing, the only diviner implementation available runs on the web, and as such, is accessible via a web browser (like the Studio, Theatre and Web Histrion components of the DNAP). In the previous section, we have already seen how when given a published persona's UUID, and the theatre via which it is published, it becomes possible to access its diviner (refer to URL-6). However, like the web histrion, there exists a standalone diviner implementation [7] that one can access directly, and then, equipped with a valid persona URI, one can load and analyze incoming or existing data associated with the persona. Typically, an end-to-end data engineering task involves designing a data collection tool such as are traditionally called "forms", publishing it somewhere, capturing data with it, storing the data, then later analyzing or sharing the 5 DNAP's Novelty DNAP differs from some of its predecessors and contemporaries in the following ways especially;

How DNAP Works
• Where the central logical structure of other technologies and platforms is the "form", for the DNAP, it is something like a form, but with more capabilities than a typical data acquisition tool; we refer to this new structure as the "persona", and we have formally defined what it is in the previous sections.
• Several ways to kickstart a persona-authoring project from existing ones: • Ability to craft a persona directly in code from any editor (a feature aimed at experienced users able to edit existing persona code such as that downloaded from the Studio, or those who can understand and write the persona script by hand) • The speed and ease with which deployment of a persona can be done across many devices -Deployment can be done by downloading the designed persona (encoded as a DNAP persona file -i.e *.persona), which can then be shared via mail, social media, or any file-transfer method, so as to later be run on mobile or web via a histrion. Meaning, personas are exportable and thus sharable outside the DNAP ecosystem.
-Deployment can be done using "Channels", whereby the persona is published under a specific keyword, that is then used by subscribers to automatically discover and fetch the persona (and any other related ones) from an online repository such as a theatre. This feature also brings to the DNAP the concept of automated data service discovery as applied in Service Oriented Architecture.
-Deployment can be done using QRCodes; in this case, a QRCode is generated every time a persona project is published via the studio, and it can be scanned using a histrion, from anywhere, which fetches, installs and runs the target persona as specified by the persona QR-Code. This allows for quick and effortless sharing of persona-software across devices without actual transfer of files or configuration of anything on the side of the users.
• Personas run on mobile as native mobile apps -the histrion turns any persona into a native mobile app, complete with custom themes and the ability to create custom launchers that make using personas feel like using ordinary mobile apps than traditional form widgets that other platforms offer. Additionally, these personas can function offline -for data acquisition, storage and dissemination especially, though data analysis and some types of data dissemination require connectivity to function.
• Data Resilience -apart from supporting offline rendering of personas on mobile and web, the mobile histrion supports a feature called "Sticky-Acts", which can be manually or automatically turned-on or off for each cached persona, and which feature, when enabled, lets the app automatically save a persistent, local (on-device) copy of any data created by the user via that persona, regardless of whether the data was posted to the online repository yet or not. In the reference implementation, the histrion never deletes sticky-acts unless the user manually triggers this. This feature offers a simple, client-side data-recovery mechanism that can be very useful in the absence of a reliable data connection between histrions and their configured theatre.
• Personas can explicitly be linked to each other -for example, it is possible to design a data acquisition tool that includes a mechanism to hot-load another related or dependent tool on-demand from the histrion. That way, it becomes possible to build sophisticated, multi-step forms or wizards, or even implement hierarchical documents akin to websites directly on DNAP.
• Personas support simple relational data models -for example, it is possible to design a persona applet that includes a menu field whose items are autopopulated based on the posted data (the "acts") of yet another another persona. This ability to reference fields from other personas is based on the data APIs automatically generated by the theatre for every published tool, and which APIs offer a means for clients to query, filter, and apply basic transformations to persona data ("act streams") via a simple and secure RESTful mechanism.
• DNAP tools are not limited to data acquisition form-type apps only, no. It is possible to design a persona whose purpose it is to only show, but not collect data. This can include showing text, images, playing back audio or video, displaying the contents of a website or even displaying the data from the same or another persona. With this kind of capability, the DNAP further sets itself apart from other similar technologies in that it can be used to build a wider category of apps outside of traditional data forms -say, e-magazines, periodicals, marketing apps, e-learning apps, music players, and more. And further, if well designed, the content of these apps can be dynamic such that content changes between app reloads, based on client-side interactions or other conditions such as time.
• Feature Completion: without relying on any external or 3rd-party tools, the DNAP suite includes all the elements required to perform typical data engineering tasks end-to-end; design, host, distribute and run data collection and analysis tools from one place. Further, DNAP's data analysis tools allow for the design and use of persistent analytics dashboards useful in long-term data monitoring, management and reporting scenarios.

DNAP applied to Data Engineering
When it comes to data engineering, the main tasks involve being able to build mechanisms for performing the data acquisition, data aggregation and finally data analysis. This trio we have already explored in the previous sections when looking at the various components of the DNAP and how it works, however, let's delve deeper into the last item, which is arguably the most important. As mentioned earlier, the DNAP deals with acts (see Definition 6), which are a form of structured data. There are many ways structured data can be analyzed, but generally, the choice of analysis method depends on the structure of the data, the domain or purpose of the data and the preferences or skills of the analyst. However, for the DNAP's current diviner implementation [7], analysis is of an exploratory kind by default -what the formal literature refers to as Explorative Data Analysis (EDA).
That the DNAP gives focus and priority to EDA is justified by the importance of this form of analysis in most -if not all early phases of scientific research and analysis. In their seminal work on the subject, Yu et al [12] stress that EDA is a very important step which takes place after feature engineering and acquiring data and that it should be done before any modeling. This, they indicate, is because it is very important for a data scientist to be able to understand the nature of the data without making assumptions. Further, the purpose of EDA is to use summary statistics and visualizations to better understand data, and thus find clues about the tendencies of the data, its quality and to formulate assumptions and the hypothesis of the subsequent analyses.
In this regard, it comes as no surprise that DNAP's Diviner gives priority to EDA by making available the following analytical capabilities on any data collected using the platform: 1. Generate a basic tabular projection of the data 2. Generate an advanced tabular projection of the data -includes pagination, sorting, search and filtering 3. Generate a line chart from the data -requires than one of two chosen fields include a numerical type (or where both are categorical, a numerical transform such as COUNT be applied) 4. Generate a time series chart of the data -requires than one of two chosen fields include a timestamp type (note that by default, all acts generated via 7 Potential Users of the DNAP In brief, the DNAP makes it easy to design, deploy and manage mobile and web tools for structured data acquisition and analysis as well as tools for information dissemination or combinations of both. But more specifically, the platform targets the following categories of users and use-cases: • Monitoring and Evaluation teams, Data Surveyors and Data Analysts: these can be business owners or managers in need of simple, continuous, and reliable monitoring and evaluation of their business processes via mobile or web, in and out of office.
• Data Analysts that already have data pathways from legacy systems, but who need to extend their data footprint by adding new data acquisition channels in a simple, but efficient manner.
• NGOs and other large organizations whose optimal performance relies on having quick and reliable access to data and insights about internal or external metrics, and which data they need to collect themselves or via third-parties on-demand, with low ICT overheads, and especially while keeping such operations low on budget.
• Researchers at all levels -whether it is students wishing to document school lab experiments, professors collecting a little extra data for their esoteric projects or industrial experts in need of a quick and effective way to source for actionable data about difficult processes; whenever one has a need to put together a form for collecting data, and if they do with to use something better than paper or a spreadsheet for this, then the DNAP offers a simpler, cheaper and more reliable option that is easily accessible to users at all levels of expertise by design.
• Data Hobbyists -it could be friends of democracy, that just wish to crowdsource for opinion using distributed polls; it could be someone in need of documenting and analyzing their own eating habits ("self-quantification"), etc.
• Data Disseminators or Publishers: Using the information sharing capabilities of personas -showing images, video, audio, text, web pages, etc. It is possible to design and distribute such usually tricky things as e-magazines, periodicals, e-books, podcasts, and more, over the DNAP in a way that combines ability to share information, but also obtain feedback about it, all simplified.

Known Limitations of the DNAP
As with any software or technological platform, there are both structural and technological limitations to be found in the DNAP. Among these, the most notable ones include: • The DNAP's diviner, which offers data analysis functionality, can only operate on data in the form of acts.
• The web histrion [8] can't reliably support all the field types that the mobile histrion currently supports. For example, using GPS, Camera and Barcode field types meets with challenges across various browser types and operating systems, which is not the case with the native mobile histrion [9].
• If a malicious entity discovered the UUID of a persona not meant for public, anonymous access, they still can go ahead to craft a persona QRCode with which access to the persona and its dataset can be obtained without the owner of the tool discovering this. There is currently a limited mechanism to prevent access to the dataset for personas requiring an access token for their data APIs, but this feature is only configurable by those users with access to a persona's administration pages on its associated theatre -which in the reference implementation [7] requires an invite or administrator account.
• The DNAP's studio and histrions can't yet handle such field types as input via OCR, and though support for a sensor-input such as GPS is currently supported, other obvious types such as temperature, humidity, luminosity, and the like aren't yet supported.
• Though ability to populate data-driven field types such as the Menu fieldtype can leverage remote, online data sources at runtime, this capability is currently restricted to data specifically formatted as a flattened JSON array of strings or numbers, and this capability only implemented in the mobile histrion.
• Data submitted to the online data repository, the theatre, can only be editable by users with administrator access to the associated persona's administration pages, and this access is not readily obtained via the persona authoring tool -the studio. However, those using the mobile histrion can still edit data they locally hold on their device as "Saved Acts".
• Currently, there isn't much analytics capabilities offered on the DNAP's diviner beyond EDA. There is a simple regression analysis capability that was introduced for pairs of numeric fields, but it isn't well evolved and can't handle categorical or temporal data types yet.

Conclusion
All in all, the Dynamic Nuchwezi Architecture Platform offers a new way for both professionals and amateurs to design, publish, share and exploit web and mobile tools for data acquisition and dissemination in a straight-forward, very simplified way. By championing a simple, browser-based visual coding paradigm as the default way to design and deploy these tools, the DNAP readily realizes the modern idea of "Citizen Programming" that is of growing interest in the software engineering industry [14], and thus offers a much needed solution in a world that increasingly needs to put the power to perform automation in the hands of as many people as possible. However, Dynamic Nuchwezi Architecture Platform can further be enhanced in design and implementation so as to support more use-cases in the data acquisition, data dissemination and data analysis contexts. These, so that DNAP becomes the ideal, fully self-contained solution for those performing real-world data-driven work hinged on tools collecting or consuming data as is typical with data engineering, data science, business intelligence, as well as data service providers with a desire for speed, simplicity and robustness while working on and offline.