OutSystems Partners

At Version 1 we have been working with OutSystems since 2019 – and have recently had a series of large public sector projects go live.

Whilst every project has its own challenges, this blog explains some of the low-code-specific challenges that have popped up along the way, despite our best efforts.

We get it, developers move fast with OutSystems. That’s fantastic, and typically results in 30-50% less development time than traditional coding.  But invariably our projects have fixed deadlines and a set of minimum viable product requirements that must be delivered for the first release. The danger we see is in a few areas, as highlighted below.

Perfect is the Enemy of Complete

Can the customer’s product team keep pace with the changes, and keep a backlog for future sprints, that is not just a constant iteration cycle around some of the main screens?  This requires a step back after each sprint, to look at the progress against MVP, and strong control over what is ‘good enough’ for this release, knowing things can always improve.

Sometimes it takes an experienced agile business analyst to really lean in and help prioritise; sometimes it takes strong and active project management or governance, that really leans into the content of each sprint.  But the focus should be in making all required features work, and then improving them – instead of trying to really optimise one at the expense of others.

Negating the Admin Users

Are we spending enough time outside the main happy path – with the role of administrators, helpdesk operations, and supervisors to act on behalf of any one of the other actors in the scenario?  Especially with large public sector customers, people sometimes just don’t get the technology, so we need to make sure we can troubleshoot and support effectively.

One pattern we often surface is to make all the system data available to a supervisor role in the super-easy “list and details” routine. In this way, at least one end user can trace a problem through the tables, if it’s not obvious on the main user interface for some reason.  We do not want to have to rely on direct database access for routine data tracing and investigation.

Short-Circuiting the Testing

It’s really easy at the start of a project to just get into feature-factory mode, and churn out screens at a speed that is really exciting.  But testing those properly takes time, partly to look at the described feature and validations to ensure it works as expected – but also to look at the different end-user personas, and then do some exploratory testing to see how robust the solution is, and if strange data or click combinations come up with something unexpected.

One option for handling that is to include the functional testing in the developer’s definition of done – building up the regression suite

Trying to Solve Everything with One Platform

When all you have is a hammer, everything looks like a nail.

Never was a truer word spoken than when you invest in a massively capable development platform like OutSystems.

But the reality of it is, that no solution exists in isolation.  From the basics like email and SMS integration to location and map services, and then integration with the rest of the application and desktop infrastructure, there is a range of internal and external components that need to be connected to complete your architecture picture.  Some common options we see are:

  1. Identity – early on a single sign-on solution is seen as desirable but frequently overlooked. But at least the authentication should be integrated with Active Directory, Okta, or another provider.  It’s worth putting the effort in early on to get this done, as there will never be a good time to switch over.
  2. Data Warehouse / Analytics – whilst we love a good dashboard view in OutSystems, that’s probably best for the operational reporting, and the day-to-day. In customers where we’ve had the option to connect to a separate data tool by exposing APIs, we’ve been able to tap into a different skill set and a different view when it comes to progress reporting, benefits realisation, and even help troubleshoot potential data errors.
  3. API Management – either Integration PaaS options like Boomi or Workato, or Azure / AWS / GCP API management tools – with public sector customers, something is normally required to help manage traffic through a firewall and connect to on-premise solutions from a cloud-hosted instance.
  4. SaaS options – the world is well connected now, and many things have leading SaaS options that are just easy for the end user to consume – think about email & SMS (e.g. Twilio, or UK’s Gov.Notify solution). Maps, location, and distance calculation – Google / Bing Maps, ArcGIS.  Document storage if needed (we often keep ours as binary content in the database).  It’s often worth leaving a budget for these at the start to help MVP, and if you want to improve later, well, there’s a clear cost-benefit for that.

Hopefully these come up naturally in a discovery or architecture conversation at the project scoping stage.  But even if you bootstrapped a standalone MVP, at some point it’s worth opening the door to see where your low-code applications fit with the rest of the stack. Talk to our experts today about our OutSystems software solutions.

About our OutSystems’ Experience

Version 1 is proud to be an OutSystems Partner. As a long-term market leader, OutSystems are focused on constantly improving the developer experience and platform operation. This allows partners like Version 1 to focus on our customers’ needs and experiences – helping them achieve a faster ROI, and getting through more of the digital transformation backlog, with leaner, more effective teams.