A graphical user interface to build apps on top of microservices

How to enable non-programmer business users to create their own data applications.

By Andy Oram
March 28, 2018
Modules Modules (source: Pixabay)

Companies are increasingly asking their IT staffs for rapid turn-around on tasks that require programming. The most likely path to attaining quick turn-around would be to let non-programmers create their own applications—an approach that can be achieved with a combination of microservices, APIs, and graphical user interfaces (GUIs).

The goal of letting non-programmers manipulate data is an old one. When IBM released early versions of the SQL programming language, they intended it for business users. They really expected a mid-level manager to sit down in the morning and type UPDATE PRODUCT.SPEC SET WIDTH = 19, HEIGHT = 12, DEPTH = 4 WHERE PRODUCT_NUM LIKE ‘GK145%’ onto a green screen. More realistically, though, SQL was hidden behind various forms that eventually moved to the web. But these forms do not offer the full power of the language.

Learn faster. Dig deeper. See farther.

Join the O'Reilly online learning platform. Get a free trial today and find answers on the fly, or master something new and useful.

Learn more

Visual programming, using some technique such as moving boxes around a screen to create control flows, has also been researched for decades. It is best known in children’s educational tools such as Alice and MIT’s Scratch. The problem with trying to create large-scale applications using visual programming—and the reason I’m guessing that visual programming hasn’t won a large user base—is that programming’s complexity lies more in the mind than in the syntax. Exposing the complexity of control flow and math through boxes and lines doesn’t make it easier than using words and punctuation.

It may be quite a different matter, however, when powerful chunks of functionality, already hooked up to an organization’s data sets and control structure, are offered in a visual interface, also known as a “low-code development platform.” For instance, an auto insurance assessor can do something really useful if she can automate part of her job by drawing a line between client information and a tool that calculates how much to pay for each part of a car.

Where do microservices enter the picture? They work at a higher level than function or library calls, offering precise access to specific data and services in the organization. I talked about microservices with Bruno Trimouille, a senior marketing executive at TIBCO Software. He spoke of an airline that has microservices for travel services, customer profile data, flight information, and other elements of their workflow. Visual programming exposes all these things to the average employee. If someone in the luggage department thinks up an application that can find a bag more quickly or send a voucher to a customer’s mobile phone, he can hook up services to create the application.

The low-code application environment can tap microservices to digitize a process that previously was done manually, such as submitting expenses or getting travel approval. It can also extend an existing system, or add some logic that stitches two microservices together.

As another example, Trimouille points to the problem of repricing in insurance. When an auto body shop takes apart a car, it often discovers new damage that the insurance assessor did not originally cover. The insurance company can upgrade its assessment tool to do repricing quickly and save both time and money.

Thus, microservices, APIs, and low-code application development may lead to a new level of productivity. They could provide end users with the deep reach into their corporate data promised by the classic UPDATE statement—but now backed up by full insight into the structure and value of the data.

This post is a collaboration between O’Reilly and TIBCO. See our statement of editorial independence.

Post topics: Software Architecture