This concept describes how to use modeling tools and techniques common in software development and other engineering
disciplines to the modeling of businesses. The approach described here is based upon the Component Business Model (CBM)
developed and used by IBM Global Business Services, however the question of how to integrate such a model with more
traditional business models leads us to present this guidance.
This topic draws heavily upon existing guidance in the RUP Business Modeling plug-in and as such demonstrates that
there are more similarities between these two methods than there are differences, albeit that CBM models are often
used for different decision making than a RUP business model would be. Specifically the following topics should be
reviewed by the reader.
Concept: Business Architecture describes the architectural views commonly
used to describe a business as well as some of the drivers for considering business architecture.
Concept: Modeling Large Organizations begins to describe the partitioning of
a business into autonomous units that communicate through well defined services.
Guideline: Business System (and Task: Define Business System Context) describes in more detail how business systems may be used in the same way as CBM
Business Systems "partition large business models into interdependent areas of responsibilities. Business
Systems encapsulate their resources, and provide services through well-defined interfaces, to other parts of the
The Component Business Model
The most commonly described work product resulting from a CBM engagement is the component map. A typical CBM
component map is presented below (taken from the web resource "A component-based approach to strategic change"). As you
can see the business components are arranged in a grid form, categorized by their competency area (sometimes
termed business functional area or domain area) and their action. The value in this map
is not simply that the business may be viewed as a set of components but that the analysis of the business
carefully produces the set of components and describes their dependencies and interactions. The following descriptions
are taken from the discussion on CBM found on IBM's web site.
IBM's Component Business Model is a new way of looking at your business. It represents the entire business in a
simple framework that fits on a single page. It is an evolution of traditional views of a business, such as
business unit, function, geographic or process.
The component business map shows activities across lines of business, without the constrictions of geographies,
internal silos or business units. The Component Business Map lets you see your entire company on a single
This single page perspective gives you a view of your business that is not constricted by barriers that could
potentially hamper your ability to make meaningful changes. You can see which components of the business really
create differentiation and value. You can identify where you have capability gaps that need to be addressed. With
the component view you can identify opportunities to improve efficiency and lower costs across the entire
enterprise. Identify the components where you can realize the greatest impact, and start there.
Figure 1 - Example CBM Map
So, the notion of a business component is very important and should be defined in a little more detail before we move
on to look at the parallel between CBM and RUP business modeling. Each business component identifies a basic building
block of your business, comprising:
People - the organizational aspect of the component,
Process - the functions the component performs and their implementation,
Technology - the technology supporting the component and implementing the services it provides.
The business component also provides (and depends upon) one or more services to the business, these services are
supported by the people, process and technology within a business component.
While the component map is the most visible artifact (certainly in the published materials) produced by CBM, there is a
lot more to the model than this picture. For example, "enterprise processes" are described as processes that are owned
by the business itself and usually customer facing in some manner. These processes are implemented as a choreography of
the services provided by the business components. However, it is also the case that a business component has processes
within it, either implementing the services it provides to the business, or potentially management processes of its
own. This is also described in the topic Guideline: Business System using the analogy of business systems and business use cases.
Using RUP Business Modeling
As a start, we outline in the table below a mapping from the concepts of CBM introduced above to the work
products in the current RUP Business Modeling discipline.
* - This element does not exist in the current UML Profile for Business Modeling (see Whitepaper: Rational UML Profile for Business Modeling).
The figure below demonstrates how this mapping can be achieved in UML (using Rational Software Modeler) using the
profile elements listed in the table above. Note that the business competencies contain the business systems which does
ensure that a component cannot appear in multiple competencies. In terms of the actions (rows in the CBM map above) we
have not included any particular organizational element in the model below, but it seems reasonable to add a property
to the business system to capture this information.
Figure 2 - Example UML Business Component Map
Having identified a set of business components/systems, we want to go on and define the services that these components
provide (and depend upon). Again, this is described in some detail in Guideline: Business System, however it describes the provided/required functionality as "capabilities". So to recap let's look
at an example; the figure below shows a business component/system which provides two distinct services, modeled as
interfaces and realized by the component. This allows us to not only model the services, but if required to even model
the business functions on each service. Modeling the dependencies between services in this way is reasonably
straightforward and produces a structural model which is almost identical to the CBM map above.
Figure 3 - Example UML Business Component with Services
In terms of modeling process in UML, the RUP describes the use of Artifact: Business Use Case to capture process descriptions with
the Artifact: Business Use-Case Realization detailed implementation
flows. With respect to the separation of enterprise processes from component processes described in CBM, we see very
similar guidance already in the Guideline: Business System where business use cases are described as cutting across business systems as well as
potentially being owned by a business system.