Setting up a DSL

[rosevidney]

Hello,

I have been tasked with setting up a DSL from scratch. Can anyone give me any advice on layout etc and what I should consider?

Many thanks for your help

Rachel

[Roger]

Hi Rachel

I see that a few folks have looked at your question, but not replied... I guess the reason is that it's a tricky question...

Firstly, as you may be aware the DSL and DHS are replaced by the DML in v3.. !!!!

BUT I have a favorite saying that I like to use for all tough questions... it's my saying and when you read it you will agree with me...

It all depends !

There are no hard and fast rules about what a DSL should look like or contain.. the important point here is that the DSL is a CONCEPT, rather than an actual product. The primary consideration is that the information about what is stored in the DSL is held in the CMDB.

You will also have a physical and electronic storage area and you will have names on media that follow your release policy. You will not have archives of software in the DHS... they will live in a seperate area.

[Guerino1]

Hi Rachel,

I've designed and implemented a number of DSLs for multiple large enterprises. A good DSL, when complete, is a very complicated system. ITIL's description of a DSL is very limited and vague. You may want to start with some very basic things...

1: Create a common repository/disk that will get mounted/mapped to each and every machine
2: Create at least one partition for every standard environment you have (Development, Systems Integration Testing, User Acceptance Testing, Production). More environments are always better than less, as you can always scale down. Scaling up become a problem after everything is in place and working.
3: Create a structured "root" taxonomy/hierarchy for storage on the disk. Something like /dsl00001/<environment>/Products/
4: Create sub-categorized taxonomies. For example:
.../Products/3rd_Party/<Product_Name>/Release_ID>, and
.../Products/Internal/<Product_Name>/<Release_ID>
5: Create domain based taxonomies. For example, under "Internal", you might have something like:
.../<Product_Name>/<Release_ID>/src (for source code)
.../<Product_Name>/<Release_ID>/install (for installable entities or what ITIL calls Release Units)
.../<Product_Name>/<Release_ID>/regressions
6: Once all your taxonomies are in place, for each environment, then you have to decide on policies and procedures. For example:
- Since your DSL becomes your golden copy repository for all code, a best practice is that, aside from administrators, no human hands should ever have access to the content. All access should be through automated abstraction scripts that captures who has performed work, when, etc. (for true auditing, since you will need to prove to auditors that you can control who does or doesn't have access to the DSL and how you know and can control that.
- You will need to come up with World Group, and User permissions.
- You will need to come up with appropriate Groups that you can cluster specific roles into
- What are your naming standards for Products & Releases (both Internal and Vendor)
- Who installs vendor software on the DSL and when?
- How does internally designed source code get into the DSL
- Builds of software automatically should populate the sub-branches in the "install" directory
- Human hands should never touch the "Internal" products partition
- Etc.
7: After your first phase of roll-out/deployment, you will need to build your abstraction scripts/code/utilities.
- Ability to copy media to/from the DSL
- Ability to Check-In/Check-Out source code and sync with the SCCS
- Ability to "promote" RFCs (and ultimately their associated code) across environments
- Software Build Templates
- Software push/pull distribution templates
- Partition Lock Templates
- Tools to map and control RFC dependencies
- Tools to map and control Build dependencies
- Tools to map and control Release dependencies
- Tools to map and control Product dependences
- Tools to map and control Deployment/Distribution dependencies
- Etc.

On top of this, ITIL misses a very critical point. You will not only need a DSL but you will also need a Local Software Library (LSL) on every machine, which is something that ITIL does not even mention. Your deployment tools should distribute/pull software from the DSL into the LSL, which is a local shadow taxonomy of the DSL. Upon distribution, all appropriate Release Units get mapped into their appropriate LSL directories to ensure that 1: everything is on the target machine in a structure & organized way and 2: to ensure that all dependencies are accounted for, since in order to run Product A - Release A.X.Y.Z, you may need to have Product B - Release B.F.G.Y installed.

A DSL is "not" an easy concept, if it's done correctly. If you go by using ITIL's descriptions, I promise you that you will question your implementation very quickly.

I hope this helps.

My Best,

Frank Guerino, CEO
TraverseIT
On-Demand ITIL Platform

[Mark_B]

Hi all,
Is anyone able to give me an example to what extent you have populated the DML? I am scoping out what to include - there are the obvious items like Lisences and Application Software, but coming from a shop which is both Midrange and Mainframe would you include JCL and Source Code even though they are already under the control of a Library Manager (SCLM)?

Cheers,
Mark

[Diarmid]

[Guerino1]

[BorisBear]

[Diarmid]

[quote="BorisBear"]

[UKVIKING]

I did not implement Intellectual Property on It depends !

1 - I feared the lawsuits about adult diapers


And i could not decide whether the phrase was

It depends
IT depends
it depends

because.. you know.. it depends
_________________
John Hardesty
ITSM Manager's Certificate (Red Badge)

Change Management is POWER & CONTROL. /....evil laughter

[Diarmid]

Admit it John. You have a dependency issue.

Hang on and see if we can help you sort it.
_________________
"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