Concepts of automation

Many individual concepts within automation help define what it encompasses technically. In this section, let's focus on a few that are more applicable to common business scenarios or solutions within Software as a Service (SaaS).

To help visualize these concepts, please reference the following diagram:

Figure 1.3 – Visualization of the concepts of automation

Now that we have seen the visualization, let's take a deeper dive into exactly what these concepts mean.

Infrastructure

This is an important piece of the automation puzzle, and one not to be taken lightly. Thankfully, most SaaS will largely take care of this issue upfront. You begin provisioned with a powerful cloud solutions environment that can scale to your needs and contains robust APIs for interacting both internally and externally with the platform. Problem solved? Yes, but also no.

First, let's explore exactly what an API is. API is an acronym for Application Programming Interface, which is basically a middle software that allows two applications to talk to each other. APIs are essentially messengers for your two applications. I like to view it as if the API is a phone call between two friends. You can share information, receive information, make plans, cancel plans, and more via a phone call. Although you each have phones, voices, and so on, without the connection provided by the call, the API, you could not connect and communicate these messages without direct interaction. Now, back to the SaaS infrastructure.

While most SaaS platforms do resolve a lot of issues around provisioning and configuration, it may only be a piece in your larger workflow. Perhaps there is a business need for automating some communication with an external service at dynamic points in a customer life cycle? While some built-in tools can provide us with a way to track milestones in a customer journey, integrating custom services or solutions can require more complex solutions that require outside integrations.

Maybe you want to utilize your SaaS for individual functions within a larger automated workflow for your organization and not as a standalone product. Considering the road that your solutions run on is an important step in planning and designing a technical solution.

When selecting the environment that will house a given component of your solution, consider how well it integrates with the other platforms you've defined. Knowing how your systems are going to talk to each other is a key step of the planning phase and can drive the direction of your technical solution.

Triggers

Triggers are the events that flag an activity or process from some response or action by your automated solution. These can be initiated by both humans and machines and are the primary method by which your automated solution is compelled to complete some tasks.

A common form of triggers in most SaaS platforms is API entry points. Usually, when you call an API into the platform, it comes in with information that is used once the call is received (the trigger to take an action) to create a new action or process, such as returning data from the platform to the requestor.

Another example might be a form hosted on a website, and integrated with an external service or custom solution. The user triggers the event by submitting the form on the website, and an automated solution is called by that event to take some action (say, send an email confirmation).

These types of events can take many forms and differ in both type and the complexity of the action being triggered. For a webhook, like our form submission scenario above, some event is triggered automatically when an event has taken place in our environment.

Using something like an API, for instance, requires data to be requested and for a response to be generated based on the validity of that request. The main takeaway here is that we need to keep in mind that there is a wide range of possible trigger events, but the core concept remains consistent.

Data collection

Data collection often involves a form being completed, but it can also involve data being automatically extracted or received from a system. For most automated processes, the validity and robustness of your data store can define the scope or functionality of the solution.

While there are use cases where a method of data ingestion or collection is not needed, and the trigger itself is the only required source of action, most processes will require some form of data collection to generate an automated solution.

Planning how your data will be ingested and stored should be a priority when developing the flow of your automated solution. Ensuring your data store has a consistent structure and schema, and that the data you're storing is properly formatted and reliably populated, are both key to ensuring that you can retrieve it reliably when needed and that it will integrate well with your solution.

Important in this regard will be data validation, particularly when capturing or importing data from user-input or external services. Your solution will only be as good as the data you collect for it, so take care to make sure it's as clean and consistent as possible.

Information routing

Information routing involves moving data between people or systems where business rules and logic dictate where data needs to travel next. This is a common concept that can be found in solutions both internal and external to most SaaS platforms. When implementing a solution that utilizes complex data flows, containing multiple sources or destinations, understanding the routing necessary to seamlessly pull it together into a final source requires careful consideration of both your individual components and of how they depend and interrelate with one another. Sequencing, timing, and monitoring are especially critical and can be the difference between a successful or failed program.

For external solutions or those that involve multiple systems integrating within the same core initiative, it becomes even more important to understand the information routing occurring with a solution. In this scenario, you're accounting for the flows across various services that are subject to failures, timing inconsistencies, and misconfigured trigger events, among others.

Activity tracking

How can we define the success or failure of a program if we don't have a reliable way of tracking its performance against our defined goals? Tracking what happens from end to end in a process allows processes to be audited and measured in order to improve the solution or otherwise highlight points of failure that make it ill-suited for automation.

When integrating with external systems, this becomes even more critical, as there are more points for failure that must be accounted for and tracked reliably at the request level. Taking a proactive approach to logging, in addition to constructing your solution for ease in reporting and accountability, can help mitigate missed errors that propagate or obvious points for remediation and revision.

With these core concepts in hand, let's take a look at some common best practices to consider when building automated solutions.