Software development is broken and low-code is here to fix it
Rosado: "Even when we had the evidence of first 100 and then 200 customers the analysts could not believe that this was possible."
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.
Forrester: The analysts reckon that OutSystems is the clear market leader in low-code development. As of Q2 '16.
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.
So in that modelling environment, for instance in our systems, we are able to model responsive, web native, mobile [apps], and then the stacks you would normally associate with that.
Then we also take care of integrations and the synchronous processes and so on. That stack is sufficient to tackle almost any problem. Any transactional app, any portals, dashboards, the big systems of record, BI, all that stuff.
We create model artefacts with, for instance, 3,000 objects and 11 million lines of code. Then from that modelling environment we have a code generator that generates into a target architecture. That's another thing that we do a lot of research on: 'What is the de-facto best target architecture for the next two or three years?'.
That group makes choices like 'What is the architecture of the mobile native app?', 'Is it pure native or is it some hybrid?', 'What is our microservices strategy with containers?'.
This is all completely independent, so you just click and the apps are generated and deployed. When an architect comes in underneath, what he sees is services, and it is almost as if it was done by hand.
How do you get developers to buy in to this?
The reason why developers, especially the experienced ones, are wary of this type of product is because of a couple of issues.
One is the 'wall' issue. The issue is whether these platforms are sufficiently powerful.
The way we solve that is by our sheer multi-functionality. Our language is very powerful and when you extend it, it extends very elegantly, with JavaScript or CSS [Cascading Style Sheets]. You can integrate, we have plug-ins for almost everything, but you can [also] build your own plugins for almost anything.
That is why it's call low-code. When no-code stops, you can go to code, augment the capabilities of the platform, and continue.
The second issue we also solved is that in most of these platforms it's hard and it really takes time to build a platform to generate code, one that is capable, scalable and secure.
One of our requirements was that with each of those [generated] apps you could have at least 20 million devices accessing that application -- one app could have 20 million users at one time.
We put in those requirements, along with the requirement that there be no single point of failure. On security, we did the same thing.
Many of our customers are very keen on security, so with our beta processes we sent them the platform so that they could try everything out for themselves. And when things come up, we go in and we change it.
There is a trust level that you build up with your customers. They can see how we can solve the whole problem, and not just the functional requirement problem.
So, to some extent it's automation?
That's exactly what it is. It's automating a process as much as possible so that it is simple to use.
Are there notable successes that you can talk about in terms of companies?
We have over 800 customers and I know so many inside stories. UK customers include the NHS Practitioners Health Programme, where we built a mobile app and online patient booking system in seven weeks. The pharmaceutical and biotechnology company Charles River is another company who we built a mobile app for. Again, it only took us seven weeks.
[Worcestershire County Council, the Netherlands-based gas, electricity and heating company Eneco, and Ricoh Singapore are all customers.]
We have very big manufacturing companies, very big banks, logistics companies and the like. We have common use cases where people use our systems to build a digital factory [an arrangement of technology that lets management configure, model, simulate, assess and evaluate systems before building them].
And presumably with automation in there?
Oh yes. Our platform has an internal manager that does real-time impact analysis. What that means is the quality of the apps from the get-go is absolutely top.
If you are building a very big system there are situations where you need to augment them with standard testing, so we integrate some testing tools. We have a lot of use cases for very large systems where testing is required.
To give you some idea, there is a logistics company in the Netherlands which is one of the largest oil and gas handlers. They store oil and gas and they have 73 terminals. The system that manages the oil tankers, the pumping stations, the transportation is all managed by applications built using our systems. A full, worldwide, mission-critical system.
What was the key aspect of software development that needed fixing as far as you're concerned?
It was that change issue. It was fixing the change request problem. Because the reason why we are so successful today -- why we are growing so fast and have so much demand -- is because before, you could get along with these waterfall projects where everything's defined upfront, etc. We still get that.
But mobile changed everything -- the single mobile project that you can do without iterating. That's because it's an exercise in trial and error, an exercise in change.
If you don't change, well... Let's say you build a map. It's really well designed so you think: 'I don't need to worry about this for the next six months'. You're already dead because, before that, after just two weeks, you find there's a huge number of requirements that want you to change that app.
So you find that you must now compress that delivery cycle to two weeks.
You've created a tipping point in IT because they start doing it for mobile, and then they start doing it to get more responsive systems on the web, and so they have to redo all that. And that's when they realise 'wow, I can do this so much faster!' That created the appetite inside the business; the business increased the pressure for delivery to the point where the backlogs are so huge -- in terms of digital demand -- that they can only do it with our productivity tools which are very good at doing change.
And that's exactly what we are.
And that's why you are enjoying this very successful growth and that's worldwide?
We are very successful in the US and in Europe of course, but also in Asia-Pac. And even in countries that are a little bit more conservative, like Japan.
Japan's a difficult market to crack.
It is. We started about four years ago and now it's going very well. Japan relies on extremely custom-developed software because they can very rarely use pre-built software from America. They have to build a lot of their own stuff and our type of tool saves them hundreds of millions of dollars. Over there we are compressing projects which could take five years into 18 months.
So why are you not better known?
Well, it's partly a lack of marketing acumen, but also, for a long time we were very much alone. These are products that are extremely difficult to catch up to. There are huge barriers.
See also
I can tell you from our experience with Gartner and Forrester. Even when we had the evidence of first 100 and then 200 customers, they could not believe that what we said we did was possible.
And then we were very lucky because Salesforce jumped into the category and only then was low-code seen as a distinct category in its own right. But fundamentally we had been alone in this category for many years.
We weren't big enough back then and we weren't in Silicon Valley so we couldn't create this new category of software until things got better. Now we have our headquarters in Silicon Valley and a customer base more than big enough to define this new category of low-code development.
PREVIOUS AND RELATED COVERAGE
Software developers: We're on board with low-code (or even no-code) tools
Do IT professionals see a place for citizen developers, or is this more fantasy than productive reality?
The future of apps: How Salesforce is using low code development
A new App Cloud Mobile suite blends all of Salesforce's developer tools into one mobile application development platform.
Salesforce bridges gap between development worlds
With Salesforce DX, the SaaS CRM giant is taking a leap into the modern development world.