In this release we introduce the final part of our Distributed Integration concept: “Append”. Append focusses on the usage of libraries and offers a complete new technology to evolve from managing knowledge to applying knowledge. Information becomes yours.
The concept of append libraries
With Append, it becomes extremely easy to apply accumulated expertise in projects. Examples are standard verifications consisting of standard checks, a default set of requirements per physical object, task lists or complete work breakdown structures that can be appended to your project workspaces. This way of knowledge usage improves quality, speeds up the project and avoids to reinvent the wheel.
The Append technology distinguishes itself by the selective and dynamic nature of how knowledge is applied in projects. Firstly, a library makes proposals and the project members can decide whether or not to incorporate that information: they are the only ones that can qualify which information is relevant and useful for their project. As a consequence, a library is not required to be complete and fully reviewed before it can be used in projects.
Secondly, the Append technology is network oriented; instead of cloning elements, the information network around a source element is appended from the library to a project element. This subtle difference opens a very new way of using knowledge. A project element’s information can be gradually enriched during its lifetime. And for this same element, different complementary libraries can be used to append from, instead of just one single, comprehensive library.
Using append libraries
Appending is the process of enriching the information of an element in the project workspace, by taking over an elements information network from an append library.
Given an instance element in the project workspace that is the target for appending, an end user typically performs the following steps:
Initiate. On the target, initiate the appending process and select the element of the append library that should serve as the template.
Prepare. Verify the information that is involved and if desired, include or exclude parts of the targets information.
Complete. Confirm the appending, resulting in the target element being enriched.
The append technology gathers information from the library and adds this information to the target element. In a formal mapping, the functional designer specifies how information from the append library should be inserted in the project workspace. This mapping allows the append library and the project workspace to have their own independent information structure.
As an example, consider “Project ABC” that manages the information of verifications consisting of checks. At project start, a verification plan is created, describing the verifications that must be executed during the project. During the project, verifications are extended with additional checks, in order to deliver quality at the end.
Traditionally, these checks are created from scratch and entered manually. The new append technology gives the functional designer the opportunity to set up a library workspace “Standard verifications”. This enables the reuse of information, speeds up the project process and prevents that important checks are left out.
After selecting a standard verification, an end user is still able to adjust the subset of checks that is appended to his project. This enables project members to intentionally include or exclude certain checks. After all, the “Standard verifications” library probably contains a rich set of optional checks to select from.
Creating a verification (from scratch) and appending library information to it are two different things, but an end user can combine these in one single “Create” action that results in a fresh ‘clone’ of the standard verification.
The strength of appending lies in the ability to append information to the same target more than once: from different templates or even from a completely different library. Suppose that “Project ABC” is also going to manage the set of precautions for a given verification. For this purpose, a second library “Precautions” is set up, containing verifications with precautions. After creating a verification and appending checks to it, the end user complements the verification by appending precautions from the “Precautions” library.
The append algorithm is relatively straightforward: where possible, it enriches the target with the selected subset of template information. Appending a template multiple times to the same verification adds the checks just as many times (because of the “Create” behaviour of the relation between verification and check). A precaution is skipped if the verification already contains that precaution (because of the “Select” behaviour of the relation between verification and precaution) and a precaution is added if it is not present yet. In case of a conflict between the target and the template, for example a mismatching property value, the append operation shall not be executed.
Defining append libraries
Setting up an append library requires no effort. A Relatics type element has a setting “Template behaviour” and if set to “Act as template”, its instances (and their network) can be used as templates for elements in other workspaces (in the same Relatics environment).
As a result, libraries can be developed relatively easily. As a quick start, consider copying the workspace of a best practice project and define this copy as an append library. A new project can use this library straight away and further development of the library is just a matter of reviewing content, eliminating redundancies, re-ordering best practice information and removing unnecessary project information.
The following sections cover two advanced configurations that give an idea of the power of append.
An append library can, just as a project workspace, use the Distributed Integration concept Referencing to connect to another workspace. The project workspace and append library can even share the same Referencing source workspace. For example, persons in the project workspace (responsible for verifications) and persons in the library (responsible for a verification by default) are both pointing to the same workspace “Employees”. Appending a verification from the library results in persons in the project workspace which are in fact pointers to the “Employees” workspace.
Another example is a workspace “OTL” (“Object Type Library”) that contains a taxonomy. By sharing “OTL” as a referencing source across project workspaces and append libraries, we facilitate a common language to connect all kinds of information: both the project workspaces and append libraries use this shared taxonomy.
The image below shows how “Standard verifications” and “Standard checks” are managed in separate append libraries. The “Standard verifications” library relies on “Standard checks” using referencing. So a user who defines standard verifications, actually selects from this “Standard checks” library.
On the other hand, the project workspace can use both “Standard verifications” and “Standard checks” as append libraries. Obviously, this enables a project member to append from “Standard checks” when adding checks to a verification. But more important, when a project member appends a verification from “Standard verifications”, the append technology follows the standard verification to gather information from “Standard checks”. The libraries perform as if they are stacked. So when appending a check or a verification, the latest information from “Standard checks” is used.
Taking this concept of stacked libraries one step further: imagine another workspace “Standard systems” that defines standard systems and the required standard verifications. In other words, “Standard systems” is stacked on top of the “Standard verifications”. If a user of the project workspace now appends from a standard system, the “Standard verifications” library is accessed to append verifications and the “Standard checks” is accessed to append checks as explained above.
Mapping append libraries
How a project workspace appends information from an append library is defined by a so-called Append definition that specifies how attributes, properties and relations are mapped. For example, in the project workspace, an append definition for type element “Verification” specifies how a “Standard verification” in workspace “Standard verifications” is appended into the project workspace.
In addition, select-relations in the library can be used to append create-relations in the project. For example, in the library “Standard verifications” the relation between standard verification and check can have “Select” behaviour, while the relation between verification and check in the project workspace has “Create” behaviour. This keeps the append library maintainable while in the project, each verification has its own set of checks and associated answers.
Released on April 14, 2016.