Part 4: Freedom of business logic and business services

[raeijpe]

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