In our previous article, we argued why business leaders and executives should learn to use IT strategic planning templates rather than learn to use software tools. Current trends in software development include the citizen developer movement and low-code development platforms. For readers familiar with these trends, it is not too far-fetched to reason that the “canvas-to-software” concept will be the next evolution of these trends. In future, we foresee that using canvases will be the primary way for citizen developers to participate in the software development process, and any type of enterprise software can be generated from canvases.
We recently published an article titled “Reimagining The Enterprise Software Development Process”, where we talked about inventing the Workflow Canvas to empower stakeholders. Learning to use our Workflow Canvas is not unlike learning a technique like mind-mapping, SWOT analysis, Fishbone Diagram, etc. We first focus on the Workflow Canvas for workflow software, but In future, we foresee the emergence of different types of canvases to cater to the development of different types of software. We view “canvas-to-software” as a new paradigm, one that connects conceptualizing, describing and generating usable software.
We think that advancing the Citizen Developer (CD) movement entails the following: 1. Reduce the difficulty and workload that CDs need to bear; 2. Provide a shared language for CDs to use to communicate with other stakeholders; 3. Encourage CDs to learn enough about IT strategy so that they can solve real world problems using software. We believe in the benefits of citizen development, and aim to take this movement to the next level. To aid in (1), by using our Workflow Canvas, CDs do not need to learn to use any software tool. To aid in (2), our Workflow Canvas is an example of such a shared language between CDs, stakeholders and IT consultants. To aid in (3), the process of detailing a Workflow Canvas which is translatable into usable software promotes thinking and learning about IT strategy.
Participatory design is an approach to design attempting to actively involve all stakeholders. Whether used for solitary brainstorming or for participatory design, we advocate the use of physical canvases such as paper and whiteboard over digital canvases. We view learning to use a digital canvas as the same as learning to use a software tool, which entails the drawbacks mentioned in my previous article. A recent research comparing paper and software tool for participatory design can be found here. We advocate physical canvases rather than digital, because compared to using PDotCapturer in that research, the learning curve for a software tool to detail a digital canvas will be higher.
There are many products, such as Google App Maker and Microsoft PowerApps which allow citizen developers to create usable software using software tools, with user interface patterns such as drag-and-drop and form builder. From the angle of participatory design, we argue that using paper or whiteboard is better compared to using these software tools, because for paper or whiteboard, getting familiar with using a technology does not get in the way. By not having to adjust to using technology and not having to adapt to the limitations of a software tool, it will allow ideas generated during a discussion to flow more freely.
Optical character recognition (OCR) technology has advanced to a level where learning to use software tools becomes unnecessary, because writing and drawing on a paper or a whiteboard is sufficient. Using OCR, an algorithm can read a physical canvas and translate it into usable software. In future, citizen developers will be able to generate usable software, regardless whether they use a physical canvas or a software tool. So, there will be no reason for citizen developers learn to use multiple software tools to generate usable software.
Using a canvas brings numerous advantages to citizen developers. A canvas serves as a template for visual thinking and visual communication, which helps in effective decision making and helps stakeholders communicate their decisions more effectively. One reason adoption of the Business Model Canvas proposed by Alexander Osterwalder has taken off is because of the benefits of it being visual. We foresee the “canvas-to-software” concept taking off for a similar reason. Using a canvas is an ideal technique for citizen developers to brainstorm, discuss, design, conceptualize and describe their software needs - together with other stakeholders, and if necessary, with their IT consultant. In addition to that, we view a canvas as a template for citizen developers to express their creativity.
There are many techniques and frameworks in the fields of innovation, marketing and management. But what about a technique for stakeholders to conceptualize and describe their software needs? Before we introduced the Workflow Canvas, there was a void in the marketplace of such a technique. Due to advancements in OCR, it is only natural that physical canvases exist for stakeholders to conceptualize and describe software. Together with our Workflow Canvas invention, we introduce the “canvas-to-software” concept, and view this concept as the next evolution of software development.