Introduction

I think we are seeing a core change in ERP landscapes at the moment.  The rise of the low code / no code add-ons.  These are perfect "on point" solutions that can be developed rapidly and implemented into production rapidly.  They are probably going to be the enterprise architects nightmare - but I honestly think that the people paying the bills are going to love it!

ERPs do come in different shapes and forms, I’m more talking about the on premise ERP here (like JD Edwards), but much of this also relates to any modern cloud based ERP.  These rapid application development platforms can deliver functionality that on premise legacy applications can only dream about.

For JD Edwards customers that have orchestration studio, this is Good News!  You can basically extend the reach of your ERP to mobile platforms and to the latest AI and ML capabilities with the implementation of apps in these new platforms.

Host them as e1pages if you write some awesome ones…  Could this be the beginning of a new default development platform for JDE.   Like the old school “portal” but better and more portable?

Benefits of no code / low code:

·       You can make applications quickly and easily.  

·       You can deploy your applications on android and iOS(!!!!) quickly

·       Eventually power users can edit the code and deploy changes to the app

·       The IDE's are generally all web and very smart

·       Generally you can call webhooks

·       There are great communities for support and training

Problems of no code / low code

·       Power users are bad with security

·       Security

·       Standards can be hard to comply with

·       Synchronisation of data can become problematic, you need to understand master data

·       Costs could creep up, depending on users and usage (and poor code)

Low code / No code options

There are a heap of options out there, I am going to cover off only 3 for the purposes of this article.  VBCS from oracle, AppSheet from google and finally PowerApps from Microsoft.

This is not going to be an in depth analysis of all of the options – it’s basically a summary of what I was able to do in about 1 hour of messing around with each platform.

VBCS

This is the chosen on for JD Edwards mobile development.  This is where the eggs are being placed by oracle.  And guess what – it’s a cloud product…  No I’m serious…  Who would have thought?

My experience is pretty low with this product.  I felt that the IDE was a little more complex than what I was expecting.  You have your traditional design pane and drag and drop capabilities.  I thought that the relationships between the controls and the variables was a little clunky, especially when dealing with arrays, but this might have just been me.  Like I said, I did not have a lot of experience.

It was really easy to import the OpenAPI3.0 compliant orchestrations that I developed.

That was totally awesome.  IF you are not using this functionality and you use webhooks or you use postman, you gotta go http://yourAISServer:yourAISPort/jderest/v3/orchestratorhere.  This is what you are going to import for all of the functions.  Too cool!

Costs

The costs are based upon 5K message packs on OCI – per hour.  Thought you’d want to run a basic analysis operation to ensure that the price was not too high. 

Messages/hour metric

This message pack metric means you pay a certain amount per hour based on the amount of message packs your environment needs to process all requests. The interesting, but also little bit difficult thing about this is, is how messages are measured.

A message pack includes a maximum of either 5000 messages (cloud license) or 20000 messages (bring-your-own licence) per hour. The unit of one message is a payload size of 50kb of in-and-out transmission from/to the Oracle Cloud Service. If a transmitted message is 270kb it will be counted as 6 messages, as it is rounded up. If you use process automation or visual builder you also need to calculate the amount of concurrent users. Process automation counts one concurrent user as 400 messages and Visual Builder counts one concurrent user as 100 messages.

A minimum for an app is going to be approximately 2.57 USD per hour, if you use less than 5000 messages in the hour.  This is a pay as you go estimate.

You might also need to pony up for build machines.  And, of course, your users need to be licenced for JDE too.

App deployment seemed to be pretty simple, as with all of these platforms.

Everything was JS at the end of the day.

AppSheet

I have to admit from the start that I’m a fanboy of google tech, and this company has just been purchased by google.  I loved the concept of this – run anything from a googlesheet.  It’s amazing.  You have 100000’s of rows, you can have complex relationships in the sheet, you can have data slices for security purposes and performance reasons – but you also do NOT have to have a database.   That is neat (or is it?).

This is a very easy platform to use.

I went to JDE, created a grid I liked (item master), exported the grid to a CSV and then saved this in my https://drive.google.com .  I then went through the app created wizard, and I had a pretty cool app in a very short amount of time – but guess what.  I had a spreadsheet that was “up to date”, not a relational database.

I was able to remedy this quickly by writing a couple of web hooks that called orchestrations to delete, update or create items in JDE.  It WAS that simple.  3 orchestrations later I was keeping my spreadsheet and JDE synchronised.  I could add items to the JDE item master easily.

AppSheet did some amazing things:

·       Created virtual lists from repeated items in the data  [it realised things were UDC’s or codes and did all of the validation for you]

·       Automatically generate all of the code for the insert, update and delete forms.

·       Can assign “models” to rip OCR out of any images that are taken with the phone / app [this is really cool)

·       Easy to integrate label scanning and more – PRO plan

·       Creating graphs and visuals was very easy

Costs

User based Premium - $5 PUPM

User based Pro - $10 PUPM

There is an enterprise plan too, I do not know the details.

As a publisher though, this is a cost per user - $50 PAPM (per app per month) [only if this is PUBLIC!!)

To determine what is PRO or PREMIUM – go here https://solutions.appsheet.com/pricing

PowerApps

The Microsoft offering is palatable for so many customers.  People who thing that they have office365 and therefore need to use Azure for everything…  I’m trivialising, but you get my drift… Once you’ve drunk the Kool-Aid – well you are going to keep drinking, it’s addictive.

My experience of PowerApps was that it was also a little clunky.  I was struggling with the plethora of options and then was equally confused with how much everything was going to cost me.  What I did like is that PowerApps could easily call my published orchestrations and read my OpenAPI catalog.  It was easy to authenticate.

PowerApps did not build the app automatically for me, I had to start from nothing and start building.  There was a good code interface and I could generally get things done.

Of course deployment is pretty easy

Costs

From here

PowerApps per app plan. Allow individual users to run applications for a specific business scenario based on the full capabilities of PowerApps. Pricing will be $10 user/app/month. (USD)

PowerApps per user plan. Equip individual users to run an unlimited number of apps, without any feature restrictions. This takes the place of existing P1 and P2 plans and will be $40 /user / month. (USD)

The Wrap

With such light usage and experience, it’s hard for me to do a complete comparison.  What I do suggest however is to start your journey, as you can be proficient in a week as far as I can tell – especially when dealing predominately with JDE orchestrations and external web services.

I think you also need to ensure that you understand the TCO of each of the options, and what that is going to cost you post POC.  The different costing models make this a little difficult.

Ensure that you understand all of your deployment options too – to ensure that consoles, phones and tablets can run the code.

It’s incredible what you can achieve in a small amount of time, but remember, with great power comes great responsibility.  If you are opening web services to public ports, please ensure that your security is ready!

If I was training my internal team, I'd say use PowerApps, as that is going to set you up for the entire power platform.  If you wanted cool apps and amazing immediate functionality - I'd use AppSheet (I'd probably use this).  Finally if you want one throat to choke, choke oracle's with VBCS!