How much is too much automation
Automation has changed so many aspects of our working lives. Right back from the earliest signs of automation with the automatic water collection in Egypt or the printing press in the 1700’s Exelate shows us how automation is constantly there to make our lives easier and more effective. So with automation making our lives easier, is there ever a point where it can become too much? Is there ever a time where we need to genuinely think to ourselves it is time to stop? Well lets take a look.
WHAT IS AUTOMATION
Okay, Okay. Well let’s just do the housekeeping. We should all be on the same page for understanding what automation is. Automation is the term given when making apparatus, a process, or a system operate automatically without or minimized human interaction using predetermined decisions. Automations can be classed as basic, process, integration or artificial intelligence (AI).
Your basic automations could be a simple input data task and nothing for. Process automations are designed to create efficiencies and transparencies. Integration automations are there to mimic humans. Performing X, doing Y. Anything you do multiple times in the same way can be automated. Lastly AI is there to learn and perform those tasks, but we all know that is its own topic.
So what is automation within the Atlassian ecosystem? Automation for us is covering the first three types. It is there to make your lives easier and make you more productive. There are different ways of automating - native, workflow extensions and scripting. All have their benefits but all also carry a level of technical debt which contributes to when enough is enough. We’ll be rating this out of 5.
AUTOMATION IN THE ATLASSIAN ECOSYSTEM
A4J AND A4C
Atlassian’s native automation platform. Automation for Jira & the newly created, Automation for Confluence. Some incredibly powerful no code / low code automation engines. To get a full rundown on the automation engines read A4J / A4C.
While options are actually some what endless, the only thing that stops us is the imagination, there are some more common examples.
Some of the benefits of the native automation platform are that it is by far one of the easiest automation platforms out there to learn. The simple to understand when if then that statements mean anyone can follow and develop the rules to reach their full potential. Easier to learn does not mean any less powerful though.
Another huge benefit is a big deb reducer. Being able to delegate abilities to the project admins means more users can get rules made, more users can look after them and less reliance on the system administrators. All of this means happier users and a happier system.
what can you not do?
Unfortunately every system is not perfect. A4C is still in early development so some of the options we would like to exist for confluence, just aren’t there. For these more unique situations you need to rely on working with webhooks and APIs. Not everyone is comfortable with this. While the ability to create variables and use smart values does exist, there is still a deficit in the ability to run incredibly complex and dynamic calculations.
The Jira native counterpart has an extensive ability with smart values, calculations etc. However, it can struggle when trying to do large dynamic calculations with data from webhooks.
Tech debt vote
tech debt level - 1.5/5
MARKETPLACE WORKFLOW/LOW CODE AUTOMATIONS
While the native platform is incredibly powerful, there can be times when it isnt necessarily the best thing to use. Your business may have some more unique requirements or you may want to have additional actions happen directly within a workflow when something is triggered. The best place to look for these types or automations is, well you guessed it, the wonderful Atlassian marketplace. It is an absolute techies playground, with third party vendors creating solutions to almost any solution you could think of. While there are others that exist on the marketplace, there are no more common than Appfire’s Jira Suite Utilities (JSU) or Jira Misc. Workflow Extensions (JMWE). Both these apps are workflow extension apps aimed at slightly different administrative experience levels. JSU is a great getting started app, while JMWE is more aimed at provide low code automation options for the slightly more experienced admin. Appfire has done some incredible work with these apps over the years, so lets take a look at some of their capabilities.
Like the native automation, both mentioned marketplace apps have the ability to run basic automations such as:
Update any issue field.
Create linked issues.
Transition linked issues.
etc.
In the post functions, variables or conditions on the workflow transitions, JMWE also has the ability to use smart variables, much the same as native automation, meaning you gain more granular control of when and how those automations work.
JMWE also has some more extensive abilities. You also have the functionality to run shared actions. Using this post function allows you to reuse the same setup over multiple transitions within a workflow or multiple workflows, all while having a single item to maintain. This can greatly reduce the time it takes to make updates and can make every admin happier.
JMWE also has the ability to come away from workflows slightly and trigger their post functions based on events or just have them run on schedules. While configuring those, you have the same options available to you when creating post functions on your workflows.
What can you not do?
As mentioned above, only JMWE can use variables extensively through its automations and even come away from workflows, but even while having the ability to step away from workflows, its event based triggers are slightly more limited compared to the native counterpart.
So why would you use an app?
The JMWE send email post function is better in my option for flexibility in design and ability to incorporate a single issues custom field data.
Outside of specific functionality, personally, I have always love having the separation from automations that happen on because of X movements on a workflow etc. It is a pre determined action with pre determined outcomes. Like transitioning a ticket to the done status and having the issue get a resolution. It makes no sense for you to make a different automation rule for this. Its clean to have that automation run from the workflow with an app.
I have also found over the years that it creates a smoother maintenance and break fix support journey. when something does go wrong, you don’t have to remember items on workflow then switch to a native automation rule, it’s all in one place.
Tech debt vote
Tech debt level - 2/5
SCRIPTS
Finally we have scripting. While scripting can offer sometimes the most functionality, and unfortunately sometimes the only way to get those very specific use cases dealt with, it does come with the most technical debt.
With scripting, you have the most flexibility in terms of how you want to work. You can work with pretty much any system you so wish to, as well as any code language you choose. Just connect to the APIs and you’re off. However to avoid opening that can of worms and having every developer on my ass for bashing their favourite language, for the purpose of this blog, I’m going to keep to the marketplace app scripting options.
If you need to script you basically have two options - Adaptavist’s Scriptrunner or Appfire’s Powerscripts. They can both achieve the same outcomes, but are written in different languages, which again have the own benefits.
Scriptrunner uses Groovy as its code language while Powerscripts uses SIL (Simple Issue Language), a dedicated language to the app and the Atlassian ecosystem.
what can you do?
what can you not do? When it comes to scripting you kind of have the ability to do almost anything you want, including mass archiving or projects, creating configuration or even working with external systems. If you want the ability to do those more complicated matters, this is probably where you will be.
However, like all systems, there are cons and unfortunately, scripting probably has the most.
Both apps limit who has the ability to manage the scripts, meaning, yes it is down to you admins and you admins alone.
You also have to know the coding language. While some are easier to pick up then others, this still increases the technical debt as it increases risk.
Neither is native functionality. Atlassian does not have a native scripting engine, meaning you again, have to rely on third party apps to help out. Now these two apps are not really going anywhere and they are well supported by the vendors, but it is still an additional thing and is an additional cost which needs to be factored in.
Can cause the most damage. Before you come at me, I am well aware, any automation can cause damage. Scripting though, can cause the most since you can pretty much do anything you want.
While I personally believe that PowerScripts is the easier of the two to pick up and can provide all of the same functionality you would get with Scriptrunner, check out this article from a solution partner that ran a feature comparison.
Tech debt vote
Tech debt level - 4/5
HOW BEST TO BUILD AUTOMATION
So now we have been through our three options for automation, how do we make sure we build automations using best practice to shape them? There are some fundamental elements I think are key to building automations.
building with scale in mind
Think about how your rule will scale. As your company grows, your rules may need to be reused or change. When creating the rule, use elements that allow it to be easily adaptable and grow as the business changes.
reduce tech debt wherever possible
Proactively scan your environment to see wherever tech debt can be reduced. You will often find that some of your previously made rules were probably made can be updated for new actions making the rule smarter and more efficient.
DOCUMENT your automation
We will not always be at the same place where we make our automation rules, so we need to document them. A leading cause of automation failure is due to adopted and undocumented rules that your engineers have to learn before fixing. Documenting how they work and what they do will speed up resolution times.
LOW/NO code platforms
Low code / No code automation engines are becoming ever more prevalent. GARTNER projected that in 2021, no code automation brought a 23% increase in productivity. A great way to reduce technical debt and build your automations to the best of your ability is to move what you can to Low code / No code engines.
WHEN DOES IT BECOME TOO MUCH?
when you can no longer sustainably look after it. Tech debt is too high. Some of you may have seen the “is the jar full” story on social media, with the ping pong balls, pebbles, sand & water. If you fill your jar with large complex items, you limit the availability and resource to manage smaller and easier things. If you now imagine your Atlassian environment as that glass jar. Every action you do has a cost. Some will be so minute that it won’t matter. Some will be simple changes to update already previously spent actions. But your jar is only so big and with every action does come responsibility to maintain it for the future. The more complexity you build, the harder things can become to maintain and the more of your jar is filled. You only have so much of a finite resource to look after your ecosystem.
SUMMARISE
I wanted to write this not to put people off automation. Far from it!! I want to impress how great automation is, but just how quickly automations can get out of hand if handled incorrectly. Depending on the requirements of the automation, select the most appropriate path (lowest possible path) and go. Start by writing it on paper to help get the structure in your head if you need to.
When it comes to handling other automations, proactively scan your environments, and always develop with scale in mind. You do that, you’ll be just fine.
