Feature Waves - An Overview
A walkthough of the new approach to deploying updates to Enate going forward.
The Feature Wave Approach: Building the Foundations for more Innovation
With this latest update to Enate, we're introducing a new approach for how we roll out system enhancements, which will now be done via 'Feature Waves'. This has involved making architectural changes to allow us to support a fully SaaS approach, focused on the following improvements:
More gradual & less disruptive UX improvements
Maintaining Stability and Compatibility for Integrations
Gathering (and reacting to) user feedback from real users throughout the design process
A more robust, scalable and user-friendly platform
Here's an overview explainer of the Feature Wave approach, and how this new architecture sets about achieving these.
What is the Feature Wave approach and why is it needed?
Until now the Enate platform has operated as a monolithic application, with a single API and database model, meaning that every release required updating the entire system at once. This structure limits our agility, making it difficult to release features incrementally or patch specific components.
The strategic decision to shift to a SaaS only model enables us to deliver capabilities that help clients operationalize AI, validate new user experiences more quickly, and become more agile overall.
Key Architectural Changes
The key architectural changes we are implementing are as follows:
Versioned APIs - The Enate APIs will become versioned APIs meaning that we will be presenting a stable interface for integration with the core Enate platform. This is how the Enate Marketplace works (for example).
More Scalable, Testable & Redundant - The new Enate architecture will automatically scale out based on user demand, we are making full use of scalable cloud compute. The platform will also be truly redundant between Netherlands and Ireland with near instant failover possible between the two regions.
Alphas & Betas - New user experiences will (wherever possible) go through Alpha and Beta phases with real users being able to try them out and give the product team feedback throughout the process, before rolling out to the broader userbase.
More 'SaaSy' - In ‘pure’ SaaS platforms there is only ever one version of the code in production at any time. We won’t be going to that full extent, but there will be some aspects of Enate that will be delivered this way. Everything delivered this way will be patchable without ‘taking a new release’
Feature Waves - The concept of an ‘Enate Version’ won’t truly exist any more. Instead, changes to the public APIs will be released in Feature Waves, with each feature wave potentially bringing new versions of APIs while continuing to support old versions.
Feature Waves, Alphas, and Betas - How it works
The above diagram shows how features may move through Alpha, then Beta, then onto full usage, and how different parts of the user base will experience this.
Feature waves are regular updates that might include new features, support for previous API versions, and changes to the user experience. The very first feature wave is mostly behind the scenes, so you won’t notice any visible changes right away.
Feature in Alpha
Before we release each feature wave, we may run a new feature or feature change in alpha. These are early versions of a feature with experimental (but robust) designs, shared with a small group of users so we can gather proper user feedback on the design and be able to make iterative improvements.
Feature moves to Beta
Once we’re confident with an alpha release, we will move the feature to beta (this change is done as part of a subsequent Feature Wave). These items are now feature-complete and as part of Beta will be made available to every user in through a 'feature switch' so they can try out the new experience, or stick with the old one if they prefer. This widens out the user base and allows for more user feedback on the design.
Feature moves on from Beta, becomes default
Finally, after we’ve collected enough feedback and made any necessary tweaks, the new experience becomes the default for all users, and at the same time the feature switch option for users to flip between the beta and production model of the feature goes away. Again, this change for the feature option is brought about as part of a subsequent Feature Wave.
Impact on Users, Integration & Testing
For most people using our platform day-to-day, feature waves will have very little impact. Changes will be rolled out gradually, and only certain groups will see new features during the alpha phase, with a widening audience in the beta phases.
If you’re working with integrations, you don’t need to worry about immediate changes, because previous API versions will stay available for two feature waves, making sure everything stays compatible.
And when it comes to testing, user acceptance testing is only needed if there are explicit changes to the business logic, so testing will now only be done where behavior has changed.
Change to URL Format
With the move to the new architecture underpinning the Feature Wave approach, we're making a change to the format of the URL for Enate environments. Please note that Production environments will automatically redirect to the new url and so operational users should notice NO change in interaction. Also, this does not change the environment that users are working in. See below for an example of how the format change would look for 'acmecorp':
Old format: https://enate.cloud/acmecorp/workmanager
New format: https://acmecorp.enate.cloud/workmanager
There is no additional work or instructions needed to give your production userbase - they can simply continue working as normal, using the old url for e.g. saved shortcuts if they wish, and the system will always auto-redirect to the new url format.
Similarly, existing APIs will continue to work as normal, with urls automatically redirecting. Please note however that our preference would be that you work with Enate to update your API configuration to use the new url once it has been established.
Any changes to non-production environments such as UAT environment urls (which will not automatically redirect) will be worked through in conjunction with Enate's team as part of your migration activities across to this Feature Wave.
Release Upgrade Process
Feature Wave Release Dates visible 12 months in advance
When it comes to releasing new features, we want everything to be as smooth and predictable as possible. With that in mind, once clients have been migrated across to the initial feature wave infrastructure, we will start publishing our feature wave release dates 12 months in advance, with just a small plus or minus five-day window for the actual deployment.
Operational Activities following each Feature Wave release
We anticipate releasing new feature waves every 3 to 4 months once the initial sets of Feature Waves (mostly covering the deployment of a new UX) are complete. When a feature wave is released, timelines on activities will be as follows:
As soon as a new feature wave is released, all non-production and UAT environments are upgraded (within a few days).
There is then a 4 week window available for customers to carry our their UAT activities on Testing on these non-production environments. Customers can ask for their production environments to be updated to the new feature wave within this period.
After 4 weeks, ALL production environments will be updated to the new feature wave, specifically on the 5th weekend after the feature wave release date.
Upgrades are designed to involve minimal downtime, mostly for activities such as schema migrations, and are completed outside of business hours.
Patches are rolled out with zero downtime thanks to release slots. Plus, each feature wave continues to support the two previous API versions, so bug fixes are applied to those supported versions, but not to any older releases.
New Architecture Model - High Level Description
Enate adopts a stamp architecture on the Microsoft Azure platform.
Enate Clouds are stamped out and managed with infrastructure-as-code tooling called Terraform.
Production clouds are high availability operating in two regions through Azure Front Door with temporary UAT environments released to clients with each Feature Wave.
Most customers operate within the Shared Cloud, but customers can pay for a Private Cloud if they wish.
Next Steps
Enate will now begin migrating initial test instances across to this new feature wave, and will be contacting you in due course to start organizing your migration to the November 2025 Feature Wave.
Last updated
Was this helpful?