Many years ago, I worked in research and development for the military. It was there I quickly learnt that if I presented a technology project which was beyond the General-in-question's understanding, the answer was always: ‘No'. So I made sure to ‘dumb down' (sorry General) the solution for him to understand and therefore sign off.
I believe most BPM providers have also learnt this, and consequently a lot of demonstrations to CEO/CFOs are based on the drag-and-drop "look how easy this is, anyone can do it" model. This, together with the Citizen Developer idea, is unfortunately creating a misconception about what it really takes to develop business process management solutions, says Denis Bensch, CIO of FlowCentric Technologies.
Let's first discuss the idea of ‘citizen developer'. The citizen developer is a double-edged sword, as many IT departments can attest. There are, no doubt, countless stories about how they had to save or upgrade ‘that' Access database or Excel macro, which had become critical to business, but was designed and developed by Auntie Marie who left on retirement, and now no one actually knows how it works. On the other hand, the technically astute end-user is often the initiator of great ideas within companies. These users can be very useful on IT projects, as they can normally articulate the business requirements more effectively than non-technical users
IT Departments – Guide and Utilise These Users in Projects
Use them in project scoping workshops and in testing, encourage them to aid in the definition of the flows as well as the design of the screens. Recommend tools for them to use within the architectural constructs of the company. But ignore them at your own peril, because ignoring them increases the threat of ‘shadow IT'. These individuals are often close to the other employees and are thought to deliver solutions without the many perceived delays and overheads of the official IT department.
Why Development Should be Left to Developers
Let’s discuss the ‘drag-and-drop' development concept, and why development should be left to developers. Firstly – let's be clear – we are speaking about business-critical processes in this article; it is only the simplest, usually non-critical processes, that don't require integration to external systems or data sources. There are plenty of cloud-based, drag-and-drop workflow engines that are aimed at the ‘let's monitor Twitter and send an e-mail if someone tweets negatively about us' market. Accepted, there is a market for those, but they are not the systems that retrieve data from onsite line-of-business systems and interact with ERP solutions.
The simple fact is that to write efficient, scalable, maintainable systems requires expertise. Most people have learnt to have their buildings designed and built by professionals, and their cars to be serviced by reputable experts. Why would you want your business IT processes to be developed by amateurs?
Many vendors, including Microsoft, have been attempting for years to develop tools that span the divide between the Office power-user and the developer. Their most infamous example in this space is InfoPath. The product was designed to be used by Office users to create electronic forms. Once the complexity got beyond the Office users' ability, developers could then write Web services or .Net assemblies to handle these complexities. The problem, was that it wasn’t a developer tool, and consequently violated the most basic developer requirements or principles such as versioning and source code control. This made managing, maintaining, upgrading and deploying InfoPath forms over a period of time complicated. It was (application was discontinued in January 2014) the platypus of applications. Too complex for Office users to truly be able to use and leverage, and too simple for developers to use to create industrial strength solutions.
This brings us to the core of the discussion. We all bear witness to the accelerating rate of business - faster competitive quotes, online ordering and swift delivery of merchandise - this is created by efficient, integrated and scalable systems. These are not systems built by amateurs using hobbyist tools. These are systems designed, developed and implemented by professionals using professional tools.
At this point, I need to clarify a point about drag-and-drop and development. Almost all modern development tools support some degree of drag-and-drop interfaces to speed up development and provide a visual concept for complex structures.
These can be seen in Microsoft's Visual Studio, SQL Server Management Studio as well as its integration suite SQL Server Integration Services. However, in all of these tools, it is accepted that the basics are done with the visual tools, but the real meat – the actual executable code – is going to be written by a skilled individual. This is a far cry from the promises made by the no-code/low code community where the idea is created that most, if not all, of the work can be done with drag-and-drop configuration only.
The reason for this is that every visual tool is simply a translator to executable code. As in all translators, the translation is only as good as the translator understanding the intent of the speaker. Good developers need more latitude than this, and therefore prefer to write the code themselves. Additionally, when the visual tools don't allow for something to be done, and it is a business requirement, it forces some elaborate workarounds to be developed.
Lastly, a Point About Software Development Life Cycles
Software development as a discipline is significantly younger than many of the engineering disciplines. It has taken us some time to formalise the correct methodologies in terms of development, staging and production areas, or fine-tune scoping, versioning and change control protocols. It is unthinkable that IT departments are going to abandon this in order to allow a couple of amateurs with drag-and-drop tools to affect business-critical systems. Therefore, my message to CXOs that are evaluating BPM suites: Look for tools that are made for professionals to do their work as efficiently as possible. The tools aimed at the citizen developer are unlikely to help you build the scalable systems you want.
In closing, in the movie 300, the Greeks sent 6 000 men to meet the Persian invader Xerxes, while King Leonidas of the Sparta brought 300. When the Greeks questioned his commitment, he asked a couple of the Greeks what their profession was. They were potters, sculptors and blacksmiths that were gathered together to fight the Persians. As the Spartans were all soldiers, Leonidas made the point that he brought more soldiers. Let's stop using citizens to do what professionals should be doing.
