Monday morning thoughts: Workflow Forms and the definition of a developer
In this post, I think briefly about the definition of a developer, and in that context look at the advent of Workflow Forms, a major new addition to the functionality of the Workflow service on SAP Cloud Platform.
How do you define a developer?
Last week, a question came up about developers. Specifically, do you define a developer as one who writes code, or is the definition broader than that? It’s an interesting question. On the one hand, I class myself as a developer, I write code (or what passes for code), and I’ve traditionally considered these two things as being related. Of course they’re related – “developer” is the name of someone who develops, or creates, software. And software is code that is executed on a machine.
But thinking about it a little more, perhaps the definition is broader than that. The first developers wrote in machine code, then assembly language, and the growth of development as a practice and the number of developers increased as the language abstraction layers grew, as we got further and further away from the machine. This of course is a good thing. Most languages today bear little resemblance to the microcode that is only one step away from the hardware that actually processes what was written and translated.
In Byte magazine in the 1980s I remember adverts for 4GLs — “fourth generation languages” — that were designed to appeal to and be used by the “non-programmer” (image courtesy of archive.org)
Moreover, when thinking of this progression, there is perhaps an implicit connection between the concept of imperative constructions and programming, with little thought to anything that wasn’t procedural, anything that wasn’t “fluid”. If you aren’t telling the computer what to do, are you still “developing” code? Immediately my thoughts turn to languages that are deliberately non-imperative, non-procedural.
Think of the logic oriented nature of PROLOG, which is more declarative than imperative. Think of the array oriented nature of APL, which is nearer to maths than to procedural programming. Think of the functional programming paradigm and languages in that space. One thing that permeates function orientation is the idea of “what not how” – you say what you want, rather than how you want it computed.
So it stands to reason that when we define things declaratively, whether that’s describing what a UI looks like using XML in the UI5 space, or specifying what a business entity looks like when using CDS with the Application Programming Model for SAP Cloud Platform, or on an ABAP stack, when we declare behaviour using annotations, are we still developing?
I’d say yes, we are. Perhaps it’s not too far fetched to say that to develop is to create something that executes on a machine. How you define how that something works is an implementation detail, as they say.
The SAP Cloud Platform Workflow service
Why am I talking about this? Well, there are a number of services on SAP Cloud Platform that allow folks to build solutions to things, to create data visualisations, to connect systems together, to generally solve business problems, without much (or any) actual programming at all. One of these services is the SAP Cloud Platform Workflow service.
I’ve written and talked about about the Workflow service before, so if you’re not familiar with the service, you might want to take a look at some of these resources:
- A 10-part series on various aspects of the Workflow service: Discovering SCP Workflow
- A replay and link summary from my ASUG webinar session: Introduction to SAP Cloud Platform Workflow – Summary
- A brief CodeTalk episode: SAP CodeTalk – SAP Cloud Platform Workflow Service
- An interview on Episode 1 of the Coffee Corner Radio podcast series
- An interview on Episode 015 of The Integration Podcast
And of course there are plenty of very readable docs at the main Workflow landing page here: https://help.sap.com/viewer/product/WORKFLOW_SERVICE/Cloud/en-US.
Designing and building a workflow definition and deploying it for use on SAP Cloud Platform is something that’s pretty straightforward. Naturally, the more complex the workflow you’re designing, the more steps you have to include. But on the whole, it’s quite a pleasant experience. What’s more, it’s declarative, in the form of a workflow editor where you connect boxes together and define properties for them, and the overall diagram that you create represents the flow definition.
However, for User Task steps, you need a User Interface (UI) with which a workflow task recipient can interact, view and add data to the workflow instance context, and make decisions. There’s a well-defined API for the standard My Inbox Fiori app and you build the UI as a component that is instantiated on a task by task basis inside the My Inbox app. That component is a UI5 component (see the Component Startup and Recommendation UI posts in the Discovering SCP Workflow series for more details).
That’s all well and good if you’re a developer in the traditional sense, and a developer in the UI5 sense specifically, but the tantalising truth is that – with the exception of these User Tasks, you actually don’t need to write any code to design and implement Workflow definitions.
But programming skills in UI5 have been needed to complete that “last mile” of definition.
Last week, a major new feature was made generally available – Workflow Forms. With this feature, you can define user task UIs in a declarative fashion, using the form editor in the SAP Web IDE.
The form editor in the SAP Web IDE, via https://blogs.sap.com/2018/09/14/new-feature-in-sap-cloud-platform-workflow-forms/
The way it works is that you define the layout of the UI, and link up data in the workflow context with the fields in the UI definition. You also define actions. At runtime, there’s a forms “player” that interprets your form definition to produce the appropriate user task interface. It’s UI5 underneath, of course, but as a workflow definition creator, you don’t have to know any UI5 any more.
The Workflow Forms feature was announced last week by Joachim Meyer in this post: “New feature in SAP Cloud Platform Workflow – Forms“, and I for one am very pleased to see this announcement. I was lucky to get a sneak preview of the feature a while back, and it works very nicely indeed.
So if we’re to take the wider definition of a “developer” as someone who builds solutions to run on a machines, using appropriate tools, then this Workflow Forms feature allows traditional non-programmers to do just that – to develop and deploy entire workflow definitions.
If someone builds something using definitions and declarations alone, are they a developer? Following the thoughts earlier on in this post, one might say that they are. Of course, your opinion may be different, and that’s fine. Heck, I might change my thinking when the words “programming” and “developing” re-merge in my head. To be honest, I guess it doesn’t matter too much about how we define developers, although it’s an interesting exercise to think about their nature.
What does matter in this case is that the ability to create solutions that involve workflow definitions is now, with the advent of the forms feature, in reach of the non-programmer.
As you might know, I’m a fan of the Workflow service, and the new feature is excellent. It doesn’t preclude the use or definition of custom user task UIs with UI5 components – far from it. That approach is still possible, of course. But even as a UI5 programmer, I can see myself using the forms feature, and not worrying one iota whether people think less of me as a developer or not.
Give the new Workflow Forms feature a try. There’s documentation available for you in the Help Portal – see the new “Creating a Workflow Form” section. And there’s even a revised tutorial in the tutorial group “Get Started with SAP Cloud Platform Workflows“, specifically the “Building a simple approval UI for your workflow with Workflow Forms” tutorial, to help you get a head start.
Here’s to programming, developing, and building solutions!
This post was brought to you on a rainy Monday morning and Pact Coffee’s El Silencio.
Read more posts in this series here: Monday morning thoughts.
Great blog DJ Adams , I was waiting for your view on the new Forms feature introduced in the recent release but before that let me also provide my 2 cents about
As per my understanding Coding is an art, you need a lot of imagination to come up with something beautiful and elegant which basically solves a problem. With the kind of abstraction being brought into the languages, although we are being moved away from the machines on which they work but still the developer needs to be creative in designing a solution. So Developer are definitely the coders who are daily creating a beautiful form of art.
Now coming to forms service, it is a much needed feature and is most welcome. Whenever any new feature is coming to workflow, the basic tendency of me always goes back to our SAP Business Workflow(forgive me for the same). The forms in SAP business workflow virtually gives you an ability to design a full custom dialog application where as here as far as i can see is we are making a basic form with input fields. I have been trying to find if we can create tables here or much advanced stuff does not look possible as now(am i missing something).
It is great to see our workflow service expanding, looking forward to more of such great features.
#MondayMorningThoughts -> Rocks, keep them coming.
Thanks Nabheet! I appreciate your encouragement.
Good to hear your thoughts on development, I certainly agree that there is art in there. As someone who studied the arts (specifically Classics, incl. Ancient Greek, Latin, Sanskrit and Philology) I have a tendency to recognise the art first, and the science later, in what I do. But others may see programming differently.
Have you tried out the forms feature yet? It's great, you won't be disappointed!
The discussion on the definition of "developer" or "coder" or "programmer" is indeed going on for a while. Even in our own team 😉
One important case I missed here was the "data crunching developer" for the lack of the better term, trying to avoid popular nowadays "data scientist". They are not building solutions for the most part, but using computers for finding answers, solving problems, building models. And often they do this by using the most successful (if not the only one successful) 4GL called SQL! And yet often are not regarded as developers.
Indeed it is! The range of roles definitely blurs, and it would seem that as we struggle with terminology for folks creating software, using software, and writing software or configuration on the fly, to accomplish their goals, perhaps it makes less and less sense to try to classify in this way.
Your example of SQL is a great one - is someone who writes SQL a developer or not? Asking philosophically, of course.
How does this compare to workflow or developer definitions for other products, like Tallyfy?
In terms of low-code workflow or BPM - the real definition of developer-facing aspects is a public REST API, imo.
BPM and workflow and forms have many definitions, but it's essential to clarify them:
Hey Amit, long time no speak! 🙂
From my point of view, it compares favourably. Of course, it depends what one wants out of the workflow software. From what I've seen of Tallyfy, the definition process is a little different, but at the same time it's accessible to "solution creators" rather than just programmers. But I think anything that is based around BPMN is a good fit. That said, I'm not an expert in workflow software, so there may be different approaches.
An API is important too, of course. But that importance is more at the programmer level, rather than the type of user I was considering when writing this post. And of course there's the question of API target, of which there are at least three: designtime (e.g. manipulating workflow definitions), runtime (e.g. starting and stopping workflow instances) and -- from the other angle -- the ability to invoke APIs from within a running workflow instance.
Thanks for the comment and diving in!
I want to be thought of as a Workflow consultant. Typically in the market that has been "an abap developer with Wf experience" but I do not believe this is the right emphasis. If not calling myself a developer helps move the idea that workflow is about modelling business process not a technical "development" then it would be a good thing.
Hey Andy, what an excellent thought - something I hadn't considered. I can see how a focus on development could take away the emphasis on what's important in a role - in this example, as an expert in modelling business processes with special tools. Thanks for the comment, really appreciated!
(I must step outside of my developer box once in a while ;-))