SAP Guideline for Best-Built Applications: One short sentence with huge implications

[Former Member]

Most probably you've noticed the announcement of the SAP guidelines for best-built applications that integrate with SAP Business Suite. If you haven't yet, I highly recommend getting familiar with this initiative and the document that describes how to build applications in harmony with SAP's product stack. You can download it from the "Best-Built Apps" homepage bestbuiltapps.sap.com.

As Richard Probst and Joerg Nalik already outlined in their respective blogs (SAP Guidelines for Best-Built Applications, Insights into SAP Guidelines for Best-Built Applications) this first version of the document is just the beginning. We wanted to roll it out although there is certainly more to say. In this blog, I want to elaborate on what this actually means. As an example, I refer to one of the recommendations you will find in the "Guidelines for Process Orchestration and Service-Oriented Architecture (SOA)" section. For the usage of web services, the guideline states:

SAP recommends implementing remote consumption of business functionality using loosely coupled, asynchronous, stateless communication using web services.

"Wow", you might think. What a statement 🙂
But what if you think about what this sentence actually implies. Have you ever asked yourself, what "loosely coupled" in combination with "asynchronous, stateless communication" means for you? If not, this blog is for you!

I want to start with the term "loosely coupled." How can we measure "loose coupling"? Very often the discussion is reduced to the question of whether an application talks synchronously or asynchronously with its peers. Although this is certainly one aspect, it doesn't cover all relevant dimensions of loose coupling. The goal of loose coupling is to reduce dependencies between systems. Therefore in order to answer definitely, how tightly an application is coupled to other systems, you can be guided by a second simple question: What are the consequences for system A (the calling system) if you make changes in system B (the called system)? Most probably, this question already reveals many dependencies between your application and others that go farther than a classification of the communication style between them. Let me mention just a few more assumptions to make that point more explicit. Which "assumptions" for coupling systems can be made?

1. Location of the called system (its physical address): does your application use direct URLs for accessing systems or is your application decoupled via an abstraction layer that is responsible for maintaining connections between systems? The new service group paradigm being used in SAP NetWeaver CE is a perfect example what such an abstraction might look like. Using an ESB is another one.
2. Number of receivers: does your application take care of the receivers of a service call? Or does it simply drop a message "somewhere" and other mechanisms take care of transporting the message to the receiving systems? Don't underestimate this assumption! If you take the "loosely coupled" approach, it actually means that you are not making any assumptions about the systems you are talking to. This implies a completely different architecture compared to tightly coupled applications. You never know when or if a service call returns due to the number of involved systems and your application must be prepared for that!
3. Availability of systems: does your application require that all the systems that you are connecting to to be up and running all the time? Obviously, this is a very hard requirement especially if you want to connect to external systems that are not under your control. If your answer is "Yes, all the systems must be running all the time," you are obviously tightly coupled in this regard.
4. Data format: does your application reuse data formats as they are provided by the backend systems or are you using a canonical data type system that is independent from the type systems used in the called applications? If you are reusing the data types of the backends, you probably have to struggle with data type conversions in your application. Not a very loosely coupled approach.
5. Response time: does your application require the called systems to respond within a certain (acceptable) timeframe or is it acceptable for your application to receive an answer minutes, hours, or even days later?

You will probably find even more dependencies, but the message should be clear: loose coupling is not one-dimensional. For each of the aforementioned aspects of loose coupling, you have to make decisions. And they are not easy because moving toward loose coupling has serious implications for the architecture of your application. So loose coupling comes at a price, especially in regard to complexity, and you have to decide whether you want to pay the price for it or not.

You want to know the benefits of loose coupling? It's pretty simple: flexibility and agility. If you are aiming for a loosely coupled approach, you will get unparalleled flexibility for adaptations to changing landscapes. Since you aren't making any assumptions about the landscape your application is running against, you can easily adapt it as needed (provided your frameworks and tools support you like SAP NetWeaver Composition Environment does). This is especially important for partners and ISVs who can develop applications once and easily install and configure them at their customers' side. The application itself stays untouched. 

Not only partners and ISVs will benefit from this approach. It is useful within companies as well: once you've established a successful new application, you most likely will want to reuse it within your company in other locations or regions. Very often the IT landscape in the new locations differs from the one the application was originally designed for. If you take the loosely coupled approach right from the beginning, this undertaking will not frighten you. Another aspect you should consider is the probability of landscape changes during the lifetime of your new application. Due to mergers and acquisitions or due to system consolidations, the landscape underneath your application is constantly changing. If you are not prepared for loose coupling, you'll be forced to adapt your application again and again.

So to sum it up: loose coupling means in essence reducing the number of assumptions to a bare minimum, and you should take it very seriously, considering the benefits for doing so!

Let's now turn to the second important aspect of the recommendation: asynchronous communication. For the very first time, we are explicitly recommending an asynchronous communication style, especially for modifying service calls. If you followed this blog so far, it should have become clear to you why this is the case: as we are living in a loosely coupled environment, we never know how many systems are involved, whether the systems are available, or how long it takes to complete certain change operations in the involved backend systems. In addition, all kinds of errors can occur, which have to be handled appropriately. It is (almost) impossible to handle business-critical change operations in such an environment synchronously! I can't stress this enough: you not only have to consider the best case, where everything works perfectly. You have to explicitly consider all kinds of error situations (technical and business errors) and how to react on them. This goes well beyond simple request-response web service calls and has severe implications for your application's architecture. Especially if the services you want to call are only synchronous ones, you have to care about decoupling the calls using asynchronous means. This can be achieved by introducing an Enterprise Service Bus, but that is not the only way to handle it. It is also possible to achieve this solely using SAP NetWeaver Composition Environment. 

There is certainly more to say about architectural consequences for your composite application if you want to go for the loosely coupled, asynchronous approach. Other aspects to consider include topics such as:

• Optimistic locking
• Error handling strategies
• Idempotency
• Identity management aspects
• Usage of patterns
• Eventing
• Transaction handling using compensation
• Extensibility 

I cannot dive into all of the aspects in this blog, but they will certainly be covered in coming additions to the best-built applications guidelines and we'll talk at this year's TechEd about them. If you are interested in details about what a robust, enterprise-ready architecture based on a loosely coupled asynchronous paradigm looks like, I recommend the 2 hour lecture BPM300 "Architecture Guidelines for Composite Applications."

With that, I come to the end of this blog. You probably understand that we are just at the beginning of our voyage regarding the best-built app initiative. The ideas I presented here will certainly make their way into the document in one of the forthcoming versions. In addition to that, maybe now you have an idea of the implications that one little sentence in this document can have.