What Formula 3 and SAP Build have in common.

Once upon a time I was lucky enough to try driving a Formula 3 car. I say 'tried' as, by my own admission, I failed pretty miserably. As I struggled to learn, fast cars don't behave like a road cars. It transpires they have minimum thresholds you have to meet before you can do simple things - like turn a corner. Tyre warmth (impossible to achieve if you keep spinning off), tyre cleanliness (impossible to achieve if you keep spinning off) and a minimum speed are required to create downforce (to allow the tyres to grip). The latter is terrifying. Trying to drive 'way too fast' into a tight bend goes against everything 25 years of driving has instilled. But yet the car responds and incredibly sticks to the road like glue.

Overall it was a highly humiliating experience. As I cursed from the cockpit of my car (often from the gravel after spinning off), I watch enviously as 14-year old children lapped me. Over and over again.

Eventually my instructor took pity on me (probably to save his expensive car) and talked and guided me through every single corner on the track. I even managed the last two on my own. It was a personal victory.

So what do my Formula 3 failings have to do with SAP Build? Well, let's start from the begining. SAP Build is the latest Low-Code application release from SAP. Yes, it is a new version of a previous product, but it has pulled together everything historically with the SAP AppGyver product and created a flagship low-code solution. And it is probably the right things to do.

Low-code tooling is all about leveraging the expert individuals within business teams who have the best business knowledge. The tooling empowers them to create apps to 'help' their business areas. It's a drag and drop world, with all the code happening behind the scenes like some form of Harry Potter magic.

Sound a bit too good to be true...? Perhaps...

But the principles are right. I have always banged the drum of empowering those individuals who 'really know' the business. Not senior manager. Doers. They are the process experts and those that can take business to another level. If you let them.

So low-code tooling gets rolled out to these business experts, we give them a bit of training and the result is like giving me a state of the art Formula 3 car. Painful to say the least... So why..? Because... despite the marketing hype,

Low-Code needs more than just a tool. It needs a process and consideration .

Let's explore this...

Process Considerations for SAP Build

Strategic and Architectural Alignment

Anyone touching low-code needs to understand the direction and trajectory of the digital strategy and the organisational strategy. There is no point enabling a work force, who instantly build apps to recreate 'old' processes. Everyone needs to be signed up to the future vision, and indeed to a degree, understand the architecture of the SAP/business footprint.

Technology Understanding

This is 101. Your teams need to understand the processes around Low-Code. It's clever and incredibly powerful, but ultimately there is a learning curve and it won't be long until some clever business person asks for somethings low-code can't quite achieve, and needs technical help with. There needs to be a mechanism in organisations to 'get this done', leveraging more technical team members.

Business Process Understanding

Again, a given, but there needs to be full business process understanding when we are building these apps. We can't build in silo's. Just because we know more about supply chain than we do finance and planning, doesn't mean we don't need to consider impacts. The entire end-to-end processes need to be considered to avoid damaging something up or downstream.

Also - third party systems need to be well understood. Data flows around the organisation into other applications. The holistic impact and design is key.

Governance and Change Control

How these apps are deployed and dropped into productive use will be key. Who is going to update process maps, what documentation will be completed, who is going to put the app through its formal change control channels? What is the change control process for when it is live? How is it supported? The whole governance and deployment aspects need to be considered.

Deployment Processes

The low-code apps will need to go through formal project phases and gates, just like any other apps. They will need to be designed, built, unit tested, process tested, integration tested, users tested, volume tested, moved through an SAP landscape and ultimately signed off prior to deployment. Then there is the change management and comms, training, target operating model adjustments, cutover and transition to support.

It's not a build and press go world. It needs an element of control.

Clean Digital Core

The cleaner and more stable the digital core the better. Timo Elliott made a great point in a recent post about the 'clean core' being like a tanker, and only shifting a degree or so. Meanwhile the apps are like speedboats and helicopters zipping off the tanker to get things done quickly. This is a great analogy. The core, and the business processes, are really important. The cleaner they are (less customisation etc) the better.

Authorisations and Security / Segregation of duties

Another minefield a low-code world needs to be aware of. You can't break organisational rulesets (without governance) and this whole aspect needs to be considered when low-coding apps. Now the BTP platform does help here, but it's one for consideration.

In summary

Low-code is without doubt a huge asset to an organisation. BUT, despite the marketing fan-fair, it needs control, governance and a process to deploy in order to get these apps into production quickly and efficiently.

So let's see how this all pans out. My personal view is that it will 100% take off. Enabling the expert workforce is definitely the future, but it will need a structure (potentially light touch) or will form part of larger programmes. You just can't escape the governance and control needed to ensure 'safety' when it come to new technology/processes.

No one wants their expensive Formula 3 car sat in the grit on the side of the track.

We've already created a unique low-code project framework that is a lean version of our existing programme methodology. Why? Because low-code needs to be faster than 'ordinary programmes' - but not compromise controlling mechanisms. Reach out to either myself at [email protected], Brian Lavery or Gordon Kelly if you want to know more.

#SAP #SAPTechEd #SAPBuild