API series - OutSystems: Process purity, how to avoid ‘bad’ automation
As we connect more systems, applications, compute resources and containerised entities to each other through the neural networking connections offered by APIs, there is a clear and present need to focus on the importance of process purity and make sure that we avoid ‘bad’ automation.
As part of the Computer Weekly Developer Network’s API series, this is a guide to travelling at greater speed with enterprise software built for the modern velocity of business.
This contribution is written in full by Prakash Vyas, global head of portfolio marketing at high-performance, low-code company OutSystems.
Vyas writes as follows…
The rise of modern software application development brings with it outstanding opportunities to accelerate and advance through intelligent automation; but with great power comes great responsibility, so knowing when to apply the gas pedal matters more than at any time in the past.
Before any organisation attempts to make any quantum leap forwards and embrace new software accelerators, intelligent automations and continuous cloud-native controls, it needs to step back and perform a detailed review of its incumbent IT estate, applications and processes.
No business wants to find that it has automated what was initially less optimal, inherently inefficient or just bad processing.
Handling your hand-offs
We’re at a special point in time with technology. We have created machines that are ready to accept workloads from us – and I mean ‘machines’ in both the physical hardware sense and the virtual software sense of the word i.e. Robotic Process Automation (RPA) bots and so on.
But before we optimise and modernise, we need to look at the efficacy, efficiency and perhaps even initial progeny of how our back-end systems have come to be in the first place. If an organisation’s automation efforts are heavily gravitating towards ‘fitting around’ existing clunkiness, then there’s a real risk that that same firm will then find itself fitting around customers and doing bad things faster, rather than serving them in a fluid and seamless way.
It’s like fixing a flash flood risk upstream. It works for a while for those that live higher up, but it still leads to inevitable torrents downstream. It’s important to think about whole and complete ecosystems, entire workflow environments, total lifecycles and (if you’ve stayed with our flood risk metaphor) complete river systems.
It is fundamental to consider the whole span of the customer journey when a business automates its new platform-based approach to digital transformation. Unless we know exactly and precisely where each customer is on their journey (and we may never know personal preferences precisely), then we won’t know where they are with enough certainty to automate safely and without peril.
Hamstrung by old rungs
This whole move forward to cloud, automation, AI and integrated data-driven innovation (okay, you could say digital transformation, but I was trying to avoid it and talk about the actual mechanics involved here) needs to start with a purging process to eradicate elements of technical debt. These are the sections of code, components, services and sometimes complete applications and wider network layers that will ultimately take more time to work around, update, maintain and fix than it is productively worth them existing in the first place.
You could think of technical debt as the rusted old rungs beneath a bridge that you know are about to give way, but can be kept working for just a little while longer with some form of fix. Technical debt is a key indicator of any organisation’s ability (really we should say inability) to actually create efficient workflow and processes in the business.
Often brought about by the existence of legacy architecture, technical debt is not always simple to get rid of, but if a business is serious about modernising its application architecture, it is essential that we focus here in the first instance.
Businesses need to think about the new economic standards and principles that govern the digital economy. Don’t build for user experience by thinking that you can focus on a shiny new front end with a few website refreshes, a shiny new mobile app and some special offers – we’re working at a deeper level than that, a level that requires equal thought to be applied to the front end, integrations, the backend and data, if the goal of a seamless (and thus successful) user experience is to be achieved.
When an organisation attempts to use traditional systems that weren’t designed to function inside modern business architectures, they quickly find that they aren’t able to navigate the new dynamism that exists in the modern business.
Build for change, always
Our key watchword here is change. Organisations should adopt systems built for digital business solutions, by which I mean a platform-based approach that understands how software applications need to change frequently and be architected and constructed around the customer, always.
Let’s think about a real world example. Despite the rise of embedded finance and API centric Banking-as-a-Service (BaaS) functions, building a new digital banking presence is not just about plugging on a shiny new upper-tier application presentation layer. An organisation that thinks it can simply snap on new functions without first re-evaluating its core stack will inevitably run into integration issues, system availability troubles and – at worse – degradation and failure.
Digital transformation needs to be a holistic process that is formed with enough system empathy (yes, machines do have feelings too) to work at the velocity that the business needs. Outdated legacy technology will never form a precision fit to the landscape that our new applications need to traverse and travel over.
The immediate road ahead
OutSystems’ Vyas: A man with ‘modern’ views on modern application platforms.
As we go forwards, the immediate road ahead has many definable certainties, but it’s not guaranteed to be an even surface for all industries. While we might see retail, banking and insurance, healthcare, automotive and others advancing more quickly, there will naturally be other zones that move a little slower.
The priorities, imperatives and urgencies of those sectors – education, parts of the labour service sector, some areas of hospitality or agriculture and construction perhaps – stem from a different place, so the pace of their progress is understandable. Plus, we know that, longer-term, they will also digitise more deeply.
Understanding any organisation’s individual place on the digital evolution curve is all about knowing what an existing operations layer is really composed of first. If a business can get past that (sometimes painful, often enlightening) process of introspective analysis first, then it can more progressively start to embrace modern platform-based advantage moves to technologies like low code and the wider world of AI-centric computing.
A modern, high-performance, platform-based approach, enables an organisation to continually update applications, services and components at the pace of the modern business. I’ll say it one last time, automate please, but please don’t automate bad processes… and please don’t automate on top of bad processes.