If I were asked to choose one and only one software quality that constitutes the main strength of the Avature platform, I would definitively say extensibility, which represents a measure of the ability to extend a system and the level of effort required to implement the extension (i.e.: open/closed principle).
Of course, we pay attention to a wide range of important aspects such as security, availability, and performance. But, in my opinion, extensibility should be highlighted. We are constantly thinking of our customers and discovering an amazingly heterogeneous range of organizational styles that can't be represented with a single software. Or can it?
Extensible Workflows
Our approach led us to build some killer features that our users constantly benefit from, and I'm here to tell you about the one my team and I work on: workflows. In a nutshell, workflows are the way we model our customers' business processes, providing a fine-grained and configurable balance between automated actions and human interaction.
Do you want the process to start collecting input from a candidate from different sources? Done! Do you want the process to take care of digital signatures for contracts? Sure! Do you want the process to schedule interviews and manage your company calendar? Why not!
Our architecture was designed to be extensible, so it's not about what you can do, but what you would like to do. This means that if you wanted a drone to deliver a welcome package to your recently hired technology director, you could do it. It might be a bit creepy, but I'm not here to judge; I'm here to make that happen.
Our workflows are composed of a fairly flat hierarchy of concepts:
- Step: Status on which a "workflowable" entity is on. For example, a hiring process could be modeled as a sequence of steps: First Contact, Interview, Background Check, Sign off, Welcome.
- Actions: When moving through steps, the workflow can execute a set of pre-configured actions.
- Conditions: The workflow can check that a set of conditions is being fulfilled before allowing moving a "subject" to the next step. Those conditions can also be applied to each action individually.
There are more fine-grained concepts that are not relevant to the scope of this article but, in a glimpse, this is our workflow architecture:
As you can see in the diagram, we have 2 major extensibility points: the workflow subject and the workflow actions.
Workflow Subject: It’s the abstraction that we use to hide each entity’s internal complexity. While our application is capable of modeling lots of different entities, not all of these are eligible for being treated within a workflow. Furthermore, these entities are not within the scope of the workflow components and our module must guarantee that new entities can be supported without modifying the entire architecture.
Workflow Actions: The key to success when thinking about the workflow actions is to understand that this module leverages the value of other functionalities as well. That said, it is clear that our architecture must allow other teams to develop and deploy new actions. And that's where the beauty of extensibility arises. The "Actions Bus" supports registering new actions. Then it knows how to route action execution to the corresponding module. It’s also responsible for translating data from the workflows context to each action domain. For example, sending an email belongs to a module that doesn't know about steps and subjects, but it understands about recipients and messages. So, when deploying the "Send Email” action, a mapping strategy must be part of that deployment. That way, our module is able to translate a "Subject field" into a recipient and a "Step metadata field" into a message.
Illustrating the Point
In order to illustrate how extensible we can be, I prepared a simple and fun IoT (Internet of Things) project that I can control from within our platform. Let's enunciate our story first: "As a hiring manager, I want the system to cheerfully celebrate every time we hire."
Based on our architecture, we can build and deploy a new workflow action (“Celebrate") that will simply route the execution to a module deployed on an Arduino board. That module will raise a handcrafted flag made of straw and paper (yes, hi-tech as in the movies).
You can check this new module here.
Deploying the new workflow action took me approximately 30 minutes. It relies on existing functionality to manage conditions, execution time, security restrictions, etc. So, the only actual configuration being considered is the "endpoint" to call the external module.
But don't believe me. You can see this working in this video.
Conclusions
Building an extensible module can be challenging, as the code can organically grow to unknown and even dark places from time to time. Embracing this challenge with a spirit of discovery is a great way of building software that scales, while having fun as we fulfill every customer’s needs.