To illustrate data integration, the diagram below depicts how the central KDDart storage is fed from a variety of input mediums which in turn feeds data to perform other tasks such as conducting analysis, managing inventories and preparing for future trials.

Users benefit from a software platform built from the ground up on open IT industry standards consisting of a three-layered architecture, the middle layer of which is a RESTful Application Programming Interface (API) interface.
Safeguarding the time, resources and acquired knowledge is a system flexible enough to adjust to the rapid changes in technology and breeding methods.

The base, or database layer, provides effective and efficient storage services for a diverse range of:

• Genotypic;
• Phenotypic;
• Environmental;
• Pedigree;
• Inventory; and
• Vocabulary data.

Central storage database(s) are only accessed via the middle Data Access Layer (DAL) using the RESTful API. The DAL provides the most reliable, optimal and flexible mechanism for storing and consuming data for all users of KDDart.

The top, or applications layer, provides users with software tools to interact and work securely and efficiently with their data in the system. Using DArT developed applications, any custom developed by your organisation ‘in-house’ or software developed by other collaborators, KDDart and the DAL will manage the integrity of and access to your data. This is one of the major benefits of a language agnostic system and API.

Access Management and Permissions form an integral part of KDDart's architectural design and operation since its inception. The security model employed by KDDart is a common Unix like construct based upon record level permissions, however unlike Unix, records are owned by 'groups', not users.

In this model users are assigned to at least one group. The permissions assigned to the group dictate the privilege level, e.g. read, write, etc. Group Administrator(s) are users with the ability to perform Group management tasks such as:

• Assign or add users to the group;
• Assign other users of the group as a Group Administrator;
• Delete records (when option available) owned by the group (except where dependencies restrict deletion).

Group Administrators can only conduct administration activities for those groups they are assigned to as Group Administrator. The creator of a group automatically has Group Administrator capability for that group.

The following Permission Matrix shows task that can be performed for different user types:

Permission Matrix

Task	Admin and a Manager	Admin and NOT a Manager	Manager	User	Guest
See all records regardless of the record permission	Yes	Yes	No	No	No
Change record permission regardless of the permission	Yes	No	No	No	No
Add and remove users, add and remove groups, add and remove users from a group and reset user password	Yes	No	No	No	No
See their own records	Yes	Yes	Yes	Yes	No
Update their own records	Yes	Yes	Yes	Yes	No
Change permission of their own records	Yes	No	Yes	No	No
Add and update types, design, breeding method etc. (vocabulary entities)	Yes	No	Yes	No	No
See public records	Yes	Yes	Yes	Yes	Yes

Users of applications within the Applications Layer, are provided access to data in the database layer using the access permissions of the user logging into the system. Data is securely managed and protected by the Data Access Layer, not the specific applications.

To serve the breeding cycle, several applications are available in the applications layer which are briefly introduced on the applications page. The following illustration of the breeding cycle shows the position each application manages:

Next - Applications Overview