Somebody help me: what is the point of standalone CMDB tools?
Can somebody please explain how a stand-alone CMDB supports Incident and Problem and Change management if it is not integral to the Service Desk. How do incidents and changes get linked to a CI? In my simplistic little skeptical world it seems to me that you either pay your service desk vendor to provide an integrated solution or you spend a fortune doing the code-level integration yourself.
(This question arose from a recent discussion on another thread)
Readers will be aware I am no fan of technology, but there are some core things that can and should be automated. These are:
a) an incident ticket is linked to a CI (or asset)
b) a change ticket is linked to a CI (or asset)
c) [in ITIL 3 speak:] a request ticket can be linked to a CI (or asset)
and either integrated with this or on a separate technology island:
d) SLAs are defined against CIs
e) current status is reported for a CI (or ...)
f) availability/performnce SLOs are tracked, reported and alerted
So my questions are:
1) How does a standalone CMDB provide this capability to a service desk tool and a systems management tool in a cost-defensible (i.e. business-pragmatic) manner?
2) given that 95% of service desk tools can do a-c and systems managment tools do d-f now, why would you replace or duplicate their existing "CMDB" capability? (cost-defensible business reasons not idealistic technical ones please)
In the case where an organisation is operating effectively with their current change and help desk systems then what do they want new technology for? We reengineer process when the current process is deficient or we want to raise the maturity of the current process. And if they have current change and help desk systems then they almost always have the startings of a CMDB in those systems, so why would they want to introduce an entirely duplicate technology just because it is "better".
It isn't the guy with the best tools who wins, it is the guy who operates with more effectiveness and efficiency than his competitors. Tools never ever deliver that, process does. Tools help process. I think these stand-alone CMDB tools are pitching a technology solution to a process problem.
In an ideal world we will all use a CMDB that OOTB integrates with all service desks and systems managers and we will merrily plug and play. I hope I live to see it. Right now we have a job to do with somebody else's money.
Made in New Zealand 
Comments
Standalone CMDB is a reality
There is theory and there is practice. In theory the "CMDB" is linking various sets of information to CIs. In practice however;
1. People have multiple service desks through history
2. The service desk was bought for incident and other needs, no one looked at the detail of how a CMDB would be updated, used and validated for multiple technologies.
3. Not all IT people have access to the service desk, or want to.
4. Getting an end to end service picture where there are outsourcers involved is not so easy as ownership becomes a big issue. If they also run your help desk for you and it is shared across other customers, forget using the CMDB module!
5. Its difficult to get a list of IT assets, never mind map how they hang together
6. Typically a CMDB doesn't map relationships between everything, just the critical services and systems so there are still plenty of spreadsheets, notes databases and visio diagrams everywhere that are used for planning changes.
7. Incidents, changes and problems are often logged incorrectly against CIs anyway and often closed off properly so service reporting is of limited accuracy.
8. Technical groups can't get the detail they want into the CMDB without making over complex, or too dumb to be of value.
9. When you finally customised your service desk and implemented the CMDB, the manufacturer then comes out with a new version which results in your custom reporting, data synchronisation and CMDB relationship mapping being thrown away.
So.....
There is a market for stand alone CMDBs! I know because I am a vendor of such a beast and people buy it, even though they have a service desk system with a reputed CMDB capability. Why do they buy it in practice?
a. A team or group want to map components and relationships within a quick time frame and messing around with the mega service desk system is too difficult as it involves setting corporate standards
b. The service desk team don't see it as a priority and in the too difficult category, with the service owners having to do their own thing.
c. Required functionality may be lacking, or the user interface is unhelpful
d. The future of the current service desk is uncertain, so a stand alone solution can deliver consistency.
You don't get the nice fluffy integration of service management data promised, but you get something delivered in days or weeks which is usable. Ty mapping 1000s of servers/software/services without using a database of some form.
Standalone CMDBs do exist and deliver value as they get round people, technical and organisational barriers. This might be heresy to the purists, but some people have day jobs and have to deliver against real needs
Let's go back to first principles and semantics again
Let's go back to first principles and semantics again Dave:
If it doesn't map incidents problems and changes to CIs it isn't a CMDB
if it doesn't map services to CIs it isn't a CMDB
If it doesn't support ITIL processes especially (but not limited to) impact analysis and SLA reporting, it isn't a CMDB.
So I don't doubt that what you deliver works, is very useful and overcomes real day-to-day issues. I just question whether it is a CMDB as ITIL defines it (and there is no other way to define it as it is an ITIL term)
Who defined a CMDB first?
You might find that ITIL was not the first to define the concept CMDB - check out the Institute of Configuration Management - also check out the term/concepts related to Metadata... we need to remind ourselves of the objectives/needs that result in the call for a CMDB type solution. Relate all the elements needed to provide a specific service and the service level objectives. Thsi should take you directly to teh activities performed by the users - and then use those to map relevant infrastructure - ANY item - whether owned by IT or not - and you thought just the IT components were difficult to find and relate!
Institute of Configuration Management
Funny you should mention that. just last week I met someone who is CM-II certified - I'd not heard of it before.
I assume this is where some of that part of the ITIL IP came from??
There is a great overlap with ITIL. Seems to me the big difference is that CM-II is not service oriented. "The scope of CM, per CMII, includes any information that could impact safety, quality, schedule, cost, profit or the environment."
Overlap
Funnily that scope list looks quite close to a the critieria I agreed a few years ago in an energy company for deciding the priority of incidents (though with the addition of damaging PR!)
The etiquette of referencing sources
Well we shall never know if anything was gleamed from CMII - ITIL has a habit of NOT recognizing sources - I can offer CFIA (IBM), FTA (Bell Telephone), and Service Lifecycle, Service Provision Lifecycle, Incident Lifecycle and Holistic Service Management (ITSMI) as just the tip of the iceberg.... you can be sure we shall be looking for any such examples in V3...
Sources in v3
Hmm, well large parts of the volume I QA'd seemed to consist of summarised chunks of well known management texts. Though this was at least acknowledged I always think it is better to send people back to the original source. I know that several possible contributors to ITIL 3 held back because of the fear of IP rights being lost.
Baffling
I seem to recall the OGC website saying over 40+ vendors (many with multiple proposals) bidding for the opportunity to write a V3 book. I have to imagine all the usual big-name suspects were in attendance with their best thinking.
Why weren't they afraid of losing IP rights? They are typically the toughest defenders of proprietary IP. And what does that really mean? OGC will own their diagrams or descriptive terms? These things have very short shelf-lives to begin with.
If something is to be considered an industry practice, I imagine it has to be "battle-field tested" or at the very minimum peer-reviewed. Any good idea, particularly in a knowledge industry, is notoriously difficult keep from spreading. Sort of like sharing fire, everyone receives warmth but the new fires no longer belong to the original owner (forgive me for mangling an argument by Thomas Jefferson on IP rights).
Is it licensing? In many ways, people use the IP or take the training only because of the ITIL brand. Larger audiences mean that there would be increased opportunities and credentials for the author of the material - despite no longer owning the IP.
Or are we are discussing closely guarded closet systems with carefully constructed home-made process models? These models so good, they cannot be shared with the outside world? Well then, I think they made the right choice.
I don't buy the IP argument
I'm with Dool. I don't buy the IP argument. Anyone who held back over IP is not thinking strategically and has a twenty year old view of how IP can be managed. They deserve to have missed out. As I said in an earlier comment they are getting paid while at the same time getting priceless kudos, exposure, knowledge, experience and contacts, and shaping ITIL in their own image. I'd crawl over broken glass for a gig like that.
There you have it
Ah, but there is a world of difference, perhaps, between those vendors who have been behind ITIL for many years, genuinely are passionate about it, and mature in their view of the market and those who are busy jumping on the bandwagon. Some of the latter, I suspect, are jealously guarding IP that we regarded as outdated ten years ago. I have to say that I haven't seen anything in ITIl 3 yet which appears to indicate there has been a massive injection of IP. The discusssions about CMDB and service catalogue going on in this blog indicate the books still have a way to go to catch up with the best real life thinking going on.
Still skeptical
I still don't follow your line of reasoning.
Of all the big-name vendors, johnny-come-lately or not, only two won the rights to author a book (IBM is conspicuously absent). The remaining three books appear to be small European-based firms with authors involved since ITIL version 1. One must concede they "...have been behind ITIL for many years, genuinely are passionate about it."
So there we have it. A large pool of respondents, all passionate enough to compete openly and surrender IP, with subsequent winners representing old-hands and newcomers alike.
"I didn't compete because I didn't want to surrender IP," sounds like self-important posturing at best. A bit like saying, "I didn't compete for the olympics because I didn't want to reveal my running technique."
Its back to that definition of a CMDB
Yep, agree totally. The ITIL CMDB and all the pretty workflow diagrams are good in concept but miss out on the practical reality of IT culture and lack of recorded knowledge. Technology got a bit more complex since the early days of ITIL, so understanding the impact of a change sounds great in theory, but how many IT people recognise or understand how one technology works such as software, never mind all of them lumped into a service.
At the end of the day, what people actually use must be "best practice", so as a skeptical person it is easy to deduce that the CMDB concept as it stands is not best practice - where are all those CMDBs the ITIL books are describing?
Anyway i have a new concept to blog about - our latest bit of software is called a CMDB analysis engine. It links to existing CMDBs (Peregrine, Remedy and so on), analyses the relationships between CIs and draws service maps, physical maps and so on. Another new piece of jargon for the industry!
draw service maps through analysis
I'm intrigued. Can you really draw service maps through analysis? Last time I saw this stuff it was pretty dumb. How do you separate out services sharing a common database, a common web server, common mail server, common code....? When a software product provides transactions for three services how does analysis unravel them? When a service runs through EAI middleware, Web Services or the internet, how do you follow it?
You may guess that I think you can't ;-)
well it can de done!
Hi Skeptic,
Maybe I should elaborate, you can draw service maps from a CMDB using the data that is in it. We do not attempt to "discover" relationships using any fancy technology because the world is too complex for such tools and the way services are categorised is manual anyway. There lots of discovery tools already out there but they are often technology centric (server,network, desktop etc) and they only discover technical data, none of the business or service stuff.
What do I mean by drawing service maps.
a. select a service, analyse all relationships with underlying components or CIs and then generate a picture which you can modify to make readable, embellish etc.
b. select a CI such as a server, analyse relationships above it so you can see software, systems, services and business processes impacted (harder to do than a.)
c. Select something in the middle like a piece of software and then show all supporting components and all services etc. impacted in a service map
d. Select a seed point such as a service and then show all relationships between shared components, services and processes in a service map
So you can rest easy in that there isn't a claim to have a magic bullet than creates a CMDB of CIs and relationships. But those who have expended the effort in using their service desk as a CMDB often find they can't use it effectively. Our CMDB analysis software just uses what they already have. The biggest benefit to be honest is to quickly validate how it is set up so at least it is a reasonable representation of the current state.
Its a fairly trivial exercise to then bring in incidents, changes etc. and show them on the same service maps so that you can see what or where CIs are affected. It works well in larger environments with 1000s of servers where you need maps to comprehend issues across the services. It does mean that capability to generate 1000s of service maps is necessary
But you do need the data to start with.... before you can analyse it.
Please remember that i was a software vendor for over a decade
Please remember that I was a software vendor for over a decade. So when I hear "Its a fairly trivial exercise to then bring in incidents, changes etc" my radar goes off :-D
1) I'm assuming you mean that the CIs were already linked to the incidents and changes in the underlying service desk tool? Otherwise bringing them in would be highly non-trivial.
And 2) since incidents and changes are transactional, not static, how do you 'bring them in" frequently enough to be current?
Finally 3) I've seen GUI relationship-walkers in a few "cmdb" products. The Fat Four (IBM, HP, CA, BMC) all(?) claim to have import tools to 'bring in' data from other systems too. How does what you are describing differ from the facilities in the existing tools other than being cooler or better? i.e. what distinct business advanrtage does it give to justify the investment of the extra layer? Have i missed soemthing?
Linking service maps to incidents/changes etc.
Can't get one past the skeptic... He has too much experience and insight to believe my few words and is "skeptical"
1) In practice, if CIs are already linked to incidents and changes in the service desk then it is easy, using the CI ID as a reference. Our typical approach is to put changes, incidents, problems under the specific CI icon and have the item go red, flash etc. to reflect status, changes within last few days or planned etc. So that you can "see" where there are potential conflicts or lazy admin and things haven't been closed.
If you have don't have CIs and incidents/changes in the same system then you have a control problem and require manual checking. You have to use names as unique references for the linkages. For example an outsourcer and their customer can have two service desks, have different change processes but still understand and communicate on service issues.
2) Q. How do you reflect the current status when you are refreshing views? Well it depends. In a simple model you load up a service map and press refresh. If you have 100s or 1000s of service maps it is easier to do a timed automated refresh so that "hotspots" are noticed. As we may be generating all sorts of perspectives from a common source then you choose if there is value in having something updated within a day, week, quarter etc.
Many of customers see the production of a defined, owned, validated service map for every service as being the most valuable deliverable. Second to that is extras such as showing additional information such as changes, status etc. To put this in context, we are talking of projects lasting maybe a week or two for environments with 1000s of servers.
3)GUI Relationship Walkers
Not familiar with them although you could mean federated, dashboard or other terms where a view combines multiple data sources. It is normally their service desk systems that we are linking into - so there are customers who can't get what they want. If you or anyone else can give a lead on where to get info I'd appreciate it because there is too many concepts and little meat.
I suppose what we do is like the London A-Z. We try and link the index of streets at the back to high-level, low level and specific need maps (underground, congestion zone, hospitals etc) where a visual context may the best way to understand.
reflects on vendors' services and support more than products
Hi Dave
It sounds like what you are doing is useful stuff. Whether it is what ITIL defines as a CMDB is still to be argued, but it sounds closer than some.
I can't resist one last ex-vendor observation: the fact that clients of the Fat Four cannot get what they want often reflects on those vendors' services and support more than their products. Many of the product implementations I have seen exploited only part of the product's capability and then the implementation was often poor or just plain wrong bacause the client was left to sink or swim. There is a cynical merry-go-round where they buy one, then four years later decide it doesn't work and buy another. Either would have worked for them if (a) they invested and (b) the vendor cared.
Asking for help?
There is some truth to that, why is it that a buildings project manager does not ignore the advice of an architect, quantity surveyor, supplier of air con etc. I think there are many reason why implementations fail - customers often buy badly and suppliers won't highlight problem areas unless they have to. So the short term needs to manage incidents, changes etc. are focussed on while the tricky subject of config management is avoided.
While we use the term CMDB as part of the product name, in practice we hardly mention it when we are demoing or implementing. Its easier when talking to a customer team to focus on specifics such as a service map, or a list of servers that are critical to a process, or identifying where the test/dev/live version of an app is hosted. But with a marketing hat on - stick CMDB in the title of a seminar and you will get hundreds coming to see if the holy grail exists.
The CMDB concept is still worth striving for, becuase what else is there that attempts to understand how multiple technologies deliver services?
Have enjoyed the challenges and maybe evidence of one of our implementations will be leaked to the public.
Dave, I’m afraid I too
Dave, I’m afraid I too remain unconvinced on this one, but I am strongly hoping I can be presented with scientific fact to back it up. I had been looking at a few tools which touted the capability. One is an upcoming product from Citrix, which provides for alerting and measurement of the end user experience within the MetaFrame farm, and the other was a Blue coloured Performance Test manager. Supposedly able to measure and track the responsiveness from and an end user perspective, a Java Web based application server (Virtualised) using a range of external middleware services connecting through to an enterprise database. (Mainframe)
Lets look at the equation, end user to MetaFrame, MF server operability (Sessions hosted, concurrent processes, page file swapping r/w, Concurrent library of applications with multiple backend dependencies causing undue processing (incl Domain chatter, print network, ACL’s), Network Latency, WAN Traffic Prioritisation, etc. Java Web Server fronted with Proprietary Web Platform Load Balancer and clustered set (Host in VM Farm), with service bus, middleware layers exporting and loading into several enterprise DB’s in a mainframe environment and the vendor say “Hey No Problem”.
I do know that it is feasible to monitor these components and draw analysis but to auto discover and construct the service map may be somewhat difficult. I personally recommend a manual approach to mapping these services with a little technical tool assistance. Once defined they could be loaded into the Open Source Monitoring framework Nagios under Orion config, and detail all services and hosts under a child / parent / grandparent relationship to enable ongoing monitoring. There is also a Nagios plugin called Webinject that is able to perform the initial call to the web server, initiate DB access, DB Commit, Transaction completion, and report the round trip at whatever preset service timing check you specify.ie 5 mins.
I look forward to being convinced it is mature and accurate enough to be presented to enterprise as a qualified service worthy of the funds expended for the engagement.
Please drop me a note at one of the cmdb.info forums if you want to discuss the technical attributes, Thanks and look forward to hearing from you.
measuring a service as a black box
Maverick, as you say measuring a service as a black box is possible.
Not only is it possible but it is essential. See my latest blog entry (thanks for triggering it)
discovering business process
we once had a situation where a business fax turned out to be a critical component of an order entry system, responsible for receiving orders from folks in the field. It broke. It was not regarded as an IT asset or configuration item. It was not discoverable. Until we walked the process with the customer and manually discovered it was truly a critical element. So when the fax ribbon broke and orders came out blank - money was lost. The true expanse of a service can be very, very suprising.
Nice points
Your point about the fax reminded me of a distinguishing term I encountered during the ITIL Service Strategy Public QA. The draft made a point to speak to "Customer Assets" as well as "Service Assets." Customer Assets are tightly coupled to Service Assets but frequently overlooked. A customer asset can be a fax, business process or person.
Without Customer Assets, services have little point. A simple but, as you point out, essential observation. On second thought, it is a brilliant observation precisely because it is so easy to overlook or consider irrelevant.
Service Assets affect the performance potential of services which in turn affect the performance potential of Customer Assets which in turn affect the potential of business outcomes.
V3 grows more and more interesting every day.
V3 catching up...?
We have distinguished service assets from plan infrastructure and customer assets for years and it is reflected in our ITSM Body of Knowledge (ITSMBOK) in the form of service asset management and service infrastructure management practices. We take a truly holistic view to try and avoid these issues that are largely caused by a perpetual IT view of service. Its encouraging to hear that ITIL V3 respects this and is effectively catching up to the real word experiences. I have not been able to review any V3 materials yet - any more insights as to how they define a service.... did they go as far as recognizing that 'vital business activities' - or those that drive results - are teh main service elements - you must check out our ITSMBOK!
Love this point. A
Love this point. A fax!
CMDBs cannot discover everything, and tools that discover are not CMDBs
Well the Jury may be out for some time on this one
It would seem that there are compelling points from either side, the first being that, as ITIL is being embraced as a standard there would need to be product offerings to support the enterprise in its implementation. That’s what the commercial software vendor community is doing at the moment. Secondly is that, organizations are currently, right now, next week, wanting solutions to assist with real organizational IT issues which can only effectively be solved with automated tools.
It would appear that the middle ground is a modular and scalable platform which enables organizations to undertake specific areas of practice elements to enable them to resolve their immediate issues or to undertake a full implementation of ITIL. The overall design needs to accommodate all elements of ITIL theory model, but also be able run individual modules to cater for single detailed practice elements to resolve immediate issues. What is being proposed at CMDB.info meets this criteria. There is also a bit of a rant about Should the CMDB be separated from the ITIL process at technorati. Also in support of anyone wanting to take the first steps into the technology arena, The forum is discussing the install of auto discovery tools.
And yes my day job line management rarely want to hear the operational management theoretical pontifications of a raving configuration management practitioner; they just want their problems fixed and gain the benefits for the least amount of financial input possible. That’s what all organizations really want, They will make IT departments take as much pain as they can bare, until they react and fund critical projects. To many in management this is common practice, do as best you can, with as few resources and tools as possible for as long as you can. And only provide funding when absolutely necessary.
Stand along CMDB
I agree with you. There is no such thing as a 'stand-alone' CMDB.
If CIs are not linked to problem, incident, change and, indeed, event, release and other process records they aren't much use.
The problem is that there isn't a general interface between the various process elements, so, if you have your events measured by OpenView, your incidents managed by CA Unicenter and your change management managed by yet another tool, there is no common language between them, so there isn't really a way to link things together.
What is needed is a common interface standard, with this any individual process tool could link to the configuration process tool (aka the CMDB) as well as any other. This is not likely to be reality for quite some time, though!
A common interface standard
A common interface standard, for the most expensive tools on the market. Nah its not in anyones commercial interest for that to happen. We need to embrace the efforts of the open source community. There is no reason why GForce / SVN Subversion could not replace much of the Change / Problem and incident requirements of your site. Check the screenshots.
http://www.cmdb.info/pd1tools/html/screens/my-dashboard.png
http://www.cmdb.info/pd1tools/html/screens/project-graphs.png
http://www.cmdb.info/pd1tools/html/screens/tracker-browse.png
http://www.cmdb.info/pd1tools/html/screens/roadmap02.png
Check out other tools at www.cmdb.info
The only way around this is move away from vendor developed solutions
OK, one more question: what
OK, one more question: what standard are the open source tools coding to, in order to ensure plug-and-play interoperability?
Interoperability within open source software development
The tools that I use are all linux server based and rated as the top offerings in their functionality. All installs are performed under command line with a variety of options. I believe that desktop software is now becoming reasonably mature in terms of clean install on a range of hardware types. The types of languages used are primarily, Perl, PHP, C, writing to MYSQL DB, but its really a case of using whatever is practical for the job at hand.
Key features of Linux distributions are the supported binary software packages which can be downloaded from a supported repository under apt-get or wget etc, and yes you guessed it there is a wide variety of standards. Say for MYSQL it depends on where you get your package from as to how it installs and sets up.
I have applied a build of ubuntu linux and only used selective packages, others I installed manually even though there were packages available. The build I have specified still takes several days to build and I’m reluctant to script as the overall build may need to built differently for scalability reasons at different sites.
Most importantly, the one standard I have been able to maintain throughout this exercise is that of the Database platform. MYSQL. Without this, the project would have been of little long term benefit. Provided the data is all in one format we can do what ever we want, when we want, with whatever we want.
Linux/Unix and M$ are two very different worlds. The beauty of an open source toolset is that you get down to the physical layer of network devices and by operating outside of the domain structure. It would be unlikely you would ever see this software packaged under a graphical installer and have it install and just setup, and less likely to see it packaged for M$. Its a solution that needs to be implemented with the assistance of a Subject Matter Expert if you want to deviate from a standard build.
I thought it fitting to finish this comment with a quote, which I rarely do.
“Everything that can be counted does not necessarily count; everything that counts cannot necessarily be counted.” Albert Einstien
Uniform Resource Indicators (URIs)
I know how it *ought* to be done: via Uniform Resource Indicators.
http://en.wikipedia.org/wiki/Uniform_Resource_Identifier
Let's not get too hung up on the so-called realities of the current situation, which in a historical sense is still terribly immature. We still have some room to think outside the box and innovate.
Charles T. Betz
http://www.erp4it.com
URIs - you're right
You're right. And some of the vendors use these, at least to a limited extent...
Benchmark framework for the CMDB
Many small organizations operate in what most IT professionals would describe as a state of blissful ignorance. They have their experts who in some cases are quite misguided, always wanting the latest and greatest to fix a problem, but don’t quite know what their problems are. Organizations such as this rarely have a systems management capability, are resource and skills constrained, and have limited visibility of issues. The management layer responsible is extremely vulnerable to the software and service vendors, always being sold something that never quite does the job. So a limited standalone capability in a practice element is better than no capability. But instead of letting reality get in the way of a good theoretical debate I have detailed a response to the questions.
Q.1 The answer is clear that a standalone CMDB element is of limited value to an organization and the effort applied to achieve it should be constrained. However when you consider the cost savings realized by implementing a simple systems management practice, it becomes a real consideration for many organizations. As most IT sites are striving to achieve some degree of best practice approach, the need for a manageable low cost solution to address this requirement can’t be under estimated.
It’s similar with Change and Incident / Problem, but we know that all organizations have some capability in these areas. To date these elements have survived as standalone practice elements without linking to CI’s in many environments and although fulfilling their purpose have only provided limited benefit. Then over time configuration information goes out of date and is never updated.
Q.2Why would you replace the Service desk or systems management components. If an organization is happy with their current capability then no, there would be no point. But for an organization that would like to implement a systems monitoring capability, cmdb.info provides information which enables an organization to build this solution from open source tools. Under the open source license they can alter it in any way, and with open source standards programming interfaces is not that difficult. So they can integrate their current capabilities.
So to clear up any misconceptions regarding the open source toolset from CMDB.info It is not proposing a stand-alone CMDB. It’s just that I haven’t fully explained how integration with service / change desk can be facilitated. Integration of Change and Incident / Problem is recognized as key areas for compliance to any benchmark framework termed a CMDB. Integration of this toolset for an organization that was operating standalone change and incident would be a cost effective approach. Ideally, for an architectural approach a larger solution would need to be scaled based on business requirements. If we were approaching an enterprise requirement I would suggest Subversion and on a smaller scale there are other tools such as Issue Manager from Ultra Apps (MYSQL) and Helpdesk Issue Manager from http://helpdesk.centralmanclc.com (Postgresql). It also depends on the amount of integration that an organization’s management want to apply. But any required workflows can be enabled. Subversion is used by Sourceforge for tracking of development effort and source code management and hosts thousands of members.
CMDB.info is about enabling technology for those organizations looking for alternatives to the mainstream vendor offerings in Auto Discovery Tools, Port Scanning, IP fingerprinting, Systems Monitoring, Service Monitoring, Service Level Availability, Software and Asset Management , and Software Deployment.
Maybe another debate should be “exactly what technology functionality should be enabled in a CMDB”.