Stwórz system z gotowych klocków – poradnik wdrożenia No-code [EN]

NO-CODE PLAYBOOK

The No-code Playbook is a vendor-agnostic guide that empowers teams to deliver business applications of any complexity with no-code.

The Playbook provides guidance on how to organize efficient IT and business collaboration and deliver game-changing results leveraging the potential of the no-code approach while staying compliant with governance requirements.

PART #3

Principles of No-code Development

We’ll cover a lot of ground in this Playbook and make sure you understand no-code strategies, how to organize for success, what methodologies to follow, etc. However, before we get into these details, let’s step back and examine the “first principles” of no-code development. First principles are essential and, as observed by Aristotle, they are sometimes the most difficult concepts to grasp. It’s easy for the busy reader of this Playbook to get so immersed in the “how” of no-code that we forget to first understand the “why.” So, we are going to begin with a discussion of the three core principles of no-code development:

1. Use no-code to gather the requirements and prototype on the fly.
2. Everything that can be developed with no-code, should be developed with no-code.
3. Deliver to end users as fast as you can.

These three principles are the foundation for the rest of the Playbook. The No-code Lifecycle that we’ll be detailing from here on out will build upon these core principles. So, it’s important to address them first as everything else will extend from there.

Principle #1
USE NO-CODE TO GATHER THE REQUIREMENTS AND PROTOTYPE ON THE FLY

This first principle is about streamlining the upfront stages of the software development lifecycle that precede actual development. In traditional software projects, the requirements collection and Design Phase usually account for a big time and effort investment.

Part of the reason why custom software projects take significant effort and time is because of the sheer amount of documentation that must typically be created (and reviewed) by both business and technical stakeholders, and this work is time-consuming and complex. These documents can often be fairly technical and use specialized notations to support custom development because they are meant to facilitate the translation from the original business intent down into detailed, lower-level concepts (ultimately being translated into lines of code by developers later in the software lifecycle). The sheer volume of documentation can also result in “losing the forest for the trees,” making it easy to obscure the overall understanding of the application and overlook important gaps or missed requirements.

Also, the need to produce large amounts of documentation in traditional custom development often introduces costly defects due to translation errors. A typical custom software development lifecycle involves multiple people in each stage. It starts with a business analyst whose job is to meet with the business and document the business requirements. These requirements are then translated by a solution architect to design the overall solution and then translated again by developers to create detailed specifications. Finally, they’re translated one last time by testers who develop testing plans to ensure the software aligns with the requirements. There is a risk of introducing errors into the documents at every stage of the translation process. Errors introduced early in the process — while gathering business requirements for example — create exponential waste because each subsequent stage develops materials based on the early error.

No-code development takes a very different approach. In contrast, using the no-code tools to capture the requirements and design is inherently a more efficient and accurate process. Each of the major elements of the functional specification can be described visually, such as capturing the design of user interface (UI) form layouts, business process flows, and business logic. Using no-code tools is a highly efficient way to capture the specification and facilitate a more direct and effective way to review and gather feedback from stakeholders and end users. Business stakeholders do not have to be technology literate — they can be shown working prototypes of the no-code application very early in the lifecycle, making it easy for them to understand, navigate, and provide feedback to the no-code development team. This improves the efficiency of the process and results in higher quality feedback.

Finally, all of the time spent during these no-code activities does not result in “throwaway” documentation. As you use the no-code platform to build your prototype, you are creating both a specification and the working application. This results in greater efficiency and productivity. It also means that as you change and iterate on the underlying model, the specification and app stay synchronized throughout the lifecycle. This is a huge advantage over having to maintain both the specifications and the application code and keep them updated in tandem.

Principle #2
EVERYTHING THAT CAN BE DEVELOPED WITH NO-CODE, SHOULD BE DEVELOPED WITH NO-CODE

The second principle is about minimizing the complexity of your overall solution architecture by adopting a primary architecture of no-code. While there are many options available for designing your overall architecture, pursuing too many options can introduce unnecessary complexity — just because one can choose from many options does not mean that one should! Also, teams can fall often into the behavior of sticking with what they already know.

Companies with heavy expertise in software development tend to overuse code and apply it everywhere as it’s a learned behavior that is difficult to unlearn. In contrast, the goal of the no-code approach should be to break this cycle and use coding only as needed as a part of the fusion team approach.