Skip to Content
Business Trends

Part 4: Freedom of business logic and business services

part of blog series
Why cloud business applications will change your custom build application development

Mostly custom build application development in organizations is organized around applications or development skills. But for cloud development, this should be changed. In part 1, I explained why cloud vendors want you and your organizations to think about custom build applications development on a cloud platform. Once migrated to the cloud, an organization should become more agile, can adopt innovations faster, can control project costs by starting small and scale up fast. They will have more freedom to implement own practice to support their digital transformation. I explained the freedom of program language development and how this will influence custom development within organizations in part 2. In part 3, I focused on the impact of freedom of user interface devices and in this part, I will explain the impact of Freedom of business logic and business services.

Separation of UI and Business Logic

As mentioned in my previous blogs, in cloud software the UI logic and business logic should be separated. Business logic is provided as API which will be called by the UI at runtime. For ‘traditional’ business applications this separation isn’t hard to define. For UI logic, you only need to investigate the current UI. All logic influencing the screens or flow is UI logic. And the rest is business logic. But when you should convert this business logic into APIs, this is more difficult. Your application mostly supports a business process that should be divided into a flow of multiple process steps. These steps mostly simulate or store business data in an application needed for analytics and follow up processes. These process steps should be represented as business APIs. Next to these process step APIs, your need supporting APIs to fulfill this process step. Traditional, this supporting API will support lookups, calculations, and validations of business and master data and will help end-user to fulfill the transaction in their user interface.

This process of defining business and supporting APIs is most of the time complex and after this separation, the application is still working the same as before. But it will bring companies and software vendors a lot of advantages, I will explain later. The good news is that most of the work is done by the cloud vendors and you only have to look at your own code.

Open applications for innovations

Cloud vendors will do this separation because it will open these applications for innovations. As mentioned before, you can build multiple role-based and simple UI on top of the process step APIs. But more valuable is the possibility to split the process step into a pre-execution phase where data will be collected, validated and approved and the execution phase where the process step API will be called and stored in the backend application. The execution phase is mostly standardized based on best-practices provided by cloud vendor business applications. But the pre-execution phase within companies is unique. They are implemented as own practice processes supported by manual and unstructured way of working or supported by own developed software.  And most of the time historical and organizational arguments are the reasons that they still work the way they do. This is identified as a spot for improvements. But to automate these pre-execution phase processes, user-centric or fully automated custom build applications are needed.

Cloud platform and third-party vendors identify these company needs and provide besides different runtimes also additional business services. These business services will be provided as APIs to solve a business requirement in the pre-execution phase supported by big data, machine learning and artificial intelligence. This can help companies to simplify their pre-execution phase by enrichments of process data based on initial data, do proposals based on historical and predicted data and automated decisions and approval based on fixed rules or interpretation of the data by patterns. In some cases, the complete pre-execution phase can be taken over by a custom build application without human interaction and running in the background. In this case, the application should be built in such a way that human interaction is only needed for exceptions.

opportunities and threats

The freedom of business logic and business services will cloud vendors give opportunities and threats. Companies should choose best of breed API enabled business applications for the common applications, but also the best fitting cloud platform for their custom build applications.  This will be the biggest challenge for IT developments and customer projects.

In traditional developments, your application is built for one runtime and the program will make use of stable libraries and databases which are deployed together with the application and companies will have full control over the application.

But for cloud applications, this is not the case anymore. The business logic, data storage, and device capabilities are all hidden behind API’s. These APIs will be accessed at runtime and can run anywhere. This makes custom build cloud applications strongly depended on these APIs and the development of applications is more complex.

For future proof and stable cloud applications, these cloud business services and API’s should not only be evaluated on their functionality and value, but also on their usage costs, availability and stability, security, regulation, and data protection. Topics that developers and development organizations are usually not familiar with. The dynamic of cloud applications will bring faster innovations, but in the case of cloud platforms and business services also more dependencies.

Challenges for custom-build applications

There is another challenge for custom-build applications. On which layer should you put your own business logic? On a device UI layer, on a cloud platform application runtime layer or on a cloud platform database layer. And in a hybrid environment, you can also build the business logic on the backend application layer or even in the database layer. A clear answer to this question is: it depends on the requirements and the company guidelines. But for sure the custom build business logic should be made accessible as API on the cloud platform. This doesn’t mean that the business logic itself is built on the platform. It could be on one of the provided runtimes of the cloud platform, but it can also come directly from custom code in on-premise or cloud-based business applications. Or it’s wrapped in an API but comes from the cloud platform and third-party business services.

But sometimes it is even better to keep the business logic as close as possible to the UI or edge device.  You need to keep partial data and business logic close to the UI device when you want to support offline scenarios. And also, when a device generates a lot of data or when latency or security is an issue, you want to do preprocessing business logic on the device.

Changes in development work

For development departments, this will be a big change.  Instead of multiple isolated development streets, they need to integrate them. Companies need guidelines with decisions that help them to determine where they want to develop the business logic and made these development results available for others. This also changes the way developers should work. They have to check if business logic is already available as API within the company and investigate if this API fulfills the requirements. 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 freedom of business logic and business services will for sure be the biggest challenge for organizations but will also be the most crucial valuable driver to be successful in the digital transformation of your company. Together with other key drivers, they will force companies to changes their development processes.

In my blog series, I will also focus on the other key drivers:

  1. Freedom of program language development
  2. Freedom of user interface devices
  3. Impact of digital communities
  4. Freedom of activities
  5. Transforming raw data to business-relevant information
  6. Reuse of traditional business applications
3 Comments
You must be Logged on to comment or reply to a post.
  • I agree with you but from a technical pov, the creepy code called UI annotations in CDS is exact opposite of the decoupling we would like to have in the S4/HANA development.

    SAP is trying to provide too many shortcuts and then expect people to follow the best path. That is stupid thinking. Why so many ways of the same thing

    • ODATA via SEGW
    • Then CDS based ODATA
    • Now another concept in REST based ABAP PaaS
    • Annotations in CDS
    • Annotations in Web IDE  The list goes on…..

    These is making it an hellish experience, SAP must sit and think before committing and creating so many confusing paths they have created whole thing is a mess. Web IDE has WYSIWYG visual editor and all annotations must be through annotation modeler keep the CDS clean IMO.

    The whole UI thing is getting messed or SAP is hiding another shock??

    PSB

     

    • Thanks for sharing your opinion. It is always great to know what people are thinking about topics. And agree that your list looks like it is a mess and SAP should better explain why they make those decisions in their evaluation and innovation of the product. But imo your statement about UI annotations is the opposite of decoupling in S/4HANA is not true. I try to explain this. If you look at CDS annotations in general, they are used during the data design fase to optimise the generation of table artifacts and the use of these artefacts during the operational fase.  For accessing these artefacts through ODATA API it will provides besides the data and the metadata also the context of this data. And this possibility of adding context to an API is unique voor ODATA, which you will not find in SOAP and REST APIs.

      This means that for ODATA the backend developer can also add UI context, but it will be the frontend developer responsibility if he want to use this context or not. For the backend developer it is just providing an API with context, which means that the business logic is decoupled of the UI and can be used by any UI technology and even without an UI in automated processes.

      So the question is why SAP adds UI annotations to the CDS. The answer to this question isn’t that difficult. They developed an Fiori Player which can generate standardised UIs based on the UI annotations and standardise UI Templates. This will reduce the number of UI applications they have to build and maintain dramatically. The lifecycle of UI technology is short and new UI innovations are introducing fast. By reducing the number of UI applications through template applications, SAP will get the possibility to deliver UI innovations faster to new but also existing applications. This is why you can use the same OData services for Fiori Overview pages, Cards and Conversational UI.

      But this will not answer to the question why you can also add and overrule existing OData annotations in the webIDE. But this answer isn’t not hard to answer. As mentioned before, the CDS annotations are defined by the backend developer, mostly from SAP and this fits not always the needs of the frontend developer. Local annotations in the WebIDE is the entry-point for frontend developer, where he can  tweak the template applications for the Fiori Player to the needs of the enduser. But he also can ignore them and build his own UI application. A second purpose of the local annotations in the webIDE, is to use the Fiori Player with none-SAP OData services. Mostly these OData services don’t provide any UI specific annotations and the frontend developer gets the possibility to add them, without asking a backend developer, to build one. Of course it depends on your company rules, if you want to allow this uses of other OData apis.

      Unfortunately not all possible OData annotations are available as CDS annotations in CDS views. And not all OData Service are build directly from an CDS with annotations. This means that SAP provides possibilities to add these annotations by the backend user using the Gateway Builder or by the frontend user using the webIDE. Due the fact that SAP will hide the Gateway Builder in the future, you should only use this option for existing custom build applications with complex logic. If this is not the case I always advise to rebuild this OData service in CDS Views and let the frontend developer add the missing OData annotations.

      For Restful ABAP Programming Model (RAP) we will see in the future. At this moment the model is in development and should be an innovative successor of the current Fiori Model. At this moment due development cycles, not all UI annotations are implemented yet, but the once which are implemented aren’t different from the existing once. As mentioned RAP is still in development and the OData annotations specification changes during time. This means that it is hard to compare frameworks about their possibilities.

      Hopefully this will help you to explain and use the different possibilities of UI annotations in the future.

      • Thanks for the insight 🙂 appreciate your time. I agree with most of the points you have highlighted but I would prefer ABAP to have a default UI as ABAP is SAP’s strategic language why not go the Swift UI kind of thing.

        lets see how RAP unfolds, hopefully SAP does not creates another mess.