Intelligent Automation, leveling the playing field for Business AND IT

I had a lovely chat with Christian Umbach (CU) from xapix.io and Francis Carden (FC) from Pegasystems.

Xapix is a company based in Berlin that is offering a data integration and orchestration platform, Pegasystems one of the bigger automation firms often cited in Gartner and Forrester reports. However, for this conversation the products and services offered by both companies do not matter. What matters is how process management and orchestration together with automation serve a transformation journey.

And it's what brought us together. Here's the transcript.

Note: All views expressed are strictly personal and do not reflect necessarily the stance of any company mentioned.

Business models just like, consumer expectations and behavior are changing. It seems this happens faster than ever and the pandemic of course rapidly fueled the "digitalization" race. While digitalization itself and what it means varies from organization to organization. What do you think are the big shifts of our time?

CU: It’s clearly the drive for automation. Automation turns humans into super-humans because it augments their work and helps them focus on what they are best at. A lot of the technologies around Artificial Intelligence/Machine Learning, Robotic Process Automation but also innovation around edge computing is supporting this. One accompanying factor is the drive to bring expertise - in this case programmatically through algorithms - to where data is, versus bringing data to where the algorithms are hosted in the cloud. The combination of these factors will deliver new levels of scale, speed, and efficiency as we redefine the role of every individual.

FC: How quickly we've been able to respond was a good thing. However, the way I see it is the pandemic has shown we still have a long way to go to be truly responsive and adaptable. Which brings me to Digitalization, and I prefer the term Computerization in fact. Often we are preaching we have legacy debt to replace. It's easy to replace one debt with another, so what you really want to do is do things entirely differently in order to stay adaptable. Computerization didn't do that for us - take RPA for example (Robotic Process Automation). To the greatest extent it was (mis-)used as band-aid around legacy tools, mimicking what has been done in the past and how it was done in the past. Events like the Covid pandemic however make you realize there is no excuse for re-thinking our processes. Re-inventing is no longer "too expensive" nor does it take "too long". (Great solutions already exist that help to cut down the time to market, thinking of automation, integration and process management for example.)

Further, Intelligent Automation is about not having computers mimic human behavior but explore better ways of acting not known before. Having this capability available at scale is unique to our times. And what it may bring is a much needed shift.

What's the role of Process Management / Process Optimization in this?

CU: For many industries, take food production or component manufacturing, efficient process management has yielded more optimized production. In the last 20 years, lean and kaizen philosophies helped to reduce inefficiencies and waste in the process. In the new era of data-augmented engineering of the processes we are breaking through the optimization of a single system. Data evolving from a single system - say the process logic controllers on the production line - can be immediately available to manufacturing leads but also suppliers and logistics companies alike to improve quality, reduce downtimes, and increase throughput.

FC: Change has to be brought gradually to an organization, so while you want to fundamentally change the modus operandi on one hand you want to be reasonable about the scope of the change. Make sure you understand the baseline situation, find processes to optimize as well as ones to re-do. Have a long-term vision in mind about when you are done strangling the incumbent processes. That's an important part of the story, because often "digital transformation" is stuck "optimizing" processes - but never re-doing any. Which is no transformation journey in my books.

What about the notion of Low-Code, what does it mean and why would it matter in the brave new world of everything (intelligently) automated?

CU: No-code/low-code is a means of taking complexity out of a task. We have been making this the center of our design philosophy and developer experience from day one because it massively expands the talent pool of users. Some years ago, the term “citizen developer” was coined, and it really is more than non-developers performing coding tasks. Low code means going beyond challenges of various programming languages, interface specifications, and technology-specific deployment and operational models. It is about making complex tasks accessible through a few simple interactions. While low code doesn’t rule out the chance for developers to bring in existing code snippets or develop connections side by sideThose interactions can be still driven by code - the overall movement seeks to do this in a manner that ensures accessibility, automation, and reliability. or for a range of tasks also no code. It is about creating ubiquitous familiarity with complex challenges for everyone with a technical background - say the 25 million software developers worldwide. And additionally, giving those who don’t consider themselves a software developer yet can very much access and master slightly more complex challenges in MS Excel or being able to work with SQL. That is a good skill set today that can be quickly augmented with low-code tools that are available to everyone. 

FC: To understand Low-Code, just look at the opposite end. And at how things used to work. The IT side doing its best to gather and process requirements from Business. Showing the result. Modifying the solution again and again. Projects progress, people leave and project timelines press you to accelerate towards the finish line. For the next twenty years you keep modifying the application by hardcoding all the logic into the UI, into backend code, maybe configuration files, in your database(s) and such. While the business logic should never be encapsulated in disparate pieces of technology. The only rightful place for Business and Tech collaborating on business processes is a rules engine. If you decide to switch for example UIs or "frontend applications" for that matter, in no way should process flows be affected - or even be re-constructed. Given the possibilities around containerization, cloud native elasticity of today you may want to take these types of decisions more often than ever before. The same agnosticity you would expect against the "backend" data store. Now the idea behind using rules engines instead of hard-coding process metadata is not to code less. Even though you will eventually do so. The idea is rather that if you build something today, you build it quickly, put all the rules into a rules engine, leaving you with a loosely coupled frontend and backend. Now you can run it on any cloud, on-prem, on any device. As you wish.

To sum up, both the tighter feedback cycles between Tech and Business as well the powerful abstractions offered by low-code tools such as rules engines make low-code an important paradigm. These tools allow experts to stay in their domain and contribute playing their greatest strength. Be it business domain knowledge or technical domain knowledge.

Painting black and white, Low-Code is seen as superficial by developers and techy by business subject matter experts. Who is Low-Code really for?

CU: For developers, it’s about choosing their battle. What are the parts of the architecture that they want to master and have complete freedom/flexibility without the “limitations” of a tool. With freedom comes responsibility. We have seen that data scientists or developers focused on delivering the full applications value good tooling. It helps them to quickly get transparency on the performance of their backend and the various data streams their applications rely on. Low code doesn’t mean there is necessarily no code. It just refers to the (if done right) intelligent encapsulation of a complex task to simplify its management. 

FC: There is really no need to draw borders. Sometimes tech experts venture into business domain topics, sometimes the other way around. Having platforms that support a tight collaboration just come in handy and a low-code tool can be as useful to a pro-programmer as it can be to a citizen developer. Think about it, forty years ago you had to first write it, compile it, somehow ship it to even show and to anything. Today everybody can describe a flow inside a tool that can immediately run that very flow with the push of a button. And just to be clear, none of this means you would not require IT anymore. Quite the opposite - you need IT to shape out data models and templates in a reusable way. And more than that, not only reusable but usable for business domain experts.

You need IT to shape out data models and templates in a reusable way. And more than that, not only reusable but usable for business domain experts.

Meaning complexity needs to be abstracted away as far as you can get away with it. So, if the issue arises of the low-code solution being perceived "too complex" or "not powerful enough" it's because the right spot for the tool wasn't properly identified or the solution is not yet fleshed out enough. That's not the fault of any tool. By the way, you would expect useful abstractions not only in the direction of Tech to Business but the other way around, too. Why burden programmers with the knowledge of how mortgage calculations work? Why should they want to be in the crossfire if a business rule changes and is not reflected "in code"? It's all about enabling experts to focus - on the right things.

We have complex processes everywhere. Partly, because they grew over time and nobody wanted to touch hot irons. Partly as well because the business scenarios covered are inherently complex. Think of highly regulated domains. What needs to happen to manage and orchestrate technical processes better to support business processes?

CU: Forward thinking organizations have already moved from a project-based to a product-focused approach. This trend will continue, with that complexity will be managed by people with a product mindset. More so, various business functions which are traditionally non-tech, let’s say legal, will need easier access to data around processes to gain a better understanding of how data is handled in an ever-increasing complex world. Around regulated domains or highly security sensitive ones, the trend of bringing algorithms to the data will continue. This avoids moving data and exposing it more broadly. Rather, intelligence can be derived where the data is gathered and actions based on that intelligence be pushed. One of the key technical frameworks in the area that I see as a leading vision is the Open Algorithm (OPAL) project by MIT’s trust initiative. 

What role does the organization and its culture play in that game?

CU: The organization and its culture is the most important part. The path to a fully digitized, customer-centric and data-driven company comes with a plethora of new methodologies and perspectives. Development and sales cycles are much faster and there needs to be a much more agile culture than before, while balancing it with risk and governance. Leveraging a means like no-code tooling won’t be changing culture overnight. It rather is one out of many tools that companies need in order to make their work force overall more technically savvy and skilled to tackle the product challenges of our day and age.

For us that urge to support people with better tooling goes back to why we started gathering a team to build a novel toolset back in 2016 in the first place. 

At Xapix, we are in the business of augmenting people in their work. If you have some technical experience but you need the right data to flow or the right transactions to be triggered, you should be empowered to control that. We give people control as they scale up their projects and applications. How do we do that? By combining the fields of Machine Learning/Applied Artificial Intelligence, RPA, streaming, API management, no/low code, and edge together into a solution that keeps users focused on their data and its actions.

Aside from dealing with processes and their design, automating these appears very appealing as a value driver. Would you agree?

CU: Yes, automation for processes is key, but so is understanding its (current) limitations. Automation doesn’t only help increase speed but also helps ensure system safety, reliability, and quality as systems scale. If teams build a product or service that matters to the world, challenges around scale will soon be encountered (which is a good thing in that moment because it means they are onto something) - but that’s where automation comes into play to help them master scaling.

FC: Well, now first of all, you really have no choice but automate. If you don't do it, digital natives will eat you for breakfast. How can you get value out of automation timely is rather the question. Make sure you have buy-in into the model arising from automation and an understanding of what it means, figure out how to implement and what technologies you may want to use in parallel to make it all the way to where you want to get to with automation. RPA can play a crucial role in this play - it might be the technology that accelerates time to value dramatically. You will hit some limits with RPA alone (as previously discussed). But it will buy you some time on your path to reach the next mile stones. At the same time, legacy tools are in the process of being tossed out, which further boosts your cause and allows to take the next steps after the first RPA implementations.

How would you see process design and automation connected - would one be the prerequisite for the other? Should you start with a process discovery and document all existing processes even before going for automation?

CU: Process design is a pre-requisite. If you don’t have a process, you (or your team) is completely left in the dark to implement something. No code doesn’t mean no logic. The availability of further data through interfaces across companies and the ability to break data silos can however change existing processes. Hence, automation isn’t necessarily a drag and drop of an existing process but represents teams with a choice of improving them, this can both mean fewer connections as flows simplify, or the ability to create more connections, more transparency, and better informed decisions.

FC: Surely all business processes are well documented and everybody know how they work, no matter where you are. ;) Well, to be honest, if the incumbent processes are not already well known and documented, starting with process discovery for the sake for documentation might be a battle lost from the beginning. So, instead of trying to document all processes the answer to the question why not all the processes are already documented and updated strictly should be understood. In fact, there is technology out there that can help you auto-generate documentation for you, not like you would put it "hand-written" but still usable. Thinking of process mining etc. But the reality is, what would you actually do with a complete process documentation? Probably all it will tell you is how bad your processes are, otherwise you might already have some useful documentations. It speaks to a certain desperation that we'd try to have mining tools to analyze processes in many places, many organizations around the globe. Rather think of process models and rapid development than going great lengths to document processes.

The background of the last question is that changing processes is often a lot more difficult than going for automating processes. Is that something you see as well regularly?

CU: Soso, sometimes changing a process is required because there are more effective ways to automate than just a lift-and-drop for the existing process. However, we can see that the time pressure to move jobs is so high that teams don’t have a chance of rethinking the process from start to finish. 

We talked a lot about change so far. I often read about setting up "Centers of Excellence" within organizations to that end. Do you think that's a good idea or how would you go about the change journey towards better/automated processes?

CU: For introducing automation tooling COEs make a lot of sense. For implementing and operating these tools there are plenty of paths in terms of architecture choices there are plenty of parameters you need to get right. Think scaling, security, working with the right people and their appropriate skills within the organization, for example. The business SMEs will not do this on their own. The COE can fulfil a range of tasks and duties around making knowledge and support available to teams across functions around the whole organization. In a critical stage of the phase-in, that is.

FC: To add to that, think of where we came from. In the past, IT did what IT could and Business what Business understood. Now, we need to think differently - we need to think with outcomes in mind first, from the outside in! Instead of thinking about how processes need to be we tend to think about what is, in your typical corporate environment. Companies like Netflix do not approach their choices like that. Imagine Netflix had to shut down their services and leave you in the middle of a movie with a message saying they had to go into planned downtime, come back tomorrow. In the old IT operation world that's how it was, ever since. The ability to experiment, change applications without breaking everything and being okay with breaking parts of it as you go, building applications from the ground up for change and being mentally ready to change everything - this is what it takes to get better, and eventually as a result of that to better processes.

In the past, automation happened mainly based on static or (pre-)computed rules. Trees of rules, to be more precise. Now we have the added ingredient of Deep Learning and Machine Learning navigating through the decision tree. Even coming up with decisions not preset. How does this change automation from your point of view?

CU: It expands the scope. We can leverage rules and experiences across millions of data points and experiences instead of maybe hundred or thousands that initially went into the setup of the rule engine. Moreover, we live in an ever changing world. New information around us is constantly generated, this now informs and updates those rules engines dynamically, over time artificially. It’s a game changer when we think about the velocity of system learning. Yet, it also poses challenges to help people understand how decisions by an algorithm have been made. “We are not going to let a blackbox decide on the operations of a machine” is something we often hear in the manufacturing context. Leveraging Machine Learning for automation requires understanding of what decisions are made - at least of their underlying fundamentals.

To conclude, what is your advise to business or IT leads?

CU: Start with the outcome, what’s the result that your users or customers want to celebrate. From there think about the inputs necessary to make a connection that’s as simple as possible - not considering the constraints of your day to day. Now with a perfect process mapped out, one can start bringing back constraints. The resulting process should yield a better outcome, even by the fact that new technologies or modular solutions now offer a different way of solving for certain constraints in the business.

Thanks to both Christian and Francis for their time and the great exchange!

If you have any questions or feedback regarding Automation, Low-Code or anything I might be able to address, don't hesitate to connect and drop me a message.

Stay safe and sound - and automate!