Filter
Top Products
In many smaller computer installations, where at most a few people are involved
in system changes, ad-hoc and informal techniques have often proved adequate.
All or us have seen a case where the complaint is lodged: ″It doesn′t work
right.″ Oh, what seems to be the problem? ″Payroll doesn′t work right.″ ″What
did you change?″ Nothing...
As systems become more complex, the staff working with the systems becomes
larger, the number of components becomes greater, the location of the
components becomes more dispersed, and the complexity of the connectivity
between components increases. It becomes increasingly difficult to know what is
really causing problems, what changes have been made and where, even what
components are in use and what their state is at any given time.
A structured or organized approach to systems management activities is
required. Over the past 15 years, several groups, including IBM, have defined
the systems management tasks in terms of disciplines. Examples of these efforts
include:
•
IBM′s Information Systems Management Architecture (ISMA)
•
Guide/Share User Group definitions
•
OSI′s System Management Functional Areas (SMFA)
•
IBM′s SystemView
•
IBM′s Information Technology Process Model (ITPM), which updates ISMA
•
IBM′s TME 10, which is an update to SystemView
In practice, the objective is not to adhere to a defined set of disciplines, but
rather to follow a structured approach in defining the tasks to be achieved and
the disciplines required to achieve them.
As one example, when major changes in the OS/390 environment and
infrastructure are made, it will be very difficult to actually know what changes
have been made and their impact since something last worked correctly, unless
a change management discipline has been adopted. This is especially critical
during the migration, since a large volume of changes is occurring.
Change management provides a standard way of introducing changes into the
computer system with much less risk or system outage on one hand and with
quicker resolution of system outages should they occur on the other. To achieve
these benefits, those who have the skills and the authority to make changes to
the system configuration, whether hardware or software, systems or application
programming, give up the freedom to make changes whenever they desire and
however they desire in order to improve the stability of the overall system.
The discussions justifying other systems management disciplines follow similar
logic, and will not be explicitly stated in the sections below where the disciplines
are described. The benefits of this approach are that it:
•
Ensures that the wide range of activities required are covered.
•
Ensures a complete solution.
•
Allows a common process to cross physical and logical resource boundaries:
that is, to have one problem management system, one change management
system, and so on.
458 VSE to OS/390 Migration Workbook