In the last part of this mini-series, you will discover that the the rabbit hole is as deep as you would like it to be. It’s all about modularity and what your imagination can think up for the platform to do.
If you haven’t checked out the InfoNotion repository on github, now is the time. For this last article, follow the installation instructions and load the “in_Questionnaire_example”-example.
Although a functional module is not a meta model concept in the sense of the previous articles, it does hold information. It forms the link for the low-code developer to a specific functionality.
Part 3/4 of this series on how to start creating a low-code platform explains the design and the functionality to create pages. It is the UI-‘engine’ of the platform that lets (low-code) developers and end-users actually use the platform.
Flexibility is on top of the list. Let’s make that more tangible. Two of the main aspects to achieve that are:
Display any kind of data in any way — Genericity is paramount. Any specifics should be left out here, because that would render the low-code bit useless. So, the pages should be able to display any kind of data in…
This is part 2/4 in a series on how to start creating a low-code platform. In this part, the design of reading/writing data is explained.
It might be the most crucial aspect of the platform, since data structures and instances of these structures are all defined and created with this code.
The most important functionalities in the data-layer are:
The requirement of ‘creating the data structure once’ (see Part 1) dictates that the data structure is only stored in the database because this…
Last but not least, you might have questions for someone that are only asked when needed. How is it modeled in Neo4j, how is progress tracked and how can information be stored/fetched? I’ll show you in this last article.
So you have a question that must only be asked if a specific answer is given in a previous question.
With this new…
Because one question leads to another, part 2 of this article will elaborate on creating a static list of questions. I’ll show the metamodel, creation of instances and some queries to show results, just like in part 1.
Please read Building a Questionnaire in Neo4 — Part 1/3 for the choices made and queries to answer one Question.
The progress of the Respondent needs to be stored and tracked in order to know where the Respondent is in the List of Questions. It’s important to know that the result of each Question needs to be set before the next Question…
How a simple question can lead to many others. Implementing a Questionnaire and don’t want to ask yourself too many questions?
Use a GraphDB, use Neo4j! (and read this :-)
The goal is to supply you with Questionnaire building blocks for your own application and the why behind the design so you can adapt it to your preferences.
Part 1 will handle the answering of one single question. Part 2 handles the answering of multiple question in a linear fashion. Part 3 shows dynamic question lists (where questions become available when answering others.)
For simplicity, it’s multiple choice questions only…
There is always something strange about people in a software development team. It’s not its performance or how the team interacts with each other. Performance is usually great and they can get (or find ways to) along. But somewhere inside, you can see something bothering them. Something uncomfortable that makes them feel out of place… a nagging itch.
I bet you’ve seen (or felt) it as well.
Conceiving a new piece of complex software is cool. Especially when you get to do the groundwork. Choosing a language, framework, designing the software patterns, etc… In this period (which is mostly at…
When building your low-code architecture, there are some decisions you face that determine how your low-code platform/application will behave and what your business model is.
In an earlier article I mentioned three levels that low-code platform has: Capabilities, Behavior and Use. When taking design decisions, these levels influence eachother. They can have big consequences. Both positively, leading to the next big thing. And negatively, creating extensive resource drain (time, money, people).
Here are some aspects you’d need to think about that have a big influence on the business model of your architecture/platform.
We all know user stories. But what we have not recognized is that they are part of a trinity. So there are two other very important stories to tell…
In short the User Story is a description of what the user wants. In Agile it is used to describe a feature from the end-user perspective. It describes the goal and why the user wants it.
All around the globe, millions of software teams use them to write up the User Story and consider that the work to be done for a feature to be delivered. …
The builders of the Tower of Pisa might have thought that when they started building it. How about IT Architects? Why do we need them?
In short, an IT architect is a creative, collaborative problem solver for a multi-layered (organisational, technological, non-functional and functional) cake of problems that needs to blend into one nice, tasty package that can be well consumed by all parties involved.
Let’s dig a little deeper into the capabilities needed.
Let’s start with how the architect interacts with its stakeholders. This is an integral part of the architect its work.
Connect — The architect connects stakeholders…