A little-known Portuguese company, OutSystems, which specialises in the equally little-known practice of low-code development, is taking large sections of the corporate market by storm.
As its name suggests, low-code development reduces the amount of coding required to develop applications. And, by doing so, it reduces the time needed to develop applications — in some cases by a factor of 10.
The speed of this approach makes it especially attractive to the mobile market and, as that market has grown, so has OutSystems. According to analyst Forrester, OutSystems is the market leader in low-code development, beating better-known names like Salesforce.
OutSystems CEO, Paulo Rosado, outlined the advantages of the low-code approach to ZDNet.
ZDNet: Why did you start it in this business?
Rosado: This is my second company. I started my previous one in 1997. What we handled there was infrastructure software for very large national and international companies.
We were right at the middle of the bubble. I sold the company in 1999, but during that time I didn’t have a single project that was on time and on budget.
When we started a project, we tried to change the analysis phase but we could never get the requirements right. That concerned and interested me, because it was a difficult problem. I ran the company for 18 months and during that time I focused on this problem. OutSystems was the result of that. I looked back at why these projects were failures, and that related to a fundamental issue in software construction. It had to do with technical debt [relying on a solution that is quick and easy to implement but will cause problems in the future], and the fact that, as software changes and time passes, the next change needs to be done.
What happens is that the cost increases exponentially as each change is made, until it becomes too expensive and you have to start afresh.
So, the idea we came up with was, instead of starting by trying to get the requirements right, why don’t we assume that they are always wrong and then attack the problem of change?
We kind of reverse engineered the anatomy of software change and created a product that was unique. To give you an idea, one of the reasons was that as you increase the size of the software, the software becomes harder to change. If you double the size of the software, the dependencies increase exponentially.
So if you have fewer options to track, you can put in a dependency engine and you decrease dramatically the cost of your packet. That’s why we went with a model.
I had a lot of experience with very large Java projects and I thought Java was terrible. I was an architect in Oracle and I had my first glimpse of the dark ages that would come because of the lack of productivity. As people change things they are afraid of changing something and breaking something else.
One of the things we did was create a domain specific language, a visual language that was built for any specific domain of apps and was built to solve the problem of maintenance of change.
We removed Inheritance in objects — which was a big, stupid idea — but the other big thing was we realised that in order to tackle the problem of change we had to tackle the full lifecycle. So you have to take over the staging all the way through to deployment.
Basically, we introduced a DevOps capability into our product in 2002 [DevOps came into common usage in 2008].
You were doing DevOps before anybody else?
Exactly. If you look at that notion of One-Click Publish, we have big buttons that [were introduced] in 2002, with those buttons you click and deploy automatically. It’s a huge portion of our R&D, taking all those pieces, even database, integrations, making sure that with one click you upgrade the version that’s in production in a hot environment.
[When] you try to create a platform for Agile where technology is not in the way you stumble into continuous delivery, and you stumble into DevOps. There is no way around it.
What do you see as the key difference between Agile and DevOps?
It’s fixing the latency of change. Very simple to say but it’s a big problem.
We have an ALM [Application Lifecycle Management] group and we also have a domain group, so we constantly monitor the nature of the applications.
For example, when REST [Representational State Transfer] appeared about four years ago and started making inroads inside the enterprise, replacing web services and SOAP [Simple Object Access Protocol], we said: ‘We need to create a visual construct to model REST’.
The low-code aspect — how do you do that?
You have a modelling environment. It’s a very visual environment. In our case, the scope of that modelling environment is the scope of the domain of apps you want to create.