Home > Articles

  • Print
  • + Share This
This chapter is from the book

Abstraction: The Way to Put Management in Control

Abstraction (suppression of irrelevant detail) is essential for any kind of human understanding and therefore for decision making. In the specific context of large IT system design and development, J.I. Schwartz noted in 1969 that "control is needed by managers, so that they don't begin a task before the initial specification is clear" [SE1970]. Clarity may be obtained only by using abstraction.

As C.A.R. Hoare observed at the same conference, if for some task you don't know what you have to do, "you can start out with the hypothesis that it will take a great number of people. Following down this slippery slope of reasoning, as soon as you have a very large number of people you have a very large management problem" [SE1970]. In this situation, management is not and probably cannot be in control; i.e., management cannot make justifiable decisions with the objective to improve the well-being of the owners of the enterprise.

Abstraction leads to elegant and very useful insights in all areas of human endeavor. When the irrelevant details have been eliminated and only the essentials remain, the number of potential blind alleys is drastically reduced. (For example, the essential properties of a thing cannot be changed without changing the thing.) At the same time, commonalities between seemingly different areas (often using quite different languages) may become apparent. Generalizations based on the essential properties of specific situations become formulated. The "Aha!" is being distilled.

Abstraction is indispensable for establishing that rapport between individuals that is "a very significant factor in arriving at agreed upon specifications from which one can proceed to build a programming system... It is quite evident you cannot have an effective software engineering facility when you lack rapport" (J.D. Aron, [SE1970], in the context of the Apollo project). This observation is valid not only in the context of programming systems. The rapport between people may be achieved only if some characteristics of people and things are by mutual (implicit or explicit) agreement considered to be irrelevant10 and thus ignored; the remaining characteristics will provide for a fruitful communication between the participants. Indeed, "[w]e get acquainted with another culture in the same manner as with another person: at our first meeting we look for commonalities in order for an acquaintance to become possible, and later we look for differences in order for the acquaintance to become interesting" (Averintsev's metaphor as described in [G2000]). It is instructive to observe that what was ignored as accidental when the communication was established becomes essential for the communication to become and remain interesting. At the same time, the essentials that made the communication possible remain as the fundamental context, when the communication participants concentrate on whatever at a higher abstraction level was considered to be accidental. For an important example of communication difficulties in the programming environment, of substantial interest to management at various levels, consider the infamous buffer overflows that have led to expensive and even dangerous consequences for too many IT users. A plausible explanation of such blindingly obvious violations of good programming practice (corresponding to violations of the most basic safeguards found in professional engineering) was presented in [N2002]: the programming culture of disciplined programming emphasizing the correctness concern differs from the programming culture emphasizing the efficiency concern in which it is imperative for "your dancing pigs [not to] dance slower than the other guy's."

The commonalities between cultures describe the essential structure of the subject matter of the cultures (for example, businesses). And the differences describe the specific nature of each culture.11 Following the discoveries made in present-day mathematics,12 we note that the structures of the essential fragments of apparently very different domains are often the same because the relationships between the individuals specified in these domains are of the same kind. We describe and use these relationships throughout the book.

Codifying corporate strategy

"In the mathematics I can report no deficience, except that it be that men do not sufficiently understand the excellent use of the pure mathematics, in that they do remedy and cure many defects in the wit and faculties intellectual. For if the wit be too dull, they sharpen it; if too wandering, they fix it; if too inherent in the sense, they abstract it."

Roger Bacon (1214?-1294?)

In any domain, when we make important decisions we want to understand precisely what exists, where it is, and what it does [RM-ODP2]. A business specification of the domain defines exactly that.

In business modeling, we need to be able to discover and make explicit the structures13 inherent in the business but often hidden within a huge amount of detail. In addition, we need to be able to discover how reasoning about these structures may lead to improving various properties of the business. And, of course, we need to be able to define precisely the corporate strategy, i.e., what properties are of interest and what "improving" means! In order to do that, we need to be able to reuse as much as we can, starting with well-defined fundamental constructs. Definitions of these constructs often come from mathematics (or philosophy) and can be translated from mathematical terms into terms more familiar to the stakeholders. Although the elucidation and explicit specification of concepts and structures described here may have happened relatively recently, the concepts and structures themselves have been around for centuries and perhaps millennia, and have been mentioned with varying degrees of explicitness and precision for quite a while.

In business modeling, when we use, discover, and formulate business laws and business rules, we can follow the founders of economics. And in economics (a science of complex phenomena, according to Hayek), specifications and discussions of the essential structures may be found in classical works by Adam Smith and Francis Hutcheson, and in more recent works by von Mises, Hayek, and others. All these structures are abstractions; that is, they are obtained by suppressing irrelevant details. Specification of corporate business structures within their environment is essential for reasoning about corporate strategy and tactics.

With respect to logical reasoning (which goes back to Aristotle), we note the remark by von Mises [M1949]: "Logical thinking and real life are not two separate orbits. Logic is for man the only means to master the problems of reality." Alternatives to logical reasoning—such as handwaving, reliance on those who "get it," or on business plans described by means of flashy presentations using box-and-line diagrams—often leads to business failures exemplified by many "dot-coms". As noted by Paul Strassman [S2001c], knowledge about a company's business environment and its competitive position is the most valuable insight for strategic decision making by executive management; 65 percent of the profit performance of corporations can be attributed to this knowledge.

As noted above, modeling is an area in which mathematical maturity is of great importance. Mathematical maturity is not the same as specific mathematical knowledge because mathematics in general is "the art and science of effective14 reasoning." In other words, mathematics promotes simplification rather than sophistication; by using abstraction, mathematics elucidates the essentials instead of creating a language barrier. Mathematics emphasizes the structure—i.e., the relations among various objects—to a much greater extent than the properties of the objects themselves. As a result, we speak about the fundamental unity of all mathematics. In understanding and modeling a business, as in mathematics, we emphasize the structure—i.e., the relations among various business things15—to a much greater extent than the properties of the specific business things themselves. And as in mathematics, we can see a fundamental unity of the same kind in the basic concepts of all kinds of specifications. In this manner, the writers and readers of business, technological infrastructure, and IT system specifications use the same basic concepts and constructs and are able to communicate in precise and explicit terms.

Abstraction makes things simpler and makes understanding much easier. Concepts are understood much better than technicalities, and important results are essentially simple. Modeling experience suggests that business stakeholders (non-experts in modeling or mathematics) understand and use conceptual material very well.

As a result, we may speak about the profound commonalities among apparently different kinds of business. More specifically, we may speak about the commonalities between the "old" and the "new" economy or about discovering and reusing business laws (structural and behavioral) common to all businesses. In this manner, by using abstraction—suppression of irrelevant details—we break through the traditional and not too helpful partitions separating different kinds of business.

The structuring of any system (business, IT, and so on) is where relationships, especially a small number of generic relationships encountered in all business, and other, specifications, come into play. The three kinds of generic relationships encountered everywhere and widely used in this book are composition, subtyping, and reference.

Concepts, like concrete things, do not exist in isolation: only a system of interrelated concepts makes it possible to be precise and explicit when the corporate strategy is discussed. We can bridge the communications gap between different people and departments when everyone can use the same well-defined—and small!—conceptual framework. And thus it becomes possible to make decisions based on reasoning about explicitly presented facts and structures within that framework rather than based on handwaving and eloquence. The fallacy of the latter kind of decision making was clearly visible in the failure of some "dot-coms" created, supported, and even valuated by those who "got it" as opposed to those who "didn't get it" [W2000].

Creating and maintaining elegant systems of concepts requires a considerable effort. Bypassing this effort is "about as appropriate for the software engineer ... as it is for the civil engineer to try to avoid expensive heavy earth-moving equipment, relying instead upon armies of men with baskets" (R.M. Needham, [SE1970]). Unfortunately, some important aspects of the current state of software engineering, especially the ones associated with "engineering" as a profession, can still be characterized by this quote. This is unacceptable. Producing and using demonstrably correct specifications as a foundation for making strategic decisions leads to success both in traditional businesses and in software engineering with further, and easier (due to reuse), success in traditional businesses.

Prerequisites for Decision Making

When we want to make reasonable decisions and justify these decisions to ourselves, our partners, customers, and other stakeholders, we need to base our decisions on the essentials of the information we have or can obtain while ignoring the accidentals. Choosing what is essential is often viewpoint-dependent. In other words, we need to apply abstraction in order to concentrate on the essentials, and precision in order to demonstrably "know what we are talking about." Thus, we act as scientists developing a theory of the business we are dealing with and validating this theory with the business stakeholders [CHJ1986].

These approaches have been around in traditional business and engineering for a long time. There has not been and cannot be any step-by-step guide showing how to create elegant specifications and how to use them in decision making. At the same time, important general guidelines exist.

Consider the Laws of the Problem Domain

The helmsman used to stand by with tears in his eyes; he knew it was all wrong, but alas! Rule 42 of the Code, "No one shall speak to the Man at the Helm," had been completed by the Bellman himself with the words "and the Man at the Helm shall speak to no one." So remonstrance was impossible, and no steering could be done till the next varnishing day. During these bewildering intervals the ship usually sailed backwards.

Lewis Carroll, The Hunting of the Snark [C1876]

Before solving a problem, we need to be able to understand what the problem is about. This approach is used in other areas of human endeavor, but not always in information management. Many of us have heard about solutions in search of problems. And many have heard about universal solutions apparently applicable to any problem of some—not always well-defined—type.

Before trying to solve a business problem by means of an IT solution, we need to understand the business context (i.e., the business laws, as well as explicit and implicit rules) and the specifics of the particular problem. Usually, this is the most difficult aspect of the job. The business context defines the properties of the business (things, relationships, and actions16) in the same manner as laws of nature define the properties of nature. In the context of IT system development, the need for "concept formulation at the beginning" was explicitly mentioned at least as early as 1969 by J.D. Aron from IBM Federal Systems Division [SE1970]. In order to be understood, the business problem should be explicitly formulated in terms of these essential properties of the business.

Understanding of a business problem may be compared with a "business diagnosis" (ICSE 2001 talk by J. Ning from Accenture). When we use this metaphor, we may recall that in medicine the normal characteristics of a human body—both static and dynamic—are supposed to be well known before dealing with its "abnormal" characteristics. This includes the determination of "normality" of the characteristics.

After we understand the business and the specific problem in the context of that business, we may see that a computer-based solution is not even needed: manual changes in business processes may help the business stakeholders to understand better the current business objectives and to achieve them. At the same time, in many situations, IT (computing support) may help the business to achieve its existing objectives or may provide for new business opportunities that may become or change, after approval by business decision makers, the current business objectives. In either case, the IT artefacts must be understood by the business decision makers and specified from the business viewpoint. This approach does not—and should not—differ from applying any technology in a business. For example, if we want to "get from here to there" we need to know some aspects of the map (which will show the relationships between Here and There17) and some aspects of the technology—the transportation mechanisms available to us.

Understanding and precise specification of the (laws of the) appropriate domains18 is the essential prerequisite for understanding both the business and the IT artefacts,19 and in particular, for trying to formulate any requirements for computing support. In other words, both the business problem and its solution could be understood only in the context of their business and solution domains since the laws of these domains ought to be satisfied all the time. This is as it should be: in more established branches of engineering, for example, we consider the laws of nature (specified, e.g., in physics) as a natural conceptual framework for dealing with engineering problems and artefacts. In software engineering, we ought to apply the same approach.

Of course, there are differences between traditional and software engineering. Because laws underlying software engineering are relatively new, they may be less familiar than those underlying traditional engineering; some of these new laws have not been formulated yet. And because software engineering is applicable in many very different business areas, we ought to be able to find out how to specify in a uniform manner the laws of these business areas. Fortunately, mathematics, being the art and science of effective reasoning, helps us to do just that. Thus, we will see that specifications of very different businesses areas (including the businesses of software engineering) have much in common.

Some models of various application domains and their fragments are (publicly or otherwise) available, so in software engineering—of which business modeling is an essential part—it is often necessary to create new models or at least to evaluate and change models created by others, rather than merely to apply such models.

Requirements "Always Change" ... or Do They?

Business processes often change: such changes may lead to a competitive advantage for the business, or may simply be perceived as necessary for the business to survive. Similarly, decisions about using computer-based IT systems to automate certain business processes may also change (for example, due to perceived opportunities). At the same time, the basics of a business domain often remain the same for centuries if not for millennia: we successfully used banking and financial texts published in the early twentieth century (or earlier—for example, fragments from Adam Smith's Wealth of Nations) in order to understand and specify the corresponding business domains. The changes due to "modernity" were minimal and were mostly additions or refinements of the existing classical models.

It is interesting to note that in literature and art, modernity is an attempt to derive the eternal from the transitory. In the words of Baudelaire, "Modernity is the transitory, the fleeting, the contingent, one half of Art, whose other half is the eternal and immutable" [P2001a]. In our terminology, invariants—properties of things and relationships that remain true no matter what processes have been or will be performed—provide for the description of this immutable. This terminology has also been used by some scholars of humanities. For example, linguistic invariants provided the foundation of many deep discoveries by Roman Jakobson. For another example, the interesting book by Zholkovsky [Z1999] is about the discovery of a small number of invariants in the life and literary work of Zoshchenko; these invariants help in understanding the seemingly very different kinds of Zoshchenko's creative work.

The invariants that define the business domain are a very good and stable foundation for a specification.20 We do not want to start in the middle, that is, with a possible solution, or even with a specific problem; we start with the stable (that is, invariant) basics and proceed from there. In other words, we use abstraction to concentrate on the essential and ignore the transitory. The transitory cannot be understood without the basics. In particular, the interrelated concepts used in describing this transitory are defined by (and in) the basics.

The invariants are the "laws of the domain," and we use them in the same manner as laws of nature are used in more traditional engineering. And the basic laws of a domain—unlike the transitory21—are usually simple and elegant, as are the basic laws of nature. These laws of the domain constrain and govern all actions that happen in that domain; specifically, human participants of the domain use the invariants in planning their actions to improve their future conditions. In this manner, the stable structure of a business domain provides an excellent reusable foundation for creating and reasoning about all kinds of potentially volatile—but not frighteningly volatile—requirements for business processes and systems.

The invariants that define the basic structure of a business domain also may change. However, such changes happen much more seldom than changes in the transitory characteristics of the domain (sometimes called "business needs") or changes in behavior (business processes) governed by these invariants. In addition, business specifications based on the invariants have delivered an unusually high degree of robustness [KA1997]; almost all changes have been local. The structure of the business domain usually remains stable, while the changes of the contents often are about permission of prohibition of certain products or services, introducing of a product or service into new contexts, deregulation leading to competition where none previously existed, and so on. The general properties (but, of course, not the specifics) of many of these changes can often be anticipated, and appropriate abstraction leads to substantially greater stability of specifications.

Strive for Simplicity and Elegance

Association with ugliness blunts the instinct for beauty, and warps the intellect if long continued, whereas association with beauty sharpens instinct and allows the intellect to develop without hindrance. Beauty thus being hygienic, art should come into everything, and the architect, like every other worker, should make his work beautiful.

H. Kempton-Dyson, Design, in [S1904]

The stable foundations often ought to be discovered and distilled from the complex world around us. These discoveries are the only way to master the complexity and abstract out the irrelevant details.

Unmastered complexity can creep in various ways. "Too much stuff" is probably the most familiar22 and the most dangerous. A specification with too much unstructured stuff in it is a write-only specification, even if most names used in it are perceived to be very familiar to its possible users. Most of us have seen such specifications materialize in boxes full of precise information; if we want to ask a question, the answer is probably there, but impossible to find. Decision makers and others who have seen only such specifications may become convinced that all specifications are not worth their time and effort. Some practitioners may, as a result, strive for "quick and dirty" work with often disastrous consequences.

As E.W. Dijkstra noticed some time ago, "I get extremely suspicious when the engineer justifies adhoccery by an appeal to the presumed law of nature, summarized by 'quick and dirty,' for from my experience and from my understanding I feel that 'quick and elegant' is a much more likely combination" [D1969]. This adhoccery is often realized by following the appropriate buzzwords and starting from scratch without paying much (or any) attention to the basics of the discipline. Contrariwise, quick and elegant specifications help enormously in the collective work of business experts, modelers, and IT experts. (Most specifications shown in this book are generalized fragments of real-life business specifications.)

In business and IT system specifications, too much stuff is often realized as overuse of a huge number of detailed facts possibly including application-specific or technology-specific artefacts invented for the benefit of the initiated. Such a specification may be precise and even may be claimed to be complete, but who can read it? If we want to drive from New Jersey to California and we can use only very detailed road maps (e.g., having the scale of one mile to one inch) plus a "data dictionary" such as an alphabetized list of towns, rivers, and counties, we are in a very difficult situation; based on these complete and precise specifications, we cannot even figure out that we have to drive west! In addition, some specifications introduce new terminology invented for an apparently new area, while in fact many existing concepts could have been reused. We often see proponents of reuse who propose first of all to create a set of new and therefore better reusable constructs.

According to Ronald Posner [P2000], semiotic pollution harms our intellectual environment in the same manner as physical pollution harms our physical environment. Information overload often leads to our intellectual incapacitation: we are overwhelmed by complexity. "The most effective way of avoiding unmastered complexity is not to introduce that complexity in the first place" [D2000]. After such complexity has been introduced into a system, it is usually too late: only trivial changes can be "reliably" made to that system unless a complete rewrite is accomplished. Even changes considered to be trivial (i.e., apparently local) may lead to grave consequences if the locality assumption, often unstated, will appear to be mistaken. Some of these grave consequences were described as front page news. And similar problems have been well-known in traditional environmental pollution.

A system with unmastered complexity is far from elegant; "in the design of sophisticated digital systems, elegance is not a dispensable luxury but a matter of life and death, being a major factor that decides between success and failure" [D2000]. The same is true about any system. And Paul Erd?, one of the greatest mathematicians of the twentieth century, put forward the idea that the Creator has a Book in which all of the most elegant proofs are written [S2001].

In the same manner as many basic business concepts (e.g., those described in Adam Smith's Wealth of Nations or in the United States Uniform Commercial Code) are neutral with respect to a specific business, many basic IT concepts are neutral with respect to a specific technology (and of course, to a specific methodology or toolset). This approach has been used by E.F. Codd, the founding father of the simple and elegant relational data model, as opposed to navigational models that "burdened application programmers with numerous concepts that were irrelevant to their data retrieval and manipulation tasks, forcing them to think and code at a needlessly low level of structural detail" [C1982]. More generally, this approach has been used in excellent programming texts (such as [D1976, D1982]) that teach programming concepts rather than a specific programming language. It leads to simplicity and understandability, and it is not new. As an example, the concept of Occam's razor was formulated long ago and has been successfully used for centuries. The same approach has been successfully applied to humanities. Johann Joachim Winckelmann, an eighteenth-century German aesthetician, noted that it was easy to use lots of means to produce insignificant works while it was difficult to create real masterpieces—beautiful works (of art) with simple means. These observations were made in a very interesting paper on Web design simplicity [K2000a].

Using mathematics helps in avoiding too much stuff for any system. Yuri Lotman, one of the founders of semiotics, noted that mathematics is "a method of scientific thought, and a methodological basis for the discovery of the most general regularities of life" [L1964]. Observe that Lotman considered the main difficulty in using mathematical methods in literary studies to be "in the fact that the basic concepts of literary science have not yet been formulated." As an IT-related example, Jim Davies and Jim Woodcock from the University of Oxford presented at the Oxford-Microsoft Symposium in Honour of Sir Tony Hoare (in 1999) an extraordinarily successful project of a smart card (for electronic commerce) for a very large U.K. bank—the first U.K. system to gain the Level 6 security rating that was considered unattainable by the industry. Formal specification, design and implementation (with proof) were successfully used in the project. The emphasis was on simplicity: it made the specification "blindingly obvious," so that the specifiers could convince a bank manager that the specification was correct. The presenters stressed that their most interesting examples were characterized by eureka moments. The mathematics required for the specification, refinement, and proof was completed on time and under budget, and there was no problem of "using Greek letters"!

Some authors (E.W. Dijkstra, J.W. Smith [SE1969]) advise to use not more than several lines (or a paragraph) in order to explain something specific, be it in mathematics or specifications. This approach perfectly corresponds to presenting the main characteristics of a language used to express a specification on the back of the proverbial envelope. We try to follow these recommendations throughout the book.

Simplicity should never be at the expense of generality. Discovering commonalities in areas perceived to be somewhat or substantially different leads to generalization and simplification (by virtue of suppressing irrelevant details), and thus to better understanding. As a result, effective recurring templates may be discovered or distilled and specified for reuse. The simple, general, and powerful concept of a contract described, for example, by Francis Hutcheson [H1755] and by the U.S. Uniform Commercial Code—as a composite in the composition of parties, subject matter, and consideration—represents a well-known example used in a variety of contexts.

Elegant Representation

We have to communicate our specifications, i.e., to represent them in a language or languages understandable to the users of these specifications.23 There are many specification languages, in the same manner as there are many programming languages. A programming language may be ugly, but at the very least it has to be precise because it includes instructions to an inanimate object (a computing system). A specification language may be ugly and also (independently) may be imprecise because it may be used only by humans. Box-and-line diagrams,24 slide shows, narratives, and so on are familiar examples. This book does not promote a "best" specification language, but rather describes some criteria that make a language good.

A good specification language should first be simple and elegant. It should not add its own complexity to the intrinsic complexity of the problem. "All knowledge of one's programming language can conveniently be formulated on a single sheet of paper and can be gotten across the limelight in about twenty minutes lecturing.... [O]nly then real difficulties of understanding and solving real problems can be dealt with; that activity requires the ability to think effectively more than anything else" [D1976a]. Thus, again we encounter the need for a well-defined elegant structure. The same approach applies to languages used for non-executable programs, i.e., for specifications considered in this book.

A good specification language should be precise. In other words, the semantics of its concepts and constructs and the relationships between them should be explicitly and unambiguously defined. Thus, if diagrams are used, then they should not be pictures of anything; rather, all elements of these diagrams should represent mathematical objects. (As a counter-example, consider a line between two boxes that intends to represent a relationship graphically; the semantics of such a representation is not clear; different lines that look the same often denote different semantics; and in most cases, a relationship has more than two participants.) Of course, we do not need to repeat the definition of a construct every time we use it; once defined, the construct may be abbreviated (named) and reused. We reuse such constructs, from very basic to very specific, in this book.

A good specification language should permit the specifier to say what is meant without any language-imposed restrictions: it should permit an easy mapping from the structure of the problem to the structure of its representation. This is a very important characteristic of any notation: to quote E.W. Dijkstra, "the tools we are trying to use and the language or notation we are using to express or record our thoughts are the major factors determining what we can think or express at all" [D1972]. The specifiers should be able to, and should be encouraged to, say what they mean rather than something quite different.25 For example, if the specifier means to say that there exist several independent subtyping hierarchies for the same supertype, then the specifier should say precisely this, and the specification language should be able to express this directly and explicitly, rather than prohibiting such an expression "because you cannot do that in [insert your favorite programming language]." For another example, if the specifier means to say that a composite in a composition has three components of different types, then the specifier should say precisely that, and the specification language should be able to express that directly and explicitly, rather than prohibiting such an expression and imposing instead three binary compositions that collectively have a very different semantics.

  • + Share This
  • 🔖 Save To Your Account

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.


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.


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.


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.


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


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


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.


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.


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