- SAP AIF and BRF are proposed by SAP to be important integration products.
- We review these two applications.
AIF follows an approach of promoting itself as a product that is visible to business users. This is a commonly presented concept, but something important 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.
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 a nice idea, this must be demonstrated to be true through use of the application rather than accepting the claim, and we will cover further on 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 it AIF for a Business User to Use?
A primary selling point of AIF is that it is straightforward for a business user to use, which leads to greater transparency in the integration solution that is 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 that they created. This is part of the error management that would be a responsibility that would 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 setup so that it will run in a repeated fashion into the future. It is not a term used in among business users.
This screen shows the key fields for the Serialization Object, which is the Material.
In this screen all the errors are published. This way the user can view these errors and then rectify them. This is a common 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 the publication of this paper, 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 IF/THEN type of logic that would 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 the application of PO Approval.
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 normally be used by IT. They have no noticeable features which differentiate them from a purely IT tools. In fact, it appears as if both application standard integration tools.
The proposals around how business users would gravitate to the tools seem to be manufactured from on the part of what customers would like to hear. It is very appealing to believe that a technical tool can be easily used by business users, but 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 is difficult 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 BRF can be used by business users, but then when the topic of using BRF is addressed, the book switches back to being a normal integration book, which would be read by people in IT.
Brightwork’s Prediction of the Business User Adoption of AIF/BRF
- Our prediction is 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 really 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. In all of our clients, we have yet to see a company where business users are involved solely in interface development.
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 simply 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 the 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 specialization between functional and technical resources. If this held true, then all business users could to technical tasks, and all IT resources could do technical tasks. After all, the book proposes that this is possible. The book asks us to not 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 frequent weakness with SAP integration products, 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 the ability of business users 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 be able to 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 the impact of a single interface, even if the goal of creating a complete business uses friendly user interface were to be met. And of course, in our view SAP has come nowhere close to meeting this goal with AIF or BRF.
Business Rules and BRF
If SAP were to read this analysis, they might state that the critique of the product completely misses the point on how BRF can create rules. Throughout the BRF documentation, the emphasis on how rules can be created that enhance the capabilities at 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 are so useable by business users (in marketing literature, in books, in sales presentations, etc..). Yet they have put very little 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 feasibility of the goal, AIF/BRF are not the tools to accomplish this goal.
The Accuracy of Claims About AIF/BRF from 2012
SAP has a number of 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 do 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 was aimed at empowering 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 easily monitor errors and rectify them.” – blogs.sap.com
There are many problems with this quotation, which is now (at the time of this article you are reading being published) 3 month short of 7 years old.
- First, SAP proposed their adoption of SOA (service-oriented architecture, which was 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 inaccurate 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 easily monitor errors 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 is it 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 basic misunderstanding of what makes an integration tool auditable and high in productivity, and this is also obscured by the SAP literature.
For more technical resources, programs can be highly effective, and more auditable than going through 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.
The Problem: A Lack of Fact-Checking of SAP
There are two fundamental problems around SAP. The first is the exaggeration of SAP, which means that companies that purchased SAP end up getting far less than they were promised. The second is that the SAP consulting companies simply repeat whatever SAP says. This means that on virtually all accounts there is no independent entity that can contradict statements by SAP.
Being Part of the Solution: Fact-Checking SAP and Consulting Firms
We can provide feedback from multiple SAP accounts that provide realistic information around SAP products — and this reduces the dependence on biased entities like SAP and all of the large SAP consulting firms that parrot what SAP says. We offer fact-checking services that are entirely research-based and that can stop inaccurate information dead in its tracks. SAP and the consulting firms rely on providing information without any fact-checking entity to contradict the information they provide.
If you need independent advice and fact-checking that is outside of the SAP and SAP consulting system, reach out to us with the messenger to the bottom right of the page.
Financial Bias Disclosure
Neither this article nor any other article on the Brightwork website is paid for by a software vendor, including Oracle, SAP or their competitors. As part of our commitment to publishing independent, unbiased research; no paid media placements, commissions or incentives of any nature are allowed.
Search Our Other SAP Integration Content