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: Numswede
New Today: 31
New Yesterday: 76
Overall: 142326

People Online:
Visitors: 64
Members: 1
Total: 65 .

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 - CI Attributes for Software
 Forum FAQForum FAQ   SearchSearch   UsergroupsUsergroups   ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

CI Attributes for Software

 
Post new topic   Reply to topic    ITIL Forum Index -> Configuration Management
View previous topic :: View next topic  
Author Message
JeffL
Newbie
Newbie


Joined: Oct 19, 2005
Posts: 6

PostPosted: Wed Jan 11, 2006 6:47 am    Post subject: CI Attributes for Software Reply with quote

I've seen a number of attribute lists for CI's but most of them seem to be hardware-centric. I'm really interested in seeing an attribute list for software CI's. For example, CI's related to Cobol Modules, PC DLL's, Websphere Component, JAR file, .NET, C#, VB.NET code, install scripts, etc.

What I want to do is to be able to leverage our CMDB to identify those CI's that have the highest Operational Risk and potential Impact when a RFC is presented to our CAB.

Can someone identify a soure for software CI attributes ??
Back to top
View user's profile
rjp
Senior Itiler


Joined: Mar 12, 2005
Posts: 255
Location: Melbourne, Australia

PostPosted: Wed Jan 11, 2006 10:59 am    Post subject: Reply with quote

It would be very easy to over complicate this - the attributes you need are those required to;

a) uniquely identify an 'instance' of software
b) track, control, and audit changes to those instances

One thinb to bear in mind is that much software these days is auto-updated - which will change version numbers, etc. Take care to account for this in your information management.

Also scope is very important - identify the level of modularity at which change will be controlled and don't go below that. How effectively you can identify the boundaries of a software CI, is going to be a more critical success factor than deciding what info to keep on it.
Back to top
View user's profile Send e-mail AIM Address Yahoo Messenger
Guerino1
Senior Itiler


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

PostPosted: Sun Feb 12, 2006 3:44 pm    Post subject: Reply with quote

Hello Jeff,

I don't know if this will help but I've a significant amount of experience in this area and so I'll take a shot at it. Here are what have been and have not been considered to be CIs:

CIs include:
Source Code files (names, versions, locations, creation dates, mod. dates, etc.)
Libraries & Modules
Documentation (design, build, deployment, user, reference, tutorials, configuration, etc.)
Test Cases
Test Reference Data
Test Execution Rules

We have never considered the running instance to be a CI but rather a SW asset, as it represents a running instance of the software product. You can have more than one instance running, like you can have many servers running, which represent instances of a server product.

I hope this helps.

Regards,
_________________
[Edited by Admin to remove link]
Back to top
View user's profile Send e-mail Visit poster's website
rjp
Senior Itiler


Joined: Mar 12, 2005
Posts: 255
Location: Melbourne, Australia

PostPosted: Sun Feb 12, 2006 11:14 pm    Post subject: Reply with quote

Mmm Frank, that is an interesting area.

I think in all but the most rigorously controlled environments (maybe NORAD Confused ) run-time instances would be out of scope - but primarily because you would change a run-time by changing the parameters of the application - its configuration - which as you indicated might be included as a CI. This would be more than sufficient from a change control point of view. Though availability, continuity and capacity managers might cough loudly at this point.

I do think it gets a little grey when software licensing comes into it - and in some cases run time stats have to be collected. But in this case the reports would probably be the change controlled documents (if required). And of course there are any number of tools out there to automate this.

There is a lot of hype around application services - run-time instance on demand. From an inventory/asset magement (or even an infrastructure management) point of view - this might appear to simplify deployment tasks to the point where there are no longer requirements to keep such 'demand ware' under configuration managment.

But what about where such load and run app-services are a production factor in the delivery of other services. How is the end-to-end view of the service chain maintained, configuration information delivered to incident managment - and availablity data rolled up to managment as real time business information?

Some interesting challenges ahead - not all of them resolveable through underpinning contracts.

(Not even beginning to think about business owners and staff basing their widget production processes on some future Google apps without telling ICT Shocked The day will come!)
Back to top
View user's profile Send e-mail AIM Address Yahoo Messenger
Guerino1
Senior Itiler


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

PostPosted: Mon Feb 13, 2006 2:01 am    Post subject: Reply with quote

Hi Ric,

I don't know that anyone would reject your notions. It is true that many runtime instances need to be managed, end-to-end. Actually, most need to be. However, few are.

The only time we view a license as a configuration item is when the license, itself, is a dependency for any part of the end-to-end process (build, deployment, installation, execution, etc.). A corporate wide ELA is typically not considered a true CI. However, you're better off managing it as one, just the same. It will save you headaches, later.

I have to say that I personally think there is a confusing gray area in ITIL when it comes to CIs vs. Release Units (RUs). Quite simply, we view RUs as nothing more than "deployable or distributable CIs" as opposed to those that you would keep hidden from end-users.

To you're point about application services, I think any strong shop will always manage its dependencies, from soup to nuts. The very fact that automation always requires your automation solutions to know "exactly" what they're using in order to perform the work, at a very minimum, will require stringent CI management. If licenses are part of that process then they, too, will be managed as CIs. Loosely coupled CI's, such as end-user documentation, will always be open for interpretation.

Your point about businesses strapping their solutions to services, such as those available by Google, is an interesting one that is definitively becoming a problem. How do you absolutely ensure the integrity of a remote service that is not absolutely guaranteed to be there, especially since you're not paying for it? I see more and more developers tying their business vertical software to such services, like Google maps, to show their businesses that they can perform cool things with their software. Their poor, unsuspecting, business clients have no clue about the volatility of such arrangements. I wonder what happens if someone ever buys Google and decides to shut such services down? While it's unthinkable to believe someone has that kind of money, it happens all the time. And, since the services are not paid for, what if the new owner feels they're not part of the future vision? Imagine world reaction after everyone has unwhittingly tied themselves to such services and now find themselves in a position to get off of them quickly. (BTW, I'm very impressed by Google services and their technologies and the above is not to imply otherwise.)

Regards,
_________________
[Edited by Admin to remove link]
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 -> Configuration 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.