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: GC56
New Today: 1
New Yesterday: 78
Overall: 142151

People Online:
Visitors: 69
Members: 2
Total: 71 .

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

CMDB Scope

 
Post new topic   Reply to topic    ITIL Forum Index -> Configuration Management
View previous topic :: View next topic  
Author Message
dsemeniuk
Itiler


Joined: Feb 06, 2007
Posts: 41

PostPosted: Sat Apr 21, 2007 6:34 am    Post subject: CMDB Scope Reply with quote

We are currently implementing our CMDB and our tracking environments such as Dev, Testing, Staging, and Production.

As in all the hardware that make up our environments, all the COTS software that is installed on them, and then from Testing and on, we track what versions of Custom Software are installed where.

So at anyone point, we can go to the CMDB and see what is all installed or what makes up our Testing environment from a hardware, software, database, network point of view. And if any change is needed to these environments, an RFC is submitted and goes through Change Management for approval and to ffed the update into the CMDB.

Do other people do this or do they just focus on the production environment?
Back to top
View user's profile
UKVIKING
Senior Itiler


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

PostPosted: Sat Apr 21, 2007 8:48 pm    Post subject: Reply with quote

We are in the same quandry

As teh change manager, my outlook is this.

The production environment gets the full Change mgmt process

The dev/uat/test environment gets a quickee version.
-especially if they are addign/removing devices so that config and the mgt teams are aware
_________________
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: Sun Apr 22, 2007 5:44 am    Post subject: Reply with quote

Hello Dsemeniuk,

Yes, there are many enterprises that do what you're describing. However, what we find is that the majority that do usually do so because their software teams usually follow SW development and engineering best practices that come from older SDLC principles, not from ITIL. The reason is that ITIL pretty much only covers production operations. We're finding that most enterprises who take on ITIL rollouts forget about pre-production environments in their implementations. The sad part is that it's more difficult and retrofit your solutions, after the fact, than it is to plan for including all environments, as part of your rollout, from the beginning.

An interesting implementation that we put together for clients is the use of an RFC as an automation reference handle, within a Product Release. Change records get created, assigned to Product specific Releases, and then Changes are managed as part of a Release. What this means is that the Release is the parent for all child Changes. Changes can then be independently promoted and rejected across relevant environments and, as a result, you can now see the lifecycle of a Change, from inception through successful or failed close, with complete transparency as to it's drivers (Requirements, Problems, Risks), it's work, its correlation to specific source code files (including their specific version), to the specific builds, deployments, etc. Builds maintain detailed Change dependencies, so that you can snapshot/checkpoint your builds and recall any version of any build, from any environment, that occured at any point in time. Very powerful.

We find that most infrastructure teams do not follow the same rigorous processes that many SW dev teams follow, especially when it comes to running changes through multiple environments and appropriately repeating builds, deployments, installation, instantiation, execution, testing, rollback, etc., in each environment.

ITIL Application Mgmt wants to go in this direction but, in my opinion, it is far from where it needs to be.

My Best,

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


Joined: Mar 03, 2007
Posts: 33
Location: Minneapolis

PostPosted: Mon Apr 23, 2007 8:23 am    Post subject: Development IS production. Reply with quote

The so-called "non production" environments actually are supporting a production business process: the IT development lifecycle. They are part of the total cost of ownership for the IT service organization. Their outages result in the idling of highly compensated individuals.

So, why would we not put them in the CMDB?

I probably wouldn't try to control their parameter configuration to the same degree as production. But that is a slightly different question.

-ctb
_________________
Charles T. Betz
Back to top
View user's profile Send e-mail
Guerino1
Senior Itiler


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

PostPosted: Mon Apr 23, 2007 11:50 am    Post subject: Reply with quote

Hello Charles,

I fully agree and believe that all environments need to be covered by all operational disciplines, something I've been recommending to members of the forum for a very long time. However, many people that become ITIL certified tend to try and implement ITIL disciplines to the letter. Unfortunately, the end result is that most enterprises that implement ITIL completely ignore implementing ITIL disciplines for non-production environments. The reason: If you're implementing ITIL to the letter, the letter says nothing explicit about non-production environments.

For example, ITIL does not acknowledge things like:

  • SW Build failures, regardless of the environment you're building in, are Incidents
  • SW Regression failures, regardless of the environment you're running regressions in, are Incidents
  • SW Deployment/Distribution failures, regardless of the environment you're deploying in, are Incidents
  • SW Installation failures, regardless of the environment you're installing in, are Incidents
  • SW Execution failures, regardless of the environment you're executing in, are Incidents
  • Etc.

This is just related to SW. ITIL doesn't address assets not performing properly in non-production environments. It doesn't address Problem Management as a form of defect tracking in non-production environments. It doesn't address the fact that Requests for Change should be fed into the beginning of the Product Release process and that Changes need to progress across and be tested within each environment. We can go on and on. It's the same thing for Configuration Management. While some people that have spent many years in IT get the importance of managing Configurations across all environments, there are many people that don't get it and are looking to ITIL to help teach them. Unfortunately, while ITIL is trying to do the right thing, there are still far too many gaps, conflicts, and even some incorrect recommendations, such as how they recommend the implementation of a DSL.

What's really unfortunate is that many people who will implement ITIL for the first time have really never gone through the process of experiencing what does or doesn't work. In many cases, they will be too far down the road, deep in expensive and overly complicated implementations, before realizing such issues.

The point is that what is obvious to you, because of your experience, is not necessarilly obvious to many others who are learning as they go.

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
alphasong
Itiler


Joined: Mar 03, 2007
Posts: 33
Location: Minneapolis

PostPosted: Mon Apr 23, 2007 12:01 pm    Post subject: The sticky area Reply with quote

The sticky area here is in striking the right balance of control for dev environments. Developers do have legitimate needs to tweak and experiment and the relationship between them and the infrastructure engineering organization always requires considerable attention.

-ctb
_________________
Charles T. Betz
Back to top
View user's profile Send e-mail
Guerino1
Senior Itiler


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

PostPosted: Mon Apr 23, 2007 9:52 pm    Post subject: Reply with quote

Hello Charles,

Yes, but it can be done successfully. Remember,

- The Development Environment is a production environment to the Developers
- Testing Environments are Production environments to Testers
- Etc.

What we find is that the principles of ITIL work very well (even better than specified by ITIL), if you include all environments in your implementation. Very simply, you'll be on top of managing the larger picture, which includes everything, and you'll collect far more valuable data/metrics while doing so.

My Best,

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


Joined: Feb 06, 2007
Posts: 41

PostPosted: Tue Apr 24, 2007 6:56 am    Post subject: Reply with quote

I guess the complexity we are having is trying to manage all the relationships that can exist through each environment within the CMDB.

So we introduced an Environment CI to help out but are still trying to figure out what ypes of relationships we need to manage, the main value of the CMDB.

So far for our software CI, it can have a relationship to a server, a database schema, and the environment CI. So we can tell where/what version of the software is installed physically and if there are any connections to database schemas.

What relationships do people track between CIs?

We are currently trying to work out the process to help automate the promotion of the version of the Software CI to the next environment and magically establish the realtionships it needs within the environment it is being promoted to, as it would gain new relationships, as it would be installed on a different server and connect to a different database instance and then the version it is replacing would lose those relationships.

Not sure if I am making sense but is eanyone else tackling this scenario?

Thanks for everyones input so far!
Back to top
View user's profile
Guerino1
Senior Itiler


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

PostPosted: Tue Apr 24, 2007 7:24 am    Post subject: Reply with quote

Hello Dsemeniuk,

Creating an environment CI will work. It's not the most useful thing to do, since there are rarely more than a few environments and, typically, CIs tend to be instantiated far more than a few times. But, implementing environments as CIs is not wrong.

As for the relationships that are tracked, between CIs, there are thousands of different relationships. This is why implementing your own CMDB or using one where you have to define your own relationships will typically hit a ceiling, with respect to what you will be able to do with it.

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
Display posts from previous:   
Post new topic   Reply to topic    ITIL Forum Index -> Configuration Management 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.