Artifact: Business System
A Business System encapsulates a set of roles and resources that together fulfill a specific purpose and defines a set of responsibilities with which that purpose can be achieved.
Work Product Kinds: Model Element
Purpose

The purpose of a Business System is to reduce and manage the complex web of interdependencies and interactions within a business. This is done by defining a set of capabilities so that those dependent on these capabilities need have no knowledge of how those capabilities are performed. In this way, Business Systems are used in much the same manner that hardware and software components are used. They define a unit of structure that encapsulates the structural elements that they contain and are characterized by their externally visible properties.

Business Systems are used by business-process analysts to determine whether the capabilities required within the organization are present and to ensure that the business model is anticipating change or is at least resilient to change. Business designers use Business Systems to form collections of related business workers and business entities and explicitly define and manage dependencies within the organization. Project managers also use Business Systems for scheduling work in parallel.

Relationships
Tailoring
Representation Options

UML Representation: component in the business analysis model, stereotyped as <<business system>>. A business system is at the same scale as a UML subsystem and, because it is a component, has packaging semantics as well. The top-level component of the model is the business or part of the business under consideration, and appears in the context diagram in the Artifact: Business Analysis Model, where its relationship with the business environment is shown.

Business Systems should be used to manage dependencies within the organization by explicitly defining the capabilities (or services) that each Business System provides. This implies that the Business System encapsulates its contained elements so that users of its services do not depend on how it provides its services but rather on what services it provides.

This rule can be relaxed when encapsulation is not important. In this case, Business Systems may directly interact with, or be dependent on elements contained within other Business Systems. Formally specifying in detail the notional services that must be provided at the Business System boundary is less important in this case because ultimately those services belong with the elements contained in the Business System, and it is to services on those contained elements that a service user will bind. This variation regards the Business System more as a packaging (structuring) mechanism, rather than as a concept in itself.

When this is done, the business system essentially does not exist at execution time, that is, as the business operates, because its notional services are provided directly by its contained elements. Even so, it may still indicate a real business organizational boundary, with ownership of resources.

More Information