Content Copyright © 2016 Bloor. All Rights Reserved.
Also posted on: The Norfolk Punt
OutSystems provides a leading general-purpose low-code app development PaaS (Platform as a Service). Its special capability is that it is a code generator – you build the app in a visual environment, by dragging and dropping visual representations of function, so it really is “low code, but after you’ve finished, you have Java code that will run in any Java environment; or c# code for a .NET environment.
This protects you from lock-in to the OutSystems platform: if you leave OutSystems, you simply maintain your code as usual in Eclipse, Visual Studio or whatever (although that may not be trivial if all your developers are used to high-level, low-code, development). Code generation also ensures that integration with other systems is always possible and gives you a fallback position if something isn’t working properly and you need to get into the low-level code in order to find out exactly what is going on. Nevertheless, it also brings a potential problem: the temptation to maintain generated code, which risks the model becoming out-of-step with the code executing in production.
However, OutSystems assure me that if developers are subscribed to and using OutSystems, then they are prevented from modifying the generated code. This is good and although there are probably ways around this, a mature company should be able to enforce “good practice”. There is no absolute issue with having code, if it makes people more comfortable. And I do believe that OutSystems Platform generates pretty good code, which users can confirm for themselves, of course. If a developer wants to incorporate code that is maintained outside of OutSystems), they can wrap the “foreign” code using the OutSystems Integration Studio tool and then add it to the platform, where OutSystems tracks all versions/dependencies (which should work well, although I can’t help feeling that if this practice is allowed too often, it adds to the system complexity).
Now there is a new release of OutSystems, Outsystems 10, which seems mainly to be tidying up OutSystems’ offline mobile capabilities. For people living outside of South Korea, we don’t all have reliable, fast, high-capacity mobile communications all of the time – and a mobile application channel which suddenly disappears can be extremely disruptive to the business. Not just because of the immediate impact of losing the app but because of the possible second order effects: the app user could, for example, go into a conference with a key customer unprepared; and/or simply make more mistakes than usual, because their work patterns are disrupted.
So, I think this is a useful new release, but not a radical innovation for the product. The OutSystems developers themselves view it as groundbreaking “because we are the only low-code platform that allows you to build the sorts of advanced, enterprise-grade, mobile applications that are only otherwise possible when coded by hand”. It seemed well worth getting a briefing from Mike Hughes, Director of Product Marketing at OutSystems, who confirms that OutSystems 10 is largely about filling a gap in the OutSystems offering, with full synchronisation between online mobile and offline data, as well as new architecture for mobile including the use of ReactJS on-device “to ensure a user experience that rivals natively coded apps”. OutSystems 10 also improves ease-of-use, with some 70-plus mobile widgets (based on studying the most popular mobile apps out there), and Mike claims that OutSystems developers managed to build an analog of FaceBook over just a weekend – true “rapid application development”.
The key to OutSystems’ long-term success is probably its community and prebuilt application templates on its Forge ecosystem. This is something that OutSystems is actively promoting – it’s not anything like as big as the Salesforce ecosystem, of course, but it is growing.
I had thought that OutSystems might be increasing its focus on Citizen Developers, as well as its existing core IT users, with this release, but apparently not. It does have some “citizen developer” users, but its usual user is in the IT Group or similar, and it rather assumes that a professional technical developer is available to build apps. As a code generator, perhaps OutSystems is well-placed to bring traditional professional developers and the new citizen developers together, as the availability of code that the IT group can inspect may reduce any low-code culture shock.
I’d also make the point that any model-based visual development platform helps bring all stakeholders in business automation together, as everyone can understand a model, whereas few people understand code or formal requirements specs.
Mike sees OutSystems Platform as an aide to digital transformation (this is, more or less, what Bloor calls “Mutable”) and he put forward a Kent State University user story in support of this. According to Sameer Jaleel (Director, Platforms & Integration Solutions at Kent State), “Adopting OutSystems Platform as our strategic development platform has allowed us to quickly transform into a digital enterprise and deliver new applications in an efficient manner”. Most of the new application requests at Kent State are workflow-related (a strong capability in OutSystems 10) and it can now deliver around 10 new applications a quarter, taking advantage of OutSystems Rapid Application Development and extensive code reuse (from pre-built or template applications).
However, Mike does point out that Kent State lost some developers who simply didn’t like the low-code culture that came in with the adoption of the OutSystems Platform. Obviously, losing people is expensive and affects morale (and risks losing “corporate memory”), so cultural change must be managed with sensitivity and the availability of mentoring and retraining, but (within limits) I see a few losses, handled properly, as a good sign. Genuine cultural change is disruptive and some people won’t like it, so they will probably leave (if they don’t, your cultural change is probably superficial). Managing such losses, fairly and with sensitivity, so as not to impact the morale of those who stay, is one of the skills needed by any company hoping to manage digital transformation effectively.