Close the gap between customer and developers with low-code platforms

It is a common problem in IT projects: the gap between customers and developers. In this blog, Jan-Jaap Zijlstra, Lead System Architect at BPM Company, tells you about the best way to close this gap.

The business analyst and the jargon problem

The gap between customer and developer is too big in many IT projects. Customers don’t understand what developers are trying to build, and developers don’t understand the expectations of customers. The consequences are clear: unnecessary delays and, in extreme cases, even failed projects.

Business analysts are usually used to close the gap. It is their job to translate the expectations and wishes of customers into clear requirements and stories for developers. This sounds good in theory, but practice shows otherwise, as business analysts have to master four different jargon:

• Customer jargon: the language used by the customer to describe their wishes and expectations.
• Platform jargon: the language of the platform vendor in which the possibilities of the platform are described.
• Developer jargon: the language used by developers to express themselves.
• Application jargon: the language used to describe how the application works.

In sum, correctly and clearly translating the wishes and expectations of customers in four different jargon is extremely difficult. Even if it is possible, it will take a lot of time.

The role of the documentation cycle

Another reason why it is so difficult for the business analyst to manage the gap is the documentation cycle. Typically, organizations organize IT projects in iterations of two weeks (Sprints). The customer, business analyst and developer implement new functions and update the documentation with each Sprint. The following image shows a common documentation cycle:

All stakeholders have to translate the delivered documentation at each step of the cycle so that the documentation can be implemented in the next step. From Word to Confluence to Stories to Implementation and back again to Confluence. The gap between customers, business analysts, and developers will increase with each iteration if too much information is lost during the documentation cycle.

I see this kind of problem during my own projects as well. I am currently working on a big Pega project where a complex financial system has to be adjusted because of changed legislation. The problem with different jargon is also visible here:

• The business analyst has to know and understand hundreds of codes and concepts.
• The business analyst has to understand Pega’s platform jargon.
• The business analyst has to understand the (English) jargon of developers to collaborate with them.
• The business analyst has to know how to navigate the portals of the financial system.

Therefore, the documentation cycle continues, and the gap increases. The result? Unnecessary loss of time. Unfortunately, there isn’t one simple solution. Organizing more meetings, agreeing on better work methods, or intensifying the collaboration efforts shorten the distance, but the gap will remain.

The solution: low-code platforms

Low-code platforms are the best solution to close the gap. These are development platforms in which developers, together with customers and business analysts, can create applications in an easy and visual way. The big advantage of low-code platforms, such as Pegasystems, is that the documentation cycle takes place in the platform itself. As a result, the customer, business analyst, and developer analyze, document, and build together within the same platform. Besides, low-code platforms are easy to, so customers and business analysts can express themselves well within the platform. The choice to use a low-code platform, therefore, solves two problems: everybody is forced to use the same jargon and the documentation cycle becomes easier to manage.

For these reasons, I try to use Pegasystems more and more as a low-code platform in my projects. Pegasystems offers two different platforms that can be used at the same time:

• Dev Studio: the technical variant, mainly meant for developers.
• App Studio: the low-code variant, meant for customers and business analysts, but also for developers.

By pushing for the use of Dev Studio and App Studio, I try to make sure that everybody uses the same jargon and that the documentation cycle stays manageable.

I try to encourage the use of App Studio more than the use of Dev Studio. As a result, people use the same jargon and the documentation cycle stays manageable. This is how I try to close the gap between customers, business analysts, and developers as a Lead System Architect.

The challenges of Pegasystems

The use of low-code platforms, such as Pegasystems, doesn’t mean that customers, business analysts, and developers don’t have to watch out for the gap. Challenges also exist when using Dev Studio and App Studio. For example, not everything developers build in Dev Studio is clearly visible in App Studio. Large amounts of code shall be invisible in App Studio if developers don’t take this into account. If they don’t, there is a chance that the gap between customers, business analysts, and developers increases again. Developers can prevent this by using App Studio as the main platform when developing applications and only switching to Dev Studio when absolutely necessary.

A different challenge lies in being in agreement regarding documentation. Customers, business analysts, and developers should agree that the documentation in App Studio is considered the official reference documentation. Otherwise, the temptation to not update the documentation in App Studio will be too big. The problems of the different jargon and documentation cycle will increase again in this case.

Closing the gap with low code platforms

Different jargon and complicated documentation cycles are fundamental to the gap between customers, business analysts, and developers. And yet, unnecessary delays and failed projects as a result of these issues can be a thing of the past. Low-code platforms offer customers, business analysts, and developers the chance to close the gap between them. When using a low-code platform, stakeholders use the same jargon and the documentation cycle becomes manageable. Thus, the gap between customers, business analysts, and developers, which was once so big, is suddenly a lot smaller.

As an experienced Lead System Architect, Jan-Jaap worked on various IT projects over the past few years. Are you curious to know more about Jan-Jaap’s experience with BPM Company and Pegasystems throughout the years? Then read his interview in honor of his tenth work anniversary at BPM Company.