SAP AG (pronounced ess-aye-pea aye-gee) is based in Walldorf, Germany and is the world's largest enterprise software company. SAP's foundation is built upon the concepts of specialization and integration. That is, each component or product within the SAP family of products and services meets a particular need, like providing web-based access to other SAP systems, addressing product lifecycle planning requirements (SAP PLM), supporting internal company procurement (SAP Enterprise Buyer), interconnecting different systems to ease integration headaches (SAP Exchange Infrastructure), and so on. Many of these components are explained in subsequent hours; suffice it to say here that there are many components, many products, and therefore many potential SAP solutions.

Each product can typically be broken down further into modulesportions of functionality that are more discrete in nature, geared toward addressing a particular piece of the overall component pie. For instance, SAP R/3 and its successor, SAP ERP Central Component (ECC), are comprised of modules like Financials, Sales & Distribution, Materials Management, Warehouse Management, and so on. Individually, each of these modules effectively serves to manage a business area or functional area for which a particular company department often is responsible.

Looking at it from another perspective, individual SAP modules combine to form an SAP component, application, or product. Within a particular module or component, a company's business processes are configured. SAP is well known for reflecting industry's best practices for the different business processes that it supports. By adopting proven best practices, companies grow more efficient serving their customers, constituents, and other stakeholders. Within ECC, for example, you can configure something as complex as an "order to cash" business process, or something as simple as a "credit check" transaction. Many business processes only require a few different modules within the component; others touch many more, however, underscoring the importance of the integration SAP provides.

However, to gain even better business visibility into trends and to maximize revenue and profit, it is becoming increasingly common to extend business processes like "order to cash" so that they inevitably touch multiple components. These so-called cross-application business processes might start by accessing ECC or perhaps SAP's Enterprise Portal, and then transfer control to another component such as SAP's Customer Relationship Management (CRM) product to determine customer-buying trends. CRM's business logic might essentially direct or influence the business process in a particular way, seeking to ultimately increase order size or gross margin. Next, SAP's Advanced Planner and Optimizer (APO) system might be accessed to revise a supply chain planning process for a set of potential orders, looking to optimize profitability as the system seeks to balance the needs of many different customers with the organization's access to materials, people, and other resources. Finally, SAP's Business Warehouse (BW) might be queried to pull historical data relevant to the financial terms at hand (so as to offer the best financial terms and discount strategy for this particular customer, for example, given his payment history). After these details are analyzed, control can be turned back over to ECC or Enterprise Portal to track warehousing, drive the pick-list process, manage shipping data and the A/R process, and at some point place the final closing touches on the cross-application business process.

Through all this, take note of the common threadSAP's products are used to satisfy the needs of enterprises, big and small, enabling an enterprise to tend to the business of running a business. After all, every enterprise needs to manage its inventories, generate and track sales, deliver services, maximize revenue, optimize its supply chains, and so on. SAP and its enterprise application competitorsOracle and to a lesser extent Microsoftenable this capability on a grand scale, integrating many otherwise discrete functions under a single umbrella. This way, the company (by way of the system's user community) gains greater visibility into how it is conducting business and how it might do so more economically, rapidly, and profitably.

Evolution of SAP AG

Before you go any further, a quick history lesson is in order. SAP AG was founded in 1972 in Mannheim, Germany by a group of ex-IBM engineers with a great idea that fell on deaf ears internally. The five original engineers who developed the concepts ultimately embraced by SAP originally named their company Systemanalyse und Programmentwicklung. Their goal was to develop a software package that integrated a company's myriad business functions in a manner that reflected best practices. Their idea grew into what soon became Systems, Applications, and Products in Data Processing (SAP).

From day one, SAP was designed to be a global software product engineered on a multilingual and multinational platform. Additionally, the engineers from IBM wanted to break away from the monolithic architecture model that defined mainframes and their applications of the daythey wanted to open the doors to a variety of hardware, operating system, and database platforms, thereby giving SAP's customers flexibility and choice. These revolutionary and innovative design features are what made SAP Germany's top software vendor only a few short years after its core product hit the marketplace.

SAP AG Today

Today, SAP AG reigns as the undisputed market leader in Enterprise Applications software. SAP is listed on the New York Stock Exchange (NYSE) under the symbol SAP. SAP AG offers comprehensive industry solutions atop their flagship R/3 and ECC products (so as to afford access to industry-specific best practices and processes), among these SAP Aerospace & Defense, SAP Automotive, SAP Banking, SAP Chemicals, SAP Consumer Products, SAP Engineering & Construction, SAP Healthcare, SAP High Tech, SAP Insurance, SAP Media, SAP Oil & Gas, SAP Pharmaceuticals, SAP Public Sector, SAP Retail, SAP Service Provider, SAP Telecommunications, SAP Utilities, and othersnearly 30 industries are addressed by these solution sets.

Many of SAP's latest products over the last few years, including ECC, are built upon a relatively new and very powerful platform called Web Application Server, or WebAS. WebAS offers an "open" front-end in that it speaks the most popular computer communication languagesHTML, XML, Web Services, and traditional "SAP." WebAS offers the programmers who help customize it a choice, tooSAP's very own and very powerful ABAP/4 language or the industry standard Java. Finally, WebAS continues to provide an "open" back-end. That is, many database versions and releases are supported in which to house all the data and configuration information that help create a solution rather than a bunch of data and a pile of equipment.

Given the flexibility and power inherent to WebAS, a company deploying it can navigate a number of different roads. You might deploy an SAP system initially very similar to how you do business today, and then evolve your own business model over time, happy about the fact that you don't need to retool your SAP platform to make this happen. This applies to the use of Web Services, for example. Or better yet, you might jump in and immediately begin supporting your customers and partners who demand you communicate with them over XML or Web Services, while still supporting HTML and the traditional SAP user interface when it comes to your company's internal users.

ECC's architecture (one component within the larger mySAP ERP bundle) is different from its predecessor's "SAP ECC and R/3"), but also alike in many ways as well. For example, both allow for the distribution of a user-based or report-based workload to multiple PCs (front-end clients called "presentation servers" by SAP). These presentation clients are linked together through a network. The SAP system was historically designed so that the presentation layer, application logic, and data management were logically separate as well as potentially physically separate from one another. In this way, a flexible system can be architected, one where additional headroom can be easily added when required. See picture below for a classic example.

The SAP classic system architecture requires a database server, one or more application servers, and one or more (typically hundreds or thousands of) front-end presentation servers.

Client/Server Environment

The concept of client/server is still very popular despite the growing popularity of other environments and architectures. SAP R/3 was built around the concept of client/server; ECC, on the other hand, is built around SAP NetWeaver and the concept of Enterprise Services Architecture. Client/server is essentially one of a few different standards used to build computer systems. Illustrated in picture below, a client/server environment is one in which the client machine (an individual PC, workstation, mobile computing device, or even another computer system) requests information (via a connection) from the supplying machine, known as the server. The communication and interchange of data between the requesting and supplying machine is known as the client/server relationship.

The configuration shown in picture below is a good example of how the three-tiered architecture applies to SAP in the world of legacy applications as well as in the world of Web Services and ESA.

In this example, a central computer houses the database, known as the database server. In terms of a distributed SAP system, it is enough to understand that a database is the place where the data is stored. For the purposes here, assume that only a single database server is set up in a client/server system.

SAP NetWeaver is the ultimate in four-tiered architectures, integrating Web Services and Internet support within the core WebAS platform. And because support is still maintained for the traditional SAP GUI as well as web browsers and other user interfaces, a company intending on moving to NetWeaver does not have to radically change the way it does business. It can do so methodically, in keeping with one of NetWeaver's core benefits to longtime SAP customers and userslegacy support.

Yet SAP NetWeaver is only one piece of the puzzle. SAP AG offers quite a bit more under the guise of mySAP ERPa suite of applications that has been specifically designed or updated to align with ESA, briefly discussed next.

Enterprise Services Architecture

"SAP NetWeaver," covers Enterprise Services Architecture (ESA) and how it is leveraged in the deployment of SAP NetWeaver. Suffice it to say here, though, that ESA is the new model around which SAP is building its solutions. ESA provides the roadmap or blueprint for designing an adaptable enterprise computing solution. ESA is not exclusive by nature, therefore. In fact, by embracing an Enterprise Services Architecture, R/3 and other legacy SAP solutions can be plugged in as application services in much the same way that new SAP NetWeaver components are. The preference might be to move to an ERP system that is architected from the ground up to fit into ESA, like SAP's ERP Central Component. But at the end of the day, if an application can share data via XML, it can be used and accessed like a service. SAP NetWeaver merely provides the vehicle for integrating these application services; it provides the platform. And in doing so, NetWeaver makes it possible for you to adopt an Enterprise Services Architecture.

mySAP ERP

Within the bundle of solutions that SAP AG calls mySAP ERP, you find not only NetWeaver but also SAP ECC. That is, ECC is but only one component (the central component!) of the mySAP ERP bundle. This comprehensive bundle of solutions also contains Business Intelligence (SAP BI), Enterprise Portal (SAP EP), SAP's Exchange Infrastructure (SAP XI), Mobile Infrastructure (SAP MI), and more. And beyond NetWeaver, mySAP ERP also includes SAP's Strategic Enterprise Management application (SAP SEM, a "bolt-on" to SAP BW), SAP's Supplier Relationship Management solution (SRM, which essentially consists of SAP Enterprise Buyer Professional), Employee Self Service (ESS) and Manager Self Service (MSS), and a number of other components designed to simplify web integration or enable collaborative project management and oversight.

SAP ECC

At the core of mySAP ERP is ECC. SAP's ERP Central Component replaces SAP R/3 as the company's core online transaction processing (OLTP) system. Like R/3, ECC addresses a business organization's needs to manage inventories and sales, track orders, plan and execute warehouse movements, and much more. Such activities often constitute the core business activities that must be accomplished day in and day out. Although a number of these functions were mentioned in passing, it's important to point out that many of these functions are now augmented through the deployment of one of four solutions that ship with mySAP ERP.

• mySAP ERP Financials

• mySAP ERP Human Capital Management

• mySAP ERP Operations

• mySAP ERP Corporate Services

These solutions include all the individual components necessary to fulfill their intended needs, making them easy ways to procure, plan for, and implement such a system. It's also important to note that any of these solutions can be easily tailored for a company's specific business needs by developing and deploying one or more of the other components that ship with mySAP ERP (described previously).

When all is said and done, though, the real work of a computing system is not accomplished by business processes, but rather by the individual SAP transactions that make up each business process. The role of SAP transactions is discussed next.

SAP Transactions

At a high level, we talk of computing architectures and business models. But nothing useful can be realized until you understand that the backbone of SAP is at the transaction level. An SAP transaction is any logical process in the R/3, CRM, BW, or other SAP system. A simpler way to define this is to say that a transaction is a self-contained unit, a set of steps with a beginning and an end, resulting in some kind of output and often an update to the underlying SAP database. Creating a new customer, generating a list of existing customers, processing an order, and executing a program are all examples of SAP transactions. SAP transactions therefore do the work of the application; everything else simply supports how this work gets done.

An SAP logical unit of work (LUW) contains all the steps of a transaction, concluding with the update to the SAP database, if necessary.

Suppose that you are adding a new employee in the SAP ECC Human Resources module. To complete this employee new-hire process, you need to go through several screens to describe and add that new employee to the system. Adding the employee's name and address on one screen and then proceeding to the next screen is considered a dialog step within the process. Adding the new employee's salary and paycheck information on another screen is an additional dialog step. At the end of an employee hiring, after you have gone through all the necessary screens (or dialogs) in the process, the data is committed to the SAP database, thus completing your LUW.

Dialog, Dispatch, and Dataflow

Dialog, dispatch, and dataflow refer to the information entered on a screen (dialog), the transfer of that screen data to the database (dispatch), and the update to the database and movement to the next process (dataflow). The data typed into a screen by the user is performed through the Presentation Layer via the SAP GUI. Finally, in order to update the database, this data must be manipulated and managed by the dispatcher.

A dispatcher enables SAP to communicate with the presentation server by managing the information exchange between the SAP GUI and the individual processes within SAP that execute work.

In simpler terms, the dispatcher serves as the go-to guy. Its role is to get things done. You learned about a logical unit of work, the steps performed to complete a task. It is the responsibility of the dispatcher to assure that complete processing of these steps occurs. The dispatcher evenly distributes the work it receives and organizes the communication activities so that, in the end, the database is updated and the transaction is complete (see picture below).