IgniteWorx Design Models

Figure 63: User roles and user interfaces in IgniteWorx

Figure 63 provides an overview of the key user roles and required user interfaces in IgniteWorx:

 Ignite Project Dimensions Author (1): Responsible for creation and maintenance of Ignite project dimensions, using specialized UIs for this task

 Ignite Rules / Results Author (2): Responsible for creation and maintenance of IgniteWorx results sets, results and the rules that create the mapping between project dimensions and results, using specialized UIs for this task

 IIoT Subject Matter Expert / Author (3): Responsible for creation and maintenance of the content in the IIoT knowledge base, using specialized UIs for this task

 IIoT Project Manager: The end-user of the system, using it for assessing his or her individual IIoT project and getting concrete recommendations. Will require specialized UIs to support

o Project Assessment (4): The UI used to perform the project assessment based on the Ignite dimensions

o Project Assessment Outcome (5): The UI providing assessment summary and recommendations for individual project setup

The system implementation must ensure that the UIs as described above are provided in a way that allows efficient data capturing and presentation and also supports data privacy policies for the IIoT project manager to provide him or her with a choice of whether he or she is willing to share his or her project assessment data or not.

application development tools such as Ruby on Rails, Django, JHipster, and others are supporting a scaffolding approach, which automatically creates working—albeit usually rudimentary—applications from models (Sasidharan and Kumar, 2018).

To best support a hybrid architecture as introduced in 3.3.4.2, the IgniteWorx design proposes an MDA approach for the implementation. With this, one can select the most suitable elements from the different system categories described in section 3.3.1, as well as from the related concepts and algorithms described in section 3.3.3, model them using a modeling language such as UML, and then use an MDA-based rapid application development (RAD) or scaffolding framework to automatically generate the skeleton of the new system. This should help with minimizing development costs and provide a high degree of flexibility for supporting the evolution of the system.

In section 3.3.2.4, W3C’s OWL is taken as an example for technologies to support semantic reasoning systems. In theory, a language such as OWL could be used to model parts of the required functionality of IgniteWorx (an example is provided). However, most tools that support OWL or similar ontology languages are not designed to support more modern, web-based applications in a way that the aforementioned scaffolding tools are providing. This is why in the following basic UML is used to provide a consistent design for all required micro services of IgniteWorx. Zedlitz et al. (2012) describe an approach for creating OWL models from UML. This approach could be used to derive OWL models for those services where it is required.

3.3.5.2 Ignite Project Dimensions

For the Ignite project dimensions, a hierarchical data structure is suggested to manage project dimensions and options, as described, for example, in 3.1.1.

Figure 64: IgniteWorx project dimensions

Figure 64 provides an overview of the proposed design. IgniteWorx is defined as a so-called root entity, which aggregates all other entities underneath. All aggregated entity names have the character Q as a post-fix to indicate that they are actually describing the question side of the project dimensions. These entities are designed to actually capture

the project survey questions (as opposed to the survey answers provided by the end-users, as described in the next section).

As the first aggregation level, the entity CategoryQ is proposed. This entity can be used like a folder, which groups together different dimensions. Examples of concrete instances would be assets and devices or backend services (see section 3.1.1.). The position attribute can be used by the IgniteWorx engine for ordering the categories when presenting them as questions to the end-user. The ImageArea attribute can be used by the IgniteWorx engine to display an illustrative image, e.g., as a reusable solution canvas that guides the user through the assessment like a visual navigation tool. The IsRepeatable attribute indicates whether a category can be repeated in the project assessment. For example, the category “Assets and Devices” could be repeated for multiple asset classes.

Categories aggregate 0-n dimensions. In addition to “Position” and “ImageArea,” a

“DimensionQ” has a “DetailLevel”. This attribute can be used to support different levels of detail for the project assessment. For example, level 1 could indicate a quick survey, while level 3 indicates that an instance of this DimensionQ would be included only in a detailed assessment.

Each dimension aggregates exactly 0 or 4 options. An “OptionQ” represents one of the options offered for a question in the project assessment. As discussed in section 3.1.1., each dimension should offer exactly four options. Zero options will also be allowed for dimensions that are actually not really questions but rather an explanation about the next questions. Using this design, the aggregation hierarchy in this case is kept simple and does not use, for example, nestes categories.

3.3.5.3 Project Assessment

Having defined the question catalogue using the concept of Ignite dimensions, the next requirement is a structure to capture the concrete answers provided by the end-user in an individual project assessment.

Figure 65: IgniteWorx project assessment

Figure 65 provides an overview of the proposed design: “IgniteWorx” aggregates

“Project Assessments.” From an MDA point of view, one complication here is that project assessments are not necessarily saved in the backend, so the MDA framework will have

to allow for an exception here, for example, supporting data storage in the end-user’s browser.

Other than this, the proposed aggregation hierarchy is mirroring the design of the previous section: “ProjectAssessment” aggregates “CategoryA,” which in turn aggregates

“DimensionA” (“A” is now used as a post-fix since these data structures are designed to capture the answers, not the questions).

The link between questions and answers is created through the association between

“DimensionA” and “OptionQ”. This means that a “DimensionA” is representing a concrete answer, which references one of the four options provided by the question.

3.3.5.4 Result Sets

For the design of the result sets, there are at least two options. The recommended one is examined before discussing the alternative.

Figure 66: IgniteWorx result sets

Figure 67 provides an overview of the recommended design: “IgniteWorx” aggregates

“ResultSets,” which in turn aggregate “Results.” Each result has an association with an abstract entity “Content,” which represents content in the external services “IIoT Knowledge Base,” introduced in section 3.3.4.2.

The alternative design would have been to use an inheritance relationship between

“Result” and “Content.” The advantage of this approach would be that the actual number of instances to be manually maintained would have been reduced by half. Instead of creating a new instance “Result” for each result, a “ResultSet” could simply refer to different content elements included in this particular “Result Set.” However, the disadvantage of this design is that it would create a tight coupling between the components “IgniteWorx System Content Manager” and “IIoT Knowledge Base,” which would be against the principle of micro-services, as introduced in section 3.3.4.2.

3.3.5.5 Rules

This work proposes to also apply the MDA approach to IgniteWorx rules and manage them as entities in the repository. The advantage is that the same MDA templates used for the other entities can be used to create and manage rules instances, including the required UIs for this process (assuming the chosen MDA system is supporting this).

Figure 67: IgniteWorx rules

Figure 67 provides an overview of the proposed design for rules, which is actually relatively lightweight: Instead of modeling an “IgniteWorx Rule” as a dedicated entity, it is proposed to model rules as an association between “Result” and “DimensionQ.” An instance of a rule is required to indicate whether a particular result has a high (or low) relevance for a given dimension. This design is supporting exactly this. By actually using two different associations (“Relevant_If_High” and “Relevant_If_Low”), one can express whether the relevance is based on a low or high value of the dimension.

As long as the expressiveness of a rule is limited to this semantic, not modeling a rule as a dedicated entity significantly reduces the number of instances created in the system.

This is a huge benefit from a content management point of view since rules are—at least initially—created and maintained manually.

The idea is that this design will also support self-learning concepts in the next phase of the system evolution, as described in section 3.3.3.2. Analogizers or a Bayesian inference algorithm could extend the current data structures to make them suitable for its own needs without having to replace the manually created content from phase 1.

3.3.5.6 Engine and Matching Algorithm

The matching algorithm proposed for phase 1 of the system evolution is relatively straightforward. Figure 68 provides an overview using a concrete example.

Figure 68: Example of IgniteWorx rules and matching algorithm

This example describes an instance of “ResultSet” with four “Results” as children:

“Waterfall,” “SCRUM,” etc. On the other end, there are two examples:

“DimensionQ”/“Number of Assets” and “Lifetime of System.” “SAFE (Scaled Agile)”

has a reference (“Relevant_If_High”) to “Number of Assets.” This means that if a user indicates that in his or her project he or she has a high number of assets, then SAFE could be considered as a project management methodology.

The options always go from 1 to 4. This means, for example, that such a rule match could add a 4 to an overall weight. For “Relevant_If_Low,” the inverse order (4 to 1) could be used.

This design proposal is not specifying exactly how the algorithm should calculate the weights of the individual results, but there are multiple options:

 Sum: In this example, SAFE gets 1+3=4 (building the sum). This means that there is no maximum weight.

 Average: SAVE gets (1+3)/2 = 2 (take average). This means that all weights are always between 1 and 4.

 Pairwise comparison, as proposed by AHP (see 3.3.3.1)