Home > Articles

This chapter is from the book

SAP System Landscape Design and Planning Approaches

Remember, a system landscape exists for each mySAP solution—if you deploy R/3, APO, CRM, and PLM, you will in effect be creating four different SAP system landscapes, one for each product. The focus in this and the following few sections, though, is on what one of these system landscapes looks like from a design and planning perspective, for example R/3 alone or APO alone.

In the most general form, an SAP system landscape consists of SAP instances (installations of the SAP database and application software) and SAP servers. In the Microsoft world of SAP implementations, there is a one-to-one correlation between instances and servers nearly all the time. That is, the Development instance resides on a dedicated Development server, the Test instance resides on a dedicated Test server, and so on. In the world of UNIX implementations, though, multiple instances can be often found on a single "larger" server. For example, both Development and Test instances can reside on a single server. And multiple application instances can be installed on a single server as well.

Until last year's release of SAP's Multiple Components, One Database (MCOD) initiative, there was a one-to-one correlation between instances and database systems, too, regardless of the Operating System platform. MCOD is beginning to change this, such that a single "larger" database can be leveraged for multiple instances. However, an important difference between MCOD and multiple instances/one server exists—MCOD ties the same type of databases within different SAP system landscapes together. With MCOD, all Development databases used by your R/3, SRM, CRM, and Workplace implementations can be one and the same. Similarly, all Test databases across R/3, SRM, CRM, and Workplace can be bundled together, too, as illustrated in Figure 3.3. Note, however, that in many cases SAP AG frowns on mixing OLTP and OLAP systems, or combining different databases within the same system landscape. In that regard, forcing an MCOD database server to host your R/3 system's Development and Test databases would therefore be unsupported and contrary to best practices.

Figure 3.3Figure 3.3 A properly architected sample MCOD deployment is displayed for a typical mySAP enterprise consisting of R/3, CRM, SRM, and Workplace.

As we move forward with our basic understanding of SAP system landscapes, and seek to understand how your SAP solution vision impacts and is impacted by your landscape decisions, my hope is to achieve the following:

  • Note the relative importance and relationship of technology perspectives to our solution vision

  • Understand why each system landscape is important to fulfilling our vision

  • Note how the presence or absence of a particular system within a landscape impacts the other systems and ultimately the overall solution vision

All these design and planning approaches I cover tend to come into play in one manner or another across all mySAP implementations. It's how they are weighted or addressed that makes one system landscape different from the next.

Simplifying Your SAP System Landscape

After spending time with hundreds of customers and SAP implementations, I think it is safe to say that when all things are equal, the desire to simplify emerges as an important driver. Simplification takes many forms, too. In the case of the SAP system landscape and how it fulfills our SAP solution vision, the desire to simplify manifests itself in any number of ways:

  • First, the pure number of instances will be reduced to the fewest necessary to get the job done "right" for a particular company. An organization focused on simplifying administrative, change management, systems management, operations, and other tasks will deploy a three-system or even a two-system landscape, whereas similar organizations without the same simplification goals can deploy more. There are trade-offs, of course. A system landscape without a dedicated test instance will, for example, be forced to perform testing in the same system used for development. Because of these kinds of limitations, simplification achieved through instance reductions is not as common as it has been in the past.

  • Instead, a more popular approach to simplification seeks to reduce the number of physical servers in a particular system landscape, by installing multiple instances on a single server. Consolidation of instances is becoming quite common in SAP customer environments today, as displayed in Figure 3.4.

Figure 3.4Figure 3.4 Multiple SAP instances can be installed and configured on a single physical server, oftentimes reducing both acquisition and systems management costs down the road.

  • Similarly, deploying a shared disk subsystem and tape backup/restore solution also simplifies a very complex piece of the SAP Solution Stack. This is why my colleagues and I have spent so much time in the last two years designing and implementing Storage Area Networks, or SANs—they provide outstanding performance while simultaneously reducing system landscape complexity and allowing expensive resources like enterprise tape libraries to be shared between systems.

  • Another customer of mine shared with me why they went with the WebGUI as opposed to the classic SAPGUI approach to system accessibility—to simplify desktop support and maintenance requirements.

  • Companies that value simplification will also standardize on a particular solution stack option or approach, too, as this simplifies support and maintenance, and minimizes the need for a variety of onsite/reserved spare parts, the time spent in change management activities, and more.

Although simplification tends to work in one direction by encouraging a "do more with less" philosophy, our next topic goes the other route in that it purposefully introduces complexity and differences between various systems within a system landscape—high availability.

High Availability and the SAP System Landscape

When it comes to high availability, many technology professionals automatically think about what it means to improve the availability of a particular system or hardware component—thoughts of basic HA offerings like clustering or redundancy come to mind. With regard to the broader topic of how your solution vision impacts your SAP system landscape, though, high availability equates to the following:

  • Business-driven requirements—HA offerings and approaches are normally implemented to satisfy specific business-oriented needs, and therefore form an integral part of your overall SAP solution vision.

  • Complexity—HA complicates the SAP system landscape, as HA offerings and approaches tend to only really exist or apply to the Production system and at minimum (hopefully!) another similarly configured system within the landscape.

  • Increased support needs—Because HA offerings are inherently complex, a very real need exists to prepare your SAP support organization in how to install it, update it, manage it, and troubleshoot HA issues.

To read more about how business requirements relate to high availability, see "Availability Planning—Documenting Requirements and Key Drivers," p. 167 in Chapter 6.

Disaster Recovery Considerations

All companies implement a method of addressing Disaster Recovery (DR), whether or not they actually realize it. Even companies that do not add a dedicated DR system to their system landscape address disaster recovery. That is, their de facto disaster recovery plan simply reflects the challenges and timeframes surrounding rebuilding their SAP system from scratch, restoring from their latest tape backup, and imposing upon their end users to manually rekey any new business transactions lost between the last successful tape backup and the point at which the disaster occurred. This doesn't sound like much of a "plan," of course, but it does represent a baseline against which all other disaster recovery approaches and solutions can be weighed.

A host of DR approaches are discussed throughout Chapter 6, from those involving disk subsystem data replication solutions, to various clustering solutions, to database and mySAP-specific tactics. But when it comes to sifting the potential layout of your SAP system landscape through your solution vision, two general approaches fall out:

  • Creating and maintaining a dedicated Disaster Recovery system within your overall system landscape.

  • Outsourcing your Disaster Recovery system to an outsourcing provider.

Both approaches are valid, and the first is more traditional. But I believe that the time and expense related to setting up, configuring, keeping current, and managing your own DR system explains the recent increase in outsourcing I've seen over the last two years.

To review some of the tasks and considerations inherent to addressing DR internally as opposed to outsourcing it, see "SAP General Availability and DR Best Practices," p. 207 in Chapter 6.

Companies that outsource the DR component of their SAP system landscape help to preserve their data, and access to this data, in that the outsourcer operates a completely independent data center, typically in a very different geographic location. For smaller and mid-size companies with only a single data center, the expense relief is tremendous. On the other hand, if the DR solution is maintained "in-house," so to speak, it will need to be housed in a separate facility. This alone is sure to drive complexity, cost, and even the architecture and makeup of both the SAP system landscape and its individual systems.

Addressing Training Requirements

The SAP system landscape is directly impacted by the potential need to train SAP end users as well as the system's developers and technical support staff. Three different systems come into play, as illustrated in Figure 3.5:

  • A dedicated Training system is often implemented to assist in teaching users new to a particular mySAP component how to actually use the system. This amounts to business-process training as well as SAP user interface training (an excellent alternative to creating multiple training clients on the Test system, which is busy fulfilling integration responsibilities prior to Go-Live—the exact time when end users need to be trained!). To provide the most value to its students, the Training system needs to be an exact copy of Production.

  • A dedicated Technical Sandbox system is extremely useful in helping the SAP Technical Support Organization (SAP TSO) get up to speed on the entire SAP Solution Stack, especially with regard to new components and complex HA offerings (rather than attempting to get time on other systems for what could amount to crash-and-burn testing).

  • A dedicated Business Sandbox or Development Sandbox system allows developers unfamiliar with a particular mySAP component, or faced with integrating multiple components and other legacy systems, the opportunity to do so in a pure testing environment (rather than the real Development system).

Figure 3.5Figure 3.5 These SAP training systems support the different needs of different organizations, from end users, to developers and programmers, to technical implementation specialists.

For details as to how the SAP system landscape satisfies the training needs of both the SAP Technical Support Organization and the production system's end users, see "Training and the Role of the SAP System Landscape," p. 314 in Chapter 9.

It can represent quite a challenge for the "customers" of one of these training systems to convince everyone that such a system is truly required. In my own experience, I have seen the lack of a Technical Sandbox really hurt an organization in terms of downtime due to botched infrastructure upgrades and changes to DR processes.

Another colleague of mine has more than once had to strongly push for the adoption of a Training system, too. Such a system allows for extensive informal user testing and practice outside of formally delivered training. He believes that this extra level of hands-on self-directed training is critical because your end-user community is best positioned of all groups to find business-process operational errors and limitations. And of course it is desirable to correct these issues well before Go-Live. But a consultant or even a senior super user is typically not positioned to push the adoption and use of a dedicated Training system. More often than not, it takes the SAP Steering Committee, the project's experienced management team, and the prodding of a knowledgeable SAP Solution Architect to do so. I cannot stress this enough—the risk is huge, in that you do not want to find out too late that not every business scenario works as it did during integration testing (for example, all types of contracts, all types of material movements, all kinds of accounting entries, and so on).

The Performance-Driven System Landscape

When it comes to evaluating your solution vision against the layout of your SAP system landscape, it is important to ensure that the performance of the systems meets the needs of their different end-user communities. Most of the time, of course, the focus is on designing, installing, and configuring a well-performing Production system. Performance considerations usually relate back to what an end user will experience while on the system, including

  • Business transaction response times, or how long it takes to refresh your SAPGUI after pressing the Enter key, for example.

  • How quickly a background or "batch" job will execute, otherwise known as throughput.

  • How quickly a report or other query will make it through the system and actually be printed, sometimes called latency.

To read more about verifying that a Production system can meet performance expectations, see "Key SAP Stress-Testing Considerations," p. 580 in Chapter 16.

However, these same performance considerations apply to all of the other systems within the SAP system landscape, too. The Development system, for example, needs to exhibit excellent performance even while 25 or 50 or more developers are banging away at keyboards trying to build your custom mySAP solution. Similarly, your Test system needs to provide the performance necessary to get through integration testing. Even the Training system needs to provide adequate user response times so as to make the actual training experience more than something to be avoided.

High-performance considerations cover the gamut, touching every facet of every system within the landscape. This means that everything—from the performance of the network connecting each system, to each server's CPU, RAM, and disk configuration, to each system's OS, database, and mySAP component—must be addressed. Starting off on the right foot (with properly sized and configured hardware and software elements) is paramount, of course, but tuning all these solution stack pieces to create a cohesive well-running machine is just as important to achieving excellent performance. Like the weakest link in a chain, a single underperforming solution component will only throttle back the maximum performance otherwise obtainable from your system.

Driving Scalability into Your System Landscape

The need for scalability, like high availability and excellent performance, is addressed primarily through the sizing process. Scalability does not pay off up front in terms of improved system availability or better user response times, though. Rather, scalability is all about paying for "headroom" in your system, headroom that is not actually needed at present but might be required in the near future. In other words, scalability addresses future planned and unplanned growth in your system.

This growth can manifest itself in a number of ways. In my experience in the real world, I have seen the results of unplanned growth hurt companies where scalability was never addressed, as in the following cases:

  • The number of end users increased at one of my new accounts, not due to more hiring than was anticipated when their mySAP.com solution was crafted, but because they unexpectedly acquired their competitor and doubled in size. We had six months to project the delta needed in terms of database and application server processing power and RAM requirements, followed by stress-testing the new design and finally implementing it.

  • More than one of my customers' databases grew so fast that they outstripped the results of their comprehensive three-year database sizing methodology in the first year! In most cases, the system we put in place for these customers was scalable—more disk drives could be added, smaller drives could be swapped with larger ones, and so on. In three cases in particular, though, the database growth was so explosive that a whole new disk subsystem platform needed to be brought in, and the recently acquired current platform retired (or redeployed) years earlier than expected.

  • When databases grow quickly, the tape backup/restore solution implemented often grows less effective as well. I have seen this most often in relatively small SAP implementations, where an initial investment in tape backup technology needed to be tossed in favor of tape solutions that backed up more data per tape cartridge, and did so fast enough to not exceed the customer's backup window (time allotted to perform a backup, which usually equates to planned downtime in the case of offline full backups).

  • It's been a while, but I also had a customer outgrow their network, too. Today, with switched networks and Gigabit Ethernet providing more than adequate bandwidth to every mySAP.com server component, and cheap 10- and 100-Megabit Ethernet prevalent across end-user workstations, there's no excuse for lacking network scalability.

Outstripping the capabilities of your current system such that a new platform is needed probably represents a worst-case scenario. Not only does the current Production component need to be replaced, but to support sound change control principles, so does the same component in your Test, Staging, and/or Technical Sandbox environments.

This is why hardware and software vendors tout things like "highly scalable system architectures," "enterprise versions" of particular Operating Systems and Database Systems, and so on—though not necessarily needed up front, the headroom that these approaches provide helps an organization feel more comfortable if they wind up growing faster than they expected. And hardware vendors in particular can position their SAP clients for improved scalability by practicing the following:

  • Specify server platforms that allow additional CPUs and RAM to be added as needed. In other words, avoid "maxing out" the box.

  • Alternatively, design SAP solutions such that they take advantage of SAP's support for horizontal scalability. This is one of my favorite approaches when it comes to SAP Application, Web AS, J2EE middleware, and ITS servers—I prefer to max them out with regard to processors, with the understanding that an incremental number of servers can be added at any time should the environment grow to require it (interestingly, although SAP has successfully tested a system running more than 160 application servers, it is rare to find customer implementations with more than 10 or 12).

  • Architect a solution for the appropriate level of vertical scalability. In other words, if a two-tier "Central System" (where all SAP software components execute on the same physical server) approach to sizing meets today's requirements, perhaps a three-tier solution will provide for unknown scalability requirements. In a three-tiered architecture, one database server and multiple application servers are configured as a single system image.

  • Architect a highly scalable database platform. As my real-world examples earlier in this list illustrate, this tends to be where a lack of scalability causes the most problems.

Hardware and software vendors alike spend a great deal of time "proving" how scalable their offerings are. As a first step, I suggest that benchmarks, customer references/feedback, and the results of tests published through white papers and other technical documents be reviewed by prospective mySAP customers. I also suggest that you begin considering new approaches to scalability. For example, HP's iCOD offering touts "capacity on demand." When a customer buys a server, for instance, it is fully populated with CPUs. The customer pays for only what is needed in the near term, however. Later, if it is determined that more processing power is required, the customer takes advantage of the in-place processors by merely applying for a license; no intrusive field upgrade or service call is required and therefore the need for planned downtime is drastically reduced.

The TCO-Driven System Landscape

More than anything else, Total Cost of Ownership (TCO) drives what a solution vision actually looks like at the end of the day, when a mySAP solution is implemented and really being used. Discussions on TCO might instead be labeled Return on Investment (ROI), or might fall under the heading of investment protection. Regardless, a focus on lowering TCO seeks to find less expensive solution-stack alternatives that still meet the needs of the business.

To read more about the relationship between TCO and your SAP solution vision, see "How the SAP Solution Vision Drives TCO," p. 127 in Chapter 5.

When all other things are equal, the following points apply from a hardware perspective:

  • A hardware vendor's use of common components like CPUs and memory boards allows flexible sharing of resources between different SAP system landscapes and in some cases hardware platforms, too.

  • Similarly, common disk drive form factors reduce cost of ownership by increasing reusability.

  • Support for hot-pluggable and/or hot-add hardware components eliminates or worst-case minimizes downtime (can include hard drives, tape drives, power supplies, fans, and even RAM and processors).

  • Support for redundant components, like power supplies, disk drives, fans, and so on, also eliminates or minimizes downtime.

  • The ability to run mixed-speed CPUs or RAM in a particular platform protects that investment—CPUs and RAM do not have to be tossed aside when additional processing power or memory is required.

Outsourcing your entire SAP infrastructure/operations team is another potential method of reducing TCO. In fact, outsourcing can represent the biggest potential TCO factor that a company will consider. At this level, though, outsourcing becomes more of a strategic business solution that impacts a lot more than simply TCO. True, outsourcing can cut labor costs by 50%, and enhance flexibility of a technical support organization to easily change as business requirements change, but there are drawbacks and disadvantages as well (discussed later in this chapter).

Another solution vision approach that impacts the SAP system landscape from both a configuration and TCO perspective is the use of an Application Service Provider (ASP). ASPs can drive lower TCO by virtue of their application-specific expertise, above and beyond that provided by in-house staff and traditional outsourcing providers. For example:

  • An ASP can offer a preconfigured solution stack for the particular mySAP solution you want to implement. This is one reason why they look so good from a TCO perspective—design, deployment, manageability, operations, and other cost factors are substantially reduced due to a high level of both standardization and core competencies in the services they provide.

  • ASPs were more or less born out of the dot-com era, and by virtue of this, their data centers enjoy the benefit of fat redundant pipes to the Internet. Thus, mySAP.com applications are well positioned to take advantage of this flexible and powerful accessibility option.

  • ASPs offer interesting financing alternatives, in that they partner with various SAP technology partners to make leasing, pay-as-you-go, and other payment methods available.

The ASP provider market shrank over the last few years. The mySAP-focused companies that weathered these hard times seem even better prepared and well-positioned to host SAP solutions, however.

Security Considerations

I know of no company that does not envision protecting its corporate computing assets. From a solution-stack security perspective, not all software vendors are created equal, however. Oracle touts its unbreakable database, UNIX vendors tout the robust security features of their operating environments, and so on. In my eyes, security features are very important, but good security is more often about managing and testing changes to a solution stack, by carefully identifying security holes and other weaknesses in new solution stack components before these components ever find themselves in Production.

However, companies that embrace and act upon the idea of protecting computing assets will prove to be better partners in the long run. This is why I believe that Oracle's focus on security will pay big dividends in terms of slowing the adoption of competing databases. And it is why I believe that the Trusted PC joint Intel, AMD, and Microsoft vision (once labeled by Microsoft as Palladium, and now referred to as the "next-generation secure computing base for Windows") will prove fruitful as well. Its goal is to build security into servers and PCs at a microprocessor level. New initiatives coming out of the Trusted Computing Platform Alliance promise to better secure our processing platforms, ensuring that only authorized applications and program executables can ever be executed by the system, and that all data housed on the system is encrypted so that it is useless to others. To this end, Microsoft considers Trusted PC a significant part of its Trustworthy Computing strategy—we should see something commercially available in this regard by 2004 that applies to server as well as desktop and other computing platforms.

Manageability Considerations

No customers of mine have ever started their initial SAP implementation planning discussions with me by saying:

"George, all that high-availability and performance stuff is fine, but what we really want is a nice manageable system. Can you do that for us?"

By the time Go-Live looms just over the horizon, though, every single one of them—without exception—has indicated a growing concern for manageability. Sure, it's there on the project plan, and any number of products can be used to support managing your mySAP environment. But the whole field of manageability is more complex and more work than you would imagine. Consider the following:

  • Each layer in the SAP Solution Stack must be managed; the risk of not keeping an eye on a particular layer or solution component affects the uptime of the entire system.

  • Because each layer is so different from the others, it's nearly impossible to find a single management product that can actually monitor and report on more than a few layers, much less the entire stack.

  • Therefore, the next best thing becomes trying to find a product that can at least interoperate successfully with other products.

  • At the end of the day, three, four, or even more tools and utilities must ultimately be fused together to provide a holistic view of a mySAP solution stack. This is challenging, to say the least!

To learn exactly how challenging piecing together a management approach can be, see "Systems Management Techniques for SAP," p. 511 in Chapter 14.

Because of the challenges inherent to managing hardware and software products from a lot of different solution stack vendors, some of my customers have purposely chosen less than "best-of-breed" products for their SAP solutions, so as to minimize the number of software partners involved. Or they have decided to reduce the number of partners and vendors altogether by selecting one of the big enterprise hardware/services vendors. The obvious partners are clear—HP, IBM, and Sun. For example, if you go with HP and choose to implement an rp8400-based server platform with an HP StorageWorks SAN, running HP-UX 11i, and managed by HP OpenView, the challenges inherent to managing four different vendors' products just dropped tremendously. Similar arguments could be made for going with an IBM or Sun solution stack, too—IBM even throws a couple of databases into the mix.

The System Landscape and Accessibility

The last area I want to cover with regard to solution vision and the SAP system landscape is accessibility. Many companies over the last three or four years have started with a vision of dumping all application-specific interfaces in favor of browser-enabled solutions, so as to ease the burdens and costs associated with desktop/laptop management while opening up new accessibility approaches like hand-helds and other wireless devices. SAP has supported that vision since 1996, with the advent of Internet connectivity in R/3 3.1G. But only in the last few years have I really seen this take off.

SAP AG offers quite a few accessibility options today when it comes to mySAP solutions. The classic SAPGUI and its revamped and more capable EnjoySAP SAPGUI represent one end of the spectrum. This approach is safe, very mainstream, and very easy to implement. And the SAPGUI we have today is extremely comprehensive, supporting all mySAP components through a single interface, which is unlike the approach a few years ago where each so-called "New Dimension" product like BW or APO required its own GUI. But the SAPGUI still represents a typical application-specific approach to accessibility; each end user installs the client on their desktop or laptop, or runs the SAPGUI from a network share, and off they go.

Other accessibility approaches are available, however, as you see in Figure 3.6. The original WebGUI, for example, is based on HTML and provides connectivity via Microsoft's Internet Explorer and so on. And a more recent addition, the JavaGUI, allows native Java-based access to SAP. Both of these approaches fulfill an Internet-based approach to connectivity, and subsequently simplify the desktop (assuming Internet connectivity is a standard desktop offering at your particular company, of course).

Figure 3.6Figure 3.6 Access to mySAP solutions is quite varied today, ranging from classic and updated SAPGUI options to newer Web-enabled versions.

InformIT Promotional Mailings & Special Offers

I would like to receive exclusive offers and hear about products from InformIT and its family of brands. I can unsubscribe at any time.

Overview


Pearson Education, Inc., 221 River Street, Hoboken, New Jersey 07030, (Pearson) presents this site to provide information about products and services that can be purchased through this site.

This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site. Please note that other Pearson websites and online products and services have their own separate privacy policies.

Collection and Use of Information


To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:

Questions and Inquiries

For inquiries and questions, we collect the inquiry or question, together with name, contact details (email address, phone number and mailing address) and any other additional information voluntarily submitted to us through a Contact Us form or an email. We use this information to address the inquiry and respond to the question.

Online Store

For orders and purchases placed through our online store on this site, we collect order details, name, institution name and address (if applicable), email address, phone number, shipping and billing addresses, credit/debit card information, shipping options and any instructions. We use this information to complete transactions, fulfill orders, communicate with individuals placing orders or visiting the online store, and for related purposes.

Surveys

Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Participation is voluntary. Pearson collects information requested in the survey questions and uses the information to evaluate, support, maintain and improve products, services or sites, develop new products and services, conduct educational research and for other purposes specified in the survey.

Contests and Drawings

Occasionally, we may sponsor a contest or drawing. Participation is optional. Pearson collects name, contact information and other information specified on the entry form for the contest or drawing to conduct the contest or drawing. Pearson may collect additional personal information from the winners of a contest or drawing in order to award the prize and for tax reporting purposes, as required by law.

Newsletters

If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email information@informit.com.

Service Announcements

On rare occasions it is necessary to send out a strictly service related announcement. For instance, if our service is temporarily suspended for maintenance we might send users an email. Generally, users may not opt-out of these communications, though they can deactivate their account information. However, these communications are not promotional in nature.

Customer Service

We communicate with users on a regular basis to provide requested services and in regard to issues relating to their account we reply via email or phone in accordance with the users' wishes when a user submits their information through our Contact Us form.

Other Collection and Use of Information


Application and System Logs

Pearson automatically collects log data to help ensure the delivery, availability and security of this site. Log data may include technical information about how a user or visitor connected to this site, such as browser type, type of computer/device, operating system, internet service provider and IP address. We use this information for support purposes and to monitor the health of the site, identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents and appropriately scale computing resources.

Web Analytics

Pearson may use third party web trend analytical services, including Google Analytics, to collect visitor information, such as IP addresses, browser types, referring pages, pages visited and time spent on a particular site. While these analytical services collect and report information on an anonymous basis, they may use cookies to gather web trend information. The information gathered may enable Pearson (but not the third party web trend services) to link information with application and system log data. Pearson uses this information for system administration and to identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents, appropriately scale computing resources and otherwise support and deliver this site and its services.

Cookies and Related Technologies

This site uses cookies and similar technologies to personalize content, measure traffic patterns, control security, track use and access of information on this site, and provide interest-based messages and advertising. Users can manage and block the use of cookies through their browser. Disabling or blocking certain cookies may limit the functionality of this site.

Do Not Track

This site currently does not respond to Do Not Track signals.

Security


Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.

Children


This site is not directed to children under the age of 13.

Marketing


Pearson may send or direct marketing communications to users, provided that

  • Pearson will not use personal information collected or processed as a K-12 school service provider for the purpose of directed or targeted advertising.
  • Such marketing is consistent with applicable law and Pearson's legal obligations.
  • Pearson will not knowingly direct or send marketing communications to an individual who has expressed a preference not to receive marketing.
  • Where required by applicable law, express or implied consent to marketing exists and has not been withdrawn.

Pearson may provide personal information to a third party service provider on a restricted basis to provide marketing solely on behalf of Pearson or an affiliate or customer for whom Pearson is a service provider. Marketing preferences may be changed at any time.

Correcting/Updating Personal Information


If a user's personally identifiable information changes (such as your postal address or email address), we provide a way to correct or update that user's personal data provided to us. This can be done on the Account page. If a user no longer desires our service and desires to delete his or her account, please contact us at customer-service@informit.com and we will process the deletion of a user's account.

Choice/Opt-out


Users can always make an informed choice as to whether they should proceed with certain services offered by InformIT. If you choose to remove yourself from our mailing list(s) simply visit the following page and uncheck any communication you no longer want to receive: www.informit.com/u.aspx.

Sale of Personal Information


Pearson does not rent or sell personal information in exchange for any payment of money.

While Pearson does not sell personal information, as defined in Nevada law, Nevada residents may email a request for no sale of their personal information to NevadaDesignatedRequest@pearson.com.

Supplemental Privacy Statement for California Residents


California residents should read our Supplemental privacy statement for California residents in conjunction with this Privacy Notice. The Supplemental privacy statement for California residents explains Pearson's commitment to comply with California law and applies to personal information of California residents collected in connection with this site and the Services.

Sharing and Disclosure


Pearson may disclose personal information, as follows:

  • As required by law.
  • With the consent of the individual (or their parent, if the individual is a minor)
  • In response to a subpoena, court order or legal process, to the extent permitted or required by law
  • To protect the security and safety of individuals, data, assets and systems, consistent with applicable law
  • In connection the sale, joint venture or other transfer of some or all of its company or assets, subject to the provisions of this Privacy Notice
  • To investigate or address actual or suspected fraud or other illegal activities
  • To exercise its legal rights, including enforcement of the Terms of Use for this site or another contract
  • To affiliated Pearson companies and other companies and organizations who perform work for Pearson and are obligated to protect the privacy of personal information consistent with this Privacy Notice
  • To a school, organization, company or government agency, where Pearson collects or processes the personal information in a school setting or on behalf of such organization, company or government agency.

Links


This web site contains links to other sites. Please be aware that we are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of each and every web site that collects Personal Information. This privacy statement applies solely to information collected by this web site.

Requests and Contact


Please contact us about this Privacy Notice or if you have any requests or questions relating to the privacy of your personal information.

Changes to this Privacy Notice


We may revise this Privacy Notice through an updated posting. We will identify the effective date of the revision in the posting. Often, updates are made to provide greater clarity or to comply with changes in regulatory requirements. If the updates involve material changes to the collection, protection, use or disclosure of Personal Information, Pearson will provide notice of the change through a conspicuous notice on this site or other appropriate way. Continued use of the site after the effective date of a posted revision evidences acceptance. Please contact us if you have questions or concerns about the Privacy Notice or any objection to any revisions.

Last Update: November 17, 2020