Search
Topics
  Create an account Home  ·  Topics  ·  Downloads  ·  Your Account  ·  Submit News  ·  Top 10  
Modules
· Home
· Content
· FAQ
· Feedback
· Forums
· Search
· Statistics
· Surveys
· Top
· Topics
· Web Links
· Your_Account

Current Membership

Latest: ESteil
New Today: 45
New Yesterday: 42
Overall: 148231

People Online:
Visitors: 66
Members: 2
Total: 68 .

Languages
Select Interface Language:


Major ITIL Portals
For general information and resources, ITIL and ITSM World is the most well known for both ITIL and ITIL Books. A shorter snapshot approach can be found at ITIL Zone

Related Resources
Service related resources
Service Level Agreement
Outsourcing

Note: ITIL is a registered trademark of OGC. This portal is totally independent and is in no way related to them. See our Feedback Page for more information.


The Itil Community Forum: Forums

ITIL :: View topic - Which CIs are changing?
 Forum FAQForum FAQ   SearchSearch   UsergroupsUsergroups   ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Which CIs are changing?

 
Post new topic   Reply to topic    ITIL Forum Index -> Change Management
View previous topic :: View next topic  
Author Message
dsemeniuk
Itiler


Joined: Feb 06, 2007
Posts: 41

PostPosted: Wed Jun 06, 2007 11:23 pm    Post subject: Which CIs are changing? Reply with quote

Question:

There is a RFC to change a custom application, say ABC Version 1 in produciton, installed on Server XYZ, to fix a defect that was reported (incident).

On the RFC form, what CIs would the person choose at indicate which CIs are changing?

Would you link the current software application ABC Version 1 to the RFC, and as well would you enter a new CI, ABC Version 1.1 at this time, and would you link the XYZ Server as you would be changing the relationships on that server when ABC 1.1 is deployed because you would be replacing ABC 1.0 with 1.1.

Thanks.
Back to top
View user's profile
dboylan
Senior Itiler


Joined: Jan 03, 2007
Posts: 189
Location: Redmond, WA

PostPosted: Thu Jun 07, 2007 2:21 am    Post subject: Re: Which CIs are changing? Reply with quote

dsemeniuk,

I would think that you would be changing the version Attribute of the existing CI. You would link the RFC to the ABC software CI indicating that successful implementation of the Change will trigger an update to the version Attribute. The relationship of the CI to other CIs would remain the same.

Don
Back to top
View user's profile
dsemeniuk
Itiler


Joined: Feb 06, 2007
Posts: 41

PostPosted: Thu Jun 07, 2007 5:25 am    Post subject: Reply with quote

Hi Don,

Currently, we create a whole new software CI for each new version that gets built or bought due to the fact that old versions can still be installed on other hardware and do not get updated all at the same time so we still need to have the ABC Version 1 CI with links to say some other hardware and create a new CI called ABC Version 1.1. So we do not just go and update the version attribute as this could misrepresent what actually exists in our infrastructure.
Back to top
View user's profile
dboylan
Senior Itiler


Joined: Jan 03, 2007
Posts: 189
Location: Redmond, WA

PostPosted: Fri Jun 08, 2007 2:48 am    Post subject: Reply with quote

dsemeniuk,

I think you might want to look into using Variants as described in Service Support (the blue book) in section 7.11.2.

Don
Back to top
View user's profile
dsemeniuk
Itiler


Joined: Feb 06, 2007
Posts: 41

PostPosted: Fri Jun 08, 2007 11:17 pm    Post subject: Reply with quote

Hi,

I've read that section but do not quite understand the concept of variants. Could you explain it better than the book and how it would support tracking different versions of of the same software in the CMDB?

Thanks.
Back to top
View user's profile
dboylan
Senior Itiler


Joined: Jan 03, 2007
Posts: 189
Location: Redmond, WA

PostPosted: Sat Jun 09, 2007 6:04 am    Post subject: Reply with quote

dsemeniuk,

I can describe how Variants could be implemented in a CMDB.

Let's say you track all your desktop computers as CIs. And they are all identical Dell computers. The only difference is their Service Tag #, location, network segment, and the users they are associated with.

The way you would handle this using Variants would be to have one master record in your CMDB for the Dell Desktop CI. It would contain any Attribute you would want to track such as memory, OS, Monitor Model, etc. as well as the Relationships to other CIs that all the Dell Desktops share. Such as the Relationship to the Underpinning Contract with Dell, the relationship to the network domain controller, etc.

You would then create individual Variant Records in the CMDB for what is unique about each computer. Attributes including its Service Tag #, its location, its network segment might be tracked in the Variant record. You would also track unique Relationships in the Variant record such as the user its assigned to, the governing SLA, etc, etc.

You then link the Variant records to the master CI record.

Now in this situation, your database has become much more easy to manage. If you want to upgrade the OS of every computer to Vista, you don't have to update each individual CI record, you just update the one master CI record.

But using Variants limits you on what you can differentiate. You cannot have half of the computers managed by one Underpinning Contract and half by another if you want to track the UC in the master CI record.

Using the Variant method, you could have one master CI for the common aspects of the applications' attributes (who supports it, availability times) and their common relationships (the governing OLAs, servers, database feeds, etc).

Each version of the app would get a Variant record that tracked the variable attributes of the application (version, compile date, etc.) and relationships (use your imagination). You would then link the Variant records to the master CI record.

Managing the master CI modifies the common aspect of all the different versions of the app. yet you still have the ability to track the non-common aspects of the app using the linked Variant records.

Don
Back to top
View user's profile
Guerino1
Senior Itiler


Joined: Jan 01, 2006
Posts: 500
Location: New Jersey

PostPosted: Sun Jun 10, 2007 1:32 am    Post subject: Re: Which CIs are changing? Reply with quote

Hello dsemeniuk,

Please find my comments, embedded below...


dsemeniuk wrote:
There is a RFC to change a custom application, say ABC Version 1 in produciton, installed on Server XYZ, to fix a defect that was reported (incident).

On the RFC form, what CIs would the person choose at indicate which CIs are changing?

Would you link the current software application ABC Version 1 to the RFC, and as well would you enter a new CI, ABC Version 1.1 at this time, and would you link the XYZ Server as you would be changing the relationships on that server when ABC 1.1 is deployed because you would be replacing ABC 1.0 with 1.1.


It's important to understand that you're mixing ITIL Change Management with Software Development "Requirements Management" and "Defect Management". Requirements Management is not a formally recognized discipline within ITIL and Defect Management is really Problem Management but at a very narrow Product related scale.

When you generate your RFC, it should be used by the Application Development team as the driver for work that needs to be done.

If the RFC is a request to fix something that's broken, whatever is broken should be logged in your Defect Tracking/Problem Tracking system, and developers should be working from a prioritized list of Defects/Problems, within that system to fix things. The Developers and/or Analysts should then go through a Requirements Analysis process to understand what it will take to fix the Defect/Problem.

If the RFC is a request for something new to be implemented, that new feature request should also drive the Requirements Managment process, which will work to determine what work needs to be done to implement the new features.

The Product Owner (the person formally accountable for the "application" in your example) should be working with appropriate stakeholders to address the next release (version 1.1 in your example). So, for example, the next Release of the Product/Application will include 10 defect fixes and 12 new features. The Product Owner will then work to ensure that a Release Manager is assigned to the Release, to ensure that all related work for the Release is properly planned, managed, and executed, throughout all environments (Developers' Workspaces, Common Development Build Environments, Systems Integration Testing Environments, User Acceptance Testing Environments, Product Environments, etc.).

As the Product Release (version 1.1) gets rolled out (deployed) into new environments, each new instance of the Product will, itself, be a virtual Asset that runs on one or more physical Assets. Therefore, the CIs that are impacted by the original RFC are the Product (via the new Release) and any and all Assets it touches as the Release moves through environments. Within the Product, there may be many Product-related CIs that are also modified, such as Source Code Files, Build Documents, Deployment Documents, User Documents, Reference Documents, etc. that are also modified and must be versioned and tracked appropriately. Done correctly, your original RFC will be associated through appropriate relationships to any and all CIs that it comes in contact with (even human CIs, such as stakeholders like End Users, Release Managers, Developers, etc. and even Organizational CIs, like the Organizations that each and every one of those stakeholders belongs to).

The ability to see what anything is associated/related to comes from doing very solid Configuration Management. Therefore, you should be able to see any and all relationships that an RFC impacts through relevant degrees of separation (DOS). Done so, you can all CIs that are directly impacted through DOS1 and things that are indirectly impacted through DOS2, DOS3, etc. So, in aswer to your original question, yes, your RFC should be tied to all of those things you mention, and much, much more...

Anyhow, I hope this helps.

My Best,

Frank Guerino, CEO
TraverseIT
On-Demand ITIL
Back to top
View user's profile Send e-mail Visit poster's website
Display posts from previous:   
Post new topic   Reply to topic    ITIL Forum Index -> Change Management All times are GMT + 10 Hours
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

Powered by phpBB 2.0.8 © 2001 phpBB Group
phpBB port v2.1 based on Tom Nitzschner's phpbb2.0.6 upgraded to phpBB 2.0.4 standalone was developed and tested by:
ArtificialIntel, ChatServ, mikem,
sixonetonoffun and Paul Laudanski (aka Zhen-Xjell).

Version 2.1 by Nuke Cops 2003 http://www.nukecops.com

Forums ©

 

Logos/trademarks property of respective owner. Comments property of poster. Rest 2004 Itil Community for Service Management & Foundation Certification. SV
Site source copyright (c)2003, and is Free Software under the GNU / GPL licence. All Rights Are Reserved.