Managing IT Frameworks

These days managing big projects in IT seems like a challenging task, involving large scales of dependencies. There are tools that help the organization of projects in many aspects but face challenges like: what is a complete project, or what documentation is relevant.

They shift the relevance of these opposite forces to the people that are getting involved. In the next few paragraphs I will try to describe a system that can handle changes in a very smart way, contributing to the transparency that IT projects have to be conformed to.

Organizing tasks using ruby's language tsort algorithm

Languages evolve. Some support powerful built- in features that can be used in various fields such as tasks management. In this blog I will describe how to organize task management using tsort algorithm using ruby 3.1

In order to describe the algorithm in simple terms, tsort is performing topological sorting in a way that can easily solve dependency problems between tasks. For example:

Let's imagine the following tasks dependency between 5 tasks.

A <- B <- C <- E
\
D

Topological sorting solves the following problem by iterating between each letter and gives the right solution on which task needs to be performed to pass all letters. In the above example, the algorithm checks first the letter A, which depends on tasks D, and B and C depends on E. The algorithm will pick the letter D as the first element of the solution, as task D completes a full circle of dependencies which the letter C is not fulfilling.

Then the algorithm will then check the next letter and avoid visiting the same path of elements that have been chosen. By checking task B, the algorithm will go to letter C and letter E. Since now a complete circle gets finished the last letter will be chosen as task to be performed second, the letter E.

Similarly, the check will give the following solution:

D, E, C, B, A

The solution the algorithm is giving is not unique.

Solving the Parent - Child relationship between projects and tasks

A project can be represented as a model that can hold information about description, progress priority etc. and many projects can have child projects, depending on the scope, phase. So, a parent / child relationship between projects would seem a suitable one to describe it, one dependency between parent and child projects.

Projects can be of no use when there are no tasks to hold more precise information about the actual text or any modification a project requires to finish. A similar relationship like parent/child brings the benefits of describing tasks relationships, where is needed, but adding a parent_id gives us the flexibility to describe more relationships with any task. This way tasks can be flexible nodes that can share the same parent_id and form a node in a graph.

Interoperability between projects

Now, tasks can have a parent task by default or any task can be attached to any project's tasks from this parent_id field. This means that we can have the flexibility of creating a graph network more easily to manage projects.

Having the structure ready of projects and tasks abstraction we can use the keys to reference a graph.

Embedding tsort algorithm to database tasks.

There is no obstacle to saving these graph dependencies to a database table as most of the databases support saving a key/value pair.

We could attach the set_key on before the save event. The set_key can be an easy “tasks_#{id}” template but we can try more meaningful content.

Now we are able to load all dependencies from the database and apply the tsort method to have a list of solving dependent tasks.

Scope management and execution context

Project's usually refer to different scope of a project life cycle that can be defined beforehand (ex ante). For example, a Project Management tool could quire the build and discussion about the requirements and many more. These are different aspects of projects that can be gathered together to define the scope. Phases also can be helpful to add another layer of abstraction.

Execution context usually refers to the bounded context of the task. This is usually defined when the projects are formed and tasks have already been formed. We can add this column to start monitoring the specific context.

Progress estimation, plan changes and context changes are usual fields that need to be tracked.

Event sourcing and auditing

Now as projects are defined and the full struct is ready while editing the projects we would like to keep a history of these edits. By keeping the history of the edits we monitor the events that happen and report them later.

A library named ‘audited’ gem can be easily configured with any field (attribute) that is significant to monitor.

Reporting and monitoring progress

Now the reason that we keep the edits to the project and task level was to be able to report the progress by weekly, monthly, and track work as it is formed. These edits can express the requirements of the project as it gets formed.

Event sourcing can be extended to further fields inside the database. One field that seems significant could be named :tools of hash type that can hold events from various sources.

Evaluation context

The association between users and tools can keep monitoring the progress of the deliverables that get delivered and requirements being formed. Additional properties can be attached to the provided to add more features (such as feeds). Further abstractions could include teams, and organization as the project progresses.

The benefits of developing such a system is the ability to evaluate (ex post) existing projects information. By gathering groups of same context tickets or pull requests, we could play the events in time, and see the balance between project requirements (tickets eg. Jira) played in contrast to project deliveries (pull requests) from eg. github.

The balance between these two aspects of the whole project organization gives the benefit of having the deliveries with documentation, which is good in almost all cases.

Thanks for reading.