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: MSchwab
New Today: 47
New Yesterday: 49
Overall: 146076

People Online:
Visitors: 67
Members: 4
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 - Buy or Build
 Forum FAQForum FAQ   SearchSearch   UsergroupsUsergroups   ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

CMDB - Buy or Build

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


Joined: Oct 19, 2005
Posts: 6

PostPosted: Thu Feb 16, 2006 11:32 pm    Post subject: CMDB - Buy or Build Reply with quote

Anyone have any thoughts on the advantages/disadvantages of buying a CMDB solution vs. building an in-house solution ??

We're launching our Configuration Management development project and we need to move quickly to a decision on buying or building our own CMDB solution.

We've looked at a number of purported CMDB providers (IBM Tivoli, Managed Objects, Perigrine, etc), but none seem to be an overall winner.

The trade off from my perspective in buying vs. building is that with buying, your biggest challenge is integrating the packaged solution into your environment vs. with a home grown solution, you get a tailored solution but have to deal with the overall development effort.

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


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

PostPosted: Fri Feb 17, 2006 7:59 am    Post subject: Reply with quote

Hi Jeff,

I've been in both positions, where I've built my own, for a number of businesses, and purchased a couple for others.

I am now in the business of building and selling a CMDB, among other solutions. So my opinion may seem biased but it's really based on experience. I will try to give you multiple perspectives...

In the beginning, there were no real options to puchase CMDBs. We didn't even know what a grand scale CMDB was. We were simply building IT operations data repositories that maintained relationships between the appropriate entities we wanted to track, version, etc.

Later, I went into the business of ramping up businesses by buying solutions and integrating them into clients' environments, which is always faster than building your own.

There are pros and cons to both.

Some Pros for Building Your Own:
- You have control and get to pick the technologies, platforms, etc.
- You get to let it grow at whatever pace you have an appetite for.
- You get to learn a great deal about how things work and interoperate with the rest of your business.

Some Cons for Building Your Own:
- You're probably not an expert in the topic, while others are.
- You will have to maintain it yourself, over time.
- Costs of development and ownership, over time, will be significant.
- Your company's business is not IT Operations, so while building a CMDB you're not focused on their core business.

Some Pros for Buying One:
- You get the expertise of others, whose job it is to focus on this topic.
- You save the time necessary to build your own.
- Maintenance and administration is usually less than one you build, yourself.
- As a vendor increases features and functionality, you get them upon upgrades, so you don't have to focus on that product, yourself.

Some Cons for Buying One:
- The vendor typically has control and you're typically at their mercy.
- Good CMDBs are, historically, not cheap.
- Vendor technology platforms don't always match yours.
- Integrations to your in-house, proprietary systems are usually weak or non-existent.
- Traditional off-the-shelf CMDBs are limited in what they can actually do or contain.
- Many vendor solutions require significant customization, which is sometimes a development effort in and of itself, before you can use them.

So the above is my technical side, which typically wants to default to building things myself, to maintain control, regardless of what my company thinks/thought.

Now for my vendor/business hat... I believe you need to understand my pitch to make your own decision. My pitch to any potential customer is always very simple. Imagine that you're the owner of a company whose focus is Insurance, or Retail, or Finance, or Selling Vertical Software, or whatever your business is. Imagine that you are the owner of the company you work for (if you're not, already). My questions to you are very simple:

"Why would you spend your company's hard earned money, resources, time, and energy on something that I can give to you for a fraction of the price, in a fraction of the time, with far more functionality than you can ever put into it, yourself, and by resources who specialize in this type of thing, knowing that you'd be using your own critical company resources to do so? Why would you want to take your critical company resources, distract them from your core expertise, and use them on something other than generating revenue for you when, instead, you can take them and focus on improving your core business?"

When I make that pitch to a business person, they almost always default to buying their CMDB.

I hope this helps.

Regards,
_________________
[Edited by Admin to remove link]
Back to top
View user's profile Send e-mail Visit poster's website
PDCA-Maem
Newbie
Newbie


Joined: Feb 24, 2006
Posts: 3

PostPosted: Sat Feb 25, 2006 6:39 am    Post subject: Buy or build Reply with quote

Hello Jeff

As with most products, one-size-fits-all is usually a myth. More than likely, you won't be able to buy one solution that covers 100% of your CMDB needs, but consider this: As momentum builds toward standardization (and certification), so will the demand for CMDB products which will support initiatives such as ITIL. If you build your own, you could find yourself out on the fringes of configuration management while others take the automated road paved by the best minds in the technology business.

My thoughts.
_________________
PDCA-Maem
Sr. Global ITIL Operations Project Manager
Back to top
View user's profile Send e-mail
rjp
Senior Itiler


Joined: Mar 12, 2005
Posts: 255
Location: Melbourne, Australia

PostPosted: Sat Feb 25, 2006 3:28 pm    Post subject: Reply with quote

Jeff,

I would like to second the replies given by both Frank and PDCA-Maem.

It's true that the market has now responded to demand sufficiently and has produced high quality technologies to meet configuration management needs. (The cost of these solutions is of course another question)

In addition many 'horizontal' initiatives are occurring which address the need for configuration management have been loping along for a while now - in the areas of process modelling, data exchange, and information architecture - which add another factor to the buy - build decision. For example the best technologies are BMPL, XML, CIMM aware at the least. And incorporating standards and frameworks such as these would be a significant cost factor in any self-build approach.

However, what is on the market does not totally address the requirements on the ground - and I doubt there are many IT shops that could find a perfect out of the box fit to requirements anywhere on the market.

The real challenge is to break the business requirement down into discrete functional components that might be addressed, in turn, by offerrings on the market, and to deploy these as a solution in your business.

Some of these functions might be:

*Auto-discovery and colleciton of asset and component information.
*Auto-discovery and reporting of component status against a system of record. (Not the same as the first function at all).
*Clssification and mapping of disparate components into aggregate structures (systems, services etc) that need to be managed as a whole.
*Mapping of component and system relationships into technical dependencies.
*Mapping of component and system relationships into Service production fators (again very different to the previous function)

The overarching goal is to a) place management controls on your infrastructure and b) be able to roll up what is going on at the infrastructure level into an end-to-end abstraction of production activity so that everything can be underrstood and managed as a production factor of your services.

Getting the core functions/capabilities in place is the 'buy' part. Pulling them together and integrating them into a configuration management solution that is really underpinning your service delivery is the build part.

That may change, but not soon I would say.
Back to top
View user's profile Send e-mail AIM Address Yahoo Messenger
JeffL
Newbie
Newbie


Joined: Oct 19, 2005
Posts: 6

PostPosted: Fri Mar 03, 2006 1:48 am    Post subject: Reply with quote

Thanks for all your comments
Back to top
View user's profile
Globis
Itiler


Joined: Apr 17, 2007
Posts: 36
Location: Cape Town

PostPosted: Mon Apr 30, 2007 7:19 pm    Post subject: Reply with quote

Quote:
Anyone have any thoughts on the advantages/disadvantages of buying a CMDB solution vs. building an in-house solution ??


If you buy a product you have two choices:

1) You adjust all your processes to work the way the product works - this is the fastest & possibly cheapest way to implement but it may not fit how you work today.

2) Buy a super-flexible prouct that you can make work how you want. This is much slower, much more expensive and you will have to maintain your implementation of the product. Upgrading to a later version of the product may be extremely difficult.

If you build:

A long road to implementation, but not always slower than 2) above. Probably more expensive when you take into account all of the effort involved, but not always much more expensive than 2) above.

However, this is probably the only way you will get something that fits how you want to work (although this is not always a good thing).

If your organisation is used to building software/dbase solutions this may be the way to go, after all you know your own business best.

If not, you'll need to compromise.

For most organisations option 1) is probably the lowest cost and if willing and able to change to how the tool works, probably the fastest.

Dave
Back to top
View user's profile
Cotswolddave
Itiler


Joined: Mar 23, 2007
Posts: 35
Location: UK

PostPosted: Thu May 03, 2007 8:16 am    Post subject: Reply with quote

A good question. I think in practice you faced with two choices of which only one is really the way forward

An inhouse development will not deliver as quick as a commercial off the shelf product. Also the inhouse system will always demand lots of resource to define, refine and optimise with time. If you have plenty of programmers, business analysts and process designers that will always be unallocated, then maybe its good for them. Unlikely to to be good for the users or business.

An off the shelf "CMDB" is a toolset that will have to be customised to reflect naming conventions, classifications etc. so it will not be a zero maintenance solution. At least something will be delivered quickly and you have to the supplier expertise to turn to if you get stuck with definitions, processes etc.

If you actually cost the inhouse solutions with the true costs, then adding the potential risk of failure it becomes a no brainer. The argument about buying something that doesn't meet your needs is a fallacy, you probably were not able to define them in the first place to make a good decision. The in house development just delays anyone having to write a spec that involves the impact on other teams and processes when you have this "CMDB".

The amount of times I hear that a CMDB is "only a database" when in fact it is a common knowledge base that requires teams to work closer together and rules to be observed. If you let developers go off and explore how they would build their own, make sure they realise that failure to deliver will affect them personally. Suppliers have to build in their process expertise (of varying depth) to enable them to sell their tools. Why would you not want to take advantage of that?

To be balanced, much of the CMDB stuff around is not really that usable, but you could waste time and money re-inventing the wheel.

Dave
Back to top
View user's profile Visit poster's website
Guerino1
Senior Itiler


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

PostPosted: Sun May 06, 2007 1:53 am    Post subject: Reply with quote

The scars of experience are always noticeable, aren't they?

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.