All developments in the field of user experience show that we are on the verge of stopping typing data. Data remains necessary to be consumed as information ultimately. But the entry will soon have two changes. First, minimizing imports by deducing the required data. And second, the use of voice apps instead of apps that need a keyboard. These developments are already at an advanced stage. The rise of digital assistants, such as Google Home, Alexa, and Siri, clearly shows this. These chatbots are an ideal stepping stone to less typed input to eventually talk to the business application, your SAP system.

Since the 1970s, not much has changed in the field of User Experience when it comes to the operation of software applications. We capture the data to process it later as information in reports or to use it as a basis for making decisions. The input screens contain more and more fields because we want to collect more and more data.

Changes regarding input screens

The screens look a lot more user-friendly and have a more modern outlook than before. They changed from the first black screens with green letters and function keys to touch screens with buttons. In the end, they all do the same thing, they ask you to type in data. Software developers have developed all those screens. Their world, making these import applications, has been subject to the necessary changes. The first screens were made in simple first-generation languages, which took a lot of work for most simple screens. Over time, this has gotten better, and they were able to use third-generation languages and, nowadays, low-code generators to develop more complex applications in a shorter time.

Unfortunately, these input screens often ask for the same information over and over again and want data that is already known. It is time to take steps forward. Let us upgrade. Or rather downgrade.

What are you thinking? What steps? I can hear you thinking about this.

Designing principles

It would be more comfortable and more efficient if every UX designer and developer applied a few principles, namely “one-time entry,” “one time right,” and “only what is needed.” Using these principles would mean building applications based on a minimized number of input fields and maximizing the data required. Deduce the data because you already know who is using the app. By deduction of the data you already know or can determine from the location.  Deduce additional information based on data being entered.

Deduction is key

This deducing leads to applications that require less input. Simple chatbots that need just a few answers to capture a sales order, handle a leave request, record a meeting request with multiple colleagues, or support one of all those other business processes. From using chatbots to using voice-only applications is only a small step forward. Imagine. No more input screens on your desk, but talking to your watch to get your work done.

Let’s try

Does this sound too futuristic? Maybe so, but the possibilities are already here today.

Organizations can support their processes with best-in-class cloud applications from different vendors. They have more options to implement their own-practice during their digital transformation journey. But often, IT development teams organize their practice around particularly applications or development skills. And for cloud development, these structures should change. In this part, I will explain why the freedom of programming languages change the custom build application development within organizations.

Traditional Development

Traditional on-premise business applications run most of the time on one specific runtime. These applications, with tightly coupled UI logic and business logic, are written in a vendor-specific language. And when possible, extensions can only be written in the same program language, which strongly depends on the business application. Most vendors also deliver a limited set of libraries, which strongly depends on the programming language of the underlying operating system (like c/c++) or supported runtimes (like java).

Based on the possibilities of the software, IT departments organize their custom build application development around the programming language skills of the application runtimes or supported operating system. Organizations have, for example, an SAP practice for SAP, a Microsoft practice for Microsoft, and a java practice for JAVA. Business applications, with a cloud mindset, needs a different supported IT development structure.

Cloud Development

Cloud applications separate the UI logic from business logic. It makes it easy to add new devices and innovative technologies to the UI without changing the underlying business logic. And the code line of the business logic is hidden behind APIs. These APIs act like black boxes that are accessible via open web standards. Almost any application can access these APIs independent of programming language, the API is written in.

The API approach adds many values for both the cloud vendors and its customers. Customers don’t need to install and maintain the software of the vendor. And vendors can provide improvements and innovations much faster to their customers. The vendors also know precisely which version of the application their customers run. So, they don’t need to support ‘obsolete’ technologies anymore, because they now control the running code. It reduces their cost for support, and they can shift their focus on improvements and innovations of their running cloud software.

But cloud vendors will only be successful if they provide their APIs (or a subset) as well documented. And secure whitelisted APIs for custom build applications. The APIs should be based on open web standards, so almost every programming language can access them. And with a trusted lifecycle where these APIs are accessible and stable for a long period.

When software vendors deliver these kinds of APIs, this is a significant advantage for their customers. Organizations can build custom-build applications and extensions on top of your business applications and have choices. They can develop extensions and adapt the best fitting programming language supported by the most valuable API libraries. Or make use of their current available development resources and tools. And develop extensions with own developed libraries on top of these APIs.

Cloud Platform Programming Languages

To help organizations in their needs for custom-build development, cloud vendors also offer a cloud development platform to their customers. These cloud platforms support several runtimes by default. Developers can build their programs in languages, like html5, java, Nodejs, Perl, .net. And in the case of SAP ABAP, UI5, and HanaDB SQLScript.

Some platforms support even multi-target applications, like Cloud Foundry support. Here it is possible to build package applications with multiple languages that can be deployed and executed as it was one standalone application. And they will support containers, like Kubernetes and Docker, where they can use their chosen runtime. By adding additional services and tools, for example, for authentication and authorization management, life cycle management, testing and execution management, and connectivity and API management, these cloud platforms become the ideal platform for custom build development.

Conclusion

Freedom of programming language development will have an impact on how companies should organize their custom build development. As mentioned before, business logic becomes black box APIs. And cloud vendors and their customers can build their own UIs, processes, and automation on top of it, supported by a cloud platform. As a result, development departments can become agile and can adopt requirements and innovations much cheaper and faster.

The freedom of programming languages also means that in a couple of years, an organization runs all kinds of languages. And they should support all these different programming languages, too. As I wrote in my blog, Freedom of business logic and cloud business APIs, the support of vendor and in-house APIs becomes that important, that IT practice should be organized differently and work closely together. In my opinion, an organization should not structure their custom build application development around programming language anymore. IT practices should mix them around user interface and device development on one side and API business logic, data storage, and cloud services development on the other side.

Reorganization of the development organization also means company development guidelines need to be updated. These guidelines can help you to make the right decisions for the required language based on development time, available resources, standardize tools, security management, libraries, and APIs.

Next steps

Our advisors, design thinking coaches, architects, consultants, and trainers of NL for Business are ready to help you to innovate your SAP practice. Since 2001, we primarily focus on custom build innovations on top of SAP solutions and use our EasyRun approach to bring success to your organization. If you have any questions or want more information, please contact us.