Co-location - Change or Release

[fighter]

We provide Co - Location Services to our clients (who are part of our group of companies).

How do you classify the migration of infrastructure from one company to the data centre ? Is it a change or a release?

I am tempted to call it a Release as infrastructure is not recorded in the Configuration details.

Throw me some light into it.

Cheers

Vimzie!!

[Ziad]

Well I would say it all depends on your CMDB depth. If it was up to me, the location would have been an attribute for my CIs, therefore relocating will incur an update in the CMDB which in my own understanding is a Change.

Z!

[m_croon]

[fighter]

That's the beauty of ITIL isnt it?

Its all about how you want to do it....

Thanks it did help!

Cheers,

Vimzie!![/b]

[UKVIKING]

It is more than just a change.

First it is a project where you have to determine whether the location (if you manage it) is capable of accepting the new kit

This would be part of an Implementation project managed by some Project manager

As part of the Imp project, there will have to be a change once the kit is installed into the love environment.

But.. that also depends on whether the new kit will be managed by you all

In my environment, we have colo and managed kit. Change management is only concerned with the managed because other than physcial space, power and lighting, the colo customers do not interact with our network and system infrastructure
_________________
John Hardesty
ITSM Manager's Certificate (Red Badge)

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

[fighter]

John,

Thanks for the reply!

Project? def it is one.

I am currently managing a project of migrating our group company's infrastructure into a centralized environment which will be managed by Corp IT in the future. This is done as part of our IT Consolidation Project.

In addition to our group of comapnies we are getting lots of inquires from external companies. We are making use of this experience from co-location within our comapny and formalizing and documenting all the steps to co locate and will make use of it ifor the future co-location projects.

We have decided to call it a release as there might be new verisions of both hardware and software to be added to the existing one's in the future.

John,

Would you be able to explain to me how a colocation project is handled in your organisation? May be you can write to me if you cannot disclose it in this forum.

I would be interested to know more about the steps involved, requirement analysis and so on..

Cheers,

Vimzie!!

[UKVIKING]

I can do it here.

First, a project manager gets assigned to the project. If the project is to remove systems from a data center only, then the project manager just needs to involved those departments which deal with the systems/customer - Operations staff, billing etc. The OPS staff would include Service Desk, Data Center, and monitoring team as well as teh Service Management person linked to the customer

If the project involves moving within or between datacenters, the Operations people for the above roles from each DC would be included as well as some other groups - Network, Network Security, and Senior MGmt.

Before anything gets done, both the old site and the new locations would have been evaluated and mapped out . You kow.. Server 1 goes from DC 1, floor 1, cage 1, rack 1, U 27 to DC2 ......etc

The effect on the current power consumption needs to be evaluated and whether the additional kit has any effect on the environmental variables in the new site - heat, A/C, power, UPS etc

Once that is cleared up, then the network issues are dealt with. What IP range, VLAN, AS, firewall rules, ACLs, switches, routers. Whether there is enough space, bandwidth, ports, interfaces etc

Then the systems are looked at... in regard to the network issues - especially if there are IP changes, Subnet changes, domain changes etc

and this is before the machines are even removed from the old location.

Then the machines should be ranked in the order of importance - so the least ones can be moved first. Then the schedule of wok for the old DC and new DC staff is handled ... same for the transport people.. who is physically moving the kit

or.... if no one really cares..... just rip the machines out in 1 DC take them to the new DC and complain when the new DC is not ready for you. Then scurry about trying to accomodate the idiots.

both ways have been done. I laughed at the second one when it occured
_________________
John Hardesty
ITSM Manager's Certificate (Red Badge)

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

[Guerino1]

Fighter,

For what it's worth, here's what we see when we deal with enterprises:

Movement of one infrastructure to another is typically large. Therefore if the enterprise is large, this is normally an "Initiative", which is a large Project that has many sub-Projects. If the infrastructure is smaller, then it can simply be "a single Project".

The Project(s) is/are made up of one or more Asset Migrations (This includes virtual assets, such as SW, and tangible Assets, such as HW & Infrastructure).

A "Release" typically represents a new "version" of a Product. In the case of migrating to a new datacenter, you are typically not creating a new Release or version, you are simply redeploying an existing Release to a new location/target.

NOTE: This highlights a flaw in ITIL, which implies that a Release and a Deployment are the same things, when in reality they are not. You can have a Project to design, engineer/implement, and deploy a new Product Release or you can have a Project to simply redeploy an existing Release.

The hierarchy is that:

- You have a Project that has many Tasks.
- A Task calls for work to be executed.
- Some work does not modify anything and therefore calls for no RFCs.
- Some work "does" modify configurations but does not Change the "Version" or Release of a Product and, therefore, simply requires one or more RFCs.
- Some work "does" modify configurations and is signficant enough to change the Product, itself, and require a new Version or Release of the Product, which in turn would spawn multiple RFCs for the new Version/Release.

This is why Software Development and Engineering is very complicated. Also, you'll note that ITIL has, both, direct conflicts with Software Dev/Engineering and leaves a lot out, as well. Everything I read in ITIL gives me the impression that it seems to have been created from the view of Infrastructure people, which leaves huge gaps in the big picture of how IT needs to run.

I hope this helps.

Regards,
_________________
[Edited by Admin to remove link]

[fighter]

Frank,

We are migrating our customer's system to our DC. After the migration our operations team provides support to the systems.

Practically, Release or change does not matter. All we need to ensure is the data is updated in the CMDB.

John, thats a fantastic explanation.

As per your words we are in the right track.

We had our fun on the second one as well.

But, however, we are enforcing strict instructions on procedures to be taken before any system can be incorporated into the Data Centre.

Thanks for your insight.

Vimzie!

[UKVIKING]

Figther

cool. Make sure that the customer, your data center front desk, your vendors providing maintenance - h/w & s/w - are aware of your new process / procedures for managing the IT assets in the CMDB (or your equivilient)
_________________
John Hardesty
ITSM Manager's Certificate (Red Badge)

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

[fighter]

John,

We are in the process of eductaing our customers on our procedures and policies, Unfortuately all the documents are in English we are getting it translated to thai and will be sending it to our customers.

Cheers,

Vimzie!!