Guidelines: Business System
Topics
- Introduction
- Business Systems Enable Dynamic Structure
- Business Systems Have Well-Defined Responsibilities
- Business Systems Contain Roles and Resources
- Business Use Cases Cut Across Business Systems
- Examples
Introduction
Business systems represent an independent capability within a business. They are used to partition and understand the structure of a business into manageable chunks, in much the same way that an organization is typically partitioned into interdependent units. However, the role and purpose of different parts of an organization are not always clear to other parts of it, which results in less-than-optimal interactions when executing a business process.
Business systems take the concept of partitioning and interdependence one step further. Business systems not only bind and contain roles and resources (and possible other business systems), but they also explicitly define interfaces, or the set of services or responsibilities they can be asked to provide. Organizations that define service level agreements to formally specify and manage interactions between departments and external collaborators are in effect defining business systems. The use of a business system often goes hand-in-hand with using business models at different levels of abstraction (see Concepts: Modeling Large Organizations).
The term "business system" should not be confused with a software system. A business system contains people, hardware, and software and is therefore at a higher level of abstraction than a software system.
Business
Systems Enable Dynamic Structure
In his book Enterprise Modeling with UML, Chris Marshall points out that traditional relatively static organizational structures are no longer sufficient for the radically decentralized and dynamic business world that is emerging. We can no longer expect a part of the organization to remain intact for long periods of time. As he states in his book, "Value is created and delivered through value chains that form and disband over time. Indeed, the day when such a chain is formed for a single transaction may not be far away."
Organizations are organic. As they feel increasing pressure from the business environment, they need to adapt to remain competitive. Taken to the extreme, a static organization structure may be crippling in a highly dynamic and ruthless business environment, and companies may need to turn to dynamic structure as a survival mechanism.
In the traditional static organization structure, departmental boundaries are only conceptual. While this may be a sign of an "open" and "informal" organization, the result is that every person in and segment of the organization is intertwined with the rest of the organization. It becomes extremely difficult to change or manage one part of the organization completely independently from the other parts. Business systems enforce partitions and boundaries by disallowing interactions between business systems, except by the predefined interfaces. These interfaces (possibly formalized service-level agreements) become the hinges that support the organization. The most significant advantage to these interfaces between business systems is that different parts of the organization are decoupled from each other. Dependencies are defined in terms of responsibilities and not on how those responsibilities are carried out.
Separating the specification of responsibilities from the realization of responsibilities results in a nimble organization-one that is capable of changing its structure rapidly without degrading the performance of its processes. In such an organization, one of its capabilities (defined by a business system) can be modified, improved, or outsourced, and the overall effect on the rest of the organization is kept to a minimum. As long as the quality of service remains the same after the change, the business operations continue uninterrupted. The same work could be performed by a software system, one person, or an entire department-either on-site or remote.
Using business events to abstract interactions could reduce direct dependencies between business systems even further. Because business events make time and space transparent, business systems can interact indirectly (see Guidelines: Business Event).
Business
Systems Have Well-Defined Responsibilities
Business systems explicitly define the responsibilities (also called services) that they can be asked to perform. This specification of behavior is essential because it allows the decoupling of dependencies mentioned in the previous section. A business system that does not define its services is without meaning. There is no way that another business system can know what services it provides, other than inferring them from its name. For example, we could expect a Resourcing business system (in departmental terms, it would be called Resource Management) to provide services for requesting a resource, querying the availability of resources, and possibly querying the resources types, or profiles.
Responsibilities (or services) define the means of interaction with the business system and are specified as operations of the interface(s) to it. These interfaces are collections of related services and as such describe the role that the business system can play in a particular interaction. In the example that appears below the next paragraph, we see that each interface is a collection of logically related services. These interfaces (clusters of responsibility) are assigned to the business system responsible for carrying out the responsibilities. When something external to the business system requests one of the provided services, an event occurs within the business system to initiate fulfillment of the requested service. This event, which is internal to the business system, may be explicitly defined as a business event. The roles and resources (business workers and business entities) within the business system then collaborate with each other (internally) to fulfill the requested service. As we can see, this is much the same way the business operates toward its customers. In fact, we could even model the business system as a "business," in which case the requestors of services would be the business system's business actors.
The example below shows the business systems of a generic financial services institution. Only some of the dependencies between business systems and interfaces are shown to improve understandability. From this diagram, it becomes apparent that the responsibilities can be reassigned by allocating an interface to another business system. This reallocation of responsibility would conceptually have no effect on the business systems that make use of those services.
Business Systems
Contain Roles and Resources
A business system is an abstraction of a collection of people, hardware, and software that work together to perform the responsibilities of the business system. We use the word "abstraction" because we do not describe the internal collaborations within the business system in terms of people, machines, and software, but in terms of roles and resources. A business system contains business workers and business entities. A business worker is a role that represents either a human or a hardware or software system. A business entity is a piece of information created or manipulated by business workers. These business workers can eventually be mapped to human resources, or to specific hardware or software systems. This abstraction helps us focus on the role of the business worker and determine the necessary responsibilities without having to consider the (usually imperfect) real situation of a specific person or system.
Business Use
Cases Cut Across Business Systems
Business use cases must not be allocated to a business system. Business use cases are the customer-facing processes that require the collaboration of a number of business systems, partners, and suppliers. This is referred to as the value chain. Business systems collaborate to perform business use cases, as shown in the figure below.
This cross-functional nature of business use cases is one of the reasons for the interest in business modeling and re-engineering, as well as in analysis of the cost and performance of business processes (see Concept: Activity-Based Costing). It is more valuable to understand how the cost of the entire business use case relates to the added value provided to the customer than to know how the annual budget of one of the departments relates to the overall corporate budget.
Examples
Furniture Store
The figure below shows the business systems for the furniture store used as an example in Guidelines: Business Goal and Guidelines: Business Use-Case Model. This store keeps large inventory in a warehouse attached to its showroom. This allows customers to browse through the products on display in the showroom and pick up the products they have purchased at the warehouse. Customers can arrange for delivery of large items.
This business has been divided into three interdependent business systems. Each business system has a clear purpose and provides well-defined services (not visible in the diagram). Explicitly defining these interdependencies and interactions helps to optimize the business.
Airport
An airport provides services to airlines and to passengers and visitors on behalf of the airlines. Because an airport is a very large and complex business to model, it makes sense to divide it into a number of independent business systems. Each business system can then be modeled independently as a business in its own right, as shown below.
In the example above, we see that an airline would have to participate in the Passengers and Flights business systems. Air traffic would be regulated by Air Traffic Control, according to laws and regulations. Hangar Facilities would provide services to the ground crews of the airline. Both Passengers and Flights would use services provided by Baggage Handling for departures and arrivals, respectively. The entertainment business system could also be called Airport Facilities and would include such things as shops, waiting areas, parking, and transport.
|
This content developed or partially developed by  Empulsys BV.
|
