asset mgmt is the core of refresh services provided by the resolver group and critical when configuration mgmt concepts are extended to workgroups. send the technicians out with a magnifying glass and ask that they document the serial number on every asset involved in the trouble ticket. the resolver group should be getting paid for asset and configuration management, you might as well grab the data when someone is touching the hardware rather than define and execute independent sampling processes.
ITIL insists that each infrastructure element have an identified “owner”, and perhaps its a good thing that procurement can go to someone when its time to discuss hardware support contract options. but we are really missing the formality of an application owner who understands not only the CI’s necessary to convey and crunch the transactions but also can dig out the original business justification for the app.
CIOs get hung up on app transformation with an expectation that many boxes will ultimately be turned off. Having the original business justification gives a different perspective on the app and its multiple components. Often, features that supported the original vision of the app have become obsolete as strategy, business partners, and technology changes. Dusting off the original business justfication can provide some easy cost savings suggestions and reminders.
red days are designated “hands off the infrastructure”; no changes allowed. delivery teams need to have a feel for application activity throughout the month and quarter. It would help if the service managers had a solid understanding of all infrastructure elements (and suppliers) required to complete transactions.
even emergency changes need to be handled with extra care during these periods. impact assessment, implementation and test planning should be more formal than normal.
configuration mgmt databases are notoriously difficult to maintain. every change should touch the CMDB in the planning, approval, and implementation stages. hopefully the records get updated during this cycle.
maybe because we think about SLAs in terms of availability and we think of availability in terms of boxes, we end up registering the boxes as the most meaningful CIs in the CMDB.
there are two glaring weaknesses in this approach: we don’t recognize the context of the service delivered to the end user and we don’t recognize the context of the business outcome belivered to the business.
suggestion: register business outcomes as the CI root. then identify all the infrastructure elements, the participating service providers, and the end users as supporting CIs.