Why BOPF is a strategic part of our application architecture

Introduction

As head of development one of my responsibilities is to deliver high class custom applications to our business. It would be best to achieve this without spending money 😉   So I am always looking for ways to get things done more efficient. As new technologies (especially UI technologies) are trending to come along more frequently things are getting more complicated. Our proven way to develop custom applications in the past did not match today’s requirements to be ready for frequent innovations and also to remain cost efficient. So we needed a new approach.

Fundamentals

To be able to integrate new technologies in an easier way there are just a few design principles to observe. These are the separation of concerns and loose coupling. Both design principles will make it easier to replace components with new ones without side effects. Those new components can integrate new technologies.

A common approach is to set up a high level architecture showing the application layers. So that’s what we have done at first.

The layers and components within a layer focus on having a unique application model that delivers data and functionality to several consumers. Consumers can be lightweight portal and mobile user interfaces (SAPUI5) as well as heavyweight transactional user interfaces (Floorplan Manager). Also collaboration through SOAP webservices shall be possible.

The key feature to be able to adapt new ui technologies in an easy way is the dedicated integration layer. This layer works as an adapter transforming data by means of FPM feeder classes and Gateway data provider classes.

So far we have set up a high level architecture for developing applications using the current UI technologies and being able to adapt new UI technologies when they come into play.

Cost Efficiency

As I said before cost efficiency is another key figure to deliver custom applications. At first sight the architecture will tend not to be cost efficient. Implementing three adapters to serve SAPUI5, SOAP and FPM cannot be cost efficient. So what will help us to become more cost efficient.

Our approach was to identify components that are not bringing value to the business and to reduce efforts for these components. To bring value to the business means that it is helping us to cover our company specific needs and to enable us to differentiate from our competitors. So on the other hand if things do not bring value to our business this does not implicate that those things are useless. These things are just more likely to cover general aspects of an IT solution.

The user interfaces are bringing value to the business. The more a user interface is tailored to the specific needs of the business the more savings are achieved with respect to process efficiency. But having two implementations for the user interface will result in higher costs. So we may end up in spending the money we just saved. The key figure is to use functions that enable us to easily tailor user interfaces to our needs.

Having a look at the integration layer ends up in realizing that mapping and converting data is nothing that brings direct value to the business. In this layer we have to place multiple implementations to support our user interfaces. To be cost efficient we have to get rid of multiple implementations as well as individual implementations. But we also have to stay agile to be able to support new technologies.

Within the application layer there is the specific business logic that is bringing direct value to the business. But it also covers many functions like transaction handling, locking a.s.o. that is not bringing direct value to the business.

So we have collected plenty of aspects that are not bringing value to our business. The key to avoid spending plenty of money on implementing these aspects is to reuse existing components. The best solution would be to use proven and solid frameworks that cover those aspects. And that’s were BOPF comes into place.

Target Architecture

Based on the fundamental architecture above we are now integrating BOPF and check if it will help us to focus on business needs.

BOPF will be placed within the application layer. The core framework helps us implementing the business object with its information structure. Without any coding we get a working business objects with all common aspects like transaction handling, locking a.s.o. Further standard functionality like admin data, authorization checks, attachments, texts and change documents can be “plugged in” with reuse components. Our BO specific business requirements can be added by implementing actions, validations and determinations.

Now let’s have a look further on our way towards the user interface. The next layer covers integration aspects. BOPF has further components like the FBI (Floorplan BOPF Integration) and GBI (Gateway BOPF Integration) that let us reduce implementation efforts within the integration layer. For simple scenarios you can consume the business objects directly but in real world you probably will implement and FBI-View. So within the integration layer you will still need to implement some exit classes and do some modeling (like composition of BOs and reducing information for external access).

To be flexible for further technological innovations we rely on further standardization with SADL or getting new standard based integration components like GBI or FBI when necessary.

On the UI layers we focus on the strategic technologies like Floorplan Manager and SAPUI5 with Netweaver Gateway. While the Floorplan Manager and Netweaver Gateway already allow us to easily build transactional (stateful) web applications and REST services we hope that River RDE will be the missing step to efficiently develop SAPUI5 based applications.

Now it’s time for the big picture with the frameworks and components being places in the fundamental architecture.

You may wonder why integration to SAP standard is nearly shaded away. If the SAP standard BOs are also implemented by BOPF everything is fine, but to integrate with other technologies is not as easy as it should be. Maybe SADL will help here too, but SADL relies on BOs being implemented with at least another framework and most of the SAP BOs are free implementations. But to be fair, most of the customer BOs are also free implementations and are not based on frameworks.

Summary

As you can see the usage of BOPF as a framework for creating business objects can help you focus on your business needs and to reduce efforts for implementing standard functionality. In addiction it supports the separation of concerns and helps you establish a clear fundamental architecture.

Like in all strategic pictures things look perfect. In real world you will probably have situations where things don’t fit perfectly. But in the end I am sure there are much more pros than cons.

Another aspect when being in real world is that you usually do not start from scratch and have to integrate into already existing BOs that are developed without frameworks. In another blog post I will describe a way on how to convert existing developments to the BOPF world.