Chapter 5. Implementation planning 139
? Action requirement: Some operators may need a special ability to issue an
action to an object, so consider addressing this in the implementation.
5.7 Business System requirements
IBM Tivoli Business Systems Manager offers two types of views: All Resources
View and Business System View. The All Resources View, sometimes called the
physical view, represents the actual enterprise structure. Business System Views
(BSVs) are created with managed objects from the physical view. Business
System objects are additional representations of the physical objects that exist
within the enterprise; specifically, a link to the actual object that resides within the
All Resources View. Each link contains a set of filters and controls, so data
coming into the Business System object is the only data that is important to the
BSV's author. Operations performed on the physical object affect the object in the
created BSVs. You create Business System objects by dragging a physical object
from the physical view, or another Business System object from another BSV,
into the destination BSV.
5.7.1 Business System View theory
IBM Tivoli Business Systems Manager has the capability to create logical
aggregations of all the physical objects discovered within the enterprise. In order
to represent critical business processes or services, the objects contained in the
All Resources View can be extrapolated from their original tree and inserted into
different hierarchical structures. Such new structures (Business System Views)
enable you to diversify enterprise monitoring according to different IBM Tivoli
Business Systems Manager operators’ business interests and needs.
5.7.2 Business System View design concept
Designing a BSV’s structure involves understanding and accounting for the
complex relationships between the objects involved and the myriad ways to
represent them. This section provides our recommendations for designing
correct BSVs:
? Create BSVs based on the need and required monitoring function of an
operator or a group of operators. BSVs should provide critical business
information about the collection of resources or applications the operators are
responsible for managing.
? Create BSVs covering multiple business interests as root BSVs directly in the
Business System folder so that they can be reused and incorporated in other
BSVs. Dragging and dropping a child BSV into another one results in
140 Tivoli Business Systems Manager Version 2.1: End-to-End Business Impact Management
propagation errors because the child event from the original BSV does not
propagate in the dragged BSV.
? Drag objects to BSVs directly from the original objects in the All Resources
View to avoid having objects in the DELETED state when the original object is
deleted.
? Propagation of a child event does not happen to a leaf node (an object
dragged into a BSV that has children in its physical view, such as a DB2
subsytem), so when the physical object turns red because of a child event, its
corresponding leaf node does not change. Indeed, the leaf node mantains a
link with its children. Opening certain IBM Tivoli Business Systems Manager
views (Managed Resources view, Event Viewer) on the leaf node in the BSV
enables you to see all the object children as if you had dragged them all.
However, dragging another object under the leaf node (for example a DB2
database under a DB2 subsystem) breaks the existing link between the leaf
node and its children.
? Some objects, such as the network interface, can represent the status of the
original hosts. When a networked application cannot connect to the machine,
the machine is practically useless. Therefore any component of an application
in a machine will have the network interface as a critical dependent.
? The BSV Properties view must be adjusted to match the required priority and
the threshold of the child event.
? Setting the individual priority of each object in the BSV must be evaluated and
matched with the BSV’s child event threshold.
5.7.3 Business System View structure
BSVs can contain resources directly or affect the BSV. Several methods can be
used to implement these configurations, so we will give an example to illustrate
the difference between the two approaches.
The WorldBank Remote Banking application depends on two Web servers,
castore and polluce, running the RemoteAccess service. The core of the
RemoteAccess application is the APPL CICS transaction that accesses the
database HYPERDB under the DB2 Subsystem to grant user remote access.
Remote Banking’s BSV consists of:
? Remote Access service on castore
? Remote Access service on polluce
? HYPERDB DB2 database
? APPL CICS transaction
Chapter 5. Implementation planning 141
The BSV also indirectly depends on other resources, such as:
? Network Interface NetCom for castore and polluce, to ensure that the Web
servers are online
? MVS1 operating system
? JRLM DB2 subsystem
The BSV can be implemented variously as:
? No hierarchy: Using this method, all resources that the BSV depends on are
laid out flat under the BSV object. Figure 5-1 shows the conceptual BSV
structure.
Figure 5-1 Flat BSV for Remote Banking
142 Tivoli Business Systems Manager Version 2.1: End-to-End Business Impact Management
? Original hierarchy: Using this method, all resources are laid out under the
BSV according to its physical tree hierarchy. The objects that affect the BSV
directly are listed as the leaf node of the BSV tree. Figure 5-2 shows the
conceptual BSV structure.
Figure 5-2 Hierarchical BSV for Remote Banking
Chapter 5. Implementation planning 143
? Inverted hierarchy: Using this method, all resources on which a BSV depends
are listed as the first-level BSV, and each resource that indirectly affects the
BSV is placed under the resource it affects. This method provides the best
cause/effect relationship of the objects. Figure 5-3 shows the conceptual BSV
structure.
Figure 5-3 Inverted hierarchy BSV for Remote Banking
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.