Our digitial innovation methodology supports building your digital transformation making use of new innovative technologies.

A lot of companies are struggling with their digital transformation strategy. They see all these new innovative technologies, but don’t know where to start. To overcome this challenge, we, from NL for Business, developed a Digital Innovation Methodology based on our 20 years of development experiences. The methodology exists of 6 steps:.

Step 1: Transfer your business model into a digital business model

Most companies use a Business Model Canvas (BMC) to understand their business model in a straightforward, structured way. Using this canvas will lead to insights about the customers you serve, what value propositions are offered through what channels, and how your company makes money. And companies used the canvas to compare their business model with their competitors. But these Business Models don’t look at the influences, possibilities, and threads of digitalization. For this reason, we extend the business model canvas with digital aspects like cloud, internet of things, communities, and artificial intelligence. This digital BMC helps C-level to understand the impact of the digital revolution.

Step 2: Identify the digitalization hotspots

The digital business model helps us to identify with areas we have to look at first. Depending on these areas and the chosen digital transformation strategy, we will look to the underlying business processes to identify the digitalization hotspots with our own developed ICASIO model. We will look at supporting activities, their stakeholders, and outcomes. As a result, we will find hotspots that bring the most value from digitalization.

Step 3: Identify the digital data requirements

Once we know the hotspots, we look at the activities from different angles. We plot insights to our Information model from a process-centric, a user-centric, an application-centric, and a strategy centric view. Together with the ICASIO model, we know which data is needed from a manual perspective and an automated digital perspective.

Step 4: Identify the needed intelligent technology

By combining data from business systems, publicly available big data, social media data, and data collected by sensors, intelligent technology can help us to create and access data in our business context. Together with our ICASIO and Information model, we can now identify which intelligent technology and data sources can help us to digitalize our activities.

Step 5: Design your digital solution

In this step, we will make together with you the decision, which activities you will support with best-practices standard (cloud) software. And which applications you will develop yourself. These so-called own-practices will differentiate you from your competitors because they cannot buy it. And with the cloud, you use a hybrid approach. You can design your own-practice applications that make use of best-practice APIs. And you know which best-practice applications are needed. You are now able to create a roadmap to support your digital transformation. It will give you insights, which applications you should make accessible through RPA, must upgrade, get new features, can move to the cloud, and which apps you need to develop.

Step 6: Implement the solutions

The roadmap helps companies also to create a backlog with priorities for your implementations. It will help product owners and development teams to work agile. And they can make the right decisions during their sprints for both cases, during implementing or migrating best-practices standard (cloud) software and for the development of own-practice applications.

Conclusion

Our Digital Innovation Methodology guides companies in their digital transformation and facilitates all stakeholders from management to business to IT. The methodology identifies the most valuable hotspots and gives insights into the most valuable intelligence technologies for your company. As an outcome, you will get a roadmap for your digital transformation which gives you insights into your needs. These needs can be best-practice applications from vendors, emerging intelligent technology, external APIs, and own developed apps. The roadmap also will help during the implementations by providing the backlog and priorities for the sprints.

Next steps

If you want to know more about our Digital Innovation Methodology, please contact us. Our advisors, design thinking coaches, architects, consultants, and trainers of NL for Business are ready to help you.

Low Code / No Code platforms are hot these days! We know why and how this can be improved.

Low Code / No Code (LCNC) platforms are seen as the solution for the Business that can develop applications by people without IT background, the so-called citizen developer.

The citizen developer

The idea is that the use of this new group of developers will help to spare the IT department. In this way, the necessary business processes can be supported more quickly and intuitively by applications. Partly because you easily design the user experience as you see fit and click the required data and (process) steps according to exactly your own needs. This the business has been used to do for years with their own designed paper forms and Excel spreadsheet. Only now with a new platform. This approach works until the data from these apps has to form an integral whole with the rest of the organization. Then it turns out that it is useful to capture all the data in a joint system. And this is where the IT department comes in, because they maintain and manage these central IT systems.

Integration is key

The success of the Low Code / No Code (LCNC) platforms infinite possibilities is, in the (medium) long term, highly dependent on the convenience or simplicity of integration with their environment.

It often contains the weakness of such LCNC platforms. Solitary they work fine and are great to achieve results. But somewhere in the supported process, there is a need to retrieve additional information or to share the information gathered.

In order to deal with this problem, it is necessary to establish a connection between the flexibility of the LCNC platform on the one hand and the central administrative basis IT systems on the other. This connection can be facilitated by agreeing on how these systems communicate with each other. Here, an IT architecture based on a Corporate Data Model and Application Programming Interface (API) can help. A corporate data model is necessary to bridge the gap between business and IT to describe the data and information. And an API to record the communication between them. In this way, we record what data we are talking about and what is needed to share information with each other. For applications that do not yet offer these possibilities, alternatively Robotic Process Automation (RPA) is made available. It allows the required manual operations to be automated and made available as an API.

A lot of software vendors are focussing on this integration these days. For the Mendix platform, a product that SAP has on its price list, one of the major announcements during the Mendix World in September 2020, was the developments around its own data hub. The press release “Revolutionary Mendix Data Hub Democratizes Data Integration” clarifies that this is the tooling that Mendix users have been waiting for.

SAP and Low Code / No Code

SAP also develops its own Low Code / No Code portfolio. During the last SAP Teched, December 2020, this was announced in the press release “SAP Empowers Developers with Low-Code/No-Code Tools and Further Enhancements to SAP Business Technology Platform“. In this announcement, SAP indicates that different tools are provided for the different types of developers. In this way, many kinds of scenarios can be supported. SAP Cloud Platform Workflow Management for developers and business experts to work together to shape end-to-end processes. RPA of SAP can be used by developers to automate repetitive manual operations.

SAP Ruum is the newest addition to this family. With SAP Ruum, business experts with no programming experience can click business processes together. In the use cases about this, you can see that you will tackle and improve a whole process within a few hours. That does not include integration. The condition is that this must already be present. To this end, SAP provides its own API hub on the SAP Cloud Platform, and Odata plays a vital role in enabling integration. If that is not sufficient, then the RPA of SAP can always be resorted to.

SAP, API & OData

By choosing OData, SAP chooses a solid API description and indicates the context within which this API can be used. Like Microsoft, SAP is in the process of laying a uniform data model, called SAP Graph, across its entire portfolio, which can be accessed via a uniform API layer. It is the way SAP shapes the integration between its LCNC environment and the other SAP applications.

In addition to the mentioned options of SAP there are many other LCNC platforms. With most, you can start quickly to set up a process or application and make it work. However, we always get to the point where integration with the rest of the world becomes essential, and then often, the problems and the associated costs start.

A flawless collaboration between the IT department that makes the API of the systems available and the citizen developer within the business units for the rapid development of agile business applications, is crucial. It can be done without having any hassle, but this requires a sound strategy. The organizations that recognize this strategy and address their business processes this way are able to develop better applications faster, ultimately letting the entire company benefit.

NL for Business the integration experts

NL for Business has been active in the field of SAP integration issues for 20 years and has extensive experience in advising and applying company-specific solutions. Therefore we are the ideal partner to support you in your Low Code/No Code strategy. We guide your organization in the choice, introduction, and successful implementation of your Low Code/No Code platform and the associated IT architecture, Corporate Data Model, and required integration.

Our lessons learned developing an Enterprise-Ready application with CAP and Fiori Tools in the Business Application Studio

Nowadays, SAP delivers a lot of possibilities to build a future proof SAP application. SAP bets for its development on two new programming models: at the ABAP Restful Application Programming (RAP) model and at the Cloud Application Programming (CAP) model. Both models are promising, and we think they both have their strengths and weaknesses. How can we find these strengths and weaknesses better than implementing a real application? So, we did, and we share our experience and lessons learned with you in our blog series under the umbrella: Our lessons learned developing an Enterprise-Ready application with CAP and Fiori Tools in the Business Application Studio.
This first blog compares the RAP and CAP model and explains why we choose to rebuild our Microsoft Time Sheet for consultancy application with CAP and Fiori Tools in the Business Application Studio.

This blog compares the RAP and CAP model and explains why we choose to rebuild our Microsoft Time Sheet for consultancy application with CAP and Fiori Tools in the Business Application Studio.

The UI layer of CAP and RAP

 

When we looked at RAP and CAP, we saw that both programming models deliver an API layer without a productive UI layer. The currently supported API flavors are pure REST-based JSON services or OData Services versions 2 (standard RAP) and version 4 (standard CAP). Both models have the option to deliver OData Annotated services.  A Fiori Elements player can generate a Fiori Application from these OData annotations, which can be used by the developer to check developments and as a starting point for your UI. Still, productive UI applications should be developed independently. Both models can use any UI technology, including Fiori Elements, SAPUI5, OpenUI5, Fiori for iOS, Fiori for Android, React, Angular, VUE, and HTML5 web components. All the mentioned UI technologies have their strengths, and it is up to your organization to choose the one which fits the best.

We decided to build our application using Fiori Elements with UI5 custom extensions close to SAP technology. As part of the SAP Cloud Portal and in a Fiori Cloud Launchpad, we need to run the application standalone.  We selected the SAP Cloud Platform multi-cloud environment as our Cloud Platform, and we want to profit from SAP key-integration points using the SAP Cloud SDK. We didn’t choose Fiori for iOS and Fiori for Android because both UI technologies will restrict our applications to specific native device types. With React, Angular, and VUE, we miss some needed Business UI Controls and out-of-the-box integration with the service layer. A decision for one of those three will cost us a lot of additional effort for Look and Feel and to connect the UI layer to the service layer. We want to spend this effort in building the application.

Supported Databases of CAP and RAP

Now we decided on the UI technology; we next needed to decide about the programming model. As mentioned, they both have their strengths and weaknesses and are relatively new but built on proven technologies. RAP uses SAP Netweaver ABAP stack, also known as Steampunk, as the underlying runtime. And CAP runs on top of Node.js or Java server. Both models are optimized for an SAP HANA DB as their database layer, and for RAP, this is the only supported database. CAP also runs on SQLite during development, and there is a community contribution for PostgreSQL.

Strength of RAP

RAP is the preferred model for ’ABAP in the Cloud’ and S/4HANA environments. RAP’s strength is its ABAP CDS layer, which is much major than the CAP CDS layer. The ABAP programming language will use, when possible, the native database capabilities behind the scenes and run the data handling on database level. With the so-called code pushdown at runtime, we will get the maximum power out of the database, without losing the strengths of the ABAP language. With the custom entities concept, RAP handles external API as CDS content. The planned development for providing the RAP services as RFC function modules, next to OData and Rest, makes backward compatible integration with traditional SAP Business Suite applications like ECC possible without complexity.

Other key features of RAP are their data dictionary for data artifacts, their transport layer, and, in the case of RAP on S/4HANA (Cloud and On-Premise), their direct access to SAP S/4HANA Business Content. Together, RAP will provide a robust environment to build an application that handles big data sets, needs analytic and transactional capabilities, and the power of the underlying database.

RAP’s downside is the overkill of resources needed to run the environment and results in a high price tag for most applications. And a lack of available ABAP functionality due to restrictions is, in our opinion, a weakness at this moment. SAP re-evaluates the complete ABAP environment, including statements, data dictionary content, core data services, function modules (including BAPI, RFC, ALE, and IDOC), classes, and tools. Commonly used ABAP features are already obsolete in RAP. Workflow, reports, transactions, BSP, and (web)Dynpros and not available anymore. Only released content, released API’s and validated tools are available for the developer, the eclipse-based development environment ADT must be used. Also, the ABAP toolset and statements for handling cloud services and external APIs are not mature. It is very time-consuming to configure the system to call external services and make their services available. But these current weaknesses will be a strength in a short time from now. A clean ABAP environment will promote the ABAP stack to a modern and future proof environment without the past ballast. And SAP can make steps fast because the ABAP assets are already there, and they only have to pass the evaluation process.

Strength of CAP

When we compare CAP with RAP, we see that CAP is the opposite of RAP in most cases. The programming language of RAP is the proprietary SAP language ABAP and runs on a proprietary NetWeaver ABAP stack called Steampunk. CAP applications are written in the open-source languages like Java and Javascript/TypeScript and run on open-source runtimes like JVM or Node.js. The decision to use open source languages and runtimes for CAP brings the environment a lot of advantages. Besides the strength of the language, package managers like NPM for Node.js and POM for JAVA will speed up developments, improves the quality of code by best-practices, and removes restrictions for accessing the functionality of other systems. You can add almost any function using code library from vendors and the open-source community to your project, and this is why these languages and runtimes are so popular on Cloud Platforms. That brought us to a crucial question; Which values add CAP to existing Java and Node.js frameworks? Why should we run our application on SAP Cloud Platform instead of using the Node.js or Java runtimes of the hyperscalers like Google, Amazon, and Microsoft?

But CAP adds an essential feature. Like ABAP did in the past by providing a unified SQL layer with Open SQL on top of the different databases, CAP brings a uniform SQL layer on top open-source languages and cloud-based data sources. So not only data from databases but any data sources, including these from libraries functions and external APIs, can be handled in the same way. In our perspective, CAP becomes, in some ways, the successor of RAP.  We believe this even more after Thomas Jung mentioned in the CAP introduction video of the Devtoberfest 2020 that CAP would get all the best practice concepts we known from the ABAP world.

And CAP will bring even more value when using its SAP Cloud SDK capabilities and run it on the SAP Cloud Platform. With the SAP Cloud SDK, most APIs of SAP business solutions and best practice development experiences are directly available in CAP. And when deploying the CAP application on the SAP Cloud Platform, the SAP Cloud SDK gives CAP also access to the complete feature set of the Cloud Platform.  It will simplify the connectivity, authorization, and identification of other SAP solutions using the SAP Cloud Platform Destinations. The SAP Cloud SDK will provide hundreds of library functions, which will make the use of cloud platform services and capabilities much more straightforward.

Another excellent value of CAP is its accessibility to the databases natively. Natively access means that with CAP on the HANA DB, we get full access to database capabilities and artifacts using SQL Script. In RAP, direct access to the HANA DB artifacts is not possible. Through CDS Table Functions and ABAP Managed Database Procedures, read-only tables in the same schema as the ABAP environment are possible.

But the most significant advantage of CAP compare to RAP is its needed runtime. The package manager collects only those libraries the CAP application needs without installing resources the application doesn’t need. The easy integration of API libraries of external vendors prevents us from writing our logic by ourselves. And the multi-target application (MTA) capability of the SAP Cloud Platform makes it possible to write the CAP application in the best fitting programming language and consistently use cloud platform services and external services. Configurations, data access, business logic, service enablement, and UI logic can be written in different programming languages but packed as one deployment package. Using MTA will guarantee the consistency of the application when deployed to the runtime. All these CAP features make the application real lean and mean. It doesn’t need an overkill of resources like RAP. With CAP, we only need to buy and run the SAP Cloud Platform resources we need, which lower the initial cost barrier for starting the project. But the choice of RAP or CAP not only depends on the initial cost. TCO is influenced by multiple factors. Running multiple applications, the availability of specific features you don’t need to develop, the knowledge within your company, your support organization are some of these factors.

Our decision and motivation for CAP

The price tag was our most prominent driver to choose for CAP over RAP for our business case. But we probably also decided on the CAP model based on the compared feature set of RAP and CAP. Our solution is independent of S/4HANA, will not handle massive datasets, and need limited analytic capabilities. It should combine application database data with external API data sources from third-party applications from Google Cloud and Microsoft Azure, and Office 365 Cloud. And based on these requirements, we think CAP fits better for our application than RAP.

Now we know the model, we need to decide which IDE we will use to build our Enterprise-Ready application. In my next blog, I will compare the different IDE for CAP and explain why we choose the Business Application studio.

Wie vandaag een website bezoekt wordt al snel bestookt met chatbots die hun diensten aanbieden. Soms tot vervelens toe. De vraag die zich nu aandient is of we een chatbot in een business omgeving zinvol in kunnen zetten? En als dat kan, hoe doen we dat dan? Hoe ziet uw SAP gebruikersinteractie er uit anno 2021.

Een chatbot is uitermate geschikt voor het beantwoorden van eenvoudige vragen en vragen die herhaaldelijk worden gesteld. Bijvoorbeeld bij een Shared Service Center of een Backoffice achtige afdeling. Veel interne of externe klanten bedienen betekent vragen krijgen die vaak hetzelfde antwoord krijgen. Dit vraag en antwoordspel is ideaal om door een chatbot te worden opgepakt. Het voordeel voor iedereen is dat de chatbot 7/24 beschikbaar is en dus altijd antwoord kan geven, niet ziek wordt en eindeloos blijft doorgaan. Het voordeel voor de medewerker van de betreffende afdeling is dat de aandacht kan worden gericht op de vragen waar niet zo makkelijk antwoord op kan worden gegeven. Waar wat uitzoekwerk aan ten grondslag ligt. Omdat deze medewerker die standaardvragen niet meer hoeft te beantwoorden is er meer tijd om de complexe vragen te kunnen behandelen.

Denk nu bij herhalende of eenvoudige vragen niet alleen aan een FAQ maar ook aan vragen over de status van een order of een factuur. Of het aantal verlofdagen dat nog kan worden opgenomen. Om deze vragen te beantwoorden is interactie met een achterliggend systeem nodig. Met de huidige stand van de techniek is dat geen enkel probleem.

Interesse wat dit voor uw organisatie kan betekenen. Om de mogelijkheden te onderzoeken of tot een eerste proof-of-concept te komen bieden wij een specifieke chatbot Design Thinking workshop aan om met elkaar te kijken wat er wel en niet kan.

Neem gerust contact met ons zodat we een gesprek over het inzetten van chatbot. Dit gesprek kunnen online of op locatie laten plaatsvinden. Stuur een mail naar: info@nl4b.nl

[

Most companies organize their in-house IT department for developments in separate units. Mostly around applications or specific development skills. With the move to the cloud, this separation will not work anymore. The cloud allows organizations to become more agile and adopt innovations faster. And they can control their project costs by starting small and scale up quickly. With the cloud, organizations will have more freedom and opportunities to implement their own-practices to support their digital transformation. In this blog, I focus on the freedom of user interface devices and how this has an impact on IT development.

Traditional Business Applications

In ‘traditional’ business applications, business logic, and user interfaces (UI) logic are written in the same code line. And mostly only available for one specific device type. These restrictions mean that these business applications are not agile enough. It prevents organizations from adopting innovations fast. And the personalization and simplification of the UI are difficult.

Multiple Device Types

Nowadays, to fulfill a business process, organizations need user interfaces for different types of devices without changing the business logic behind. Employees and business partners like to use the desktop, laptop, tablet, phone of their own. But also wearables like watches, glasses and clothing, IoT edge computing devices, and home automation needs to integrate into business processes.

In business applications, with a cloud mindset, decoupling the UI code line from business logic is the standard. Cloud vendors provide business logic as an API. And they build multiple role-based and simplified UIs on top of the same business logic. This approach gives software vendors the possibility to adopt modern user interface techniques without rewriting the business logic. And when the vendor UI does not fit the customer’s requirements, customers can build their own UI.

Decoupling the UI code line from business logic makes it also possible to simplify the UI by adapting device-specific UI features to collect information by using sensors automatically. And by using sensor data as input of cloud business services, the user interfaces can be simplified even more.

In the beginning, cloud business services facilitate simple lookups. But these services become smarter during the time using machine learning and artificial intelligence. And then, the output of these intelligent business services can advise the end-user with proposed prefilled values. And over time, when trusted, the user interface shows read-only values only. Or hide the fields in the user interface. When all requested input can be determined automatically, the process can execute in the background without user interaction.

3rd generation web application

To support many different device types, cloud vendors choose 3rd generation web application like HTML5, to support their UI. HTML5 is an ongoing specification using open standards and implemented by all modern browsers. When an application starts, the browser loads only one web page, which dynamically changes during runtime. The behavior and presence are based on templates, data, scripting, stylesheets, and assets. The browser will collect all the pieces necessary for the current screen and will request the server for additional parts when the end-user navigates through the application.

In time, the development of HTML5 applications becomes more complicated due to multiple involving technologies and standards. This opens the market for HTML5 frameworks to speed up and simplify the development of cloud business applications. For example, SAP UI5 & Open UI5, Google Angular, Facebook React, and Vue are some of the most known HTML5 frameworks. And HTML5 frameworks become the defacto UI standard for the cloud applications for 3rd generation web applications. But this UI standard will not fit all use cases.

Hybrid Applications

As mentioned before, organizations and cloud vendors simplify the user interface for the end-user using device-specific features, which most of them are only accessible natively. And this conflicts with the device-independency of the 3rd generation web application.

One solution is running the HTML5 application inside a so-called hybrid container. The hybrid container is installed as a native application on the device. For the HTML5 code, this container acts like a browser with native device capabilities. During runtime, the HTML5 app recognizes the hybrid container and calls device-specific features using a generic API to collect the data and hide some fields on the screen. These features can even influence the screen flow. The hybrid container recognizes the generic API calls and bridges them to the native device-specific APIs.

The strength of this solution is the device-independent development of the HTML5 application. Vendors and own IT departments only should provide a hybrid container application for every device they want to support.

Native Applications

But for security reasons, lack of openness of the device, or missing features in the hybrid container, hybrid applications will not be the solution. This can also be the case when the latency of screen interaction or the network becomes very important. And in cases where the device types don’t have a browser or hybrid container at all, like wearables.

In all these cases, you need to build your application natively in the supported programming languages, with available libraries, and capabilities of this specific device. But this comes with a price. The app must be built multiple times to support different device types.

Conclusion

The freedom of user interface devices changed the way of UI development completely. Some companies changed their device management to a bring-your-own-device (BYOD) policy. This policy is only manageable for generic HTML5 supported devices and applications. For innovative HTML5 applications and hybrid or native frontends, it’s better to have guidance that describes which browsers and devices will be supported. Additional guidelines should describe when IT departments built an application as an HTML5 application running in a browser or as a hybrid application or as a native application.

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 organisation. If you have any questions of want more information, please contact us. 

Software vendors want organizations to move their developments to cloud platforms. The vendors promised that once organizations migrate to the cloud, they should become more agile, can adopt innovations faster, and can control project costs by starting small and scale up quickly.

Organizations can support their processes with best-in-class cloud applications from different vendors and will have more options to implement their own-practice during their digital transformation journey. The developers can use the best-fitting program language. And End-users can use the device which fits the best to fulfill their work.

To achieve all these promises, software vendors had to restructure their software. As also mentioned in my blog Freedom of User Interfaces, software vendors should ideally separate their UI logic and business logic and provides this logic as cloud business APIs. In this blog, I focus on the value of cloud business APIs for software vendors and its customers and why these APIs play an essential role in the digital transformation.

Why do software vendors shift to the cloud?

For newly designed applications, the separation of UI and business logic isn’t hard to implement. But for existing software, this isn’t that easy. Splitting the UI from the business logic and provide this logic as APIs is a lot of work and expensive too. And after the separation, the supporting software is still working the same as before. So, you can ask yourself the question:

‘What is the reason that traditional software vendors shift to the cloud and why do they invest in splitting the UI logic and business logic.’

Of course, software vendors can run their applications as a hosted service on a cloud platform. But this will not bring any significant value. It will bring even the opposite. Besides the responsibility of the code line, they now also become responsible for the execution and support. However, if they don’t shift to the cloud, they can become obsolete and will be replaced by the new cloud vendors.

So for traditional software vendors, the only way to survive is by going to the cloud. And in a worse case, they need to compete against pure cloud vendors that design their solutions from the ground with a cloud mindset. A competition that traditional software vendors only will win with a web-based UI and business logic accessible through a rich feature set of business APIs. So splitting the UI and business logic is crucial for surviving. This splitting is expensive and time-consuming but will also bring significant additional value: it opens their applications for innovations and flexibility.

Value of cloud business APIs

Vendors can test business logic, provided as multiple black-box business APIs, separately to improve the quality of their software. They can call the API from any code line in any language that will speed up developments. They can reuse their own logic or use APIs of their partners. And the vendor can improve the code behind the API without impact for the user. The loosely coupled UI from the business logic gives software vendors the possibility to adapt to new UI technologies faster.

The cloud route of traditional software vendors is also good news for the organizations which use their applications. Next to the vendor UIs, organizations can build multiple role-based and straightforward best-fitting UIs on top of the business APIs. This way, the operational costs can be lower due to lower training costs, reduced errors, and speed up processes.

This low hanging fruit gives organizations already the possibility to get value by shifting to cloud applications.

Digital revolution strategies

But more valuable is the possibility to innovate the pre-execution phase. The phase where data will be collected, validated and approved. And it comes before the execution phase, where the business API will be called and stores the data in the backend application.

Within organizations, the execution phase is mostly already standardized based on best-practices business applications. But the pre-execution stage is unique within organizations and differentiates the same type of companies. It creates the differentiation of the organization in the market. The way of working is primarily implemented as own-practice processes supported by manual and unstructured work or supported by own developed software. And most of the time, historical and organizational arguments are the reasons why they still work the way they do.

I believe the digital revolution strategies of companies should mainly focus on these pre-execution processes. Quick innovations are possible by replacing or reducing manual effort by automation. But, organizations have to develop solutions by themselves because of the different ways organizations are running their procedures.

Hyperscaler cloud platform vendors

Hyperscaler cloud platform vendors like Amazon AWS, Google Cloud, Alibaba Cloud, and Microsoft Azure and business software vendors like SAP, identify these needs. These cloud vendors provide flexible platforms with additional business services supported by big data, machine learning, and artificial intelligence. These business services are available as APIs. And help companies to solve business requirements by simplifying and digitalize the pre-execution phase. Custom-build applications use business services to enrich the initial data based on related process data. They do proposals based on historical and predicted data. And make automated decisions and approvals based on fixed rules or learned patterns. In some cases, the custom-build code takes over the complete pre-execution phase as a background job without human interaction. In this case, the application only needs human actions when an exception occurs.

Opportunities and threats

The shift to cloud applications and business services also creates a new dimension for supporting business processes with IT. Companies will choose best-of-breed API-enabled business applications to standardize their work processes and achieve operational excellence. But also want a flexible and agile cloud platform to build fast, innovative custom-build applications based on open standards and without boundaries. This change is a big challenge for IT development, running implementation projects.

In traditional business software developments, the developer built an isolated application for one runtime. The program also uses stable libraries and databases which are deployed together. It gives companies full control over the application and the running hardware.
But for cloud applications, this is not the case anymore. The business logic, data storage, and device capabilities are hidden behind black-box APIs and can run anywhere.

This shift is good news. In-house developers are not restricted to propriety libraries anymore but can use any API written in any language and running on any runtimes. Organizations don’t have to invest in and wait for hardware but can start within minutes. They can grow with their needs, and only have to pay for the resources they use. And they don’t have to maintain and support the business logic behind the APIs,

On the other side, for in-house developed applications, the playground also will change. These custom-build applications will strongly depend on these cloud business APIs. Developers should evaluate not only the functionality and added value, but also their usage costs, availability and stability, security, regulation, and data protection. And traditional developers and development organizations are usually not familiar with these topics.

Challenges for custom-build applications

For development departments, this will be a significant change. Instead of multiple isolated development streets, they need to integrate them. Companies need guidelines and decision flows that help them to determine which business logic they want to build on their own and made them available for others. This change also the way developers should work. They first have to check if business logic, including required needs, is already available as API within the company. If this is the case, they should know the consequences of the usage of this API. If this is not the case, they need guidelines on how to proceed.

In traditional software development, libraries can be easily embedded in their program and are often for free. But the use of API’s on a cloud platform comes with cost and dependency. You should be sure that the API will be highly available for the lifetime of your applications, and if this cannot be guaranteed, you need to have a failback approach.

Conclusion

The dynamic of cloud applications and business APIs will be a big challenge for IT organizations and their developers. It will bring operational excellence and faster innovations but also higher risk and more complexity. Still, organizations will shift to cloud applications because it is one of the most valuable key drivers to be successful in their digital transformation.

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.