The quest for hyper-agility — OutSystems (part #1): A brief history of composable software
In a world of ever-fast-changing cloud-based applications, an augmented 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…
When we think about software application development and the supposedly new notion of composability, our view is that custom enterprise software is always evolving and it’s always morphing.
If we look at the way we have built code traditionally (say, perhaps, 20-years ago), it was a slower waterfall process but always iterative and changing and so — in that sense — it has always been composing, re-composing and dynamically morphing. Plus, think about the fact that all the other elements of technology in the stack (from infrastructure to platforms and upwards to application styles) have also always been changing.
“The more I build, the less I have to build” (sic)
The difference now, with composability, is that there is a speedier cadence… but throughout, we (as a company and team) believe in the ‘modularity’ first principle of software design. Thinking more deeply about software modularity, the very smallest thing you can do (as a programmer/developer) is to build a module — and that could be anything i.e. a function call, the logic flow or database, a query or whatever. When enterprise developers who work in related app portfolios apply this first principle of reusability, they love the boost in productivity and quality they achieve — we literally hear some customers tell us, “the more I build, the less I have to build” as they work to accelerate delivery of their enterprise app portfolios.
Lessons learned from old models
Throughout the 1980s and 1990s, there was a big wave of computer-aided software engineering, right? This saw many professionals embrace software modelling by working at higher abstraction levels with UML (Unified Modelling Language) and some automation of some stages of software development. This was the infancy of the augmented app dev concepts we’re seeing played out today.
It was all about designing the system from the top-level down and then implementing the building blocks needed to support it. The problem there was that modelling would be perfect at the start of the project, but 13 weeks later (for example), the initial model was garbage, because user requirements and use cases had changed and there was no connection between the model and the real software running and being maintained.
As Paulo Rosado, our CEO and founder, says: the problem with software development is that we, as engineers, too often look at problems as ‘still [static] pictures’ and just implement what we had on the drawing board. In the real world, life does not work in still pictures, but in dynamic movies, instead: the context; the needs, the tech stack are changing over time and we need to adapt swiftly and find new approaches to go from new ideas to running code.
The right abstraction level
Augmented software engineering is where developers create at a higher abstraction level including composable modules, leverage software automation for all software engineering steps and have AI augment new and old developers work to create more secure and performing apps with less effort.
The higher abstraction above the rudimentary syntax and logic error level of popular languages means people from various backgrounds can collaborate instantly, because of “what you see is what you get” and the fact they have now a common programming (visual) language that can even be understood by their business counterparts.
This is not just modelling anymore, this is a higher level of abstraction, because the visual code is the final specification of what runs and the code that is maintained for the long term. In this case, the intermediate language artifacts in Javascript, C# or CSS are just “compilation” by-products, like the Assembly resulting from the compiled text-language was just a by-product.
There is a massive productivity boost for professional developers with augmented app dev cloud platforms, because the new development and delivery platforms can intelligently orchestrate their DevOps with SDLC smart process automation with the benefits of software helping to build software. The beauty is that the platform can systematically apply the best practices in security, performance optimisation, etc every time that a new release is published.
Users will know the difference when they use applications that are built like this i.e. there’s a bit of magic (we all know it’s software engineering process automation) happening in the background and it may lead to great user experiences, better security and performance benchmarking for the apps in the portfolio created with this augmented approach. We can now do this with the cloud because of the higher levels of abstraction and DevOps automation possible today, but we do need to remember that composability and modularity are not exactly the same thing.
Russian dolls vs. Lego blocks
We can certainly stand back now and say that things have evolved. If in the past I had an Application Programming Interface (API) that would send an SMS, today I can have an API that calls an accounts payable function in an enterprise accounting module.
OutSystems’ Lopes: Software is always changing, but for today’s cadence, you need a modern app dev approach.
That API goes to get a credit score rating for a company debtor/payer and lets me know that they are most likely to pay in 37.5 days for a £36,000 payment.
Today’s APIs take users to a lot smarter levels of functionality by virtue of their ability to compose a lot more granular (and connected) low-level functions and integrate business operational steps… and that means more end-user and business value. This is the composability payoff that augmented application platforms can deliver.
It’s a question of a composable function existing inside a wider/higher (also essentially composable) function, so it’s not so much an analogy of Lego blocks and it’s more an analogy of Russian Matryoshka dolls.
You don’t just have a bigger doll, you have many more dolls inside.
We need to appreciate the differences in the levels of abstraction that we bring to bear upon our modern application stacks — some functionalities and processes will be inherently more complex, convoluted and interconnected — but when we do appreciate the structure of what we have, we can orchestrate our application components more effectively to truly advance.
Build at the speed of buy(ing)
So why is augmented programming so much faster? We may stop and ask, if an API is providing 90% of the functionality needed for an application service and all you’re doing is ‘just’ wrapping some additional system connectors and a User Interface (UI) layer on top of it… is that still software application development and programming?
The answer is yes, it is a build — and it is a custom build — but it doesn’t quite feel the same as the old way of building, because it feels better than starting from scratch when you didn’t need to. When you can build at speed, you can build more accurately and with greater creativity for better functionality.
In part II of this story linked here, we will dive deeper into composable computing and look at the mechanics of collaboration, the direction composability stems from, the application of neural-like Al, testing automation into live production, the reality of SaaS-sprawl (and what to do about it) and what all of this means for user expectations in the real world.