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: MPqu
New Today: 15
New Yesterday: 165
Overall: 131425

People Online:
Visitors: 61
Members: 4
Total: 65 .

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 - Is ITIL only for production systems?
 Forum FAQForum FAQ   SearchSearch   UsergroupsUsergroups   ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Is ITIL only for production systems?
Goto page 1, 2, 3  Next
 
Post new topic   Reply to topic    ITIL Forum Index -> ITIL Discussion
View previous topic :: View next topic  
Author Message
bnetra
Newbie
Newbie


Joined: Sep 17, 2006
Posts: 7
Location: Bahrain

PostPosted: Wed Dec 06, 2006 3:47 pm    Post subject: Is ITIL only for production systems? Reply with quote

Is ITIL only for production systems (including changes to production systems)? Does it cover new projects (totally new)?
Thanks.
Back to top
View user's profile Send e-mail
Ziad
Senior Itiler


Joined: Sep 27, 2006
Posts: 91

PostPosted: Wed Dec 06, 2006 5:37 pm    Post subject: Reply with quote

Hummmmm, Interesting.
We know that ITIL applies in an operational environment, nevertheless I think that some of the processes can govern a new project implementation. I think that Change Management and Release Management combined are so close to Project Management, and why not have a CMDB in place throughout the project to get a final view of the infrastructure once done.

Availability and Security, their aspects are also addressed during a project implementation, you can follow the ITIL giudelines in these terms as well.

Now all that is theory, if you happen to go through a project implementation following ITIL guidelines, I am very interested in knowing how things will go and what will be the problems you may face along the way.

Regards,
Z!
Back to top
View user's profile Send e-mail
itilimp
Senior Itiler


Joined: Jan 20, 2006
Posts: 172
Location: England

PostPosted: Thu Dec 07, 2006 7:40 am    Post subject: Reply with quote

You may be interested to know that the authors of ITIL v3 have clarified the relationship between a project and the operational environment.

My understanding is that the core books (slated for April 2007) that would cover this in particular are 'Service Design' and 'Service Transition'. If you haven't already, check out the newsletter (there's a link to it in my blog).
Back to top
View user's profile Visit poster's website
raroa
Senior Itiler


Joined: Dec 05, 2006
Posts: 54

PostPosted: Thu Dec 07, 2006 2:18 pm    Post subject: Reply with quote

several points occur to me:

First, the platforms on which dev and test function are often considered production platforms: lower priority than Prod but still administered by the same operations people and processes. A big corporation may have hundreds of developers sitting idle if a key Dev server goes down so they are production status machines alright. So the ITIL processes extend into the solutions environment in that way in some shops

Second, the ITIL books are a bit inconsistent in how they regard Change: whether it is to control change from the inception of an idea and its approval through its project to its final production turnover or whether it just controls change to the production environment. Mostly it is the latter but there are hints of the former. In general though most people would agree that ITIL does not cover project management or project portfolio management.

Third, ITIL Application Management absolutely gets its tendrils into environments other than Prod, and to a lesser extent so does Release. The IT Operations group needs visibility of what is coming,and some input into the architecture, and assurance that sytems are production ready, long before they get chucked over The Wall from development.
Back to top
View user's profile
ankitkat
Newbie
Newbie


Joined: Dec 07, 2006
Posts: 1

PostPosted: Thu Dec 07, 2006 7:50 pm    Post subject: Re: Is ITIL only for production systems? Reply with quote

bnetra wrote:
Is ITIL only for production systems (including changes to production systems)? Does it cover new projects (totally new)?
Thanks.


Not atall. Yes it can be impelemented at any stage of project.
Back to top
View user's profile
Marcel
Senior Itiler


Joined: Sep 21, 2006
Posts: 63
Location: USA

PostPosted: Thu Dec 07, 2006 11:51 pm    Post subject: Reply with quote

As correctly stated by previous posters, ITIL mainly targets the production environments (including infrastructure that supports development activities), but except for the Application Management module it doesn't really reach out much to stages prior to production.

This gap has been filled in though by ASL, the Application Services Library. ASL is ITIL's younger sibling that focuses on best practices for application development and management (the entire lifecycle). It is public domain, was originally developed in the Netherlands (initiated by Pink Elephant, which is also big on ITIL), is set up very much like ITIL and also has certifications, exams (also by EXIN), etcetera. For more information see the ASL Foundation website.

A third sibling to ITIL and ASL, called BISL (Business Information Services Library) is still in its infancy (only a Dutch book is available at the moment) and focuses on the business/functional side of IT. This initiative will probably need a few more years to mature and spread out.
Back to top
View user's profile
Guerino1
Senior Itiler


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

PostPosted: Fri Dec 08, 2006 5:33 am    Post subject: Reply with quote

Hello All,

Some clarification...

ITIL is "not" intended, nor was it specified for non-production environments.

This is one of the major flaws with ITIL, as it started from the operational/support area of IT and started to work its way backward, through the enterprise.

Product Development and Engineering, which are sub-concepts of "Product Management"

Product Management is not an ITIL concept but a long established model for taking a product to market, from inception, through many iterations, and ultimately through to its decommission, many years later. Concepts such as "Product Lifecycle" (PLC) and "System Development Lifecycle" (SDLC) are small subsets of this concept. Product Management is actually a concept that is generic and applies to all products, regardless of whether it's software, hardware, a car, a plane, a mutual fund, etc.

The biggest issue with ITIL that constantly comes up in real life implementations is that it is about getting the infrastructure and support organizations to control themselves and run themselves more like a business. However, "running yourself like a business" requires far more than what ITIL specifies. ITIL is actually very small in the grand scheme of doing so. Also, most infrastructure and support resources have not formally been trained on "Product Management & Development" concepts.

As a result, ITIL leaves out the core concepts of "forward development" and also creates definitions and best practices that conflict with many of the concepts that designers, developers, and engineers are taught to use to bring a product to market (or production).

The net result is that ITIL leaves out the majority of the work and information needed to actually bring a given product to market/production, as the majority of the work associated with any product is done long before it's deployment to production.

Anyone that has had responsibility for both Product Development organizations and support organizations will understand this and be able to add value to this.

Anyone that has truly implemented a signficant portion of ITIL will be able to attest to the issues that show up when you try and get development and engineering organizations on board. For example, a CMDB to an infrastructure person is a bit different than what one is to a designer, or even to a developer. Also, Release Management in ITIL is different than what it is in RUP/MSF/SDLC/PLC/etc. This is only the beginning.

Earlier in the thread, it was mentioned that other environments "are" the production environments to the teams that use them. This is absolutely true and a very accurate insight. A QA testing team relies on their testing environment. They register two types of Incidents: Those associated with their Testing Infrastructure & Environment having disruptions and those associated with the systems they are testing that do not perform as expected (in other words, a test failure is an Incident, not a Problem/Defect). ITIL does not handle either of these cases, which are important to testers, not to mention everything needed by architects, designers, developers, engineers, etc.

This thread is a wonderful knowledge base because it is one of the few that actually starts to address critical flaws, gaps, and contradictions in ITIL.

For those that like to quote ITIL, blindly, from the book. It's always important to know that while ITIL has a lot of great things to take away, it also was designed and written by human beings. Since no human is perfect, the writers of ITIL transfered unintentional flaws, gaps, and conflicts into ITIL's specification and it's critical for followers to understand this and always resort to "common sense".


Anyhow, I hope this helps.

Best Regards,

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


Joined: Dec 05, 2006
Posts: 54

PostPosted: Fri Dec 08, 2006 8:50 am    Post subject: Reply with quote

Hi Frank

I must disagree with one statement you made

Quote:
QA testing team ... register two types of Incidents: Those associated with their Testing Infrastructure & Environment having disruptions and those associated with the systems they are testing that do not perform as expected (in other words, a test failure is an Incident, not a Problem/Defect). ITIL does not handle either of these cases


the first case is precisely what ITIL handles, so long as their Testing Infrastructure & Environment is treated as a production platofrm, which it often is (and should be)

the second case is not an incident. An incident is an interruption to the expected function of a service. A system under test is not a service (although the delivery of a platform to the testers is - first case). ITIL is not expected to handle this second case. I'd go further and say that those who try to use ITIL tools (and occasionally also Change processes) to handle development bug tracking usually end up in trouble by trying to use shoes for tires: wrong thing for the job.

Most readers are familiar by now with how TraverseIT spans all IT processes, but - as you say - ITIL doesn't. So it does not reflect badly on ITIL if it doesn't cover bug tracking: it is not an incident process. it is outside ITIL's scope.
Back to top
View user's profile
Guerino1
Senior Itiler


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

PostPosted: Fri Dec 08, 2006 9:43 am    Post subject: Reply with quote

Hello Raroa,

Please don't misinterpret anything I've written below as wanting or trying to create conflict with you. I am simply trying to share information, based on my own personal experiences and based on what I've learned from some very smart and very globally visible IT leaders. I see this as one of the more interesting and valuable threads on the entire forum. Too many people blindly quote ITIL and don't look at the bigger picture. I believe that it's extremely important to understand the bigger picture and the good and the bad of anything we use to help us solve our problems. An open mind and common sense are a very powerful combination.

raroa wrote:

the second case is not an incident. An incident is an interruption to the expected function of a service. A system under test is not a service (although the delivery of a platform to the testers is - first case). ITIL is not expected to handle this second case.


For the purpose of this discusion, I'm going to ask you to not just think ITIL but to also think like you own the entire company, of which ITIL is only a very small part...

To a testing/QA team, the latter case is absolutely an Incident. ITIL doesn't cover that type of Incident, it is true, but Incident Management was not invented by ITIL. It was around for many decades, long before ITIL. The failure of a test case is absolutely an "Incident". Read on for explaination...

You're correct that ITIL is not expected to handle this type of issue. However, "Product Management" is absolutely expected to handle this type of Incident. And, Product Management "must" is more important and must be successful, because without it you have no infrastructure, applications, systems, etc. to support. In other words, without your Product Management processes, you don't have a company to run. So, if in the Product Management process you have a test case failure, your Product Management assembly line can come to a complete stop and you will never get your product out the door.

Think of this... A test case is not supposed to fail. It's expected behavior is to pass (especially in the case of formalized regression tests). In other words, when the test completes, successfully, it registers a "PASS", not a "FAIL". If, for any reason, the test case registers a "FAIL", you have an Incident. Why? Simply because the test case's behavior had a "disruption" in its expected behavior (i.e. it experienced an Incident!). In this case, it was the test system that experienced and caught the Incident, not a human. But, it is an Incident, nonetheless. It may have failed due to a defect (Problem in ITIL) or it may have failed due to some reason that had nothing to do with a defect, like a major external power failure. The team doing the testing must then take that failed test Incident and resolve why it failed. If they can't do it themselves, they actually go through a formal escalation process, back to the original developers, to resolve it... very much like ITIL's Incident escalation process.

This also goes back to development... If a software developer tries to compile his/her application and it fails, it doesn't mean it's because of a defect (Problem). That is completely unknown until formal debugging has been performed. The failure is an Incident... a disruption in normal or expected behavior.

Quote:
I'd go further and say that those who try to use ITIL tools (and occasionally also Change processes) to handle development bug tracking usually end up in trouble by trying to use shoes for tires: wrong thing for the job.


I'd venture to say that this is innacurate only because we have partners and clients already doing this successfully. Implementing such solutions is one of the many things we do. The creation of our product, to sell, was a direct byproduct of this type of successful experience. As a matter of fact, if you implement such a solution correctly, developers will love you for it, because not only can they manage themselves but will also see what infrastructure and support are doing with their products and services in production. Visibility across organizations, roles, locations, etc. is a very big issue and if you implement your processes correctly, in such a way so that they all intersect naturally, seamlessly, and efficiently, you will have that visibility and your entire Produce Management/Lifecycle process will run like a lean, mean, high quality, and very fast assembly line.

The reason I was able to "collapse" and integrate approximately 50 different operational disciplines into one platform is a byproduct of doing it the right way. There are entire companies that are 10 to 20 times the size of my own that focus only on one or two disciplines in their product(s). You have to ask yourself, "Why can he deliver more with fewer resources than many entire companies combined?" The answer is simple to "us".

Quote:
Most readers are familiar by now with how TraverseIT spans all IT processes, but - as you say - ITIL doesn't. So it does not reflect badly on ITIL if it doesn't cover bug tracking: it is not an incident process. it is outside ITIL's scope.


Thanks for the positive statement but TraverseIT does not yet span all IT processes, nor do we pretend that it does. We do span "many" more than any other single vendor and our intent is to attack and fully integrate each operational/commodity area of IT, one process/discipline at a time, but we are far from having built "everything" that an IT organization will need, into the platform. That's one huge space to tackle and it represents our open roadmap, since every commoditizable (if that's a word) discipline is a viable target for us.

As for the reflection of good or bad on ITIL, it depends on who you speak with. If you speak with the manager of a help desk who is trying to get their Incident Management process under control and eliminate the chaos in their world, it's a great thing. However, if you speak to any business owner or IT leader who is required to manage the bigger picture, ITIL is good because it provides a consistent language and the beginnings of a framework but it's also incomplete, inconsistent, and sometimes even wrong. This doesn't make ITIL bad but you have to understand that it implies limitations, investments, effort, etc. As an IT leader, you have to worry about the "whole picture" and how things interoperate, not just the improvement of infrastructure and support.

"Run yourself like a business" means "Run yourself like a complete and entire business" not "Run yourself like an incomplete and piecemeal business"... because if you run yourself as an incomplete and piecemeal business your business fails and you are "not" running yourself like a business, at all. Failed businesses are not "businesses", at all. They're just "memories of wishful dreams"... and everyone goes home unemployed.

Anyhow, as always, I hope this information adds value.

Best Regards,

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


Joined: Jul 26, 2005
Posts: 42
Location: Northern Virginia, USA

PostPosted: Thu Dec 14, 2006 5:59 am    Post subject: Reply with quote

ITIL is for production environments, but many aspects of it can be used in bringing a new system up. I worked on a two year project that rebuilt and installed a new backbone in a large five sided building. Once the design was presented, the design was put under change management. It was in fact a large release management project. Since no equipment was to be maintained by the project just installed and turned over, there was no incident management etc. We had just Change, Configuration, and Release. It was an interesting and successful hybrid.

For pre-production, there is a application development section of ITIL for software. Many of its principles can be used for hardware. System design is system design so to speak.
Back to top
View user's profile Send e-mail
Fabien
Senior Itiler


Joined: Sep 27, 2005
Posts: 207

PostPosted: Sat Dec 16, 2006 1:37 am    Post subject: Reply with quote

I think you can say that the bottomline is that both Operations and Proj Mgt would benefit from similar process structures and that if Operations is using ITIL, it would seriously help if ProjM is geared for it.

For instance, when an application is beta tested in the live production environment, there should be a process to allow users to report errors in a way that is "compatible" with the way that they usually report other incidents. The regular service desk could be used for that. In any case, ITIL recommends that a subset of the project team be allocated to Problem Management because the introduction of new CI's (be HW or SW) should come with Known Errors, etc.

So there definitely is a number of touch points and synergies to develop.
_________________
BR,
Fabien Papleux

Accenture
Technology Consulting | Service Excellence
Red Badge Certified

Twitter @itilgeek
Back to top
View user's profile Send e-mail Visit poster's website MSN Messenger
Guerino1
Senior Itiler


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

PostPosted: Sat Dec 16, 2006 4:51 am    Post subject: Reply with quote

Wouldn't the better answer be to simply follow true Product Management disciplines, from soup to nuts, so that you wouldn't even need ITIL? After all, ITIL is just the support and maintenance portion of the master Product Management process, as it applies to the Production environment.

Best Regards,

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


Joined: Dec 05, 2006
Posts: 54

PostPosted: Sat Dec 16, 2006 10:23 am    Post subject: Reply with quote

For many (most?) organisations, ITIL in all its splendour is too big a mouthful, let alone reengineering all the processes "from soup to nuts". Such a revolutionary approach can be recipe for disaster without total organisational commitment and lots of resources.
Back to top
View user's profile
Guerino1
Senior Itiler


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

PostPosted: Sat Dec 16, 2006 12:29 pm    Post subject: Reply with quote

raroa wrote:
For many (most?) organisations, ITIL in all its splendour is too big a mouthful, let alone reengineering all the processes "from soup to nuts". Such a revolutionary approach can be recipe for disaster without total organisational commitment and lots of resources.


Hello raroa,

It's not that ITIL is too much. It's that ITIL is too vague and too incomplete. However, "every" organization already performs Product Management functions. IT organizations exist, specifically, to address the needs of "product". (The exception is when providing a Service is your Product. But, in this case, the same principles apply). The functions ITIL helps outline are nothing more than some of the many things you already do. ITIL just puts a name to it and challenges enterprises to ensure that the displines are structured and repeatable.

Enterprises all over the world were already performing Incident, Problem, Change, and Asset Management functions, long before ITIL published its framework. They had to. These functions were and are critical to Product Management. ITIL just put a name to it all, so that everyone can speak a common language and understand common functions.

Product Management is what you already do. It's why IT exists. In my opinion and based on my experiences, it is the core process/discipline that acts as the backbone for all others and feeds all others. It's also, again in my opinion, the primary missing link in ITIL.

I hope this helps.

Best Regards,

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


Joined: Dec 05, 2006
Posts: 54

PostPosted: Sat Dec 16, 2006 3:47 pm    Post subject: Reply with quote

Entirely agree and entirely disagree - due to my sloppy terminology.

What we are both talking about is not implementing process, it is raising the maturity level of existing process, because as you say all processes exist, if only in an anarchic state.

ITIL is about revisiting these processes in order to determine if the maturity should be higher and if so then to reengineer them so it is. Likewise when you say "follow true Product Management disciplines" I assume you are talking about the saem activity only over a broader range of processes.

That activity of reviewing and improving process is hard work. One doesn't attempt it over more processes than there is a business case for. Certainly one doesn't go the whole hog except in unusual circumstances.
Back to top
View user's profile
Display posts from previous:   
Post new topic   Reply to topic    ITIL Forum Index -> ITIL Discussion All times are GMT + 10 Hours
Goto page 1, 2, 3  Next
Page 1 of 3

 
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.