To anyone who has worked with SAP software for any amount of time, one of the best parts about it is that it is highly flexible, able to handle business processes of practically any variety. Also, to anyone who has worked with SAP software for any amount of time, one of the worst parts about it is that it is highly flexible, leading to (often too) many choices about how to support business processes of practically any variety.
Now, this inherent contradiction is often a boon to consultants, who never really have to say “no” but rather answer just about every technical question with “it depends.” It what!? Yes, it depends. SAP software covers so much technology, so many versions, so many processes, that implementing any business process depends on what version you are using, what platform you are on, who will be consuming it, what technology you want to use, and so on…
Obviously, this is frustrating and not a sustainable model. Now imagine you are an ISV that develops applications for the SAP ecosystem, or even a customer creating custom developed applications for the SAP platform. What technology should be used? Just knowing that SAP supports a technology or development does tell me the best way to build an application. And navigating through all the available information resources – SDN, SAP Service Marketplace, help documentation, your own personal network, etc. – is time consuming at best and not, or partially, informative at worst. ISVs, partners, and customers rightly assume that we have a technological vision, that we do know the best technological choices for integrating applications into SAP software. It’s just that nasty “it depends” that makes it difficult to find the right answers.
Well, help is now on the way. Over the summer I have helped to contribute to a new publication SAP GUIDELINES FOR BEST-BUILT APPLICATIONS THAT INTEGRATE WITH SAP BUSINESS SUITE. Although primarily directed toward ISVs that build applications that integrate with the Business Suite, anyone working with development of software for the Business Suite can certainly benefit.
The technology guidelines will consider 3 approaches for developing applications:
• “Developed as SAP application” – applications that use SAP design-time tools and SAP run-time in either the ABAP or Java stack (or both)
• “Deployed on SAP” – applications that use non-SAP design-time tools that are migrated to SAP run-time
• “Standalone, integrated with SAP” – applications that use non-SAP design-time tools and non-SAP run-time and connect to SAP
The guidelines are organized into the following topic areas:
• Application life-cycle management, which encompasses the requirements, design, build and test, deployment, operation, and optimization phases as well as support.
• Process orchestration and service-oriented architecture (SOA), which explains topics related to process orchestration, business process management, business rules, and the usage of enterprise services.
• User interface and user experience, which describes how to build user interfaces so that the user experience is as pleasing and productive as possible.
• Data and information, which recommends techniques for storing data, for managing master data, and for providing analytical functionality.
• Application development, which covers topics related to building enterprise-class software, including performance, monitoring, heterogeneous environments, and so forth
• Governance and security, which provides recommendations about technical aspects of security, identity management, and role management as well as aspects of compliance, auditability, and risk management of business application use.
I have been helping to contribute to the third chapter on Application life-cycle management topics. We strive to finish this chapter for publication by the end of this year. Here we discuss our approach that is based upon ITIL (http://www.itil-officialsite.com/). Guidelines are given, for example, for understanding the Product Availability Matrix (http://service.sap.com/pam), architecting high availability into applications, building scalable and high performing applications, integrating with Solution Manager for support, and so on.
For example, for a software developer, understanding how SAP maintains, updates and releases software can be very important: so their software can operate with the current functionality, take advantage of new functionality or to even understand how bugs are corrected. So, for example, in the ALM chapter, we discuss the difference between major releases, enhancement packages, support packages and Note corrections and ways to find more information about the release strategy. All of the topics are treated this way. That is, we try to explain the vision and provide reference material, along with guidelines where appropriate.
This document is a continual work in progress, and we encourage feedback. The first version and further information is available at SAP Guidelines for Best-Built Applications.
