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
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.
Posted: Thu Apr 23, 2009 4:51 am Post subject: Source Code Control
I've been working in the ITIL world for a little while now. I went through v2 and most recently v3 training. The one thing I've always had a hard time making the leap from real world to ITIL world is Source Code Control / Version Control.....where exactly does this fit in?
I think it safe to say it's part of Configuration Management. But that's about as far as I can go. It's not part of the CMDB....but I guess it could be the DSL or DML depending on your ITIL flavor.....but it always seemed like a stretch given their definition.
Then there's the configuration manager....could that possibly be stretched to be the code librarian?
Am I in for a headache trying to wrap source code control in ITIL, or am I overthinking this?
Joined: Mar 04, 2008 Posts: 1893 Location: Helensburgh
Posted: Thu Apr 23, 2009 7:26 pm Post subject:
Controlling source code would not normally be a service management issue. Typically, your software supplier (even if this is your in-house development team) are wholly responsible for the delivery and maintenance of the software. You care that they can be relied on, but not in how they do it. no more than you care about the processes whereby your hardware supplier manufactures the components.
The closest you should get is, in certain circumstances, you might audit your supplier (hardware or software) to determine that their quality management system is adequate to meet your needs of reliability. In this case you do not specify how they do it; you simply establish that what they do is adequate.
This is not to say that with in-house development environments you do not make management links in order, say, to streamline processes, but that Service Management has no management role concerning source code per se. _________________ "Method goes far to prevent trouble in business: for it makes the task easy, hinders confusion, saves abundance of time, and instructs those that have business depending, both what to do and what to hope."
William Penn 1644-1718
I can see where Release Mgmt starts to enter the SDLC...we are actually going through this now.
Regarding the CMDB, aren't individual pieces of code and release packages considered CI's?
We are going that route....and we're using the CMDB to compare one environment to another to make sure we're apples to apples during a given release.
Because of this, the role of code librarian is trying to be pushed onto the Configuration Librarian/Manager. Does that make sense to anyone here? It makes more sense to me that this responsibility should be within each development team....but it is obviously going to add overhead to each team...and no one willingly wants to take that on.
To me, this is the biggest area where ITIL falls down. IT is more than computers, servers and networks. Most IT shops are several "engineering" departments crammed under 1 umbrella. But I'm sure the OGC knew that going in and sort of side stepped it because once you enter the "software" realm, things get awfully complicated and confusing awfully quick.
Joined: Mar 04, 2008 Posts: 1893 Location: Helensburgh
Posted: Fri Apr 24, 2009 5:49 am Post subject:
mdibatti wrote:
Regarding the CMDB, aren't individual pieces of code and release packages considered CI's?
Yes, if and only if there is benefit in managing them at that level. what goes in the CMDB is entirely dependent on the management requirements of the organization in question.
mdibatti wrote:
To me, this is the biggest area where ITIL falls down. IT is more than computers, servers and networks. Most IT shops are several "engineering" departments crammed under 1 umbrella. But I'm sure the OGC knew that going in and sort of side stepped it because once you enter the "software" realm, things get awfully complicated and confusing awfully quick.
Thoughts?
No ITIL does not fall down here. ITIL deals with software just as much as it does with servers etc. I do not consider that CCTA sidestepped software atall. In fact there is a whole volume in v2 entitled Application Management.
What it does not do is deal with software development for the very obvious reason that software development has got little to do with Service Management.
The wider the scope, the less focussed the guidance would be. For this reason ITIL recognizes the need for Service Management to interface with many other activities but does not try to define the manner in which they are carried out.
There may even be a case for considering v3 to have gone too far, or at least to have been interpreted in ways that go too far by some people. _________________ "Method goes far to prevent trouble in business: for it makes the task easy, hinders confusion, saves abundance of time, and instructs those that have business depending, both what to do and what to hope."
William Penn 1644-1718
I didn't realize they got into Application Management. I've only taken foundation classes. How would someone know about that? I don't remember them mentioning App Mgmt during v2 training.
We are using ITIL as a way to help us manage our Change, Release and Configuration processes. Maybe we are overstretching ITIL into SCM territory.....the it's tough to judge which parts fall under which methodologies. As far as the SDLC goes, we have a process for this, but the distinction between ITIL and SCM isn't as clear....to me anyway.
Joined: Mar 04, 2008 Posts: 1893 Location: Helensburgh
Posted: Fri Apr 24, 2009 5:35 pm Post subject:
mdibatti wrote:
I didn't realize they got into Application Management. I've only taken foundation classes. How would someone know about that? I don't remember them mentioning App Mgmt during v2 training.
Application Management is not part of the course because it is not directly Service Management and that is what the course is about.
The range of v2 is (I'm borrowing from Wikipedia here to save typing):
The IT Service Management sets
1. Service Delivery
2. Service Support
Other operational guidance
3. ICT Infrastructure Management
4. Security Management
5. The Business Perspective
6. Application Management
7. Software Asset Management
To assist with the implementation of ITIL practices a further book was published providing guidance on implementation (mainly of Service Management):
8. Planning to Implement Service Management
And this was finally supplemented with guidelines for smaller IT units, not included in the original eight publications:
9. ITIL Small-Scale Implementation
The Service Management training is concerned with the content of the first two books.
Without saying that everything was absolutely right, it is fair to say that CCTA understood that there was a bigger picture and that it was important. however the focus remained solid and that probably explains the success of ITIL.
I'm surprised if app mngmnt did not get at least a passing reference during a full blown v2 course. I'm sure it was discussed on my course in 1995. It's the sort of thing that someone is almost bound to bring up in open discussion.
mdibatti wrote:
We are using ITIL as a way to help us manage our Change, Release and Configuration processes. Maybe we are overstretching ITIL into SCM territory.....the it's tough to judge which parts fall under which methodologies. As far as the SDLC goes, we have a process for this, but the distinction between ITIL and SCM isn't as clear....to me anyway.
I presume you mean Source Code Management. The interface between the two is quite obvious: Service Management does not care about source code and Source code Management does not care about how the live code is run. but don't get confused because the design and development process has to care about the production environment.
How you manage this interface is not amenable to formal description because ITIL is not a formal system and you are free to implement Service Management in any way you see fit, applying ITIL guidance appropriately throughout.
Therefore the interface you need to design has to be specified on the basis of your requirements for the interface (or what you want to achieve). There is no magic solution.
I would not worry about 'ITIL territory' and 'SCM territory'. I would focus on roles and responsibilities and process and information flow and then apply the relevant techniques and guidance where it is useful. It does not seem fruitful to design things around labels like ITIL and SCM when you can be much more meaningful with, e.g., software development, code maintenance, service implementation, service management. _________________ "Method goes far to prevent trouble in business: for it makes the task easy, hinders confusion, saves abundance of time, and instructs those that have business depending, both what to do and what to hope."
William Penn 1644-1718
Joined: Mar 04, 2008 Posts: 1893 Location: Helensburgh
Posted: Fri Apr 24, 2009 7:07 pm Post subject:
UKVIKING wrote:
And if you need some one to help you, Diarmid is available
... and very capable!
cheers John. _________________ "Method goes far to prevent trouble in business: for it makes the task easy, hinders confusion, saves abundance of time, and instructs those that have business depending, both what to do and what to hope."
William Penn 1644-1718
Diarmid, thank you very much for your helpful and thoughtful responses. It certainly helps clear things up for me.
By SCM, I actually meant Software Configuration Management....which could also be SCCM, Software Change and Configuration Management. This has more to do with development and code maintenance/control.
I think part of my problem is, right now I'm working on 2 projects.....1 is implementing a CMDB and the other is implementing an ALM system (application lifecycle mgmt)...which is release/version/source control. I'm trying to apply ITIL to everything and sort of confusing myself in the process
All of these processes are intertwined....in an IT development organization you really have a hybrid of several processes all coming together and at times it's hard to make the distinction. Like you said, you need to think about the individual processes, not giving them a label, but at the same time, when you want to reference some guidelines, it's confusing where to start looking.....cause you really could stretch ITIL to cover everything.
Things are clearer now, but it's still confusing stuff. Lot of acronyms in this post, eh? Thanks again!
Posted: Wed Aug 29, 2012 11:22 am Post subject: Software development and version control and the ITIL CMDB
The following article sheds some interesting light on this topic, was written a few months after this discussion thread. Those searching the net looking for answers might find it useful.
[Removed by Admin]
It includes (and explains)
"You may believe that all your organisation does is release applications, and you have been doing it successfully for years. We encourage you to think of that as providing an “application service”, and then being able to benefit from the excellent work and best practices that are documented in ITIL V3. It will lead to a more seamless and joined up organisation, providing more value to the business."
And (also explained)
"All successful software development has some form of change, configuration and release management systems in place. It will include defect tracking (both for defects and changes typically) and version control tools. So we classify the software development repositories as a physical CMDB, part of the overall federated CMDB or CMS."
Joined: Mar 04, 2008 Posts: 1893 Location: Helensburgh
Posted: Wed Aug 29, 2012 3:52 pm Post subject:
No URLs allowed.
You need to disguise the URL. E.g. www dot site dot net
or just give search engine key words.
Of course, these quotes are only fully relevant for an organization that develops its own software for its own systems, and they shed less light on the needs of independent software development organizations. _________________ "Method goes far to prevent trouble in business: for it makes the task easy, hinders confusion, saves abundance of time, and instructs those that have business depending, both what to do and what to hope."
William Penn 1644-1718
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
Forum FAQ
Search
Usergroups
Profile
Log in to check your private messages
Log in
