Recently a partner said to us ‘You know, some of your customers are actually using agilebase as an engine to power their business, in ways that go beyond simply building applications.’
And it’s true, agileBase is being used not just to deliver user-facing apps, but to act as a central store, processing data which is fed in and out of multiple third party systems, including for transaction processing, interacting with machinery and feeding public websites. It’s a service upon which other elements can build.
Emergent use-cases like these occur so often with startups: customers find new and exciting ways to utilise the technology which the founders didn’t necessarily envisage. This in turn opens up opportunities to grow the business in new ways and to provide way more value than ever before.
This use does however place more demands on people and systems, covering many facets, including
- Scale: the throughput of data possible with API-based inflows and outflows is much greater than that of human beings manually interacting with systems. The same goes for automated workflows which can act on many thousands of records per second
- Criticality: if a user can’t do their job for 5 minutes because the system is down or broken, that can be critical, but if an interaction with a third party system fails for 5 minutes causing multitudes of transactions to fail and potentially reputational damage, that’s much more likely to be critical. Both of these events have very low probability but still the consequence of the latter is far greater.
- Complexity: when agileBase transitions from a platform powering user-facing apps to an engine powering a network of interdependent and often third party services, system complexity increases, so new means of dealing with this need to surface.
We recognise this is a major change. If growth in this area continues at its current trajectory and nothing is done, the system will start to be overwhelmed, with all customers being affected.
However, that’s not going to happen as we’re not standing still. We’ve already started implementing concrete changes to ensure we’re ahead of the curve. We’re serious about planning for and supporting this use of the platform, as opposed to just capping usage at a certain number of requests per minute or limiting complexity artificially.
Work we’ve started
At a board level we have agreed to commit to support the option for customers to use “agileBase as an engine”, in other words following the principles behind Service Oriented Architectures.
As a direct consequence of this we have engaged consultants to help us identify how we need to adapt, both technically and commercially.
Technical – platform development
Some immediate recommendations we’ve actioned or planned are
- Employing people to increase the test coverage of
all of which must, given the increased criticality of the use case, have a higher level of stability and predictability. We’re also
- Updating development processes to increase automation and reduce errors. (Amongst the tools in our armory are continuous integration, unit tests, static analysis and 3rd party library auditing)
- Updating deployment processes to minimise downtime
- Taking measures to shape API traffic, to avoid usage spikes from one source impacting the whole system
- Introducing new workflow features (see below) to make them even more powerful and useful for automations
In the longer term, we’ve a roadmap which goes much further, with items such as
- completely removing the need for any downtime at all when deploying new versions
- scaling horizontally for virtually unlimited capacity increases
Customers will now be able to run a much higher volume of workflows and rely on larger volumes of transactions flowing through the API, which opens up new ways of using the platform.
We will in future be introducing two new pricing elements to accommodate this, one for workflows and the other for APIs. These will allow us to
- ensure the platform can move forward at the required pace
- properly service and support customer requirements in the professional ways expected of us.
Please be assured that general base costs will not be rising, only customers using these particular features will need to factor them in.
We greatly appreciate the innovation that current customers have brought to the table by using the system in this novel way. It’s what helps push us, and everyone else, forward.
Therefore we want to recognise this value and help these companies by offering a free remote session or face to face meeting, to
- Uncover your most important mission critical elements so we can, at a later date, build customer-specific unit tests to cover these elements to add to our growing test suite
- Gather further feedback and requirements about what would make the system even more useful, with the results being prioritised in our roadmap
We will be getting in touch with any customers who may benefit from this, and to assess whether there are any cost implications for the future (there will be no immediate changes).
As always, we look forward to talking to you. Get in touch by any of the methods listed on our contact page, or drop in and visit us at Bristol & Bath Science Park.
Background to Workflows and APIs
Fundamental to many of these new and innovative usage patterns are two features – workflows and APIs.
The thinking behind the development of these features followed the same pattern we’ve used while creating the whole agileBase platform; make things which are powerful because they’re easy to use (following common principles) and flexible i.e. generic enough to be used for many different purposes.
For the technically minded, APIs can be auto-generated for any View in the system, by ticking a box. Developers get an industry standard Restful, JSON based API based on the contents of the view, complete with https://swagger.io/ description for easy import to third party systems.
Similarly, workflows are built on Views. Using the built in agileBot you can set rules for how to automatically process data – whether creating, updating or deleting it, as well as generating documents and automating email communications to and from people.
|Example: one customer running a membership franchise uses workflows to automatically recognise and de-dupe leads coming from multiple sources, to aid the attribution of leads back to marketing campaigns. APIs then send and receive data from the website to track customers’ touch points and spending.|
To help customers with this particular emergent usage pattern, we’ll be introducing enhancements to both of these features, so watch this space.