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: JAcuna
New Today: 93
New Yesterday: 82
Overall: 143922

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

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

Custom Software Tracking in CMDB

 
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: Thu May 10, 2007 6:19 am    Post subject: Custom Software Tracking in CMDB Reply with quote

We currently have CMDB and have been tracking versions of Custom Software being built through Testing, Staging, and Production.

We have a Logical CI called Environment that we use to link Hardware, Databases, and Software to enable us to know what is installed in which environment and what makes up that environment.

Question is, does it make sense to track the Custom Software CI through these environments within the CMDB, as in knowing where they are installed, what database they are connected to, or should we just focus on the production environment?

I ask this cause I could see this being hard to manage with many systems.

Opinions?
Back to top
View user's profile
Guerino1
Senior Itiler


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

PostPosted: Thu May 10, 2007 12:46 pm    Post subject: Reply with quote

Hello Dsemeniuk,

The answer is, "yes", you do want to track everything that is installed in every environment. The reason is that for SW development, you may have many concurrent versions running in different environments (sometimes even in the same environments) and you'll want to track anything and everything you can, as a Release and it's Changes move from one environment to another.

However, I do understand what you're saying about how hard it is to do. What we do for our clients is to implement a powerful "phone home" strategy that ultimately keeps the CDMB up to date, without human intervention. After all, that is why automation exists, right?

What we've built are the following Phone Home strategies...

- Phone Home when you check source code in/out
- Phone Home when you build
- Phone Home when you deploy/distribute
- Phone Home when you install
- Phone Home when you instantiate
- Phone Home when you run
- Phone Home when tests run (start, finish, pass/fail, etc.)
- Phone Home when you have runtime behavioral errors or critical events
- Phone Home when your application is logging
- Phone Home when you promote/reject Releases and/or Changes
- Etc.

The "Phone Home" concept, in essence, captures critical details about an entire environment, at the time of invocation, through processing, and at it's end, and publishes those details back to master logs and CMDBs. It's something that mature SW shops have been doing for decades. If you're in a modern and competitive environment, virtually nothing you do should be manual anymore and most of what I've described above should be in place, anyhow. These days, even most of the code generation should be automated through code synthesizers. Everything that is automated should be in constant communications with your master Knowledge Management platform (a.k.a. your CMDB).

Anyhow, I hope this helps.

My Best,

Frank Guerino, CEO
TraverseIT
On-Demand ITIL
Back to top
View user's profile Send e-mail Visit poster's website
dsemeniuk
Itiler


Joined: Feb 06, 2007
Posts: 41

PostPosted: Fri May 11, 2007 12:10 am    Post subject: Reply with quote

Thanks Frank.

I guess the other side is, what process do you use to trigger or allow the deployment of custom software to be deployed into each environment, then up to production?

That is the debate around here, right now the teams must submit RFCs to deploy their new versions of their customer code into each environment (Test, Staging, Production) which I think is a bit much as we are in project mode right now, and are getting ready to deploy the new system to the production environment. So there can be many iterations/versions of the custom software being built, so does it still seem reasonable to do doing this?

Being in project mode, what process do you use to start capturing the CIs that are being built?
Back to top
View user's profile
Guerino1
Senior Itiler


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

PostPosted: Fri May 11, 2007 10:18 am    Post subject: Reply with quote

Hello Dsemeniuk,

dsemeniuk wrote:
I guess the other side is, what process do you use to trigger or allow the deployment of custom software to be deployed into each environment, then up to production?

That is the debate around here, right now the teams must submit RFCs to deploy their new versions of their customer code into each environment (Test, Staging, Production) which I think is a bit much as we are in project mode right now, and are getting ready to deploy the new system to the production environment. So there can be many iterations/versions of the custom software being built, so does it still seem reasonable to do doing this?


These are very interesting questions because they highlight how wrongly most infrastructure teams interpret RFCs, Change Management, and ultimtaely Release Management.

From a traditional "Product Development" perspective, which is what most Product Management teams in the world follow, they're usually following a Product Lifecycle format. This means...

  • The Product comes first
  • Releases are subconcepts of Products by representing "Versioned Products" (i.e. Product X - Release 1.0.0, Product X - Release 1.0.1, Product X - Release 1.1.0, etc.)
  • Changes are requests to modify a Product, which are manifested in a specific Release. Therefore, Release 1.0.1 might be composed of Changes A, B, and C.

Now, depending on how advanced your SW development team is, they will either "promote" entire Releases across environments or, for the more advanced, "promote" individual Changes across environments. Promoting Changes is a highly advanced concept because it means that Changes, themselves, are versioned, have dependencies to specific versions of Source Files, and must be managed for dependencies between other Changes. It also applies that all Changes get promoted, rebuilt, redeployed, reinstalled, reinstantiated, re-executed, and reverified in every single environment, before they are promoted to the next environment. This is something that most infrastructure teams are not even close to attempting. Most we talk to don't even understand the complexity of such an environment.

It is very important to know that most "Request for Changes" impact things that are supposed to be engineered and tested, long before they go into your production environment. This means that, technically, an RFC gets created, gets scheduled for a specific Release of a Product, starts to get worked on, and gets marched across testing environments, one environment at a time, as it's rebuilt, redeployed, etc., until it's reverified and approved for the next environment. If done corrrectly, you can watch/track your Changes across "all" environments, something ITIL completely misses and, ultimately, something that is missed by many teams that implement ITIL.

I can't stress enough that if you're not creating and scheduling RFCs "before" they get marched through all environments, you're violating the fundamental principles of a solid SDLC.

One interesting thing that I find is that most infrastructure teams we speak with aren't managing their infrastructures as Products & Services with controlled Releases. They just simply apply Changes directly to Assets, which violates the fundamental principles of a solid SDLC.

So, after all of this and to specifically answer your question about what process is used to trigger the deployment of custom code to each environment, the answer is your "Verification Management" process (critical but not covered, at all, by ITIL). Changes are promoted to the next environment based on rigorous testing and signoff on the testcases for those Changes in that specific environment. Only when the tests are executed successfully and approved, should the Changes be approved for "submission/promotion" to the next environment. Once staged for the next environment, the owning "roles" of the next environment (could be the same people in many companies) should take those Changes and apply them to the new environment, based on the dependencies they have to other Changes. NOTE: Most teams we encounter don't even come close to managing Change dependencies. It's the Verification process that signs off an any step in any process, allowing that step to move its "deliverables" (whatever they may be and Changes in this case) to the next step in the process.

Quote:
Being in project mode, what process do you use to start capturing the CIs that are being built?


The answer to this question is very long. To give you a short insight, it starts with a clearly defined Product Lifecycle that everyone in your organization should be following (if you're interested, contact me off line and I'll give you an example of one we use as a baseline for our customers). The Product Lifecycle acts as a backbone for all activities associated with a Product or Service, from the day of inception to the day of its decommission (possibly many years later) and it includes all iterations of Releases and work done within or outside of those Releases. The steps in your lifecycle should act like a Value Chain and highlight critical activities that everyone must follow. It is also this Product Lifecycle that binds and interleaves all other processes...

  • Project Management,
  • Release Management,
  • Change Management,
  • Incident Management,
  • Problem Management,
  • Build Management,
  • Deployment/Distribution Management,
  • Installation Management,
  • Requirements Management,
  • License Management,
  • Document Management,
  • Contract Management,
  • Verification Management,
  • Etc., etc. etc.

Mature enterprises understand that "Product Management" is the backbone of "everything" an enterprise does. It has been for decades and ITIL tends to miss this point, completely. Although, they are finally starting to see the light (in a very minimalistic way) in v3, where they just begin to talk about "lifecycles". One of the biggest reasons there is contention between Infrastructure teams and Product Dev & Engineering teams is because ITIL pitches concepts that violate some bigger picture Product Lifecycle best practices, while Dev & Engineering teams have no choice but to follow PLC & SDLC concepts. This leads to instant conflict.

Anyhow, if you have a solid Product Lifecycle in place, you will have steps in the lifecycle that will ensure that appropriate CIs are following their own creation, modification, and lifcycle rules. So, for example, there might be a step that says "Procure Assets". In this step, an Asset should immediately be registered and marked as submitted for procurement, procured, etc. There will be steps where Assets will be built or even rebuilt in new environments. Every action in every lifecycle step simply triggers an update to the CMDB. In this way, you will capture "everything" that makes sense to capture, including its dependencies to environments, people, places, documents, licenses, contracts, etc. In other words, you'll run IT more like a business...

I hope this helps.

My Best,

Frank Guerino, CEO
TraverseIT
On-Demand ITIL
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.