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.

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.

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.

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.

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.

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.