Tonkean is redefining the automation industry by breaking away from traditional models of “imperative step-based automation” with a radical alternative.
The alternative is a platform that is driven by “declarative state-based automation,” which enables automation scenarios previously impossible.
This article will help you understand why declarative automation is so meaningful, how it is a fundamentally different approach from existing automation solutions, and why it’s a key enabler not just for more seamless automation, but for true no-code.
In software engineering there are two, widely used paradigms—imperative programming, and declarative programming.
Declarative programs are state driven, and thus far more concise and easy to understand. They enable developers to simply list the different states of a program and to define how the program should behave in each of the states.
On the other hand, imperative programs are “literal”, and thus more complex. They contain significantly more code. They require developers to also define how the program moves between the states. Imperative programming forces programmers to provide precise instructions for how the state changes across the lifetime of the program.
The state-driven approach of declarative programs has huge efficiencies over imperative programs. Declarative programs allow programmers to focus on how each state impacts their program—and not on the implementation logic of how that state changes.
Let’s look at a real life example. Declarative programming is akin to asking a friend skilled in the craft of car repair to fix your car. You don’t worry about how she fixes it; that’s up to her. You just care about the end state of the car (which is hopefully fixed).
Imperative programming, on the other hand, is like calling a friend to help fix your car, but you have to tell her how to fix the car step-by-step. Assuming your instructions were precise enough and she understood, you should still end up with a fixed car—but at a far greater effort.
The latter approach is also inherently brittle. Imperative programming is like putting software on rails: The application is forced to move between states in a very specific and pre-programmed way, and any deviation from that logic that is not supported doesn’t reach the desired state or potentially breaks the application.
Declarative programming abstracts all the complexity of how we get to our desired states, and lets us focus only on what happens after that fact. It allows program definitions to be significantly more robust. Programs don’t break if an application arrives at a state in an unforeseen way, because all state change is handled by an expert system designed for that task.
In declarative programs, there are endless degrees of freedom to move between states, and so implementation can be abstracted. Complex programs are more easily made composable and can be more rapidly scaled by simply defining new states or extending existing states.
So, how does all this translate to process automation?
Organizational processes are no different than computer programs. They are built from different statements that describe how a business process should move between different business states until a desired outcome is reached.
Traditionally, low-code automation platforms such as RPA and IPaaS systems—which are used to automate parts of organizational processes—take an imperative approach. They expect automation engineers to define all of the sequences and steps that describe how data should move between business applications, and what actions should be taken by the automation to move between the different business states.
The downside with that approach is the same as imperative programming—it’s process automation on rails! Every permutation and every edge case needs to be defined literally. Deviations from the predefined sequences are not supported, and the automation breaks down when the process arrives at a business state in a new or undefined way.
Imperative automation works well for simple and predictable automations. For example, high volume repetitive tasks with low variability, such as two point integrations, or clicking a button on a screen every hour.
Suppose the task in hand is to send an email every time a new ticket is being created—that’s a simple, predictable automation and can be easily done with an imperative approach.
But if the process you are looking to automate involves sending an email when a customer is considered at risk (which can be determined by a combination of multiple data points computed over time), imperative automation will fall short. The definition of “at-risk” might be dynamic or asynchronous, and the data required to make that assessment might be partial or inconsistent—dependent, for example, on properties such as the closeness of the renewal date, the customer tier, anomalies in the volume of support tickets, or errors on the customer account.
Imperative automation can also be good for personal productivity hacks, because an individual’s work patterns are typically predictable enough to be defined imperatively.
Essentially, imperative automation is suitable when there are a small and constant number of ways to move between the desired business states. Only then is it feasible for the automation paths to be defined imperatively and for those use cases to align well with functionality offered by RPA and IPaaS solutions available in the market today.
But what do you do when automation sequences and processes are complex and dynamic?
This is the challenge when automating enterprise-wide processes at scale; when there are thousands of employees each interacting with an organizational process in a different way, creating many variations of long and complex automation paths. And this is where declarative automation becomes so valuable. It’s the only feasible way to model the complexity of enterprise-grade automations because it hides away the implementation of state changes from the business process.
A declarative automation platform simply works differently. It continuously monitors the entire state of an organization’s critical business applications, enabling you to focus on which business states matter—and not how the system arrives at a given state.
Using the same Customer “at-risk” example above, in this case, the definition of what “at-risk” means is declared as part of the process, but nothing about the manner in which it’s measured and tracked needs to be defined. Instead, the organization can focus on what happens when the state of “at-risk” is achieved, no matter how it was achieved or the order of occurrence of its internal composition. You only need to declare that this state is what you care about, and how the automation should act when it happens.
By focusing on business states, an organization is able to abstract away the implementation details of the automation and focus on the business process from an organizational prism—and not the data flow prism that is common on iPaaS platforms. You can define the states that matter and not how your applications arrive at those states.
Declarative automations are powered by continuous context supplied by real time access to complex states across system data. Since state is continuously monitored, it doesn’t matter how state is derived. This enables automations to be invoked asynchronously, even if a state change takes hours or days to complete. The automations are always invoked correctly, as they are based on context and not on previous steps.
And this is how we’ve designed Tonkean to work.
Tonkean has redefined automation by embracing the declarative paradigm. In Tonkean, the business process owners can define the states that matter, and the business actions that should be performed when the process reaches those predefined states.
Tonkean achieves this by continuously monitoring a holistic image of the data across all systems within an organization and by taking action no matter how that state is derived. Tonkean is the only automation platform available today that does so.
That small but powerful difference opens the world to declarative automation and more importantly enables one to apply business abstractions over the technicalities of automation.
This is important. The business abstraction layer on top of the state that Tonkean provides connects organizational processes to the underlying automation platform. By focusing on business state and abstracting the actions performed (a topic for another blog), business logic becomes composable, and organizations can robustly define automations that continue to work even when the mechanics and systems beneath the automations are replaced.
This simplifies everything. Real world processes make so much more sense when you only need to think about the states you need to handle, as opposed to all the steps and events you need to manifest in order to lead to that state. In the real world, processes involve humans who can take hours, days or weeks to take an action. With Tonkean, that doesn’t matter, since declarative automations support truly asynchronous workflows, as your programs are never dependent on previous steps or on how long it takes the process to arrive at a state.
The resulting efficiencies are massive, as processes that contain multiple imperative steps can often be boiled down to a handful of critical states.
Another example to consider is the process of escalating a support ticket. There could be multiple ways a ticket is escalated, but the state of the ticketing system is all that is required to capture the automation definition:
Here, a complex set of step driven automations becomes a very simple state-based automation.
We’ve seen this in software before. When Facebook made a declarative paradigm shift—by introducing React JS, which revolutionized how programmers build application interfaces—they redefined the industry of web programming. Before React, programmers battled with JavaScript to imperatively define how interfaces should update each time an event in their programs caused the state to change. They had to think about all the possible actions that would drive those state changes and make sure that interface responded to the change.
After React, which continually monitored the state of the entire application, programmers were free. They simply declared interface components, and defined how each component should behave in a given state. Because React was declarative and decoupled from imperative logic, programmers could create reusable, abstract components that could be easily composed to build complex interfaces.
The impact was world-changing, and mirrors in many ways the impact Tonkean is making in the context of automation.
But automation is only the beginning. Because the abstraction that makes Tonkean’s declarative approach to automation so useful is likewise integral to realizing the full promise of true no-code.
What holds most low-code/no-code automation platforms back from realizing that promise is they’re grounded in imperative programming paradigms, which prove in practice either technically preclusive or creatively limiting—resulting in low-code/no-code solutions that are either only usable by people who know how to code, or that are not powerful enough to create much real value.
By removing the need to worry about directing programs from state-to-state, and by abstracting the task of defining states, declarative paradigms transcend these limitations. And this is what makes revolution actually possible. It’s what changed the software industry. It’s how Tonkean is changing the automation world. And it will be integral to other advancements in accessibility and technical independence that are to follow—but more on that in a later chapter.
Want to learn more about what makes Tonkean’s approach to automation and no-code different? Click here.
