What we’re going to be talking about today are the basics of the task delegation system we’re building at Mativy using Neo4j:
Efficiently Delegating Tasks: The “Ant Model”
At Mativy, we try to tackle only large and complicated tasks — and we like to learn from the animal kingdom. This article from ABC Science Online talks about ants, which are incredibly strong when they work together.
Take a piece of cereal for example: no individual ant is strong enough to move it by itself. Instead of having to figure out how to move the cereal to the nest, they have a scout showing them the way. This requires constant communication and synchronization.
So how do the ants do it? What’s the trick? The ants have the overarching task to bring the breakfast cereal home, but each one also has an assigned subtask: some are pushing, some are pulling, some are scouting. The recipe is to first split the task and then delegate it. But as I said, the ants weren’t moving in the right direction, so they needed a scout to show them the way.
If you draw the parallel to the human world, every project needs to be split into smaller tasks. We want to assign specific tasks to specific users, but the only thing that we can be sure of is that we will have to make adjustments. Just like the ants, we need to communicate and be synchronized. So we are creating a tool that will enable us to focus more on the times that things don’t go according to plan, with a focus on communication.
The big problem is when we only split the project and delegate the tasks, which results in personal task lists that are frequently changed over time. We need to communicate what is wrong.
So — why did we choose Neo4j? Because a graph database is a really good fit for our requirements. It can model, split and delegate extras in a natural way and it allows us to move the tasks easily, effectively and quickly. We initially implemented the project five years ago in a relational database (RDBMS), which couldn’t support an adequate load of users. And that’s when we found Neo4j.
The Demo: Under the Hood
To show you how this works, in the below example I’ll take you through a full task life cycle. Every task in our system has three mandatory task elements, the three W’s: What is the task? Who is responsible for it? And, when is it due?
In the following example, John needs to ship an order and notify a customer by Monday. The first action we take is to create a task:
Let’s follow the recipe from before. First, John splits the main task into two smaller tasks: shipping and notifying. He delegates the shipping to Sarah, while the notifying task remains John’s responsibility:
The next step is for Sarah to commit to completing the task, and then they sync target completion dates. John initially asks her to complete it by Monday, but she’s out Monday so she asks John to change the due date to Tuesday. All of this communication happens directly through the system.
Because there was disagreement on dates, there is a synchronization cycle. There can be disagreements over a lot of things — maybe someone needs additional information, or maybe they’ve selected the wrong person to do the job. But all of these are possible synchronization cycles performed in our system.
It turns out John is okay with the due date and so Sarah gets a date. And as I mentioned above, we copied the task from John to Sarah. But even though he may not be doing the legwork, he is still responsible for the task. And if John rejected the Tuesday due date, he could either assign it to someone else or complete it himself.
Let’s fast-forward to Tuesday. Sarah has completed the task so we enter another synchronization cycle.
When Sarah has done the task, the system notifies John that the task is complete, and he then needs to confirm completion of that task. He could also reject the completion, which would initiate another synchronization cycle in which he could assign it to someone else. But he’s happy with Sarah’s job and confirms it, and resolves the synchronization cycle.
Now he moves on to his task, which is to notify the customer, and once he marks his task as complete, the original, overall task is completed as well:
So Why Neo4j?
So why is Neo4j good for this type of process?
We came up with a whiteboard diagram, and this is what it looks like:
We added some relevant nodes, isolated each person in their own node and added a root element for carrying purposes. And we go a step further: we have full access to the history of the life cycle of the task, including the sub-tasks and who was responsible for which pieces. We save all actions of users, whatever that action was, change date, change description, all litigations, all splittings. This type of data model wouldn’t work in a relational database.
We keep this type of history so that managers can make better-informed decisions in the future with the data that has been collected. For example, you can measure how quickly a user completes a task, whether or not the task is completed on time, etc.
We can also implement automatic notifications that can alert you to a stop in any given process, or a user’s inability to synchronize. You can check the system and might see that Sarah and John are still talking about the date and can’t reach an agreement, which would notify the manager.
This is what the history looks like in the database:
Every user action generates a node that contains all the relevant data needed to reconstruct the test history. For example, if we change the date we save both the previous and current date, and the same applies to the task description. Because the system enables us to read full history of every task node, it’s possible to reconstruct the entire task lifecycle efficiently.
This concept is now a true application that we have developed called the “Forget Me Not” app, which is only available for iPhone. Right not it’s only an example of a two-person task that is focused on the synchronization cycle, and you can contact the other person to come up with the best time to have a conversation.
This is what the application looks like:
In the first screen, you are able to view your calendar and select two possible dates and times to send to a customer for a phone call. On the second screen is the opportunity to write a message, as well as to accept or propose a new date, which is like the synchronization cycle from John and Sarah above. On the third screen, an agreement is reached, and they both get notifications 15 minutes before the call.
So remember this: The article I mentioned above says 15 ants is the sweet spot to move the breakfast cereal. So if you need to speed a task, you need to delegate efficiently and be constantly synchronizing. And Neo4j is perfect for modeling this.