Database Reference
In-Depth Information
To leverage on their competencies or advantages, companies cannot abandon the corresponding
differentiating processes and will have to incorporate such fundamental variants in their CRM
implementations.
Traditional client/server applications, typically developed using 4GL tools, used to be custom-
ized by changing the source code of the application to customize the screens, business logic, trig-
gers, or even the database schema of the application. This approach led to problems in the ability
to upgrade and support the applications, thereby dramatically inflating the full life-cycle costs of
application maintenance.
Because of the way SAP applications are designed, they are highly configurable and easy to
upgrade. SAP e-Business Applications are
declaratively configured:
:
that is, they are defined as
metadata in the SAP Repository. The customizations are implemented by configuring or setting
properties of business objects using the graphical toolset of SAP Tools rather than traditional pro-
gramming (see Section 5.2.9 “Internationalization and Localization”). Furthermore, because the
customizations are defined in terms of metadata, configurations and integrations can be upgraded
to the next release of software without additional effort. Not only does this obviate the need for
expending additional time and effort, it also provides a smooth upgrade path that accelerates the
deployment of the new version of applications. Overall, this strategy helps to preserve the organi-
zation's investment in custom configurations and integrations.
Competing solutions do not allow for a high level of configurability to tailor the appli-
cation to unique requirements of businesses. Generally, such applications are developed
using a fourth-generation language (4GL) against a relational database management
system (DBMS). The customer's ability to tailor the application revolves around chang-
ing the source code of the application by changing the business logic using the 4GL or the
database schemas. Such changes not only render supporting and upgrading such customized
applications extremely difficult, if not impossible, but they also make them costlier. Compared
to SAP, competing solutions have much higher TCOs. Some packaged applications permit a
certain degree of configuration, like being able to turn on or of various switches or being able
to set parameters that affect the behavior of programs constituting the application. However,
when this is inadequate to meet the needs of the business, the customer is forced to change its
business to suit the needs of the application—this is not BPR! (See Chapter 7.)
5.2.8 Highly Interactive Browser Interface
SAPGUI was the standard GUI of the SAP system. SAPGUI's design logic and element defini-
tions are independent of the presentation system, and hence, the SAP user interfaces have the
same look and feel, irrespective of the presentation software used at any installation. The graphi-
cal systems could be from any platform, including MS Windows, OS/2 Presentation Manager,
OSF/Motif, and Apple Macintosh. SAPGUI includes all the graphical capabilities of modern
Windows interfaces, with menu bars, toolbars, push buttons, radio buttons, online help, value
lists, and so on.
Moreover, because SAP does not transmit fully prepared screen images between R/3 applica-
tion servers and presentation systems, the volume of data transmitted for every screen is very low,
approximately 1-2 kb. This results in minimal network traffic, which is another major contribut-
ing factor toward the overall scalability of the SAP system.
