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: WVXD
New Today: 82
New Yesterday: 95
Overall: 141521

People Online:
Visitors: 53
Members: 1
Total: 54 .

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 - Tips on creating a DSL
 Forum FAQForum FAQ   SearchSearch   UsergroupsUsergroups   ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Tips on creating a DSL
Goto page 1, 2  Next
 
Post new topic   Reply to topic    ITIL Forum Index -> Related Topics
View previous topic :: View next topic  
Author Message
N03L
Newbie
Newbie


Joined: Apr 13, 2005
Posts: 1

PostPosted: Wed Apr 13, 2005 7:13 pm    Post subject: Tips on creating a DSL Reply with quote

I'm trying to impliment ITIL after passing the practitioners exam and the biggest quick fix for us will be a Definitive Software Library. Can anyone provide links or first hand experience of starting from scratch with a DSL. We have many CD's and network based .MSI files which need to be recorded and also physically stored.

Any help and advise would be greatly appreciate it.

N03L
Back to top
View user's profile
David Atherall
Guest





PostPosted: Thu Apr 21, 2005 1:25 am    Post subject: DSL implications Reply with quote

Hi,

Most companies have some form of unstructured DSL however, one disadvantage is that if you deploy software (MSI) from your DSL to a Workstation or Server the location of where it was installed FROM is written to the machine's registry.
If you are designing a DSL structure you should have a DR process in place to recover if the DSL is lost.

Placing applications onto the DSL.
1. If the application comes as an MSI then all you have to do is perform and "Admin Install", if you need to make changes to a default install then build a transform (MST) for those changes.

The structure should be in the format;
\\Server\DSL\ProductManufacturer\ProductName&Version

e.g. for Microsoft Office 2003
\\Server\DSL\Microsoft\Office 2003

Any Service Packs of Patches (MSP) can be "Slipstreamed" into the Admin Install point.

All other (MSI) applications should be treated the same.


2. For thos applications that do not meet the new MSI certification then you SHOULD convert these application so that the become MSI's and then treat them as above.

Hope this helps

David Atherall
david.atherall@btinternet.com
Back to top
Azard
Senior Itiler


Joined: Apr 26, 2005
Posts: 56

PostPosted: Wed May 04, 2005 10:52 pm    Post subject: Creating a DSL Reply with quote

Hi, I think having a DSL is required, but I am not sure starting with a DSL is your quickest win. Let me explain.

Lets say all you are doing is putting your .MSI files and CD's into your DSL. While this does provide for storage, it does not address the issues of:
- is this production only software?
- is this only shrink wrap or also homegrown applications?
- have you put in place methods to track software licenses?
- do you know if you have software licensees that can be reallocated, or are buying extra licenses?
- how do you promote software to your DSL?

You may be thinking you are ending up with a win with just a DSL for storage, however, unless these issues, and others are thought of before putting into place your DSL, you may end up with a DSL that may not be used in the long run.

Hope that provides a few things to think about.

Cheers

Azard
Back to top
View user's profile Send e-mail
dailo
Newbie
Newbie


Joined: Jul 16, 2005
Posts: 7

PostPosted: Sun Jul 17, 2005 2:19 am    Post subject: Reply with quote

I've been told by my fellow workmate that the DSL is actually a physical store. You actually store the physical CD and package in one centralised location, secured and locked up with only 2 personnel authorised to access it.
The burnt back up copies of the software and network distribution point for your organisation's software is part of the DSL but its not the DSL per se.

You have to secure the network distribution and only allowed authorised techies to it. Make sure you take down all the mandatory details like package name, version number...etc
Back to top
View user's profile
Guest






PostPosted: Tue Oct 04, 2005 11:43 pm    Post subject: Software for the Logical Store Reply with quote

Is there any commercially available software that handles the logical store portion of the DSL?

I am in the process of setting up a DSL and my management would prefer not to develop the logical store in-house.

Any suggestions would be appreciated.
Back to top
javierarcal
Senior Itiler


Joined: May 27, 2005
Posts: 79
Location: Madrid-Spain

PostPosted: Wed Oct 05, 2005 1:42 am    Post subject: More About DSL Reply with quote

About a product to manage DSL, in my current customer they are using a Borland product called Starteam to store and control versions of products developed using Java and Delphi tecnology to deploy they are using a proprietary development.

Hope it helps
Javier
ITIL-Consultant
Madrid-Spain
Back to top
View user's profile Send e-mail
randarbie
Newbie
Newbie


Joined: Jun 04, 2005
Posts: 3

PostPosted: Fri Sep 15, 2006 12:07 am    Post subject: NO3L - How did you end up doing with your DSL Project? Reply with quote

I am traveling down the same road you were on with the DSL. I want to know how your project turned out. Are there any suggestions or warnings you would give based on your experiences.
Back to top
View user's profile
Guerino1
Senior Itiler


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

PostPosted: Fri Sep 15, 2006 5:43 am    Post subject: Definitive Software Library & Local Software Library Reply with quote

Hello All,

DSLs are a very tricky thing. Think of them as the centralized reference and repository for "all" software and software related constructs, regardless of whether the software is built internally, provided by third parties, machine generated, etc. The DSL should rarely, if ever, be touched by human hands.

We've found very few enterprises that have implemented them successfully. Most have many small, inconsistent, unstructured, and somewhat redundant DSLs spread throughout their enterprises and wish they had thought it all through beforehand.

Another problem is that while ITIL specifies the need for a Definitive Software Library (DSL), it totally misses the need for and definition of a Local Software Library (LSL) (This is a term I've been using for years, due to the lack of a more formal definition.) The LSL is critical to the success of a real DSL and acts as a shadow of the DSL on the Machine that actually runs the software. It's like the Microsoft or Sun system directories that they install to on your machines, except that you are now the vendor and it is "your" vendor partition. This helps ensure standard installation structure and processes on all of your machines.

Here are some things we recommend you keep in mind about DSLs and LSLs:

- There should be "1" DSL. It should not be a federated model, although, you can break up storage partitions to map them in seamlessly.
- The DSL should look consistent to all OS platforms and the machines that run them. This can be done through tools like SAMBA.
- The DSL should be appropriately backed-up/replicated.
- User IDs that access the DSL (typically for product installation, build, deployment, etc.) should look the same to all OS platforms.
- The DSL should have a way of distinguishing between 3rd party software and custom built software
- The DSL should be able to consistently store and render all file forms/suffixes/types, regardless of the OS platform.
- The DSL should have partitions for each environment (i.e. Dev, Integ, UAT, Prod, etc.) to separate different quality instances of product installations (you may want to test alpha and beta versions of products
- Software should be stored in the DSL by Product Name and by Product Release, so that you can access any version of any product.
- The DSL should be visible from each and every machine in your enterprise (for example through mounting/mapping)
- Master software builds should dump their results to controlled areas in the Product Release branches of the DSL.
- The DSL's contents should never be touched by human hands. All software that is installed and/or moved across environment partitions, and/or referenced for builds and installation should be accessed, created, edited, etc. only through automated scripts that have full logging and auditing capabilities.
- Some applications should be able to run directly off of or from the DSL, others should be able to run in a totally decoupled form, off of or from their own machine's LSL
- Environment Lockdown Policies, with complete permissioning rules should exist for every environment partition. Example rules involve being able to read forward but not write forward while being able to write backward but not read backward, across environments.
- Every Product partition should have it's own Product Manifest File
- Every Release partition should have it's own Release Manifest File
- Release Paritions should be broken up into at least three sub-paritions: one for Source Code, one for installation components (ITIL calls them Release Units), and one for Regression trees.
- Release sub-partitions should be broken up to meet the needs of the specific application/product/software.
- Build rules should be stored in the source tree along with all other source code CIs.
- On promotion of Changes from one environment to another, related source code deltas should be moved through automated means across the same respective partitions.
- Builds should be re-executed in every environment to ensure that nothing points back to CIs that exist in previous environments
- Upon build and deployment to remote systems, only necessary CIs and RUs should be put into LSLs.
- Product ID names should follow a standard convention and should be compatible with all OS platforms.
- Release/Version ID names should follow a standard convention and should be compatible with all OS platforms.

The problem, here, is that the list of requirements for building a solid DSL is huge and I can't possibly list them all, here, without writing a huge specification document. Each of the above can be broken down into a great deal of sub-requirements that will keep you busy for a long time.

Also, what I described above is the "physical" store. The logical store is really the CMDB that sits above it all and works in lockstep with it.

Anyhow, I hope this information helps.

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


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

PostPosted: Fri Sep 22, 2006 6:00 am    Post subject: Reply with quote

flybd5 wrote:
dailo wrote:
I've been told by my fellow workmate that the DSL is actually a physical store. You actually store the physical CD and package in one centralised location, secured and locked up with only 2 personnel authorised to access it.
The burnt back up copies of the software and network distribution point for your organisation's software is part of the DSL but its not the DSL per se.

You have to secure the network distribution and only allowed authorised techies to it. Make sure you take down all the mandatory details like package name, version number...etc


Your workmate is correct. A DSL is supposed to be a _physical_ store, not a hard disk full of folders and install files.


Good day all,

Actually, in this day and age, where a great deal of media is acquired by download, a physical store is not only antiquated, it's useless. Any enterprise that truly centralizes the management of software storage has come to terms with the fact that the only workable solution for a DSL is a virtual store. Anything that comes on a DVD, CD, etc. is simply copied to the virtual store and managed just like any SW that came from non-physical sources, such as downloads from vendors, open source communities, etc., who provide you with no real physical media. If you work in a large enterprise, the majority of the SW you have will come from virtual sources and a physical DSL will be useless. If you implement the DSL as a physical store, you will have "two" definitive stores (one for physical and one for virtual) and then you've lost the "definitiveness".

Another thing is that a physical store, in a highly distributed enterprise, is highly illogical, since you may have people in India who need SW that is stored in some room in NY. What are you supposed to do, pack it and ship it so they can use it? ...And have other organizations wait until they're done with it before they can use it? ...And then rely on someone to ship it back to you so you can put it back in the closet, again? Sounds pretty ridiculous if you think about it. A virtual store is accessible from around the world by all the appropriate stakeholders that need it. If managed properly, it also ensures that systems are leveraging the appropriate version of SW.

In this day and age:

- Most SW is downloadable from the vendors or open source communities
- Manuals are online, so you don't need hardcopies, especially if many people around the world need access to them. It's cost ineffective to have many copies and doing so almost guarantees that people are looking at different versions of the documentation.
- License keys can be stored in manifest files on the virtual DSL and license files can also be kept local to the SW.

In this day and age, the least common denominator for SW is "virtual" so I highly recommend you consider going in that direction to save yourself a lot of work and headaches.

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


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

PostPosted: Fri Sep 22, 2006 9:54 am    Post subject: Reply with quote

Hello Juan,

Please see my comments embedded, below...

flybd5 wrote:
Guerino1 wrote:


Good day all,

Actually, in this day and age, where a great deal of media is acquired by download, a physical store is not only antiquated, it's useless.


I completely disagree.

For one thing, that goes against ITIL best practices.


Juan, if you blindly quote ITIL, you may be in for some serious issues and surprises, especially if you ever manage the implementation of ITIL disciplines in large scale enterprises. Anyone with significant IT experience, management or otherwise, will tell you that ITIL has some pretty significant gaps and flaws in it. Remember, ITIL was created by humans who are not perfect. This is why it can only be referred to as a set of best practices and not defacto standards. Above and beyond ITIL is common sense.

For example, if you try to implement RUP (which is more of a development set of best practices) and ITIL (which is a set of operational best practices) in the same enterprise, you will have natural conflict, as the two have recommendations that don't mix well, together. They're both highly accepted best practices. Which one do you choose? The answer is simple... the answer that best fits your needs for implementation. And, that might go directly against ITIL. If you start quoting ITIL blindly, you may start losing credibility with some of the executives in your enterprise. If you're an ITIL implementer for 3rd party clients and you start quoting ITIL, blindly, you stand a high probability of losing their respect. Again, anyone with significant IT experience has to use their judgment. The most important part of ITIL is your personal ability to take the best of ITIL, while leaving the worst of it, behind, not what you learned in class...

NOTE: If you go to itilskeptic.org, you will find many smart people that can find very significant issues with ITIL. Please remember, it was created by humans and ultimately has flaws because of it.

Quote:
And for good reason -- a virtual store is utterly useless in recovery if the infrastructure that supports it and gives access to it is what has failed.


Why would you implement a virtual store that isn't appropriately replicated to an offsite disaster recovery location? That's standard practice these days, Juan. You may want to understand such a solution. Your point is a non-issue if your store is properly replicated (either manually, by copying to two geographically disperse locations, or automatically, like through SAN replication).

Quote:
It is one thing to have archival storage for day to day purposes, it is quite another to have a DSL that appropriately supports an IT Service Continuity Management process.


I recommend you understand what you're saying here. Many of the largest and most advanced enterprises in the world are doing the exact opposite of what you're recommending. Every enterprise that asks me to build them a DSL, when given the decision between a virtual one and a physical one, instantly understands the need for the virtual one over the physical. And, if you don't think a virtual DSL can support an IT Service Continuity Management process then I have to question your understanding of IT Service Continuity Management processes. The process doesn't care where the software is located. It just cares that it's available, managed properly, definitive, and accessible under disaster scenarios. A single room is a single point of failure! The building can burn down, Juan. A virtual store that is mirrored to an offsite location is far more reliable.

Quote:
Quote:
Another thing is that a physical store, in a highly distributed enterprise, is highly illogical, since you may have people in India who need SW that is stored in some room in NY.


This IMO is a non-issue. Secure transmission for recovery purposes is commonplace these days.


This is rather ridiculous, Juan. No one is doing this anymore. So, Japan goes down while NYC is asleep and the software is in a NYC data closet. You have to page and wake someone up to drive to the office to find a CD in the closet, pop it in a drive, FTP the software over to Japan, while they wait for hours, under the assumption that the person will definitively respond? In the mean time, they're losing millions of dollars per minute because they can't process trades? This isn't acceptable in this day and age, Juan. More common is the practice that you simply have the virtual DSL and the mirror (at least one of them many times more) available, world-wide through multiple mounts/mappings, so that if the primary that's in NYC goes down you can simply access the secondary in Japan, or Italy, or who cares where it is? The mirrors are physically located in separate areas to allow for D&R. Remember, a single room in a single building can burn down. It's a far greater risk than a virtual DSL.

I don't want to make you feel bad but your comments seem to be those of someone that does not have a lot of experience. In this day and age, "physical" is out. The whole world is about virtual and on-demand access to things. Hosted solutions, which are virtual, are popping up all around you (TraverseIT, Salesforce, CollabNet, ADP, Aladdin, QTX, and many more). 10 to 20 years from now, most enterprises will most likely not even have their own IT organizations, as they'll simply get most of everything they need, such as their business apps, through the web... all virtually. Just google the acronym "SaaS". These companies are popping up everywhere.

Remember, a lot of what is in ITIL was written many years ago, before many technologies and processes out-paced it, and because of it, pieces will not hold up in today's world. It's fine to understand ITIL and use it as a baseline so that you don't have to start from scratch. It's very dangerous to blindly quote it. You will cost your enterprise far more money, more time, and more unnecessary effort if you blindly quote it than if you use common sense. Again, anyone who implements ITIL for a living, like my own organization, will be able to show you real areas of ITIL that are flawed and incomplete. I highly recommend you understand all options before implementing any solution, even those that don't come from ITIL.

Anyhow, 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
Guerino1
Senior Itiler


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

PostPosted: Sat Sep 23, 2006 9:31 am    Post subject: Reply with quote

Juan,

In one email you write:

Quote:
It's not a server where you store files, it's a _cabinet_.


In another you write:

Quote:
I'm not even going to address it, since it is quite apparent you're not familiar with automated physical medium storage and retrieval technology.


I have yet to see anyone that has implemented an automated solution to walk into a cabinet to pull retrieve software and put it on line to make available for access by systems and people. Could you please help us understand where to get such a solution?

For everyone reading this thread, please understand that a "physical" point of storage for all your software is a cabinet or a room. If your building burns, you've lost all media, period. You will never recover unless you've copied everything onto at least two separate storage solutions (disk/disk or disk/back-up tape).

You also wrote:

Quote:
Quote:
Remember, a single room in a single building can burn down. It's a far greater risk than a virtual DSL.
Still fixated on a single room? Hmm.

Seems to me that when you increase the number of failure points, the risk of failure INCREASES, not decreases. Even in the 21st century, KISS is still quite relevant.


I'm fixated on the single room because it's your recommendation. It totally and utterly has me shocked (and quite entertained, to be honest) that anyone with any level IT experience would recommend such a solution.

By your response, you're telling me and the rest of the world that you don't understand simple failover of geographically separated virtual storage mirrors from one physically and geographically separated storage device to another physically and geographically separated storage device. Juan, for your sake, I hope you're not going to apply for a job with anyone reading these threads.

Multiple mirrors are set up to automatically fail over to each other in order to eliminate single point of 'business service failure," Juan, not necessarilly the failure of a single DSL mirror. It's the business you're trying to keep alive, Juan, not the single DSL instance. Who cares which DSL you're using, if you've got "N" to pick from? Financial firms lose millions of dollars per minute when a critical trading system is down, Juan. They can't wait for someone to go to a room to get the software and re-package it and re-install it. They automatically fail over to a different mirror with no service interruption. You can't do that with a cabinet or room, Juan.

BTW, in many enterprises, many of their systems "run" directly off of their DSL to eliminate code spam. How do your automated systems run off of your closet or cabinet, Juan? Let me guess, you don't have a centralized difinitive virtual store, right? You install all copies of all software on each and every machine so that you force the largest storage costs for your enterprise, right?

-------------------------

Quote:
Quote:
For example, if you try to implement RUP (which is more of a development set of best practices) and ITIL (which is a set of operational best practices) in the same enterprise, you will have natural conflict, as the two have recommendations that don't mix well, together. They're both highly accepted best practices. Which one do you choose?


I happen to be certified on both, and frankly I'm surprised to see you mix apples and oranges like this. RUP is about iterative software development best practices and process. I used to work for one of the major players in the industry in this area. ITIL covers much more, and only one of its areas deals with the application lifecycle management, something with which I am also intimately familiar. If you have to wonder whether to choose RUP or ITIL for _service management_ you don't understand either one.


If you're certified in both then you understand that they both can't "equally" co-exist. True they are apples and oranges but also true that many enterprises want both. And, it's also true that they have common intersections. One is an apple in that it describes how to manage "Development" (RUP) and the other is an orange that describes how to manage "Support & Infrastructure" (ITIL). If you truly understand the two, then you know that there are common intersections between the two. You'll also know and understand that there are points in the intersections that totally conflict with each other, such as their definitions and expectations of Release Management. So, Juan, please tell the world which definition and set of expectations for Release Management is correct: RUP's? or ITIL's?

There is a very high probability that you walk into more enterprises using RUP than you do ITIL. One of these that uses RUP wants to "additionally" implement ITIL. In other words, they want the apple and the orange. What do you do, Juan? If you understand the two, you understand that you have multiple conflicts between the two. They're both best practices and RUP has a much higher world-wide penetration and level of respect. Are you going to try and convince the CIO of that enterprise that RUP is wrong when he has his many hundreds or thousands of developers and engineers using it successfully? Since Release Management is defined a totally different way in RUP than it is in ITIL, why don't you explain to everyone on the forum how you will implement two different definitions of Release Management, successfully, with absolutely no ambiguity for the enterprise?

-------------------------

[quote]
Quote:
10 to 20 years from now, most enterprises will most likely not even have their own IT organizations, as they'll simply get most of everything they need, such as their business apps, through the web... all virtually. Just google the acronym "SaaS". These companies are popping up everywhere.


More the reason to pay close attention to protecting your codebase and production releases in a format that mitigates the majority of threats out there. How you replicate that for convenience is up to the organization.[quote]

So you literally take every one of your software releases, copy them to physical media and then go put them in your cabinet/room? And, you have all your distributed offices ship all physical CDs, DVDs, Tapes, etc. to the one location in the world that has the cabint/room?

For those of you reading, I keep asking these questions because now it's becoming more of entertainment for me...

-------------------------

Quote:
Frank, I've been in the industry for a little over 30 years, working with both hardware and software, in every aspect of the lifecycle, from lowly tech to managing large infrastructures, in just about every size company from mom and pops to over 100,000 employees. Quoting blindly from anything is not something I do. I teach ITIL because it is the best practices framework that make perfect sense to me, after seeing one organization after another make mistakes such as being too trusting of technology and then paying for their complacency when a crisis becomes a disaster. The organizations from which I learned the lessons I teach not only support some of the largest IT systems in the world and provide the largest scale IT services you could imagine, one of them is the primary disaster recovery center for the US government. The point is, I didn't just land on the block, I've been around it several hundred times.


Juan, if you're telling people to use a "physical" store, such as a cabinet or room like you have stated multiple times above, you are quoting blindly.

For anyone else reading this thread, I'm not asking you to take my advice. I'm asking you to please use your own common sense when you read all of this. You will absolutely know for yourself what does or does not make sense when you read it.

As always, I hope this information helps.

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


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

PostPosted: Sat Sep 23, 2006 10:24 am    Post subject: Reply with quote

flybd5 wrote:
BTW, anyone who thinks virtual repositories are appropriate as sole disaster recovery support solutions ought to read Information Week, and the story of what happened to one solitary sysadmin, a Mr. Roger Duronio, did to their systems and network. It's been four years since, and they are _still_ recovering.

UBS was hit on March 4, 2002, at 9:30 in the morning, just as the stock market opened for the day. Files were deleted from up to 2,000 servers in both the central data center in Weehawken, N.J., and in branch offices around the country.

An article also came out listing the 5 things UBS did right, and the 5 things they did wrong. Guess what one of them was. You got it. Physical store for backups.

4. Backup, Backup, Backup: With files wiped off of up to 2,000 servers, the saving grace for restoring all of that information lay with the backup tapes, Jones says. It came out in trial that UBS had backup tapes for 80% of the servers that had been hit. The servers with solid backup tapes were up and running in a matter of days. "Imagine you're the one person who has to fix all this," says Jones. "It's not the best thing [percentage-wise] in the world, but imagine if they didn't have any backups."



Juan,

Please tell me and all the readers of this forum that you're not equating tape backup to a DSL? Iron Mountain is not a DSL. Backing up your primary DSL is mandatory but the backup of the DSL and all your systems (i.e. the location they're stored in) is not the DSL.

To all forum readers... please be careful and take the time to fully understand everything in this thread before you run off and blindly implement what's stated, here. I can't stress enough that your own common sense is the most valuable tool you can leverage.

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


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

PostPosted: Sun Sep 24, 2006 10:20 am    Post subject: Reply with quote

flybd5 wrote:
Guerino1 wrote:
Please tell me and all the readers of this forum that you're not equating tape backup to a DSL?


With all the experience and knowledge you claim you have, Frank, if you don't know the answer to that within the context of what happened to UBS, no amount of explanation will help.

Have a nice day, Frank.


Hello Juan,

For those interested, the article about what happened to UBS is at: informationweek.com/news/showArticle.jhtml?articleID=190900365

As you'll see once you read the article, their attack was from an insider, who had intimate knowledge of their environment, and had nothing to do with a DSL nor could the implementation of a DSL have helped them (much) because the attack was distributed and hit each and every server, world-wide. In reading the article, you'll find they successfully recovered from back up, for approximatley 80% of their systems. They did not recover from a DSL. They recovered from tape. This has nothing to do with a DSL.

The implementation of a centralized and virtual DSL could have helped them recover a bit faster but only if it was not part of the attack.

Juan, I guess I don't understand your point, since the situation with UBS has nothing to do with a DSL. Backing up your environment to tape is common sense. Could you please elaborate what it is that you're trying to get us to understand from the UBS situation?

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


Joined: Feb 08, 2008
Posts: 1

PostPosted: Fri Feb 08, 2008 7:30 pm    Post subject: Full Release, Delat Release Reply with quote

Hi All

Thank a lot for all this trick you've share with us.

I am a young Itiler, and I have to work with release management.
In my company there is an unstructure DSl (just a share folder).
I am thinking on how i could start
to implement a serious DSL.

In you previous explanation, everythink was clear to me exept 1 point:

How do you manage the database evolution for "custom build software".

I mean, in some other word, if a request for change lead to a "database structure change"
How do you store the delta release when a database structure change occured ?

In the dsl, do we store full release and delta release ?

Rgds,
Nicolas
Back to top
View user's profile
Display posts from previous:   
Post new topic   Reply to topic    ITIL Forum Index -> Related Topics All times are GMT + 10 Hours
Goto page 1, 2  Next
Page 1 of 2

 
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.