Cloud Pak for Business Automation

Welcome to my fourth blog in the series to discuss The Need for Speed and Low Code. In my last three blogs on the topic of Low Code/No Code, I discussed the motivation behind Low Code is really about the Need for Speed, provided a quick introduction of the new enhanced Low Code experience that we introduced as part of Business Automation Studio, and also the different dimensions of Low Code. In this article, I want to discuss my points of view on the principles of Low Code/No Code.

There are many automation solutions out there, and many of them would claim themselves as low code/no code. This is to be expected since nobody has defined what low code means, and how much coding is there before you will consider that product not low code anymore. In some "low code" solutions, you will have to write tons of Java, edit CSS/HTML, fiddle with YAML / JSON / XML data, decode Swagger or WSDL documents, etc. One can argue JSON, YAML, CSS is not "code", but really? In Cloud Pak for Business Automation, we take Low Code/No Code seriously, and we make sure one can design a true enterprise solution without having to write code.  

I will describe a few principles that I subscribe to:

1. "Must always work"

One of the philosophies that I apply in general to low code design is it "must always work", what that means is that independent of which stage your development is in, you should always be able to "run" the application, and the application must work reasonably. In the context of workflow, the mantra that I live by is "the workflow must always work". You must be at any time be able to run the automation, doesn't matter if you just put down 1 activity, 3 or 15 activities. This also means we will auto-generate UI for you when you're not yet ready to design your own. You can try this with the "Run" feature that you will see in our Workflow, Decision, Apps, and Document Processing design experience.

2. "Must match the way people work"

Another philosophy that I apply is whether a particular programming model would match the way people would have done to express their thoughts. This is important as the smaller the gap, the less the users will have to learn to tell us their story. This highly depends on the background and skill set of the users - and that's why in Low Code design, understanding the intended audience is very important. In IBM, we leverage a Design-driven approach by working closely with sponsored users to understand what they care about and how they want to express their solutions. We must resist the urge to invent for invention's sake. It is almost always better to extend an existing metaphor as opposed to creating a new one - e.g. RPA is a prime example - instead of focusing on redesigning how people should work, RPA is all about automating the way people work. 

3. "Must be fast"  

I maintain the motivation behind Low Code is Speed. So at all times, we must focus on how fast it is we can get something working, and provide an effective change management approach for the "try-n-retry" cycle. This also means we are increasingly focusing on not just low code in our development experience, but also how to allow business users to make changes and adjustments without having to go back to development. You will see examples of this with our no-code Workstream, Document Processing and Decisions components.

4. "Must handle the unexpected"

While we strive to allow automation developers to configure the automation logic without resorting to coding with Java/Python, we cannot think of everything during our design. As a result, we provide architected extensions that will allow people to contribute components to create a customized experience should they want to. Automation Services, Reusable Views, FileNet event handlers, Case widgets are all examples of those.

There are likely other aspects so I would be happy to hear what others are thinking.