Low-code and high-quality: How to successfully implement low-code at a large, multinational organisation.

OutSystems is on the rise and breaking through in the enterprise market. Today there are many large, multinational organisations that are using OutSystems not for simple app building, but as a core strategic platform that is fit for mission-critical applications. Ownership and governance of these low-code platforms is put at Head Office IT level and the platform is subject to the same level of security and information classification assessment as any other core IT component, like ERP systems – and although these assessments take time, they are one-off exercises that pay themselves off in the sense that the platform is accepted by all levels of the internal organisation, once all internal controls have been passed.

The reasons why enterprises go for low-code development can be diverse. It could be that there is a massive backlog of apps that would take years to build using traditional technology; some companies have bad experiences (cost, quality, maintainability) with building apps using classic techniques like C# or Fiori; and other companies want to have an independent development platform that can integrate with any system, not just their leading ERP system.

But even though all levels have accepted the platform, there are still several pitfalls that may hurt adoption of low-code development within the organisation. To name a few:

• the standing IT organisation does projects the waterfall way and is defensive of change
• Most of the development is off-shored to other countries/continents and performance is strictly governed through SLAs

Waterfall

A major pitfall is underestimating the effort it takes to educate internal staff on agile and scrum. You can’t do OutSystems projects the waterfall way, because you will lose many of the benefits low-code brings. Make sure IT leadership understands agile and why it must be used; and convince them that for each project initiation and design session time must be reserved to explain the agile way of working. Always stress the importance of the product owner and explain in detail what that role entails. And make sure you actually get one who understands the role!

Another problem is when you hit the boundaries between your now well-educated agile low-code team and the company’s existing waterfall teams, for instance when you need to integrate with Oracle or SAP. Or when you need a piece of custom code developed on any legacy system. Be sure to inform your stakeholders of the implications. Having to wait on the internal ERP release calendar can take considerable time. While you can develop a new function on your ERP development instance and then build in that new function in your OutSytems app in an hour or so, it might take months before that ERP functions is finally transported to the ERP production environment. If you have the need for such development in your project, always start engaging with your ERP counterparts at the start if the project.

Offshore

If your company is used to offshore any development work to a low-wage country, then the company will have the natural urge to see whether OutSystems development can be off-shored as well.

This is a high risk for the acceptance of the platform. Although anybody with a bit of IT talent can learn how to build an OutSystems application quickly, building enterprise-grade applications is a completely different ballgame. These apps need to be secure, maintainable, privacy-sensitive, SSO enables, possibly encrypted and authorisation and user assignment might be controlled by an internal Identity Management system. Next to that, the application might need to interface with on-premise and cloud solutions, requiring different kinds of integrations owned by many different teams. These integrations must all be thought through well and decoupled properly to avoid spaghetti-style low-code apps, that are possibly vulnerable to attacks.

Any OutSystems team that works on complex apps with multiple integration points and multiple personas, needs to have senior development capacity in the team. It is nigh impossible to do a design session and translate the user stories into technical stories if you do not have several years of experience. And it is impossible to technically design the solution correctly with the proper architecture if you lack that experience.

Next to that, direct and open communication with the business users is vital for the delivery of apps that the business actually needs and will adopt. Putting a couple of thousand miles between the development team and the business is something that can be overcome, but having to overcome significant cultural differences might be a harder nut to crack.

My experience with low-cost offshore companies is that they are good at doing waterfall-style work that has been specified extensively. They are not that good at working agile where the product can change each sprint and close proactive collaboration is required. Next to that, offshore companies have a tendency to put people on the job that do not have the required seniority, but will learn on the job. In the case of OutSystems that is a recipe for disaster: doing low-code with low-wage will inevitably result in low-quality.

High quality

You get high quality OutSystems applications with an enterprise environment when you have development teams that work closely with the business. This can also work when your business teams are scattered across the globe. Do the design session on-site with the major stakeholders, so you can get to a level of cooperation that you can never achieve using video conferencing. Eating and drinking together, sharing photos of your cat or family helps cement a relationship that will help you when you need to work your way through impediments together. Involve a solution architect to structure your code properly. But most importantly, you need the right expertise and the right level of experience in your team to deliver on the high level of expectations of the business.