The purpose of this document, SAP® Guidelines for Best-Built Applications That Integrate with SAP Business Suite, is to offer development recommendations to partners and customers building complementary applications that extend the value of the SAP Business Suite. This will help SAP’s ecosystem partners to create higher-quality software for our mutual customers and will also help SAP customers with developers on staff who build their own (custom) complementary applications. Many of the recommendations are based on guidelines that SAP considers in building its own applications.
When this document was initially published, it stated that independent software vendors (ISVs) were the primary audience for these guidelines---and ISVs are still a very important audience. But the clear feedback from customers with their own staff of SAP developers was that they also needed such guidance, and so ISVs are no longer the sole audience. Both ISVs and customers building their own complementary applications must make significant investment commitments in the software they develop and can benefit from knowing what SAP recommends.
Note that these guidelines explain what to do, not how to do it---and then provide links to the how-to technical documents needed to follow the guidelines.
SAP guidelines for best-built applications that integrate with SAP Business Suite is a set of recommendations to help developers, whether working for ISVs or for customers, build applications that work well with SAP’s on-premise software. By adhering to these guidelines, you can create applications that deliver greater tangible value by reducing the total cost of ownership (including costs for integration, training, administration, and upgrades) while increasing security, usability, scalability, and other factors supporting governance and compliance policies.
Benefits to SAP Customers and Partners
The ultimate beneficiaries of these guidelines will be SAP customers, who enjoy the following benefits from complementary applications (whether from SAP partners or built in-house) that adhere to these SAP guidelines:
- Consistent product experience: SAP is committed to delivering products that work well together to create a consistent product experience---with these guidelines, complementary applications will contribute to (and benefit from) that consistent experience
- Integration: Complementary applications built using these guidelines should result in lower integration costs
- Support: Products that use standard components and work according to well-understood and proven patterns are easier to support. For ISVs, leveraging SAP’s support infrastructure can reduce support costs
- Familiarity: Customers have invested substantial amounts of time in learning to operate SAP solutions---software that deploys and runs like SAP solutions lowers operating and user training costs
- Capability: Faster adoption of new SAP technologies by developers results in more powerful products for SAP customers
Architectural Concepts for Complementing SAP Business Suite
SAP products have always been guided by our vision of providing the best business solutions. Adopting new generations of technology has enabled SAP and its partner ecosystem to meet the evolving business requirements of customers in new ways.
Understanding three key architectural concepts that underlie SAP’s vision and approach to developing the SAP Business Suite can help your company extend the functionality of SAP applications with complementary solutions.
Timeless Software
The first concept is timeless software. Enterprise software solves fundamental business problems, and it must do so over generations of business and technological change. Vishal Sikka, Chief Technology Officer of SAP, has commented on the similarities between urban planning and managing enterprise software. Cities and enterprise systems both have longer lifetimes than the careers of the people who build and manage them. In both cases, valuable assets must be preserved and sometimes renovated, and new development must be thoughtfully integrated. Both have a mix of centralized and decentralized decision-making---in cities, decentralized decisions can be guided by a comprehensive plan and zoning ordinances; in enterprise systems, architectural guidelines and a governance process serve the same purpose.
Sikka believes the architectural principles of timeless software can enable a constant cycle of renovation for business solutions, preserving still-valuable assets while introducing new functionality and new technology.
End-to-End Business Processes
The second concept is end-to-end business processes supported by componentized software. Rather than focusing on separate product categories like enterprise resource planning (ERP), customer relationship management (CRM), product lifecycle management (PLM), supply chain management (SCM), and so forth, end-to-end business processes shift the focus to the value that enterprise software helps provide in such broad “themes” as operational excellence, product leadership, organizational change management, and sustainability. In this approach, applications by themselves become less important, and how applications work together to deliver value becomes more important.
SAP guidelines for best-built applications help developers build applications that complement the end-to-end process support from the SAP Business Suite.
To Learn More
Business Networks
The third concept is SAP’s focus on business networks. SAP customers have processes that require increasingly complex management and integration within their own dynamic network of suppliers, customers, and partners. In a business network, IT systems are necessarily distributed and much more likely to be heterogeneous.
How SAP Guidelines for Best-Built Applications Are Being Published
To be useful, SAP guidelines must cover many topics. They must also be clear to be actionable. Finally, the guidelines must be updated to reflect changes in technology, the IT industry, and the evolution of SAP solutions. This section summarizes key principles for how the guidelines are being published to meet these requirements.
SAP guidelines for best-built applications assume a working knowledge of SAP technologies and partnering with SAP. This document is written for customers and ISVs ready to make key architecture and design choices.
The guidelines explain what to do, not how to do it. As an example, the guidelines may explain that the preferred user interface technology for a certain situation is Web Dynpro. But when it comes to how to use Web Dynpro to implement that user interface, you should look to the SAP Community Network (SCN), the SAP Service Marketplace, SAP Press books, and other resources that explain the details of Web Dynpro and how to use it. Where applicable, this document provides links to such resources.
Think of it this way: SAP guidelines for best-built applications are "the what." SAP Developer Network and other resources are "the how."
The publication of SAP guidelines for best-built applications will be incremental and iterative. The first version of the guidelines, published in October 2009, provided an initial set of recommendations to begin the conversation. This edition and future versions will address new technologies and changes introduced in SAP technologies, platforms, and business solutions.
Because the guidelines are evolving, the authoritative version is located at the “best-built applications” website. You can get a bound copy of this book, print out a PDF, or download the ePub version of the guidelines, but the online version on the website is the canonical version of these guidelines.
The guidelines deal with currently available SAP solutions and technologies. The goal of these guidelines is to help developers make choices about technologies and integration options based on functionality currently available from SAP. Recommendations are based on the latest releases because those releases typify the way SAP is currently building its own solutions and reflect our current technical direction.
It is not appropriate for SAP to use a document like this to communicate about what might or might not happen to a particular technology or about the company’s roadmap. Therefore, if you are considering making decisions based on these guidelines, pay special attention and understand the terms of use included at the beginning of this document. As mentioned previously, the ultimate architecture and implementation decisions are based on many factors; technology considerations are only one aspect.
The guidelines describe what is recommended as well as what is not recommended. SAP software is continually evolving, and SAP and its customers need to move forward incrementally. This reality is reflected in the guidelines. The guidelines use the following terminology:
- SAP recommends: This represents the safe way to do something, and it likely fits into the long-term SAP product direction
- SAP does not encourage: This represents an acceptable way to do something that may be altered in the future
- SAP does not recommend: This represents a technique or product that should be avoided for new development
It is neither possible nor desirable for SAP to attempt to control every development decision made by developers. These guidelines are meant to help you understand how your software can be compatible with SAP’s, best serve SAP customers, and be intuitive for them to use. In some cases, business concerns or other factors may mean that you cannot follow the guidelines. However, following these guidelines is likely to be your best option to minimize disruption and costs moving forward.
Sources for SAP Guidelines for Best-Built Applications
SAP has formally addressed many architecture and design questions in building its solutions. The SAP guidelines for best-built applications draw upon the following sources of information used inside SAP, making relevant content available to our partner ecosystem.
SAP Architecture Guidelines
SAP architecture guidelines are SAP’s internal recommendations for how to build software components; SAP’s own developers use these guidelines. SAP guidelines for best-built applications incorporate selected content from SAP architecture guidelines.
SAP Product Standards
SAP product standards define quality characteristics that are required for SAP products. SAP follows standards for developing its applications in 15 areas (see Table 1-1). SAP guidelines for best-built applications incorporate selected content from SAP product standards.
Table 1-1: SAP Product Standards
| Area | Description |
|---|---|
| Accessibility | Software accessible to persons with disabilities |
| Application integration and interfaces | Integration between applications |
| Business solution configuration | Adaptability to customer-specific business processes |
| Development environments | Use of development environments and programming languages |
| Documentation | Documentation for consultants, developers, and administrators |
| Functional correctness | Elimination of software bugs as much as possible |
| Globalization | Multilingual capability and internationalization |
| Information lifecycle management | Managing the lifecycle of business data, including archiving and retention |
| IT service and application management | Efficient operation at the customer site |
| Multitenancy | Enables the implementation of multiple SAP systems in one system instance |
| Open source | Controlled use of open source software |
| Performance | System performance, scalability, and hardware capacity sizing |
| Security | High level of product security |
| Technical implementation and change management | Simple implementation and upgrades |
| Usability | User friendliness |
Product Availability Matrix
The SAP product availability matrix describes which platforms and specific technologies are supported for each SAP product. The product availability matrix is available in SAP Service Marketplace. Note that advance registration is required for access to SAP Service Marketplace.
The product availability matrix includes some partner products that SAP resells as part of its portfolio. Following SAP guidelines may simplify certifying a solution for resale, but it does not qualify a solution to be listed in the matrix.
Industry Best Practices and Standards
SAP is committed to open standards and follows a wide variety of technology standards and business semantic standards. To a large extent, SAP guidelines for best-built applications are informed by SAP's commitment to industry standards. For example, the guidelines recommend using Business Process Modeling Notation (BPMN), a standard maintained by the Object Management Group (OMG).
To Learn More
Approaches to Development
There are many processes and mechanisms to meet common requirements when creating products for a global customer base that deploys software on heterogeneous platforms. Ultimately, you must decide how closely to align your architecture with SAP’s and how much SAP technology to leverage in your solution. SAP guidelines for best-built applications describe three approaches you can take when developing or deploying software in an SAP environment.
SAP has encapsulated decades of learning into its design and development practices and the tools and technology it makes available to customers and partners. Every software company has to grapple with choosing which databases to support, which operating systems to run on, which languages to use for development, and so forth. In addition, customers such as governments may add requirements for other aspects of software such as accessibility, security, and privacy. And there is always the task of integration.
SAP has developed ways to systematically manage this complexity and to meet many development challenges. Perhaps the simplest way to think of the SAP guidelines for best-built applications is as a guide to using the technology, processes, tips, and tricks that SAP has come up with over the past 30-plus years.
We understand that developers, whether at customers or at partners, will have different starting points when building software that fits into the SAP universe. For example, the degree to which an ISV wants to adhere to SAP guidelines is a business decision. Not every company will want to or be able to follow all SAP guidelines.
With this complexity in mind, we have identified three basic development choices you can make when developing and deploying products to complement SAP, as shown in Table 1-2.
Table 1-2: Approaches to Developing Complementary Applications
| Software designed with SAP tools to run in the SAP environment | Software migrated to run in the SAP environment | Software connected to an SAP solution |
|---|---|---|
| These applications are built using SAP design and development tools, and they are naturally deployed on the SAP technology platform | These applications are developed using non-SAP design tools and are later migrated to run on the SAP technology platform | These applications are developed using non-SAP design tools and run on non-SAP platforms while connecting with SAP Business Suite solutions |
It’s important to note that even in one company, different solutions may follow different approaches. Even a single solution with multiple components can have elements that follow different approaches---one part built with SAP tools, another part loosely connected. Also, these approaches are not “categories” of ISVs or even ISV products. Instead they describe development decisions that are made at the level of individual software components.
A more detailed discussion of each approach follows. Where relevant, SAP guidelines for best-built applications identify the approach to which each guideline applies. If there is no indication, the guideline applies to all three approaches.
Products Developed with SAP Tools for the SAP Environment
From a technical perspective, this approach provides guidance for using SAP design tools and runtime functions to create products that are as similar as possible to SAP Business Suite solutions.
The guidelines answer questions like the following:
- Which user interface framework is recommended?
- How could an application be affected by the switch framework?
- What standard data models should be used?
Applications that are developed with SAP design tools and built for the SAP environment are the closest that a company can come to creating software that is designed, developed, deployed, and operated like an SAP solution. Essentially, they are built like SAP solutions.
Products Migrated to Run in the SAP Environment
From a technical perspective, this approach provides guidance for software components built using non-SAP design tools that are migrated to operate in the SAP runtime environment.
There are two main advantages to migrating an application to run in the SAP environment. First, solutions that operate on the SAP runtime may be able to leverage more operational features and lifecycle management functionality of SAP software. Second, by running an application on the SAP NetWeaver Application Server (SAP NetWeaver AS) component, a customer can reduce the total cost of operation (TCO), and an ISV can reduce the cost of acquisition of their product for SAP customers.
Because SAP NetWeaver supports two development environments --ABAP™ and Java --a product to be deployed on SAP's runtime must be written for one of these environments. Only SAP provides design tools for ABAP, so software products that are migrated to SAP will in practice be applications written in Java.
The guidelines for software migrated to the SAP environment help you answer questions like:
- What version of Java EE does SAP NetWeaver support?
- What mechanisms, like the system landscape directory, must an application running on SAP NetWeaver use?
- How should an application running on SAP NetWeaver interface with the SAP Solution Manager?
Guidelines for products that are migrated to the SAP environment explain which SAP technologies and practices to use to make a product written with non-SAP design tools look and act as much like an SAP solution as possible.
Products That Are Connected to SAP Solutions
From a technical perspective, this type of guidance is for a software component that was not developed using SAP design tools and that does not operate in an SAP runtime environment.
Software that is connected to SAP solutions could be developed on Microsoft .NET, IBM WebSphere, another Java platform, or any number of other application environments such as Ruby, Python, PHP, and so on. In practical terms, the diversity of development platforms means that the product is a discrete collection of business logic that may have various integration points with the SAP Business Suite. The guidelines for software that is connected to SAP solutions answer the following types of questions:
- How can your software use the data and functionality of SAP Business Suite?
- How can your software present its data and functionality for use by SAP solutions?
- What computing platforms, operating systems, and databases should ISVs support to align their products with the SAP customer base?
These are just a few of dozens of questions that you may seek to answer, either as an SAP customer building an in-house solution with optimal return on investment, or as part of an ISV’s business strategy to make a product easier to use for SAP customers.
 | Assessing an ISV’s Commitment to SAP Customers The development approaches described here do not imply that an ISV using one approach is more committed to delivering value to SAP’s customers than other ISVs. An ISV with an application that merely connects to SAP solutions might be very committed to SAP’s vision of end-to-end process orchestration, for example, while another ISV that develops applications using SAP tools might not be quite as committed to that vision. These categories indicate the degree of proximity to the SAP Business Suite and the platforms being used for development and runtime and do not imply that one approach is inherently better or worse than another. However, all else being equal, using SAP design tools should result in the best integration and lowest cost of ownership. |
Guideline Topics
Because so much information is involved and the process of creating software is so complex, SAP guidelines for best-built applications are organized into the following topics:
- *Application development: Covers topics related to general programming guidelines as well as guidelines specific to ABAP, Java, and .NET
- Application lifecycle management: Encompasses the requirements, design, build and test, deployment, operation, and optimization phases as well as support
- *Process orchestration integration: Explains topics related to process orchestration, business process management, business rules, and the usage of integration technologies such as enterprise services, Gateway, and mobility
- User interface and user experience: Describes how to build user interfaces so that the user experience is as pleasing and productive as possible
- Enterprise information management: Describes the following key areas: information governance, data integration and data quality, master data management, event processing, content management, and information lifecycle management
- BI tools: Recommends techniques and tools for making information more accessible and understandable
- Security: Provides recommendations about secure programming, identity management, single sign-on, security zones, security Infrastructure, and transport security
Detailed How-To Information
The guidelines describe what to do, not how to do it. Most guidelines are followed by links to material that explains the technical topics in more detail.
In all cases, SAP documentation is the authoritative source of information about SAP software. These guidelines are designed to help you find your way to that authoritative information.
Changes in This Release
This is version 2.4 of these guidelines. All the chapters have now been updated to address developers at customers as well as at ISVs. Because in some way all of the guidelines relate to application development, we moved the chapter on that topic from Chapter 8 to Chapter 2 to give it pride of place. The previous content of Chapter 2, a summary listing of all of the guidelines, was moved to the Appendix for easy access.
The focus of revisions in this edition was on Chapter 6, which was substantially revised and expanded to provide updated guidance about SAP's enterprise information management (EIM) strategy.
The previous edition (version 2.3) included a preview of chapters 10 and 11, on SAP NetWeaver Gateway and mobility respectively. Since these topics are part of a larger discussion on integration and process orchestration, these preview chapters have been appended to Chapter 4. That chapter is slated for a major revision in version 2.5, which will include additional coverage of SAP NetWeaver Gateway and mobility.
See http://bestbuiltapps.sap.com for updates to this book.
