The hyper agility stack - OutSystems (part #2): The road to augmented development
In a world of ever-fast-changing cloud-based applications, a modern approach to application development is needed, argues vice president for platform strategy at OutSystems Miguel Lopes – this is a guest post for the Computer Weekly Developer Network and Lopes writes as follows…
In part #1 of this two-part analysis linked here, we walked through a brief history of enterprise software composability, the need for collaboration, the true nature of composability, the process of raising the bar on developer abstraction and we provided a rationale for why (and how) modern programming can be much faster and more efficient.
After all of that, we can dive deeper down the road to augmented development and look at where composability stems from, the application of neural-like AI, testing automation into live production and what all of this means for user expectations in the real world.
The road to augmented development
There’s a lot of AI out there and it’s doing great things. We’re quickly getting used to being able to scan a receipt and have the OCR recognise all the figures and numbers and VAT amounts on it. There are still some inaccuracies in these systems, but 90% of the time they get it right and the user experience is beautiful.
As we now move to the point where AI, machine learning and neural networks can be combined, we will be able to engineer a step-change of smartness into our modern software application development frameworks.
So despite all this talk of composable software engineering (and we’ve covered my stance on that in part #1), where we think this gets us is firmly on the road to augmented development.
If the path to augmented development is a road, then it’s a multi-lane highway with great lane discipline, safely implemented variable speed controls and some nicely stocked rest areas with the option for picnics in fine weather.
This is also a road with a variety of different passengers as more software engineers and other employees have the power to be a creator. Alongside front-end engineers will be back-end engineers, both working together for a common product. These ‘traditional’ application creators may now also be joined by specialists from legal, marketing, sales or accounts as the collaborative effort continues to widen. That’s augmenting the team from the collaboration for a faster time to the desired outcome.
From napkins to WYSIWYG
We will now move to be able to create software-based solutions a degree of magnitude faster than when we started drawing ideas on napkins and then perhaps laid down some JavaScript perhaps a month later. This is a time of real WYSIWYG where even if the initial iteration of a solution is not 100% final, its journey from inception to creation is a whole lot more rapid.
Let’s take a look at automation in production. When we look at the practical application of these tools in live production environments, we discover that we can write most of our test automation automatically, by model design. We need developers to spend less wasted effort developing intermediary products that are not the final product.
So that’s augmenting the team in terms of augmenting the power of the creators themselves. If we look at what we do internally, our systems have an acute competitive advantage in this area because that’s how our platform has been engineered from the start — and it is an approach that we can apply right throughout the software development lifecycle from DesignOs and to development, DevOps test, run and manage.
User expectations
We need to now build applications with an understanding that both customer and employee user expectations are higher. The reason user expectations are higher is that they themselves are exposed to so many more alternatives… and this is just another reason why application development now has to take a more modern approach.
The outcome of composability in this context is that users can help create experiences more accurately for what they’re doing, because they can assist the tasks needed to assemble the experience to the job they have to do. The modular composition of applications and experiences means that we see a much faster time to market.
A good composability example runs like this:
Think about how I might be using an application like Twilio to send an SMS message. I’m actually calling an API that may provide, for example, an entire app onboarding experience that will send an SMS for confirmation. The whole thing is packaging one business process in an API. That’s higher value and that’s a faster time to market because of the pre-built functionality inside and avoiding the monolithic approaches of the past.
Way beyond cookie-cutters
So wrapping up all of this discussion, we believe that composability and automation that support the augmented software development mindset will greatly expand the variety of experiences fit-to-purpose for the job to be done and yet will enable managing these app portfolios as products with their own lifecycle of updates at faster cadence.
What I do insist on explaining though (and where there is a misunderstanding in the market today) is the idea that low-code/no-code tools should never be confused as being some form of simple cookie-cutter templates that have pre-built functions and not a whole lot more. That’s why I call about augmented development. We’re going beyond the suggestion that you just snap in a piece of functionality here and there when and where you think you need it.
What we are really saying is that you can program in many of the same ways you have done traditionally, except now you can use visual tools to modify, extend and augment. For example, JavaScript or CSS isn’t going away tomorrow (or any time soon), so developers need to think about the higher-level abstractions we can now move forward with the often counterintuitive old ways we used to approach custom development that was very expensive to maintain and change.
It is a more composable and agile software world, but it’s also a better one, so go ahead compose away and be happy, please.