Executive Summary

• SAP AIF and BRF are proposed by SAP to be valuable integration products.
• We review these two applications.

Video Introduction: How Realistic are SAP’s Claims Around SAP AIF BRF?

Text Introduction (Skip if You Watched the Video)

SAP AIF or Application Integration Framework follows an approach of promoting itself as a product that is visible to business users. It follows the same marketing as low code environments where it proposes that nontechnical workers can do the work of technical workers. This is a commonly presented concept by not only SAP but other vendors, but something essential to remember is that it often tends to be less feasible than is presented. Integration is complex, and many software vendors in the space compete on describing how integration can be made more simple. You will see our independent evaluation of SAP AIF.

Our References for This Article

If you want to see our references for this article and other related Brightwork articles, see this link.

Notice of Lack of Financial Bias: We have no financial ties to SAP or any other entity mentioned in this article.

• This is published by a research entity, not some lowbrow entity that is part of the SAP ecosystem. 
• Second, no one paid for this article to be written, and it is not pretending to inform you while being rigged to sell you software or consulting services. Unlike nearly every other article you will find from Google on this topic, it has had no input from any company's marketing or sales department. As you are reading this article, consider how rare this is. The vast majority of information on the Internet on SAP is provided by SAP, which is filled with false claims and sleazy consulting companies and SAP consultants who will tell any lie for personal benefit. Furthermore, SAP pays off all IT analysts -- who have the same concern for accuracy as SAP. Not one of these entities will disclose their pro-SAP financial bias to their readers. 

The following quotation is a typical example of such a claim.

“BRF+ allows for rules to be modeled in an intuitive way that gives greater flexibility and visibility to the Business users who are not developers with training in ABAP. It is like giving more technical power to the Business users.”

And while an excellent idea, this must be demonstrated to be true through the use of the application rather than accepting the claim, and we will cover further whether BRF actually does this.

AIF (Application Integration Framework)

What is AIF Fundamentally?

• AIF is a development environment for interfaces that provides a UI, which ostensibly allows the business to perform the integration.
• AIF is presented as capable of managing IDocs, Web services, CIF, qRFC, tRFC, files, batch input, and “more.” Furthermore, SAP proposes that HANA will optimize the integration. This last statement is a problem because databases don’t speed adapters. Therefore it can be disregarded.

SAP proposes that AIF is lower in technical support and that the alert monitoring is automated, and that data quality improves because the business user is validating the information.

How Easy is AIF for a Business User to Use?

A primary selling point of AIF is that it is straightforward for a business user to use, leading to greater transparency in the integration solution created. The concept is presented by SAP is that AIF is so easy to use that users will create or partially created the interface. This would be a highly unusual thing to happen on any IT project, and therefore it is a subject of great interest.

To test this hypothesis promoted by SAP, let us cycle through screenshots of the AIF application.

In this screen, the initial database is created, and its technical configuration is set. This includes everything from the file structure to whether the file should be stored in the database.

Now within the Easy Access menu, the user would go to the File Upload transaction.

Here the user can review the file that is about to be uploaded to SAP.

Here the user is sent a message to their Outlook in the event of a problem with the interface they created. This is part of the error management that would be a responsibility to migrate to the business user.

This is the Interface Monitor screen, where the various interfaces can be reviewed for their progress. Notice the red and green statuses on the various interfaces.

This is where the user can go to serialize an object.

Serialization is where the interface can be set up to run in a repeated fashion into the future. It is not a term used among business users.

This screen shows the key fields for the Serialization Object, which is the Material.

On this screen, all the errors are published. This way, the user can view these errors and then rectify them. This is a typical log screen in SAP. However, this is nearly always used by IT, not by a business user.

This example shows that one of the errors was due to a unit of measure inconsistency. However, by changing the unit of measure, the error would be fixed.

Back at the Interface Monitor, notice that several of the interfaces that were in the red status are now green.

Now that we have reviewed the AIF let us review the BRF.

BRF (Business Rule Framework)

What is BRF Fundamentally?

BRF is ostensibly a business mapping application.

However, how BRF interrelates to AIF is not always clear in the messaging from SAP. SAP has, up to the time of this paper’s publication, provided little explanation for how AIF and BRF differ from one another. But it is not difficult to see how the two products are set apart from one another.

BRF would apply the IF/THEN type of logic to control the data movement and timing as part of the interface.

Interestingly BRF is missing in the following graphic from SAP.

In some slides, the overall integration process appears completed without BRF. Why is BRF not included in this graphic? Are business rules unnecessary in this interface?

AIF is shown as the functional portion of the interface, with SAP PO being the technical portion.

How Easy is the BRF to Use?

BRF is supposed to be even closer to the business user and extremely easy for them to use.

Let us review its likelihood of being used by a user next.

Here an application of PO Approval is being created.

The ruse is named and declared within a new application.

Now the search criteria are set.

Notice that a user would be required to create an expression for a table operation, which will be to create a new table.

The name of the table will be TABMAT.

Now the settings for the table will be created.

And the example finishes with creating a function that will connect to the table, which is part of PO Approval’s application.

Conclusion on User Friendly Claims of AIF and BRF

At Brightwork, we have reviewed interface tools over the years. Our observation is that AIF and BRF appear like applications that would usually be used by IT. They have no noticeable features which differentiate them from purely IT tools. It seems as if both application standard integration tools.

The proposals around how business users would gravitate to the tools seem to be manufactured from what customers would like to hear. It is very appealing to believe that business users can easily use a technical tool, but it is typically not true. And it also does not appear to be true in this case. BRF is a tool that is not differentiated from other tools used by technical users. The distinction only exists in the descriptions of BRF as offered by SAP.

It isn’t easy to see business users reading and comprehending this book on BRF. We were only able to read the portions we tested because of our background working in IT. To get a business user to read and comprehend, this book would take a lengthy process whereby the resource was essentially converted into an IT resource. The book is filled with references to how business users can use BRF, but then when the topic of using BRF is addressed, the book switches back to being an ordinary integration book, which people in IT would read.

Brightwork’s Prediction of the Business User Adoption of AIF/BRF

• We predict that AIF and BRF will have no discernable uptake on the part of business users.
• Secondly, we disagree with the overall presentation by SAP as it appears inconsistent with our experiences in integration. Integration is too complicated of a topic to thrust onto business users. Business users can describe the scenario to an interface developer (hopefully creating a specification), but this nearly always a combination of people with different skills. We have yet to see a company where business users are involved solely in interface development in all of our clients.

AIF/BRF Positioned with An Argument Against Specialization

In the book Leveraging SAP BRFplus in Big Data Scenarios, the authors state the following contrary view.

“In essence, this means ignoring the artificial boundary between (emphasis added) roles of the functional and the technical consultants. Why should only one of them think about the solution from a business perspective? And why should the other use only technological means to implement the solution? Is it not plausible that the ABAP developer can do a better job by having a deeper understanding of the business requirement or the business problem that needs a solution?”

This logic is that there does not need to be a specialization between functional and technical resources. If this held, then all business users could do technical tasks, and all IT resources could do technical tasks. After all, the book proposes that this is possible. The book asks us not to limit people by merely relying upon their domain expertise. The author in this book implies the distinction is artificial. However, in our experience, it is entirely real. Furthermore, but trying to make an integration application that would be usable by a business user, the application would not be designed to be fully leveraged by a person who is a specialist in interface development.

We will address this issue later in the analysis, as it is a common weakness with SAP integration products. It is currently (in our view) a negative trend promoted through products like OutSystems which promote the concept of “low code” (that is, graphical coding environments that lessen the amount of code written). The reason this is negative is that visual programming has not proven to be effective versus normal programming. And a programming tool like OutSystems has a narrow sweet spot, which is primarily UI development. A visual low code environment cannot and will not replace most of the programming languages or standard approaches.

Let us review the hypothetical possibility versus the realized outcomes of the SAP claims regarding business users’ ability to adopt AIF/BRF.

• It is hypothetically possible to make a UI so advanced that the interface development would be more or less intuitive for the business user. Hypothetically possible (that is, we can’t rule it out), but it is unlikely because of the nature of the task that integration environments must perform.
• Interfaces have many implications. These include database implications, as well as implications or independencies with other interfaces. These are interfaces that may be in a separate domain from the business user. A business uses is not well positioned to understand the overall implications of a single interface, even if the goal of creating a complete business uses a friendly user interface were to be met. And of course, in our view, SAP has come nowhere close to achieving this goal with AIF or BRF.

Business Rules and BRF

If SAP were to read this analysis, they might state that the product’s critique completely misses the point on how BRF can create rules. Throughout the BRF documentation, the emphasis on how rules can be created enhances the capabilities of SAP’s customers.

Taken from SAP’s document Business Rule Framework plus (BRFplus). The document almost makes rules out to be something quite new in integration.

However, there is nothing new about “rules.” If this had not been the case, then integrations could not have been performed for all these years. The selling point of BRF is if SAP had created an application that would have simplified the creation of rules.

And in our estimation, it has not.

In this way, SAP is selling a pipe dream to its customers. SAP appears to have put almost all of its effort into explaining why AIF/BRF is so useable by business users (in marketing literature, in books, in sales presentations, etc..). Yet, they have put minimal effort into making the products match these claims.

It may be desirable, although probably not realistic, to have business users performing interface development. But there are also many distinct disadvantages which none of SAP’s documentation in this area explains. The evidence is clear from reviewing the products that, whatever the goal’s feasibility, AIF/BRF are not the tools to accomplish this goal.

The Accuracy of Claims About AIF/BRF from 2012

SAP has several blog postings on AIF and BRF that essentially declare that SAP has met the goal of making a totally business user-friendly integration application.

The following quotation is one such example.

“However, as SAP and organizations moved more towards an SOA centric approach to interface applications and did business with their partners, there seemed to be no genuine tools for business users to correct errors in the system. SAP then introduced Forward Error Handling (FEH) and Error and Conflict Handler (ECH). This aimed to empower end users who had the business and process knowledge but limited technical know-how to correct errors on their end. FEH was based on the concept of Forward Error Recovery

 SAP AIF is a product from SAP’s CDP group (Custom Development Projects) that enables organizations to achieve all this and more. It is essentially a framework that provides a business user (who may or may not be technology savvy) tools to monitor errors easily and rectify them.” – blogs.sap.com[1]

There are many problems with this quotation, which is now (at the time of this article you are reading is published) 3 months short of 7 years old.

• First, SAP proposed their adoption of SOA (service-oriented architecture, a hot topic in the 2006 to 2010 timeframe), but SAP never followed through on this, and SOA died with SAP. SAP would never have supported SOA as it would open up their applications to competition, in effect commoditizing them – even if SOA had been technically feasible. Therefore, this statement by the author is inaccurate. And it was incorrect when it was made back in 2011. This is because the bloom was off the SOA rose even at that point. Secondly, SOA has little to do with AIF/BRF. This falls into an argumentative strategy often used by SAP to propose that “things are changing,” and the proposer will sometimes grasp for something topical, although unrelated.
• Second, the statement is made that the tool “provides a business uses tools to monitor errors easily and rectify them.” However, this looks like anything but the case.
• Third, this article was written almost seven years ago, but AIF/BRF has seen so little adoption that it is not only uncommon for SAP consultants to have heard of the product, but it is a very rarely used product. Why? If the advantages to AIF/BRF as SAP claims, the product should be quite successful in the present day.

Are User Interfaces Always Better than Reviewing Programs for Integration?

With AIF/BRF, SAP proposes that user interfaces for integration are superior to reviewing programs. This is the logic for why AIF/BRF would be effective for the user. However, the first assumption that business users will use AIF/BRF is untrue.

This means (in our estimation) that AIF/BRF would simply become a tool used by IT. However, SAP’s PO (previously named XI and the PI) does not have sufficient interface productivity. Yet SAP PO is a user interface driven integration tool.

This gets to a fundamental misunderstanding of what makes an integration tool auditable and high in productivity, and the SAP literature also obscures this.

For more technical resources, programs can be highly effective and more auditable than a user interface. What seems like a disadvantage to a non-technical user is actually an advantage to someone who can read code.

The following is some sample code written in the R programming language, which sums and bucketizes data.