Integration of a CM Process and working with CA UNICENTER

[maverick544]

Hey all,
Question 1:
I am recently coming from another company that I worked as Configuration Manager. My primary duty was to track all registrations of software installed whether licensed or not licensed that came through as a Change Request, and ensure that it was tested for baseline compliance and scanned for vaulnerbilities. Upon successful testing and acceptance by the Release Manager the software was packaged and implemented. At which point I updated what we called the Approved Software List (Excel), updated a Release Mgt tracking DB and I loaded it into the Software Media library (MS Access), then updated the CR. Now would the DSL by ITSM definition have been all of these? Also if I apply the same concept to Hardware testing, would that be considered the DHS?

Question 2:
Moving on from their I have now gotten a new job for CM where they have a similiar practice, but now instead of using BMC Remedy they are using CA UNICENTER (ServiceDesk, Desktop Management Sute, Asset Portfolio Mgt (Argis), UAM (Asset Mgt Discovery via NSM))

Now being familiar with ITIL/ITSM CM practice I understand Configuration Items are not just Assets of Hardware and Software but could also be Departments, Desktop Configuration, Server Configurations, CR's, Incidents, problem tickets. Now with how the CA Unicenter is designed: Service Desk withholds all the Incidents, Change Orders, Problem Tickets, DMS Explorer withholds Desktop Mgt Tools like Remote Control, Software Deliveries, and software that has been packaged for delivery for Individual, bulk or Enterprise pushes. UAPM/Argis is the Legal Inventory or the Asset Accountabilitiy Database for Software and Hardware and their relationship between each other and the End-User. Are all these different Modules together the CMDB or are they not and their should be another System linking all of them together.

Question 3: Are Change workflows considered a Configuration Item? for example, Predifined workflows for CR's for routine desktop purchases, or software that has not been tested...

Question 4: Can SOP's for different workshops be considered CI's?

[poloneck1]

Hi,

My firm worked with CA for 2 years to implement and transform a service management solution for a FTSE100 company, so I understand where you are coming from.

I'm in a kind of reverse position to you, I used to work for an IT Service Management company as a consultant and Project Manager, and my experience of configuration management is rooted in ITIL. I now work for a software firm and the configuration manager here does more of the role you used to do: essentially the 'guardian' of software.

I'll offer my thoughts in the order you asked your questions and make references to the products too. I hope this helps.

Q1: By DSL, I take it you are referring to the definitive software library?

"The practice of Software Control and Distribution involves the creation of a Definitive Software Library (DSL), into which the master copies of all software is stored and from here its control and release is managed. The DSL consists of a physical store and a logical store.

The physical store is where the master copies of all software media are stored. This tends to be software that has been provided from an external source.

The logical store is the index of all software and releases, versions, etc. highlighting where the physical media can be located. The logical store may also be used for the storage of software developed within the organization.

SC&D procedures include the management of the software Configuration Items and their distribution and implementation into a production environment.

This will involve the definition of a release programme suitable for the organization, the definition of how version control will be implemented, and the procedures surrounding how software will be built, released and audited".

http://www.itlibrary.org/index.php?page=Release_Management

As for the Definitive hardware store, ITIL defines it as :

An area should be set aside for the secure storage of definitive hardware spares. These are spare components and assemblies that are maintained at the same level as the comparative systems within the live environment. Details of these components and their respective builds and contents should be comprehensively recorded in the CMDB. These can then be used in a controlled manner when needed for additional systems or in the recovery from major Incidents. Once their (temporary) use has ended, they should be returned to the DHS or replacements obtained.

This essentially means that it's a set of standby systems used for failing over services in case of incidents. It seems that more practically, the systems in the

DHS should be ready to be re-purposed on demand to solve any upcoming capacity or availability issue (instead of being pre-configured to match all possible systems in the environment).

An example might be spare printers held in the DHS for a high volume printing operation, where long downtime is not acceptable and a quick swop-out is desirable. These printers would be in the CDMB, but their status would not be 'live', but something more appropriate instead.

Q2:

Firstly, I'm assuming you're aware that UAM Asset Management is agent based. NSM is a separate entity and tends to sit in your servers and other elements of network infrastructure. The two are separate.

The answer to your question is not an easy one. And it depends upon which version of CA products you are using. If you are using the R11 versions of CA products (particularly Unicentre and UAM) then life will be a bit easier.

However, most likely you are on or around V6, where things get a bit more complicated. To further complicate matters, there is a systems view and a conceptual view that you can apply to these systems and how they enable configuration management. I'm only going to talk about the systems view here.

The systems view is that all the V6 CA products you have described are separate, in that they hold data in their own databases which are part of the product. For example, UAM has its own database which stores all the asset inventory data it discovers with every scan, and CA Service desk has it's own database too.

You are probably aware that CA Service desk has CMDB capabilities (hold CI data against a logical 2 tier family/class structure, build relationships between CIs, link CIs to Problems, incidents and changes).

The big issue with this system landscape is twofold - duplication and dislocation. Dislocation in that all these systems are distinct and don't really talk to each other out of the box - they are stand alone products. Duplication in that because these products are distinct and have their own databases, the same data is potentially stored in 2 or more places. As someone with a SW background, I'm sure that you will agree that this is not good! However, that is was you have got and you have to deal with it! It raises all kinds of issues around keeping data in synch and which version of the data is really the truth?

In the new 'R11' world, CA have a single 'enterprise level management database' (can't remember what they exactly call it). This is the principle that all the R11 products share a single 'super duper' database, which they all feed into.

My client was not going to move to R11 for some time, so we had to do something to join these systems up and because of the size and complexity of the organisation and it's infrastructure, we couldn't do this 'manually' (processes and procedures and 'pots' of data). So we emulated the idea of a enterprise mdb and built a master database that took feeds from UAM, and a whole host of other third party and bespoke auto-discovery products that we had deployed across the infrastructure. All this data was crashed together and reconciled on a daily basis (all automated and driven by flexible business rules). This db became the single source of truth for the business and we then used the CDMB capabilities of the Service desk product as an abstraction layer for this database, building CI relationships and using an MI tool (in our case Forest & Trees) to extract useful MI.

So, the short answer to your question is yes - there should be a system linking all these, but in CA 'V6 world' there isn't! You have 4 options:- carry on as you are but face duplication and data synching issues, upgrade to R11, build you own interface, or manage it manually with processes.

CA do have a product called (confusingly) CA CMDB. This is an R11 product and is a 'pretty picture' bolt on to the enterprise management database. It allows you to see sets of CI relationships graphically, rather than textually (in CA Service Desk). We did a pilot to see of it would work with an R6 version of our CA service desk but it was a bit of a non starter.

Q3:

A CR workflow is not a CI. Workflows and the building of workflows in CA service desk is just a feature of the product. For 'common' CRs with
a standard workflow, you would use an IMAC (install, move, add, change). This is a pre-approved RFC that, once sanctioned, does not need to pass through the CAB as part of your change management process. Instead it is just actioned, because it is pre-approved and it uses the same workflow every time. For example, you would raise an IMAC for a routine desktop purchase such as a desktop machine with a particular build, or the provisioning of an email account for a user. IMACs were part of our CA Service desk setup, and it worked pretty well with our e-procurement catalogue and our 3rd party procurement partner.

You can also 'save' a workflow and re-use it again when another CR of that nature is raised. For example, the CR raised as part of our leavers process used the same workflow every time. It was badged with a change category of 'leaver' and used every time someone left the company.

Question 4: Can SOP's for different workshops be considered CI's?

If they are captured in a document, then yes! The document is a CI with configurable attributes such as doc ref, version number, author etc. However, in bringing document CIs under the envelope of configuration management you are creating an interface (albeit tenuous) to your document management system so you have to bear this in mind.

My client didn't have a formal DMS so to speak. Instead they had a shared drive with documents grouped in folders. We put the URL of the shared drive document location as an attribute of the document CI - this was so we knew where it lived. Whenever the document was updated (rarely) a new version was saved to the shared area and a CR was raised to update the corresponding document CI in the CMDB.

Some people might ask 'what is the point of having docs as CIs in the CMDB if that is all you did with them?'. Well, we actually used document CIs in building what we called 'service maps' in the CMDB. For example, if we had a server that had certain DR arrangements we would have the server CI and we would have the DR info in a doc and we would link the 2 with a relationship within the CMDB.

I've kept these answers brief for the sake of the forum (I could write pages and pages!), but if you want to mail me offline with further questions please do so!

[dboylan]

Poloneck, I think you win the award for the longest first post. Congratulations!

[UKVIKING]

Nah, I think he is a contender

Hey ITILAdmin ?

Do you have a answer ?
_________________
John Hardesty
ITSM Manager's Certificate (Red Badge)

Change Management is POWER & CONTROL. /....evil laughter

[ITILadmin]

[poloneck1]

Hey, does this mean I win a prize?

[Ed]

Yep

You get a plaster coated putty medal inscribed 'The longest 1st Quote (We think) presented by - Oh there's a problem, we are too far away!!

Never mind - It's the taking part that matters!!

Regards

Ed

[UKVIKING]

I will open an service request ticket in the relevent system to have some one stick it to him or her.
_________________
John Hardesty
ITSM Manager's Certificate (Red Badge)

Change Management is POWER & CONTROL. /....evil laughter