3 tips for adopting a self-serve automation operating model (based on Atlassian’s journey)

While this approach worked for some time, various lines of business (LoBs) began to make more integration and automation requests, which inevitably led to a significant backlog and delays in delivery.

To address this issue head on, the platform team transitioned from a centralized delivery model to one that’s self-serve, allowing business units to build their own integrations while the platform team supports new feature releases and oversees security and governance. 

Unfortunately, this change introduced a new issue: most business units struggled to use their traditional iPaaS solution independently as they found it to be too technically complex. 

In response, the platform team decided to try a low-code/no-code solution in Workato—and the benefits were almost immediate. A significantly greater number of teams began using the platform consistently, allowing the platform team to execute on their self-serve delivery model successfully.

The platform team clearly treated the transition to a self-serve model as a journey that required iterations and fine-tuning. But with roughly 200 active users and countless impactful automations now built in Workato, it’s safe to call this change in strategy a massive success.

So, how can you adopt a self-serve automation operating model? Swarada Deshpande, a Principal Architect of IT Platforms at Atlassian, offers some guidance based on her team’s experience. 

Tip 1: double down on security and governance to keep your data, applications, and processes secure

Deshpande shared that “Security is a top priority across Atlassian, and our team is no exception.” With that in mind, her team has adopted several measures to ensure that adding more users in Workato doesn’t compromise security. 

Here’s just a short list of what they’ve already done and what they plan to roll out:

• They’ve applied team-based permissions at the Workato project level to ensure that the project’s assets—whether that’s APIs, lookup tables or connectors—are only available to certain users.

• They’ve built a dashboard that monitors a wide range of usage metrics, from the recipes a user builds to the number of tasks they consume. They’re also pairing these insights with background information on users—such as how long they’ve had access to the platform and the department they work in—to gain a more in-depth understanding of how the platform is being used.

• They’ve added specific automations for projects that fall within their SOX compliance boundary to help them maintain compliance more easily.

• They’re planning on building an automation that detects applications that get added as connectors in Workato and that aren’t approved by IT (which would trigger a notification to the IT team).

Additional learning resources for enterprise architects

How to build and scale your enterprise automation team (course)
Everything you to need to know about enterprise automation (certification training)
ROI calculator for implementing integrations and automations with Workato

Tip 2: empower users by providing proactive guidance, documented best practices, personalized dashboards, and support

The platform team knew that different users would require varying levels of guidance and support. With this in mind, they decided to adopt several initiatives:

• They’ve tried to optimize task consumption in recipes at scale by building an automation that’s triggered when a recipe reaches a certain threshold in tasks consumed. The platform team would go on to get notified, all but ensuring that a member of the team can quickly reach out to the builder and work with them on optimizing the recipe (i.e. finding a way for it to consume fewer tasks).

• They’ve helped teams and individuals build their own dashboards so that they can better understand how they’re using the platform. 

• They’ve provided documentation in Confluence that covers a range of topics on Workato, including when they should use Workato versus another one of their automation platforms and general best practices for using Workato.

• They’ve made themselves available to any builder in Slack via a specific channel.

Adoption at scale, however, also comes down to the platform:

Tip 3: share reusable assets to help builders implement integrations and automations quickly and at scale    

The platform team has also embarked on several projects that help users avoid duplicating their efforts and move quickly in building connections and automations. 

For example, many of their teams want to connect to the same set of applications, like Slack, but to different sets of endpoints. This has led the platform team to build deep custom connectors for popular applications—via the Workato Connector SDK—that various functions could use.

The platform team has also provided a library of recipe templates that users can select from and add to their development environment with ease—all but ensuring that users can find inspiration quickly and implement automations with little delay. 

Finally, different teams were tasked with taking job logs from Workato and putting them into S3, Splunk, or Opsgenie, which proved to be tedious. To help account for this at scale, the platform team built a logging, monitoring, and alerting framework at the platform level that could streamline this work.

Everything we’ve covered only scratches the surface in describing the foundational services the platform team provides and the solution architecture they’ve deployed.