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: Casas
New Today: 50
New Yesterday: 68
Overall: 131810

People Online:
Visitors: 48
Members: 4
Total: 52 .

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

Definitive Software Library

 
Post new topic   Reply to topic    ITIL Forum Index -> Related Topics
View previous topic :: View next topic  
Author Message
ejdulcimer
Newbie
Newbie


Joined: Mar 09, 2007
Posts: 3

PostPosted: Thu Mar 15, 2007 6:00 am    Post subject: Definitive Software Library Reply with quote

Question I am heading up a Release Management implementation and one of the big items will be to establish a definitive software library. I have seen a number of threads, debating whether one should go the "hard copy" route, with software stored in a secure fireproof cabinet (as mentioned in numerous ITIL publications) or whether one should consider the "soft copy" route, storing the software on network storage.

I can see good arguements on both sides.....and we've seen remote sites where servers crashed due to hardware issues and physical media was the only route we could take to recover the O/S from.

What I would like to find out from the user forum, is what has your experiences been with establishing a DSL and what did your organization choose? Was it "soft copy" on network storage, "hard copy" in vaults, or a combo?

I'm really open to hearing the pros and cons and see what works for you!
Back to top
View user's profile
Guerino1
Senior Itiler


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

PostPosted: Thu Mar 15, 2007 11:08 pm    Post subject: Reply with quote

Hello Ejdulcimer,

In this day and age, there is no real reason for a hard copy. Soft copies, that are secured through distance are usually more than adequate. They also allow for quicker restoral and recovery, if they're part of your BCP/DR plan (which they should be, if done correctly).

What we do for most enterprises is help them set up geographically separated mirrors of their DSL and ensure that their SW Check-In, Build, and Distribution processes, automate the replication of information across all mirrors, to ensure they stay in sync. It doesn't have to be this elaborate, though. If it's acceptable to your enterprise, it's adequate to simply replicate across the mirrors, periodically, based on a frequency that meets the needs of the enterprise (for example, nightly).

To summarize, in this day and age, there really aren't too many good business reasons for hard copy of SW and I wouldn't recommend wasting time and money to create hard copies unless you have a real business reason to do so. Besides, setting up DSL mirrors will help you with a real BCP/DR plan, which you should have, anyhow.

Anyhow, I hope this helps.

My Best,

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


Joined: Sep 16, 2006
Posts: 3261
Location: London, UK

PostPosted: Fri Mar 16, 2007 1:49 am    Post subject: Reply with quote

Frank

While a remote networked DSL for the most part is a good thing, what happens when the network link to the store is comprimised ?

Having a physical store in a safe location - relatively accessible - in more than 1 location as well as multiple virtual storage I thinkis a good thing

Remember the fact that on 9/11 the NYCity Emergency Response center was in the sub basements of the WTC.

But... the hard and most complex decision on what sort of DSL to have is what does the business want for the $$
_________________
John Hardesty
ITSM Manager's Certificate (Red Badge)

Change Management is POWER & CONTROL. /....evil laughter
Back to top
View user's profile
Guerino1
Senior Itiler


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

PostPosted: Sat Mar 17, 2007 9:24 am    Post subject: Reply with quote

Hi John,
Quote:
Having a physical store in a safe location - relatively accessible - in more than 1 location as well as multiple virtual storage I thinkis a good thing


I'm not against this but just haven't found it useful in any situation I've ever been in. It's easier to create "more than two" DSL mirrors, all at separate locations, and digitally replicate everything across each mirror. If you build your network correctly, there should be no single point of failure, other than the building, itself. If the building goes down, you've got a much bigger problem than just trying to recover SW.


Please find my answers, embedded below.

UKVIKING wrote:
While a remote networked DSL for the most part is a good thing, what happens when the network link to the store is comprimised ?


First, let me say that if you understand software, you can't possibly copy everthing to every location. This is never a good answer. Also, there are solutions in place that require centralized and shared dependencies. Since all SW is not created equal, there is no definitive answer for which all SW will fall into. Your answer has to be able to handle everything: localized installs (typically to Local Software Libraries or LSLs), centralized installs to DSLs, hybrids between the two, etc.

Assuming multiple facilities that have computers and/or datacenters (which is very common in this day and age): Having hard copy at every facility doesn't scale for a number of reasons. One, think of the logistical nightmare of constantly creating, distributing, and keeping all the hard copies for each facilitiy up to date. It wouldn't be cost effective and it would take a tremendous amount of effort to keep up to date. Please note that this covers most "medium" sized enterprises, who typically have more than one facility, just like larger enterprises. The only difference would be the quantity of facilities for a medium would be far less than a large.

Assuming a single facility, where the scale/quantity of SW you have to worry about is much smaller: For the small enterprise that only has a single facility, it's as simple as setting up a few servers at one or more of owners' homes or renting a spot in a colocation center or 3rd party infrastructure provider, such as a Rackspace.com, DataPipe, etc.

Note on restoring from hardcopy: If you're restoring from hardcopy, here are some things to note. A smart enterprise is building packaged wrappers around all the software they install in their enterprise. This means that the software off of a 3rd party hard copy is typically not ready for install, since the enterprise will require customized configurations/packages. Therefore, if you wish to copy all "packaged" software to hardcopy, it will be a very ugly logistical nightmare to maintain and constantly refresh all your hard copies. Also, you can't possibly keep one set of hardcopies for every location. It's just not cost efficient or logistically practical.

Note on managing multiple hardcopies in multiple locations: This is a logistical nightmare that is very expensive to manage. I have yet to see a single enterprise that wants this or subscribes to this theory. It breaks down as soon as you get to mid-sized enterprises that have many facilities. Also, in a real environment, the state of SW is "constantly" changing, especially if you have many of your own internally constructed applications that have dedicated development teams (very common). Keeping up with hardcopies is virtually impossible if you're a fast moving, mid-to-large-sized enterprise.

Quote:
Remember the fact that on 9/11 the NYCity Emergency Response center was in the sub basements of the WTC.


If you keep more than two mirrors (let's say three at a minimum) and keep them all geographically disperse, you can pull a ripcord and simply point to any mirror at any point in time. Even the ripcord can be automated with manual BCP/DR procedures as a backup.

Quote:
But... the hard and most complex decision on what sort of DSL to have is what does the business want for the $$


A bare bones DSL is "extremely" simple and cheap to create and manage, if done properly. It's as simple as creating a centralized disk that is mounted/mapped to all machines that has a highly structured and consistent taxonomy on it that accounts for internally constructed SW vs. externally constructed SW. As you get more elaborate, you can add localized manifests, log directories, archiving directories, and much, much more. It's actually pretty simple to design and implement, once you've seen one in action. The hardest part is deciding how to automate everything around. The key rule should be that "human hands should NEVER touch the DSL", as all SW installation, updates, builds, promotion through environments, versioning, etc. should be handled by automated scripts and tools.

NOTE: A common and critical mistake that most enterprises make is not understanding that the DSL should have the same structured sub-taxonomies for every environment that your enterprise uses, such as Common Development/Build, Systems Integration Testing, User Acceptance Testing, Production, etc. (Localized and private Workspaces are usually not mapped into the DSL structure, although in this day and age it makes sense to put them on a common share.) Standard Release Management procedures should ensure that SW promotion occurs in such a way that SW CIs move forward, across the environments (a good practice is through automated RFC promotion). SW rejection should move back to a state where everything must be addressed in a localized and private Workspace environment (a good practice is to have this happen automatically, through RFC rejection).

A very good practice is to ensure that all Release Units are reconstructed, from scratch, in every forward environment to ensure that there are no dependencies on CIs in backward environments.

NOTE: A flaw in ITIL is that it leaves out the Local Software Library (or LSL). An LSL is required on every machine, to keep localized, slim shadows of SW CIs and RUs that allow for runtime decoupling from the DSL. ITIL doesn't even come close to discussing this. A good DSL design will require LSLs to be put in place. This is why companies like MS and Sun have localized directories (their own vendor LSLs) on all machines. A good practice is to have one for your own enterprise that shadows the structure of the DSL.

But I digress... Very simply, in this day and age, I don't see too many enterprises making use of hard copies for SW. It's usually an expensive, logistical nightmare. Again, in this day and age, your network shouldn't be your single point of failure.

Anyhow, I hope this helps.

My Best,

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


Joined: Sep 16, 2006
Posts: 3261
Location: London, UK

PostPosted: Mon Mar 19, 2007 2:13 am    Post subject: Reply with quote

While there is an inherent additional benefit for Continuity Management that there is a DSL; the primary objective of the Definitive Software Library (DSL) is NOT a repository for Disaster Recovery or as ITIL defines it Continuity Management

What the DSL is suppose to be for the business is the master repository of the software that the business uses.

This would mean the CD, diskettes, other media for the operating systems, applications that the customer has purchased either directly from the software vendor or through the purchase of the hardware associated with the software has a centrally located place and appropriate controls on accessing the master CDs etc.

The DSL not only should be the repository for the CD but it must be in a controlled environment.

The meaning of controlled environment is that there is some sort of process/procedures for gaining access to and relinquishing the media for the software and that only 'authorized' people have access to the media.

Because the third objective of the DSL and the CMDB is making sure that the business is making sure that the business has the licenses for the software in question.

This is a major concern for all of the software vendors - making sure that there are no unauthorized copies or insufficient # of licenses for a business

For Example, if you buy Norton Anti-Virus software, there is a commercial (personal/individual) version as well as a commercial (corporate / business). Each one has a different pricing scale for multiple seat licences

I know of more than 1 business that buys the 'individual' version copy at 29.95 or whatever the price is... and install it on 200 machines - even though the license is for 1-5 machines.

And when the business is audited directly or indirectly, there will be a penalty in the making to recover to Norton.

Same applies to all software vendors. How else do they make money....

So the DSL is a control issue as well as storage issue

Now to your silly little nit about the DSL not being a LSL or what ever.

ITIL is trying to be generic as well as trying to cover an specific issue in the DSL. ITIL does not care whether you have a Local, regional, favorite, mobile, virtual or whatever else sort of descriptive adjective adverb or even the ultimate silly word Mauve Software Library. ITIL wants you the ITIL practitioner to get your company to have the Definitive Software Library as part of your ITIL environment so that you have control over what software has been authorized in your IT environment.

If the business is happy calling the ITIL defined DSl a LSL or whatever...who cares. However, complaining that ITIL does not specific state LSL or RSL is specious.

This is the definitiion straight from the Service Support book (v2)

The library in which the definitive authorised versions of all software CIs are stored and protected. It is a physical library or storage repository where master copies of software versions are placed. This one logical storage area may in reality consist of one or more physical software libraries or filestores. They should be separate from development and test filestore areas. The DSL may also include a physical store to hold master copies of bought-in software, e.g. a fireproof safe. Only authorised software should be accepted into the DSL, strictly controlled by Change and Release Management. The DSL exists not directly because of the needs of the Configuration Management process, but as a common base for the Release Management and Configuration Management processes.
_________________
John Hardesty
ITSM Manager's Certificate (Red Badge)

Change Management is POWER & CONTROL. /....evil laughter
Back to top
View user's profile
Guerino1
Senior Itiler


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

PostPosted: Mon Mar 19, 2007 2:06 pm    Post subject: Reply with quote

Hello John,

Please find my responses, embedded below.

UKVIKING wrote:
While there is an inherent additional benefit for Continuity Management that there is a DSL; the primary objective of the Definitive Software Library (DSL) is NOT a repository for Disaster Recovery or as ITIL defines it Continuity Management


Please note that I did not state that the DSL is for DR, nor do I disagree with you about keeping a centralized repository for hard copy media that comes in from 3rd party sources. It's just that keeping hard copy media has such little value, in this day and age, especially since the source for most SW is virtual (i.e. soft), these days. I'll elaborate on this more, below.

Anyhow, yes, the DSL itself is the primary repository, not the backup repository. That's what the "D=Definitive" stands for. It can't be "definitive" if it's not the main repository. The issue at hand is where to keep "copies". You recommended hard copies in multiple facilities. I recommended soft copies in multiple facilities. My reason for this is that in this day and age, hard copy of SW is a very small percentage of all SW that an enterprise uses.

Again, in this day and age, the majority of all SW sources are virtual (i.e. soft copy), not hard copy...

  • Virtually all 3rd party open source SW comes in virtual form, not hard copy.
  • Virtually all 3rd party vendor based SW comes in virtual form, not hard copy.
  • All software created by your own enterprise is "always" virtual, before it can ever be burned to hard copy.

It's important to understand that less and less SW is coming into an enterprise via a hard form of media. As a matter of fact, the majority of all software sources, these days, are virtual. Therefore, if you want hard copy, you will have to burn and maintain your own. Most smart vendors realize that there is a significant cost that comes with burning their own media and fewer and fewer vendors are doing so. Your very first copy of purchased SW might be hard copy but, in this day and age, once you move past the first purchased version, there is a very high probability that all upgrades and patches usually come from download sites. Therefore, if the majority of your SW is already coming in soft copy form, you have to ask yourself what the real value is of burning all that soft copy to hard copy and mainting all upgrades to the hard copy. It's a logistical nightmare that would require dedicated headcount to maintain, in any mid-to-large sized enterprise. Not something any smart IT leader wants to do.

Quote:
What the DSL is suppose to be for the business is the master repository of the software that the business uses.


This is inaccurate. The DSL is the Definitive Software Library for "all" software, regardless of whether the internal non-IT organizations (i.e. your internal businesses) use that SW, the internal IT organization uses that SW, and/or any external stakeholders, such as clients, use that SW. The DSL is a repository for "all" SW, John, not just what the business uses.

Quote:
This would mean the CD, diskettes, other media for the operating systems, applications that the customer has purchased either directly from the software vendor or through the purchase of the hardware associated with the software has a centrally located place and appropriate controls on accessing the master CDs etc.


John, I don't know how much SW engineering experience you have but you shouldn't be directly installing vendor based SW, in an unpackaged form, in your infrastructure. Doing so is considered a bad practice. Those wrappers help give you control in many forms, such as for inventorying, custom configurations, agent based communications, and much more. What this means is that once you create the packages, the CDs are pretty much useless. While I wouldn't recommend it, you can safely throw them away if you keep appropriate backups of your packaged SW. The reason why is because you will be reconstructing your environment from the packaged SW, not from the hard media that it came from. Once you copy the CD to the virtual DSL, you have captured it for the package to leverage it. There is no need to go back to the CD, even if you have to update the package. In other words, it's the customized packages that include the reference to the soft copy of the original SW that are valuable to your enterprise, not the CDs, themselves.

Again, at this point, I do agree with you and recommend that you keep the hard media in a centralized library, just in case you ever need them, but the reality is the CIs that are valuable to you are now in soft copy form, on the virtual DSL (hopefully versioned in your SCCS), not in hard copy form. Things like the automated build and distribution systems will require access to the SW in soft form, so you've already done the work to get it all on your virtual repository. For an enterprise to start making hard copy of all its software is not economically or logistically prudent, since things like open source SW and the SW your own dev teams build will rarely, if ever, go to hard copy. They simply don't need to. Again, this is especially the case in this day and age, where less and less provisioned SW even has a hard media source.

Quote:
The DSL not only should be the repository for the CD but it must be in a controlled environment.


True that the DSL should be in a highly controlled environment. If you want to create an additional "Definitive Hard Media Library" then, by all means, go ahead and do so. But, most software you get from sources will come to you in soft copy form. If you go to your CIO and recommend that you take all that virtual SW and burn and maintain hard copy for all of it, I want to be there for that conversation because I want to see the look on his or her face when you do so. It will be priceless!

Quote:
The meaning of controlled environment is that there is some sort of process/procedures for gaining access to and relinquishing the media for the software and that only 'authorized' people have access to the media.


John, please don't assume that I don't understand this. My firm designs and builds DSLs to clients. We do it regularly and I'm the primary architect for the solutions. I know I can sell what we do because it makes sense to the IT leaders we sell it to. I have yet to run into a CIO/CTO that requests us to build them a safe CD closet. It adds no real business value. A virtual DSL adds tremendous value as it can be mirrored and act as the foundation for many things...

  • Automated versioning
  • Automated build
  • Automated deployment/distribution
  • Automated Configuration Management
  • Automated SW Installation
  • Automated SW Instantiation
  • Automated SW Execution
  • Automated SW rollback
  • Automated Change Management that controls promotion and rejection of code across environments
  • Automated Asset Management
  • Manifest Control
  • Document Repository
  • CI Repository
  • RU Repository
  • Etc.

You can't do any of that with a hard copy library. However, your "virtual" DSL will be the baseline/foundation for all of the above and so much more.

Quote:
Because the third objective of the DSL and the CMDB is making sure that the business is making sure that the business has the licenses for the software in question.


Again, like software, the majority of all licenses that SW rely on are in soft form. Do you intend to burn hard copy instances of the soft licenses when you could simply replicate copies to safe and redundant virtual stores in split seconds, for a small fraction of the cost? John, you're not the architect for your enterprise, are you?

Quote:
This is a major concern for all of the software vendors - making sure that there are no unauthorized copies or insufficient # of licenses for a business


License Management is not the responsibility of the DSL. A DSL can help you with licenses, if done properly, but it is not the responsibility of the DSL. Soft licenses can be kept on the DSL but, even so, what about ELAs, or non-keyed Site Licenses, or Good Faith Licenses? John, there is so much to good LM that you can't possibly address it with a DSL.

Quote:
For Example, if you buy Norton Anti-Virus software, there is a commercial (personal/individual) version as well as a commercial (corporate / business). Each one has a different pricing scale for multiple seat licences

I know of more than 1 business that buys the 'individual' version copy at 29.95 or whatever the price is... and install it on 200 machines - even though the license is for 1-5 machines.

And when the business is audited directly or indirectly, there will be a penalty in the making to recover to Norton.


It sounds like you have a bigger problem around SW management than you think or would like to admit. If you can't convince your business of the value of a centralized SW engineering group that controls all inflows, engineering, packaging, deployment, distribution, installation, and maintenance of all SW, then you're not going to be anywhere close to being able to build a real DSL. You've got bigger problems to worry about, which revolve around ethical management of procured SW through controlled processes.

[quote]Same applies to all software vendors. How else do they make money....[quote]

John, they make money on billing you for, over and over again, for what they sold you. Most smart vendors put audit clauses in their sales contracts with enterprises. Trust me when I say that you haven't lived until companies like MS, IBM, BEA, and Oracle have given you notice for audit.

Quote:
So the DSL is a control issue as well as storage issue


As I stated above, I agree with this statement. Unfortunately, it appears that I have much grander visions for SW control than you do. My views on SW control include but are not limited to:

  • Controlled SW installation to the DSL, with transactional updates to the CMDB
  • Controlled Versioning, with transactional updates to the CMDB
  • Controlled Promotion of code (through RFCs) to any targeted environment, with transactional updates to the CMDB
  • Controlled Rejection of RFCs and they're related code, with transactional updates to the CMDB
  • Controlled builds (in all environments), with transactional updates to the CMDB
  • Controlled distribution of SW from the DSL to all LSLs, with transactional updates to the CMDB
  • Controlled installation of SW to target Assets, with transactional updates to the CMDB
  • And much, much more.

All of this, is far more control in an environment than you will ever get with your hard copy solution.

Quote:
Now to your silly little nit about the DSL not being a LSL or what ever.

ITIL is trying to be generic as well as trying to cover an specific issue in the DSL. ITIL does not care whether you have a Local, regional, favorite, mobile, virtual or whatever else sort of descriptive adjective adverb or even the ultimate silly word Mauve Software Library. ITIL wants you the ITIL practitioner to get your company to have the Definitive Software Library as part of your ITIL environment so that you have control over what software has been authorized in your IT environment.


ITIL is inadequate John. I know you don't want to believe that but it is. I'm not saying it doesn't have good ideas. I'm not saying it doesn't add value. I'm simply saying that a good IT leader knows that ITIL has a significant number of gaps, flaws, and contraditions in it. If you read ITIL's details on the DSL, you will find that it is all antiquated. You may be stuck in the dark ages but the majority of the readers in forum have to deal with the majority of their SW coming from virtual sources.

And John, I can't stress that if you're installing SW directly from a CD, in an unpackaged form, you have absolutely "no control" in your environment. That's why you create packages, to have control.

Quote:
If the business is happy calling the ITIL defined DSl a LSL or whatever...who cares. However, complaining that ITIL does not specific state LSL or RSL is specious.


John, do you know what a Local Software Library (LSL) is? It's a very important concept in SW engineering that ITIL does not cover, at all. It works "with" the DSL, not in place of it.

Complaining that ITIL lacks the definition of an LSL is not specious, John. It's pointing out one of ITIL's many gaps. If you want to blindly believe that ITIL is perfect, please do so. I don't think most of the readers in this forum will blindly do so. I'd like to believe that most of the readers know how to temper the information they get from ITIL with some good common sense. I can say with confidence and experience, from interacting in these forums for well over a year, that most participants in this forum do not blindly follow ITIL as being perfect. However, if you choose to do so, it is your freedom to do so and I wish you luck in your blind faith. I just wish I had the good fortune to watch you run an entire "large" IT organization with that blind faith. It would be worth the ticket price.

Quote:
This is the definitiion straight from the Service Support book (v2)

The library in which the definitive authorised versions of all software CIs are stored and protected. It is a physical library or storage repository where master copies of software versions are placed. This one logical storage area may in reality consist of one or more physical software libraries or filestores. They should be separate from development and test filestore areas. The DSL may also include a physical store to hold master copies of bought-in software, e.g. a fireproof safe. Only authorised software should be accepted into the DSL, strictly controlled by Change and Release Management. The DSL exists not directly because of the needs of the Configuration Management process, but as a common base for the Release Management and Configuration Management processes.


Read the contradition, right in their own words: "...it is a physical library...This one logical storage area may consist of one or more physical software libraries..."

Is it physical or is it logical?

Let me say that I wish you luck in implementing your file cabinet. I'm sure your CIO will find great value in your physically logical repository.

Finally, let me say that a smart person understands that ITIL was written by human beings. All human being make errors, omit details, etc. If you think that ITIL is perfect, then you are part of a minority. There are large segments of IT that ITIL doesn't cover. There are pieces of ITIL that are flat out wrong. There are pieces of ITIL that are vague and incomplete. If you choose to blindly follow it, I simply wish you my best. I don't think there is another reader on this board that I have met that would take that stance. I guess there's always a first time.

My very best to you, John. I truly believe that if you follow ITIL to the letter, you will need all the best wishes you can get. God knows that I have yet to meet a single IT leader that would would follow it blindly. Maybe, you know something that the rest of them and I don't. If that's the case, I certainly hope to learn it all from you.

Thanks for the exchange,

Frank
_________________
[Edited by Admin to remove link]
Back to top
View user's profile Send e-mail Visit poster's website
ejdulcimer
Newbie
Newbie


Joined: Mar 09, 2007
Posts: 3

PostPosted: Fri Mar 23, 2007 12:38 am    Post subject: Definitive Software Library Reply with quote

Thanks John and Frank for your feedback and your frank discussion listing the pros and cons of setting up the hard-copy/soft-copy DSL's. I knew it was going to highlight some of the shortcomings for both setups and it will be logistically a challenge to keep it updated.

As far as I can see for my own organization, based on what the business requires and mandates for the quickest recovery possible for remote office locations, we will probably have to use a combination hard-copy/soft-copy DSL, which will cascade to a LSL for remote sites. We have recently had several remote locations where hardware failures caused massive issues and only hard-copy recovery was possible, once DELL and IBM replaced hard-drives, motherboards, etc.

As both of you mentioned, the DSL will be used for more than just DR scenarios and it will be the key for our go-ahead plan for application standards enforcement. We see on a regular basis where a downloaded version of an app makes its way onto the network and it has not been fully tested or approved for use. We also have a situation with our master software cabinet where from time to time CD's go missing. It would be great to have a secured, hands-off DSL and a repository of the copies of the masters. The only versions being accessed would the copies, and this could be done using the soft-copy or hard-copy setup.

I'll conclude by saying that it will be a real challenge implementing the DSL/LSL setup in our organization. And we'll need to adapt it to meet the business needs, at the same time being able to enforce standards, etc. The more I think about the logistical side of things, the DSL really needs to be emphasized more in ITIL. In the Release Management section in the "Blue Book," the DSL is covered in two paragraphs and one diagram. Given the options that are now available and what should be considered when implementing a DSL that is not outdated from the get go, the DSL warrants a chapter all by itself.

Thanks again guys for all your feedback....and have a great day!
Back to top
View user's profile
UKVIKING
Senior Itiler


Joined: Sep 16, 2006
Posts: 3261
Location: London, UK

PostPosted: Fri Mar 23, 2007 1:58 am    Post subject: Reply with quote

Well... I am without words to thank you ejdulcimer

I thought no one followed Frank and I when we got into a digital tennis match

But Frank and I see things from different sides of the IT fence but I agree that 1 - ITIL is just a guide and incomplete in things.... and 2- nothing is ever completely A or B

And Frank.. if I knew the answer to everything....would I tell you....
or would I tell any body else....

I know enough that I dont know everything but since I have been dealing with IT since military (80-84)ARPAnet (84-87), University and commercial teaching (88-99) and IT ops (99-now); I know have seen a lot of stupid things done on IT - including my VT100 Nuke graphic program to the Old Crow Society Conference (AFCEA in 85)

giggle
_________________
John Hardesty
ITSM Manager's Certificate (Red Badge)

Change Management is POWER & CONTROL. /....evil laughter
Back to top
View user's profile
UKVIKING
Senior Itiler


Joined: Sep 16, 2006
Posts: 3261
Location: London, UK

PostPosted: Fri Mar 23, 2007 2:01 am    Post subject: Reply with quote

With the current trend in smallness

USB datasticks are getting into the GB range.... they could be datasources for remote sites.... if they are controlled

They of course would not be a DSL, LSL but a miniSL giggle
_________________
John Hardesty
ITSM Manager's Certificate (Red Badge)

Change Management is POWER & CONTROL. /....evil laughter
Back to top
View user's profile
Guerino1
Senior Itiler


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

PostPosted: Sat Mar 24, 2007 3:29 pm    Post subject: Definitive Software Library (DSL) Taxonomy Design Reply with quote

Hello Ejdulcimer,

ejdulcimer wrote:
In the Release Management section in the "Blue Book," the DSL is covered in two paragraphs and one diagram. Given the options that are now available and what should be considered when implementing a DSL that is not outdated from the get go, the DSL warrants a chapter all by itself.


You've hit the nail on the head. You cannot possibly design a DSL based on the short, vague, and highly incomplete description of a DSL by ITIL. There is so much more to one that you must take in the full picture of how you will tie this central storage point to the rest of your enterprise. It is critical to understand how it will behave as the center of your storage nervous system. It is for this reason that I always recommend that people take what they read in ITIL with a grain of salt. It was written by humans with good intent but it is far from complete and far from perfect. If you implement things to the letter, you carry that incompleteness and that imperfection into your enterprise.

BTW, a great rule to keep in mind as you implement your DSL is that no end user hands should ever touch the content in the DSL, directly. This means no developers, engineers, or business users should ever manually create, modify, access the content on the DSL. This rule will help you automate all access to it.

DSL Taxonomy: A very simple taxonomy that we start our customers with is as follows:

dsl<instance_id>/<environment>/products/internal/<product_mnemonic>/<release_identifier>/src

dsl<instance_id>/<environment>/products/internal/<product_mnemonic>/<release_identifier>/install

dsl<instance_id>/<environment>/products/internal/<product_mnemonic>/<release_identifier>/regressions

dsl<instance_id>/<environment>/products/external/<product_mnemonic>/<release_identifier>/src

dsl<instance_id>/<environment>/products/external/<product_mnemonic>/<release_identifier>/install

dsl<instance_id>/<environment>/products/external/<product_mnemonic>/<release_identifier>/regressions

Examples:

dsl000/dev/products/internal/prd0001/1.0.0/src/(products specific custom source code tree)
dsl000/dev/products/internal/prd0001/1.0.0/install/(product specific custom release unit tree)

dsl000/uat/products/external/oracle/1.0.0/src/(oracle specific distributed code)
dsl000/prod/products/external/oracle/10g/install/(packaged oracle code for intallation)

Some Notes:

NOTE 1: Typically, the master <instance_id> would start at the lowest number, such as "0000", and mirrors would increment "0001", "0002", etc. "0000" is your definitive instance, to be used for core replication to other mirrored instances.

NOTE 2: The <environment> helps you maintain branches for your different environments and allows you to have different "quality" of SW versions, as it gets promoted through various environments for development and test. It will allow you to automate your SW based RFC promotion/rejection across environments. It will also help you standardize your representations of environments across your master enterprise. Example values for <environment>would be (in sequential order):

  • "dev" = Common Development (used for the first, master "common" build), where all developers have finally merged their code for the first time
  • "integ" = Systems Integration Testing (used to create and isolate a build that is ready for integ testing
  • "uat" = User Acceptance Testing (used to isolate a build that will be strictly for uat testing and will typically address functional testing, performance testing, etc.
  • "prod" = Production (which would allow you to isolate the final build that will be pushed/pulled to Production LSLs or allow you to burn your hard media for final distribution.

NOTE 3: The reason the hardcoded string "products" exists in the taxonomy is because you may want to create a live and interactive "data" related DSL. This is not something that is covered at all by ITIL but as you mature, you will understand the need for it (centralized log files, dynamic configuration files, etc.). If you don't put this separator in, now, it will be very difficult to put one in to partition data from products, later.

NOTE 4: The reason for hardcoding "internal" vs. "external" in the path allows you to distinguish between what software was created internally, by developers, vs. SW that was acquired by external parties (Vendors, Open Source Community, etc.). Trust me when I tell you that you won't want to comingle the two.

NOTE 5: <product_mnemonic> simply allows you to put a product mnemonic string or identifier in the path for uniqueness across products (usually a short string based on standard naming convention that maps back to the actual product in the subtree).

NOTE 6: <release_identifier> simply allows you to put a release versioning mnemonic or identifier in the path for uniqueness across all releases, within a product (usually a short string based on a standard naming/versioning convention that maps back to the actual product version in the product subtree). Example Release Versioning Mnemonic: <major_id>.<medium_id>.<minor_id>

NOTE 7: Within the release subtrees, you will need to break the original source code (contained in the "src" subtree) from the Release Units you will construct, based on your SW builds.

NOTE 8: The "install" branch will be used for Release Units that will normally be constructed based on automated builds that pull from the "src" (i.e. "source") branch of the same product and from the "install" branch of other products to build the Release Units for that specific product. The use of an install branch will allow you to separate the CIs you use for building from the CIs you use for installation to target assets (what ITIL refers to as Release Units).

NOTE 9: The "regression" branch will allow you to isolate regression code and Release Units from the actual product code and Release Units, yet, it will allow you to colocate them under the same product branch for consistent accessibility across all products and all releases.

NOTE 10: You will mirror this taxonomy in all DSL mirrors and in all "Local Software Libraries" (i.e. LSLs) that exist local to each asset that has localized storage.

NOTE 11: Once this or any taxonomy is in place, you will be able to put controlled processes around it, for how information gets put into, gets created within, is modified within, gets versioned, is exported from, and is accessed from the DSL. You will also have to put controlled processes in place for how things move across branches for promotion and/or rejection, how things are replicated to mirrors, and how things are pushed/pulled to/from LSLs. It is important to automate all of this to optimize your enterprise.

Again, there are many ways to implement the taxonomy for your DSL but this is always a good start, as it will leave you room for growth.

Please note that all of the above is the Copyright of TraverseIT (Transfered to TraverseIT by GCMS in 2006, created by GCMS in 2000). It represents a subset of a much more comprehensive engineering document that is used to implement enterprise class Master Software Repositories (a.k.a. Software Repositories, Definitive Software Repositories, Software Libraries, Definitive Software Libraries) and Local Software Libraries. Readers are more than welcomed to use it and distribute it freely but we kindly ask that as a courtesy to its source, you properly acknowledge the material's source as TraverseIT in any documentation created and/or distributed with this material or any permutation or derivative, thereof.

Anyhow, I hope you find this material to be useful.

My Best,

Frank
_________________
[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 -> Related Topics 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.