At present, the R/3 System contains more than 300 000 development objects (programs, tables, screens, BAPIs, function modules, types, and so on). These objects are grouped in over 1700 development classes stored in a flat structure.
Any developer can use any object. There is no easy way for developers to protect their own objects, or to highlight objects that they would like to make available to others. The technical modularization options open to developers on a small scale – for example, using module pools, function groups, or classes – are very limited. Whether on a large or small scale however, there are no mechanisms for technical modularization.
The package concept was developed to address these issues. Packages are designed to help developers modularize, encapsulate, and decouple units in the R/3 System. They are a further development of the concept of the development class, with additional semantics.

Existing development classes are simply containers for development objects with a transport layer that determines how the objects will be transported. Packages extend the concept of development classes with the addition of new attributes: nesting, interfaces, visibility, and use accesses.

• Nesting allows you to embed packages in other packages.
• Visibility is a property of package elements. Elements may be visible outside their package. However, they are always visible to other elements in the same package and always invisible to embedded (sub-)packages within their package. For an element to be visible outside the package, it must be contained in at least one package interface.
• Use access is the right of one package to use the visible elements in the interface of a second package (but not the other way round).

The following graphic illustrates these properties:

Packages use interfaces and visibility to make their services known to other packages. All the visible elements in a package can, potentially, be used by other packages; invisible elements cannot. This allows the package to encapsulate its contents and protect its elements from being used by unspecified external packages.

Use accesses restrict the use of the visible elements of other packages’ interfaces. Elements that are visible are not necessarily usable. Package A cannot use the visible elements of package B until use access has been created for the latter’s interface.

Nesting allows you to split the larger units of the R/3 System into a hierarchical structure. The combination of interfaces and use accesses allows developers to hide package elements, and protect them from unauthorized use.

The package concept also offers the option of splitting and encapsulating the R/3 System into technical units (the packages), reducing high levels of dependency and thus decoupling the system on a large and small scale.