The purpose of business concepts is to provide a set of categories, or buckets, to sort out the large lists of business terms discovered in the process of business language analysis.  Simply viewing the set of business terms as classified by concept is very revealing of the essential concerns and information needs within a particular organization, or human activity system.  Further relating the business terms to each other, by using the relationships indicated by concept patterns, turns business language into a model that provides a powerful basis for information system modeling and design.

Concept patterns form a seamless semantic network.  This is almost impossible to portray via any two-dimensional medium, such as this paper.  The best we can hope for is to provide an approximation of a multi-dimensional network.  The approximation used here is a set of subnets, each of which is focused on one concept.  Each subnet displays all of the relationships from a focal concept to all other relevant concepts in the scheme.  Each relationship is bi-directional, with a pair of names that is meaningful in both directions.  This means that if there is a relationship in one subnet from Concept 1 to Concept 2, there should be a subnet for Concept 2 that shows the relationship back to Concept 1.  These symmetrical relationships should be meaningful converses of each other, such as “requires” and “is required by”, or “produces” and “is produced by”.  In some cases there are important relationships that exist within the concept itself, and these are shown as recursive ovals.  There is an informal convention in the patterns that shows the main relationships to other concepts radiating off to the right of the focal concept.  Coming in from the left are relationships that refine the focal category, or that explore fundamental subtypes of the focal category.  In general, refinements of concepts and subtypes of concepts are not explored in detail in this paper.  Exceptions to this rule include subtypes of resources (material, energy, monetary, human and information resources) and subtypes of relationships (roles, systems, and agreements), and a few others that do have their own sections in this paper.

Figure 1 is a legend for the graphic conventions used in this paper.  It is important to keep in mind that this is an exploration of meaning, and an attempt to provide useful structure to the mass of business language discovered in language analysis.  What you are seeing is not a set of formalisms for building relational databases or object-oriented software.  These are not entity-relationship models or object models.  They are fragments of patterns that relate concepts together in a relatively informal, but hopefully useful and revealing way.