You are viewing...

Better Backend Workflow Management

Updated on January 31, 2020 at the 11th hour
Posted under:

DISCLAIMER: Expressed views on this blog are my own.

I could say I've seen this some times when applications would contact a ticketing system to create a ticket and then see where a ticket is before performing an action. Typically, a human would interact with the ticket and some time later the state of the application changes and it performs the action.

I haven't seen this done via something like Trello or Jira though. You almost always have to interact with the backend system in some way to progress the task. Not very automated is it.

Since I've been creating a Task Management application, I've have lots of ideas and lots are being or already implemented. I think the best idea though may be for applications to have their own area in the task management system where it could assign a task to a user and set the privacy level only to that user and the user is notified there about updates and waiting for updates from user. All fields are locked down until the application says input is needed. The application could create different kinds of tasks with different sets of properties too.

Say, you wanted to do a self service DB migration, but the DBA could be brought in by the application if it detects a problem. How would you do that today? Create custom application that does the workflow management and try to fit it in with you task or ticketing system. Worse yet, the project may never get off the ground because it is not priority, but it would save pain and potential outages that occur.

What if you just had to define all the migration workflow pieces (as usual) and communicate the schema to the task management app rather than creating it via a UI. You could tell the task management app that the migration task container is public and the user just has to create a new migration task with the set of visible fields which would kick off a workflow to the migration application. Migration application would perform some initial validation of fields/databases/etc. then "hand over" a new task for the user to set a scheduled date for the initial migration (A -> B) after that is done, it would then create a new task asking the user to setup the async writes to which the user would eventually mark it as done. Migration application then creates a task for itself (invisible for a user) to monitor the write levels between A and B to make sure they are close enough and to sync any keys that were written to when the migration started (maybe there is a last accessed metadata in your db). After some time, it would mark the task as done and create another task to the user to switch to synchronous writes, eventually reads which is the full switch over.

If one is really good the migration application would do this automatically by contacting a proxy layer, so no user intervention is needed at all.

It is just one use case, but the time that was saved by not having to think about conform to the ticketing system, bombarding unrelated people with notifications because of rigid rules, involving the user as part of the migration worfkflow and not having to create your own workflow state system to extend the state properties of a ticketing system. Your application could ask the task management system to schedule task property updates. The tasks and the schema that you created are only part of your application and are invisible (if you desire that privacy) to the rest of the organization. It can be changed at anytime with no coordination.

I'd like to see my Task Management application used for this case. I created a task in my application to definitely attempt it myself as I keep dog fooding it.

Could integrate with Github/Bitbucket code reviews, CI/CD, Google Calendar to schedule events for workers, UPS/FedEx for tracking numbers and etc. Why UPS? Datacenter users would find that one a package is delivered kick off a property update which would roll over to their workflow system to create a security authorization task (which could send an email to the datacenter security) with the owner of the task, Google Calendar event in a relevant calendar and validation task for another system. Server or Network devices that come online could be linked by a hardware id to a task that contains the UUID and other parameters it should have.

I want to keep things very simple right now with core parts because this is a blend of Trello and Jira. I would most likely create a ticketing system on top of the task management system that offer some of those specified integrations and automations. Ticketing involves a separate kind of assumptions and is absolutely JIRA/Zendesk territory.

Very elated to see where this goes. 😀🐣

You just read "Better Backend Workflow Management". Please share if you liked it!
You can read more recent posts here.