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: EKaestner
New Today: 41
New Yesterday: 68
Overall: 148066

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

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 - Anyone actually got a successful config management/CMDB?
 Forum FAQForum FAQ   SearchSearch   UsergroupsUsergroups   ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Anyone actually got a successful config management/CMDB?
Goto page 1, 2  Next
 
Post new topic   Reply to topic    ITIL Forum Index -> Configuration Management
View previous topic :: View next topic  
Author Message
UrgentJensen
Senior Itiler


Joined: Feb 23, 2005
Posts: 458
Location: London

PostPosted: Mon Feb 19, 2007 9:57 pm    Post subject: Anyone actually got a successful config management/CMDB? Reply with quote

Hi All,

I consider myself to be a fairly experienced ITIL Service Delivery Manager and have successfully introduced quite a few processes, service desks etc.

The one area I'm not so experienced with is Configuration Management and CMDBs imparticular.

I already know what the manuals say, but has anyone actually implemented a CMDB and config process that gives them measurable improvement? Shocked

Cheers,

Urgent
Back to top
View user's profile
UKVIKING
Senior Itiler


Joined: Sep 16, 2006
Posts: 3316
Location: London, UK

PostPosted: Tue Feb 27, 2007 8:04 am    Post subject: Reply with quote

Yes, yes I have

And I have seen the SnuffleUpagus as well
_________________
John Hardesty
ITSM Manager's Certificate (Red Badge)

Change Management is POWER & CONTROL. /....evil laughter
Back to top
View user's profile
Guerino1
Senior Itiler


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

PostPosted: Wed Feb 28, 2007 2:27 pm    Post subject: Reply with quote

Hello Urgent,

We help enterprises successfully establish Configuration Management processes and CMDBs all the time.

The question is simply understanding what "successful" means to those enterprises.

Configuration Management, when done correctly is not really a "process", per say. It's more of a byproduct of doing your work correctly. For example:

  • Proper design will yield proper design documentation that is versioned and managed.
  • Proper implementation will yield highly detailed and repeatable build and packaging rules that will be versioned and managed.
  • Proper distribution/deployment will yield highly detailed and repeatable deployments that are versioned and managed with respect to their targeted environments and assets.
  • Etc.

Configuration Management, as a process really shouldn't be more than making sure that everyone is doing their jobs and that the outputs of their efforts are properly showing up in the CMDB (smart enterprises will automate as much of this as possible).

Therefore, there really isn't a very "hard" or "tangible" return on having a CMDB and Configuration Management in place.

The value comes in leveraging the information that is maintained in that CMDB, when you need it. In essense, when done correctly, the CMDB becomes your Knowledge Management platform for IT (Quite honestly, it is truly nothing more than your Knowledge Management platform for IT), since it becomes your IT data warehouse.

You will see value when you can quickly go to the CMDB and "answer questions" with minimal search and report generation that would otherwise have taken you a small army to go off and collect the data.

Some examples...

  • A virus or denial of service attack that hits certain assets requires you to quickly understand what Businesses are impacted.
  • You want to know what Businesses are impacted by a Change.
  • You want to know how many assets will need to be upgraded due to a new Release of an existing Product, to assess work and impact.
  • You want to see trends in Incidents, Problems, Risks, and Requirements for key Products, Assets, Services, and Processes in your enterprise.
  • You want to understand which businesses generate the largest IT costs.
  • You want to know which Products, Services, and Processes generate the most support work, so that you can drive that work down.
  • You want to know what Products have the most Releases and Changes, so you can drive that work down.
  • You want to quickly dump inventories of Assets, Products, Releases, SubComponents, Services, Organizations, Projects, Processes, Resources, Incidents, Changes, Problems, Risks, Requirements, etc. so that you can use those inventories to make strategic and tactical decisions.
  • Quickly being able to find and access key Documentation for Products, Services, Processes, Assets, etc.
  • etc. (the list of uses for a good CMDB can go on and on)

So, the successful implementation of Configuration Management and a CMDB really is more about creating a powerful Knowledge Management solution for the enterprise that will lead you to help understand your enterprise, more effectively. Doing so will allow you to more effectively make both Strategic and Tactical decisions, since you'll have more clarity. Etc.

The net yield of a good CMDB is "Time Savings", because all the information you need is neatly stored and managed in single place.

Anyhow, I hope this information helps.

My Best,

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


Joined: Mar 03, 2007
Posts: 33
Location: Minneapolis

PostPosted: Sun Mar 04, 2007 7:35 am    Post subject: I have seen it done Reply with quote

I have seen a variety of successful configuration management systems.

Part of the problem lies in determining the scope of what you mean by config. See

erp4it.typepad.com/erp4it/2006/09/element_versus_.html

The most sophisticated system included in-depth element configuration management for the middleware systems of an integration competency center. I have described this system at

erp4it.typepad.com/erp4it/2004/01/delving_into_th.html

and the following 3 articles.

Charlie Betz
[Edited: No URLs Please]
Back to top
View user's profile Send e-mail
Guerino1
Senior Itiler


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

PostPosted: Sun Mar 04, 2007 11:26 am    Post subject: Re: I have seen it done Reply with quote

Hi Charlie,

alphasong wrote:
The most sophisticated system included in-depth element configuration management for the middleware systems of an integration competency center. I have described this system at


In addition to my own review of the content you referred us to, I had my architects take a look, just to be sure that I wasn't out on a limb on my own about this. Please don't be offended but we disagree with your view of this model being elaborate. Our view, based on reviewing the material you've provided and our experience in providing CMDB solutions as a business, is that the model you have in place is the typical model that will break down, when modeling CIs and the relationships between them.

Using concepts such as "Systems", "Components", "Libraries", "Modules", etc., while not wrong, are very vague, incomplete, and limiting. The reality is that if you're doing proper configuration management for your enterprise, you're tracking all configurations, as they pertain to all operational domains, and as they pertain to all stakeholders and their roles...

  • SW Composition
  • HW Composition
  • NW Composition
  • Facility Composition
  • Stakeholder Composition
  • Inventory tracking of "all" trackable entities: Source Files, Release Units, Documents, Assets, Products, Services, Processes, People, Projects, Vehicles, Facilities, Organizations, etc. (The list is huge, especially when you break down each permutation of each type.)
  • Build rules for all trackable entities
  • Deployment/Distribution rules for all trackable entities
  • Installation rules for all entities
  • Instantiation rules for all entities
  • Behavioral execution rules for all entities
  • Rollback rules for all entities
  • Failover, Disaster, and Recovery Rules for all entities
  • Etc. The list is huge...

The reality is that to model a limited system will yield a limited solution, one that breaks down quickly. We see it all the time. This is why enterprises that build their own CMDBs usually cry out for help and why enterprises that buy CMDBs that only focus on infrastructure call foul.

A truly useful CMDB tracks "everything", including all relationships and the details of the relationships between "everything", so that you know what direction the relationships go in, what the details of the relationship are, prioritization on relationships, context on relationships, and so much more. When done properly a CMDB is an elaborate Knowledge Management platform for the IT organization, one that allows any and all stakeholders, regardless of their role(s), to find what they need, when they need it, and see it how they want it.

I comment on all of this based on our experience. We actually design, build, and provision what might arguably be considered one of the most advanced CMDBs in the world, because it meets most of the criteria, above, and is constantly moving in a direction to address all of that criteria. It's always a slam dunk when we go up against models like the one you've described. There's got to be a reason for that. Our opinion is that it's simply because those types of models are limited, both, in their vagueness of CI modeling and in the fact that the types of CIs are highly incomplete.

Anyhow, I hope this helps.

My Best,

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


Joined: Mar 03, 2007
Posts: 33
Location: Minneapolis

PostPosted: Sun Mar 04, 2007 1:17 pm    Post subject: I realize you have a product to sell... Reply with quote

Hi Frank,

Looks like I brought out your competitive streak. Or your marketing streak, which is prominently displayed in your ongoing posts here. I'm actually a little surprised at your response and what appear to be some misunderstandings/mischaracterizations. (I'm also impressed that you and your architects can do a thorough analysis of four long and in places rather theoretical posts, and come up with such a definitive conclusion in four hours.)

The four posts describing the integration metadata problem were not a complete description of the system in question, which was actually based on the Adaptive repository. Perhaps your engineers have heard of that product, which with its OMG MOF kernel I suspect is technically competitive with anything your company has put together. (Unisys is now marketing it as a CMDB, branded IT Modeler.) Many of the other requirements you mention were also handled in that system, but the integration metadata subset was to my mind the most interesting, and one which I still have not seen handled by any CMDB or repository to the detail and sophistication we achieved with that implementation. (It took quite a bit of customization.)

By the way - I am wondering if you only read the first post. That was just laying the groundwork. The interesting metamodel is in post #4:

erp4it.typepad.com/erp4it/2005/06/an_integration_.html

I've been tracking your writings for some time and, based on what I have seen, I am unconvinced regarding your product direction. I am concerned that you are attempting far too monolithic a CMDB. I suspect you are not using the essential distinction I have proposed between enterprise and element configuration management, and will therefore be playing an endless game of platform coverage you can never win. See

erp4it.typepad.com/erp4it/2006/09/element_versus_.html

One of the most important things to realize in CMDB design is that it is part of a distributed architecture. Concerns like installation and rollback for example are the proper domain of platform-specific provisioning tools such as Opsware or mValent, which are *not* CMDBs. See

erp4it.typepad.com/erp4it/2006/04/here_is_a_simpl.html

which is only a very high level view; I have much more detail in the book.

The inclusion of domains far from core IT data center concerns is also reason for skepticism. (Vehicles? Really now...)

Rollback in terms of audit trails for specific CMDB data structures is a mundane implementation concern and while we had that in place for the integration CMDB, I chose not to include it in the conceptual model or writeup.

I agree that vagueness is a problem in CMDB/CI definition. I have written about that problem extensively, and proposed my own data models (field tested) to address this, which include most of the elements you cite. See

erp4it.typepad.com/erp4it/2005/08/a_data_architec.html

(again, this free, public version is much less comprehensive than the book's treatment and has a couple of significant weaknesses I have since addressed.)

I don't agree that the list of CI types needs to be portrayed as overwhelmingly numerous; to me, that is a failure of abstraction and needless over-complication. Perhaps it suits your marketing purposes to frame things this way, but more is not always better in data architecture, as I'm sure your architects will agree.

I also don't agree that the term "knowledge management" has any place in this conversation. Knowledge management is about unstructured data, primarily. CMDBs are highly structured.

I do agree that people need to purchase products and generally not attempt to build this kind of thing themselves. But to intelligently purchase a product, they should seek a conceptual understanding of the process, data, and systems architectures in play, which is the service I am attempting to provide. I have no software to sell.

Regards,

Charlie Betz

[Edited: No links in the forum please]
_________________
Charles T. Betz
Back to top
View user's profile Send e-mail
Guerino1
Senior Itiler


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

PostPosted: Mon Mar 05, 2007 1:46 pm    Post subject: Re: I realize you have a product to sell... Reply with quote

Hi Charlie,

Please find my comments, embedded below...

alphasong wrote:
Looks like I brought out your competitive streak. Or your marketing streak, which is prominently displayed in your ongoing posts here.


Please don't misunderstand competitive spirit for a pet peeve. You actually hit one of my greatest pet peeves in the ITIL area, which is the whole CMDB space. A CMDB is something that takes a significant amount of investment and, for which, has a very hard tangible ROI to pin down for that investment. I hate to see enterprises go down the road of implementing one if the one they're going to go after is limited, from the outset. So when someone points out CMDB advice, were' all over it.

Quote:
I'm actually a little surprised at your response and what appear to be some misunderstandings/mischaracterizations. (I'm also impressed that you and your architects can do a thorough analysis of four long and in places rather theoretical posts, and come up with such a definitive conclusion in four hours.)


Please don't be suprised by my response. I take my responses on this forum pretty seriously. When I see something that I feel I can offer value to, I get involved.

I'm impressed with my architects, too. They're highly paid professionals that have been trained to find and fix problems very quickly, which is why I have them. It doesn't take much for them to see things that are obvious. There are a lot of obvious issues with the model(s) you've pointed us at. For example, there is a mix of abstract and concrete objects, being modeled together (e.g. "system" is abstract and "Support Org" is concrete), which usually indicates weak modeling experience. I'm not implying that you created the model, as I don't know who did create it. All we can say, from experience, is that good data modelers understand not to mix abstract and concrete, as a best practice, and that having any concrete in your model will eventually not scale, as concrete objects will require a tremendous amount of support code to be written in the other architectural tiers of the design.

Quote:
The four posts describing the integration metadata problem were not a complete description of the system in question, which was actually based on the Adaptive repository. Perhaps your engineers have heard of that product, which with its OMG MOF kernel I suspect is technically competitive with anything your company has put together. (Unisys is now marketing it as a CMDB, branded IT Modeler.)


I am aware of Adaptive's repository but only from following it, myself. I haven't come across it, in industry, at all ,yet.

As for technical competitiveness, I'll simply leave that up to the prospects that evaluate the two systems side by side, when the opportunity presents itself.

Please note that the model you pointed us to is highly limited, in that 1) it only attempts to address the IT infrastructure domain and leaves out many other critical domains that are required by a good CMDB, and 2) it mixes abstract and concrete concepts, which instantly shows us a system that will not scale.

Another flaw is that in the case of this model, the CMDB you're professing implies "yet another tool" for any enterprise that implements it. This means a CIO has to puchase, package, provision hardware for, dedicate resources to, and integrate "yet another tool" in their environment. Asking someone to roll out a CMDB like this is asking them to litter their environment with more tools, infrastructure, people, etc. Not good advice, in my opinion. If what you're offering is useful, it will help reduce infrastructure, dedicated resources, SW, licenses, packaging efforts, maintenance and support, etc. A good solution won't require more of it. A good solutionis will definitively help you reduce all of it. The model you're proposing is a pitch for yet another tool. Whenever someone implies the purchase and support of another tool, you can be guaranteed that my support will fade. IT leaders around the world are struggling with the problem of how to reduce IT, not help it grow. Recommending another tool is not something I stand by. Sorry.

Quote:
Many of the other requirements you mention were also handled in that system, but the integration metadata subset was to my mind the most interesting, and one which I still have not seen handled by any CMDB or repository to the detail and sophistication we achieved with that implementation. (It took quite a bit of customization.)


The meta model you pointed us to describes a tree structure, which is extremely weak for modeling relationships, as a a real system follows a graph based model, as do all entities in real life. Trees almost instantly break down. Here is an easy test for any CMDB... If you check out a SW file for edit and check it back in... and then I check out that file and check it back in... and then you check it out for edit, again, and check it back in... we have instantly created a circular dependency on that file, quite possibly for one or more changes that we're working on. We know a good CMDB when we can instantly see a solution for that simple example, because reconstructing the build, with a snapshot at any point in time, will require that the CMDB can unravel and understand the versions of that file, the dependencies between it, and the dependencies to the Changes that are being worked on in the software system. The example you point us to shows no inclination for being able to solve such a problem. And, if it can't solve this simple problem, quite frankly, it's not going to solve many of the more complicated problems that originate when trying to map complex dependencies between and within systems, products, services, releases, assets, people, locations, organizations, documentation, projects, and so much more.

Quote:
By the way - I am wondering if you only read the first post. That was just laying the groundwork. The interesting metamodel is in post #4:

erp4it.typepad.com/erp4it/2005/06/an_integration_.html


I did not read this one until now. I just finished it. I am now convinced, more than ever, that this model is so complicated it will break down very quickly. The time that it will take an organization to properly enter and maintain the data in such a model will suck the energy and money out of that organization. Again, it's clearly mixing abstract and concrete objects together, which is an instant recipe for failure.

Quote:
I've been tracking your writings for some time and, based on what I have seen, I am unconvinced regarding your product direction. I am concerned that you are attempting far too monolithic a CMDB.


This is a very interesting statement. We usually get the same reaction from most people, until they see it. Then they understand the simplicity and the purity that allows it to have such a broad coverage with such a simple and, yet, extremely powerful interface. However, I don't want to waste time trying to describe our model, here. There are many ways design and implement a CMDB, my point is simply that the model you've presented is 1) Overly complicated, and 2) Highly limited in its representation. Both of these traits are what we see as the leading contributors to CMDB implementation failure. And, of course, the fact that you're implying "yet another system".

Quote:
I suspect you are not using the essential distinction I have proposed between enterprise and element configuration management, and will therefore be playing an endless game of platform coverage you can never win. See

erp4it.typepad.com/erp4it/2006/09/element_versus_.html


We actually do follow this paradigm of relationships "between" vs. relationships "within", and we understand the differences very clearly. However, your terminology "enterprise vs. element" seems to be fabricated to redefine what has already existed for many years in Object-Oriented Analysis and Design as "Uses" vs. "Contains".

Quote:
One of the most important things to realize in CMDB design is that it is part of a distributed architecture.


I don't see the point in this statement. "Everything" in your enterprise is part of your distributed architecture.

Quote:
Concerns like installation and rollback for example are the proper domain of platform-specific provisioning tools such as Opsware or mValent, which are *not* CMDBs. See

erp4it.typepad.com/erp4it/2006/04/here_is_a_simpl.html

which is only a very high level view; I have much more detail in the book.


Rules for things like build, deployment, installation, instantiation, rollback, etc. are configurable items. They have been configurable items in IT for decades. Tools, like the ones you've pointed out, solve for only a very small percentage of the problem domain. I certainly hope that you're not pitching that these tools will cover the basics for an enterprise, because it would be a highly incomplete picture.

Quote:
The inclusion of domains far from core IT data center concerns is also reason for skepticism. (Vehicles? Really now...)


To limit your CMDB strictly to core IT data center means you're not solving the CIO's problem. You're only solving "some" of the production operation's leaders' problems. IT is "much" bigger than a data center, Charlie. IT is huge. And, what's worse, IT is also supposed to be solving problems for the non-IT part of their enterprise. How do you propose that the non-IT staff manage their inventories and configurations?

It seems you don't understand what enterprises are asking for. You may want to spend some time talking to companies. We constantly have enterprises that want to maintain inventories, configurations, and relationships between, both, technical and non-technical entities. If you focus on nothing but infrastructure, you're doomed. You may want to re-evaluate your skepticism.

As ridiculous as it might sound to IT resources, we have enterprises that pay fortunes for things like furniture that they give to their executives so they actually want to maintain things like "chairs" in their inventories, who they're allocated to, details about the criticality of the people who get them, what offices the chairs are in, what facilities they're in, etc. There are also other organizations that wants to maintain their inventories of vehicles, what drivers they're allocated to, what facilities they are at, what organizations own them, etc. For you to say that they're wanting to do this raises skeptiscim in you tells me that you're not in touch with what enterprises are asking for. You may want to go out there and talk to high level leaders and not just technical managers, Charlie. "Configuration Management" is a generic concept, not strictly a technical one. This is one of the reasons we see so many CMDBs fail, because they're "so limited" in their scope, right from the outset. Breaks my heart to see enterprises go down that road, too.

Quote:
Rollback in terms of audit trails for specific CMDB data structures is a mundane implementation concern and while we had that in place for the integration CMDB, I chose not to include it in the conceptual model or writeup.


Nice way to opt out. I can tell you very simply that things like Rollback plans are critical to any enterprise that does Change Management, Release Management, BCP, and D&R. In enterprises that take these things seriously, their Rollback plans rely heavily on their CMDBs and, themselves, are critical CIs that need to be managed like all other CIs.

Quote:
I agree that vagueness is a problem in CMDB/CI definition. I have written about that problem extensively, and proposed my own data models (field tested) to address this, which include most of the elements you cite. See

erp4it.typepad.com/erp4it/2005/08/a_data_architec.html

(again, this free, public version is much less comprehensive than the book's treatment and has a couple of significant weaknesses I have since addressed.)

I don't agree that the list of CI types needs to be portrayed as overwhelmingly numerous; to me, that is a failure of abstraction and needless over-complication. Perhaps it suits your marketing purposes to frame things this way, but more is not always better in data architecture, as I'm sure your architects will agree.


If you say so. However, you may want to make some money off of a CMDB so that you can understand exactly what requirements come from those that actually purchase them. It's one thing to talk theory. It's quite another to live and die by that theory, daily. Build your model, and everything required to support it, and then get it out there making money. You won't need me to highlight your issues for you, then.

There is a lot to be said for listening your customers. But your point about "more is not always better" is well taken. I fully agree with it, which is why our own model is a small fraction of what you've proposed in the model you point us all to. While I admit that there are many ways to skin a cat, the model you point us to appears to err on the side of "more" not less.

Quote:
I also don't agree that the term "knowledge management" has any place in this conversation. Knowledge management is about unstructured data, primarily. CMDBs are highly structured.


That's too bad. A good CMDB is nothing more than a good KM system for IT. Not believing this is exactly where you start to limit what your CMDB can do and how it will be used. A CMDB is all about knowledge. If you don't believe me, simply ask yourself "why" you need a CMDB. Ask yourself "how" you intend to use it. You will find that its core purpose is to answer questions. If that's not the description of a KM solution, then nothing is.

And, your statement about KM being about unstructured data is inaccurate. Knowledge Management covers "all" data and information, both structured and unstructured. Pick up any KM book and you'll find this. As a matter of fact, a key challenge in KM is to find a way to take unstructured data and information and transform it to structured data and information, to make it more useful. A good CMDB is a living example of a way to help achieve this.

Quote:
I do agree that people need to purchase products and generally not attempt to build this kind of thing themselves. But to intelligently purchase a product, they should seek a conceptual understanding of the process, data, and systems architectures in play, which is the service I am attempting to provide. I have no software to sell.


This, I will say, I am in complete agreement with.

It's been a pleasure exchanging information with you.

My Best,

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


Joined: Mar 03, 2007
Posts: 33
Location: Minneapolis

PostPosted: Mon Mar 05, 2007 3:21 pm    Post subject: Re: I realize you have a product to sell... Reply with quote

Below...

Guerino1 wrote:
There are a lot of obvious issues with the model(s) you've pointed us at. For example, there is a mix of abstract and concrete objects, being modeled together (e.g. "system" is abstract and "Support Org" is concrete), which usually indicates weak modeling experience. I'm not implying that you created the model, as I don't know who did create it.


I did create it. And I will hold my modeling experience up to anyone's. It includes years of data and class modeling experience as well as hands-on OO software engineering writing production code for CMDBs and metadata repositories in Fortune 100 organizations.

What you and your architects seem to have missed, in your haste to critique, is that in that particular section, the intent was purely pedagogical - not implementation.

Guerino1 wrote:
All we can say, from experience, is that good data modelers understand not to mix abstract and concrete, as a best practice, and that having any concrete in your model will eventually not scale, as concrete objects will require a tremendous amount of support code to be written in the other architectural tiers of the design.


You're using the terms "abstract" and "concrete" in a peculiar way that leaves me unconvinced of your modeling competence. My use of the term is mainstream UML, which would say that only non-abstract classes can be instantiated... I'm quite familiar with the data modeling literature and best practices; have designed complex OLTP apps, multi-terabyte data warehouses, and OO-based metadata and CMDB tooling... I've been an invited presenter at DAMA/Wilshire for many years now...

Guerino1 wrote:
Recommending another tool is not something I stand by. Sorry.


Nor I. See

erp4it.typepad.com/erp4it/2003/12/a_story_from_a_.html

You're reacting far too strongly to a case study of a particular capability within my overall architecture in this organization. We had many other capabilities platformed on the same tool: application portfolio management, enterprise architecture, dependency management, and more.

Guerino1 wrote:
The meta model you pointed us to describes a tree structure, which is extremely weak for modeling relationships, as a a real system follows a graph based model, as do all entities in real life. Trees almost instantly break down.


Agree, I have seen this many times. Trees are typically only useful when you have organizational buy-in that things *must* be coerced into a rollup; e.g. a chart of accounts or an org structure. Again, that example in the first post was purely for illustrative purposes, and the real world implementation in Adaptive was always many to many (networks).

See

erp4it.typepad.com/erp4it/2004/03/erp_for_it_repo.html
erp4it.typepad.com/erp4it/2004/02/fundamentals_of.html

both of which discuss issues of trees and networks in IT metadata.

Quote:
By the way - I am wondering if you only read the first post. That was just laying the groundwork. The interesting metamodel is in post #4:

erp4it.typepad.com/erp4it/2005/06/an_integration_.html


Guerino1 wrote:
I did not read this one until now. I just finished it.


Which now I think invalidates most of what you said before, because you are now going from saying my model is too simplistic, to saying it is too complex.

Guerino1 wrote:
I am now convinced, more than ever, that this model is so complicated it will break down very quickly. The time that it will take an organization to properly enter and maintain the data in such a model will suck the energy and money out of that organization. Again, it's clearly mixing abstract and concrete objects together, which is an instant recipe for failure.


That's interesting, because the model has been in production for 3 years at a Fortune 100 retailer. So much for your "instant" failure. What you're not seeing is our process approach, which was thoroughly baked into the SDLC for the integration competency center.

You seem to think I am making this stuff up out of thin air... I do think that I am entitled to a bit more respect for a sound, real-world case study.

Guerino1 wrote:
However, I don't want to waste time trying to describe our model, here.


Nice way to opt out.

Guerino1 wrote:
There are many ways design and implement a CMDB, my point is simply that the model you've presented is 1) Overly complicated, and 2) Highly limited in its representation.


Actually, I'm going to agree with you on these points. It was excruciatingly complicated. But I am a firm believer in Einstein's maxim that a theory should be simple enough to describe reality, but no simpler. I was dealing with describing parameter-driven message queuing architectures with dynamic binding to heterogeneous data stores. If you can show me a simpler data architecture that meets these requirements, then I will publicly acknowledge this on my blog. That's a promise.

If you can't show me this, then I say here that you are blowing smoke.

I also agree that the focus of that metamodel was highly limited. The purpose of that writeup was to describe configuration management for an integration competency center. Period. Nothing else. Is there more to IT? I think I have demonstrated amply elsewhere that I am more than familiar with the breadth we face.

Quote:
I suspect you are not using the essential distinction I have proposed between enterprise and element configuration management, and will therefore be playing an endless game of platform coverage you can never win. See

erp4it.typepad.com/erp4it/2006/09/element_versus_.html


Guerino1 wrote:
We actually do follow this paradigm of relationships "between" vs. relationships "within", and we understand the differences very clearly. However, your terminology "enterprise vs. element" seems to be fabricated to redefine what has already existed for many years in Object-Oriented Analysis and Design as "Uses" vs. "Contains".


Hmm, no I don't think you're really getting it. "Uses" versus "Contains" of course is the network versus the tree we were discussing above. It's precise and can be expressed in graph theoretic math. Enterprise versus element configuration management is a system taxonomy, with gray areas. It's asking the question, is this system's problem domain inherently one of engineering? (element management) or one of IT process management? (enterprise config). That you'd try to apply a class modeling paradigm to attempt to understand a distributed system scoping issue is indicative...

Quote:
One of the most important things to realize in CMDB design is that it is part of a distributed architecture.


Guerino1 wrote:
I don't see the point in this statement. "Everything" in your enterprise is part of your distributed architecture.


There is a distributed architecture for the IT value chain itself, that can usefully be considered as a cohesive set of systems supporting a major enterprise functional capability.

Quote:
Concerns like installation and rollback for example are the proper domain of platform-specific provisioning tools such as Opsware or mValent, which are *not* CMDBs. See

erp4it.typepad.com/erp4it/2006/04/here_is_a_simpl.html

which is only a very high level view; I have much more detail in the book.


Guerino1 wrote:
Rules for things like build, deployment, installation, instantiation, rollback, etc. are configurable items. They have been configurable items in IT for decades. Tools, like the ones you've pointed out, solve for only a very small percentage of the problem domain. I certainly hope that you're not pitching that these tools will cover the basics for an enterprise, because it would be a highly incomplete picture..


Don't know what you mean by "these tools." I *do* assert that the tools listed here:

erp4it.typepad.com/erp4it/2006/04/here_is_a_simpl.html

are the essential nucleus of tooling needed by the large scale IT organization. There are subtypes and some other nice to haves, but really that picture lays out the major 80% (or the 20% that do 80% of the work, if you will). What am I missing? Substance, if you have it...

Quote:
The inclusion of domains far from core IT data center concerns is also reason for skepticism. (Vehicles? Really now...)


Guerino1 wrote:
To limit your CMDB strictly to core IT data center means you're not solving the CIO's problem. ... IT is "much" bigger than a data center, Charlie. IT is huge. And, what's worse, IT is also supposed to be solving problems for the non-IT part of their enterprise. How do you propose that the non-IT staff manage their inventories and configurations?


I'm quite aware that IT is huge. I am chief Enterprise Architect for ITSM for a Fortune 50 organization with an annual $1.3 billion (with a B) IT budget. But there's this thing called scope creep. When I worked in retail, the "non-IT" inventories were managed by our supply chain software. Wasn't much call for mixing that up with internal IT operations. It all depends on what those inventories are and where they fit in the enterprise value chain. In a manufacturing organization, the ERP system is going to have extensive Bill of Materials capabilities that probably would put many CMDBs to shame. But again, we wouldn't mix those things up.

Guerino1 wrote:
It seems you don't understand what enterprises are asking for. You may want to spend some time talking to companies. We constantly have enterprises that want to maintain inventories, configurations, and relationships between, both, technical and non-technical entities. If you focus on nothing but infrastructure, you're doomed. You may want to re-evaluate your skepticism.


You're making unwarranted assumptions about my focus, position, and background. I'm responsible for my organization's IT value chain, from ideation through retirement, and including supporting processes such as architecture, compliance, and finance. I want tools that plug and play into a larger picture, and interoperate nicely on a best of breed basis, because that's where the industry is today. CMDBs are not ERP for IT solutions. They are an important precursor, but today the name of the game is integration.

Guerino1 wrote:
As ridiculous as it might sound to IT resources, we have enterprises that pay fortunes for things like furniture that they give to their executives so they actually want to maintain things like "chairs" in their inventories...There are also other organizations that wants to maintain their inventories of vehicles...For you to say that they're wanting to do this raises skeptiscim in you tells me that you're not in touch with what enterprises are asking for. You may want to go out there and talk to high level leaders and not just technical managers, Charlie. "Configuration Management" is a generic concept, not strictly a technical one. This is one of the reasons we see so many CMDBs fail, because they're "so limited" in their scope, right from the outset. Breaks my heart to see enterprises go down that road, too.


I have seen office furniture in CMDBs by virtue of integration with fixed asset systems. I don't think that is a bad thing. Fleet (vehicle) management in a CMDB I would consider professional malpractice. I have all the access to senior management I need, and then some. I also am very wary of the overly generic, totalizing concept foisted by starry-eyed vendors and consultants with pitchers of Kool-Aid. That way lies the numberless corpses of gargantuan, failed ERP implementations... the other side of the desire to reduce the number of tools... I want loosely coupled, highly cohesive, distributed systems. Perhaps your architects can educate you a bit on the fundamentals of cohesion and coupling.

Quote:
Rollback in terms of audit trails for specific CMDB data structures is a mundane implementation concern and while we had that in place for the integration CMDB, I chose not to include it in the conceptual model or writeup.


Guerino1 wrote:
Nice way to opt out. ...things like Rollback plans are critical to any enterprise that does Change Management, Release Management, BCP, and D&R. In enterprises that take these things seriously, their Rollback plans rely heavily on their CMDBs and, themselves, are critical CIs that need to be managed like all other CIs.


OK, you are talking about that kind of rollback. Being platform-specific, it belongs in the provisioning systems if at all possible. I agree that if you don't have active provisioning, the CMDB is the best place to hold that data. Wasn't a problem I set out to describe in that writeup.

Quote:
I agree that vagueness is a problem in CMDB/CI definition. I have written about that problem extensively, and proposed my own data models (field tested) to address this, which include most of the elements you cite. See

erp4it.typepad.com/erp4it/2005/08/a_data_architec.html

(again, this free, public version is much less comprehensive than the book's treatment and has a couple of significant weaknesses I have since addressed.)

I don't agree that the list of CI types needs to be portrayed as overwhelmingly numerous; to me, that is a failure of abstraction and needless over-complication. Perhaps it suits your marketing purposes to frame things this way, but more is not always better in data architecture, as I'm sure your architects will agree.


Guerino1 wrote:
If you say so. However, you may want to make some money off of a CMDB so that you can understand exactly what requirements come from those that actually purchase them. It's one thing to talk theory. It's quite another to live and die by that theory, daily. Build your model, and everything required to support it, and then get it out there making money. You won't need me to highlight your issues for you, then.


I made the decision a long time ago to not be an academic, nor am I a consultant. I am in the trenches, living and dying by my theories every day as well. So far, so good.

Guerino1 wrote:
There is a lot to be said for listening your customers. But your point about "more is not always better" is well taken. I fully agree with it, which is why our own model is a small fraction of what you've proposed in the model you point us all to. While I admit that there are many ways to skin a cat, the model you point us to appears to err on the side of "more" not less.


So again, I have gone from too simple to too complex. Can't seem to win here; it's obvious that you folks have the superior model (but can't be bothered to publish it...) The model I developed was built by taking ITIL, COBIT, CMM, and the IT portfolio management literature as statement of requirements, interpreted through the lens of an IT value chain process model. Complex is in the eye of the beholder; the model fits on one page, legibly. (Complex to me is a 3 x 5 foot model with 100 entities and 200 relationships, requiring a plotter to print out, but then perhaps I have different standards than you do. My approach and technique would be considered fairly mainstream in the data modeling community.)

Quote:
I also don't agree that the term "knowledge management" has any place in this conversation. Knowledge management is about unstructured data, primarily. CMDBs are highly structured.


Guerino1 wrote:
That's too bad. A good CMDB is nothing more than a good KM system for IT. Not believing this is exactly where you start to limit what your CMDB can do and how it will be used. A CMDB is all about knowledge. If you don't believe me, simply ask yourself "why" you need a CMDB. Ask yourself "how" you intend to use it. You will find that its core purpose is to answer questions. If that's not the description of a KM solution, then nothing is.


And how then is a KM system, by your definition, different from any general BI system?

Guerino1 wrote:
And, your statement about KM being about unstructured data is inaccurate. Knowledge Management covers "all" data and information, both structured and unstructured. Pick up any KM book and you'll find this.


What I pick up is the failure of the KM community to have much of any relevance to the data management or ITSM communities. It's a moribund almost-discipline, with a notorious track record of failure, that won't quite die.

Yours,

Charlie

[Edited: Again, no links in the forum please]
_________________
Charles T. Betz


Last edited by alphasong on Tue Mar 06, 2007 9:30 am; edited 2 times in total
Back to top
View user's profile Send e-mail
Cekir
Itiler


Joined: Jan 12, 2007
Posts: 48
Location: Warsaw, Poland

PostPosted: Tue Mar 06, 2007 12:52 am    Post subject: Reply with quote

Frank,
Could you please say what average/maximum size of IT environments are managed with use of your full tools suite?
Somehow I can't imagine single, monolithic tool covering all (most) ITSM aspects working efficiently in the environment of more then 100 000 machines. Maybe you have seen it working?
_________________
Krzysztof (Chris) Baczkiewicz
IT Standards Support
Eracent
Back to top
View user's profile Send e-mail Visit poster's website
Guerino1
Senior Itiler


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

PostPosted: Thu Mar 08, 2007 10:28 pm    Post subject: Reply with quote

Hello Cekir,

It runs in small, medium, and large enterprises, where some of the large are easily beyong 100K machines. Our system was actually designed for very high transaction and data volumes. So when you do something like pull up hundreds of thousands of records, it will do it in a split second (sometimes a couple of seconds if calculations need to be performed.

Don't consider it a "monolithic" tool, as it's not... Far from it, actually. It's web-based, very light weight, uses a lot of modern AJAX based features, implements "all" Web 2.0 traits, leverages the most advanced synthesis concepts (code gen. and behavioral), etc. so that it takes advantage of the most modern concepts to allow any and all stakeholders to address their needs. To me, "monolithic" implies slow, clunky, big, old, etc. Our platform is none of those.

Think of it like this... Yahoo is a fully hosted portal that comes pre-populated with many tools and technologies that are geared toward the individual consumer, such as shopping, movies, horiscopes, etc. These tools are not viable for running an enterprise. So, if you were to integrate everything in your enterprise, you would want it to be somewhat like Yahoo, where you have access to everything you need and can share data across each of your operational areas. What we offer is a fully hosted web portal (very much like Yahoo) that comes pre-populated with the types of tools and technologies that an enterprise needs to run itself. We cater to C-Level Business Leaders and IT Leaders who understand the bigger picture of IT (what it should look like "after" you're done rolling out and integrating all your tools) and offer them a new business paradigm, which is "simply connect and run... for a fraction of the cost... in a fraction of the time & energy... for a fraction of the headaches... and get far more from it."

Remember, it's usually the lower level technologists that often get caught in the weeds of their immediate needs and can't see beyond a handful of tools and technologies that are needed only by them and their immediate customers. The higher level IT leaders have to worry about a much bigger picture that has many interacting parts, constantly moving data, many stakeholders to worry about, thousands of tools and technologies, global facilities to connect, endless data sources to centralize and standardize, etc. Our job is simply to make that easier by letting them connect to us for a good percentage of that.

When you say that you "can't imagine", keep in mind that a few years ago, most people couldn't imagine a CRM platform like Salesforce.com being fully hosted over the web, either. Wikis couldn't even be explained, and Blogs were nothing more than toys. Technologists' impressions were that you always had to buy, provision infrastructure for, hire dedicated headcount for, package, deploy, test, maintain, and upgrade all the software themselves. It took some time for the world to see different ways of getting far more CRM for far less money... for them to see that Wikis, Blogs, and Social Networking add value to the enterprise, etc.

BTW, let me clearly state that we're not the only ones doing this. There is another company out there doing this, too. And, there will be more in the next few years. The world gets the need to keep moving forward.

The old age of ITIL/ITSM was individual tools that you had to host your self, provision for yourself, integrate yourself, etc. The new age of ITIL/ITSM is going to be "simply connect and run to a pre-constructred and fully integrated suite of business operations tools". Put yourself in a leader's chair and simply ask yourself... "Do I want to do it all, myself? Pay for it all, myself? Take years to roll it all out, myself? Get very little for my efforts? OR... Do I simply leverage what experts have done better than me for a fraction of the cost, time, and effort?" I think if you were running your own company, where you were ultimately accountable for every dollar spent, the answer would be very obvious to you.

I recommend that you don't be like the masses/majority and get caught up in being at the lagging end of the curve. It will cost you and your enterprise a fortune and waste years of implementation time, only to give you little in return. Think of it this way... you have the opportunity to leapfrog the masses if you think properly. Then again, you might simply be comfortable hiding in them. It's a matter of choice, I guess.

Anyhow, I hope this helps.

My Best,

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


Joined: Jan 12, 2007
Posts: 48
Location: Warsaw, Poland

PostPosted: Thu Mar 08, 2007 11:26 pm    Post subject: Reply with quote

Guerino1 wrote:
To me, "monolithic" implies slow, clunky, big, old, etc.


That was my point Smile
I am glad we agree.

So, if I understand you properly, you provide a simple interface for many different types of information received form different sources. Then you use the model of unified data types/terms to do this, which (the model) you don't want to present here.

Is that what you meant, or have I misunderstood you?
_________________
Krzysztof (Chris) Baczkiewicz
IT Standards Support
Eracent
Back to top
View user's profile Send e-mail Visit poster's website
Guerino1
Senior Itiler


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

PostPosted: Thu Mar 08, 2007 11:53 pm    Post subject: Re: I realize you have a product to sell... Reply with quote

Charlie,

My intent is not to argue with you or make you feel like I'm attacking you. My intent is to highlight for the readers that what you're presenting (strictly in your model) seems to have very limited, if any, hardcore testing in the real world. While you've implemented it in one enterprise, it doesn't appear that you've hardened it by rolling it out and testing it in many enterprises. You only presented a data model, which is a small fraction of a CMDB. It appears that you haven't actually experienced the realities associated with the huge time, money, and energy to build the millions of lines of code that represent the layers of application engine, presentation, and UI code over it your model or to package all of it in such a way as to test its viability by getting many people to buy it (concensus of the masses). An indication of a good idea is when you can package and repeatably sell that idea, "over and over again", to many buyers, by making it a commodity that helps the masses. Try to package your model with all the supporting code to make it a viable commercial application and you'll see some very different things. I promise.

Also, please understand that I didn't say I was right or wrong. I just said that based on our experience, this is what we see.

I do understand your pedagogical intent. It is also my intent, which is why I get involved in these things. The difference between you and I is that we (my firm) sell and compete with real CMDBs all day long, every day, for a living. So, what we bring to this discussion, we bring from real commercial design, implementation, and support experience. We can share with you, from our own experiences, what things do or don't work and why. We can also share with you what things people do or don't tend to like and why. We can give you real indications of what will or won't be expensive.

What I don't want you to think is that I disagree with your philosophies. I happen to agree with many of them and think that there is a great deal of very useful information on your site. Some of it, quite visionary. So, for example, your view of a graph based model (like the toy Skwish) is something we've already achieved that many vendors in the world haven't even come close to, yet. It is because we've achieved such visual modeling and correlation that we can share with you many of the realities that are required to get there. Remember Charlie, if you truly want that graph, you have to think very differently. Getting the "model" right is the key to doing so and, in all honesty, we don't see the model you've presented as properly allowing to get there. You said you based it on the Adaptive Repository. Based on our knowledge, that repository can't get you to that graph based representation, which seems to be a pretty obvious limitation.

I love your idea of ERP for IT (denoted in the link: erp4it.typepad.com/erp4it/2006/04/here_is_a_simpl.html) because it's exactly what we sell. I can tell you from experience what it means, what parts of your model will or won't work, the many pieces that are missing from your model. We are a living and breathing implementation of your attempt at ERP for IT (not to say that we've implemented every piece of your ERP model but, then again, we have implemented far more than is in your model, too). So, please understand that I do back you on most of what you're presenting, just not the data model, itself.

Quote:
Guerino1 wrote:
There are many ways design and implement a CMDB, my point is simply that the model you've presented is 1) Overly complicated, and 2) Highly limited in its representation.


Actually, I'm going to agree with you on these points. It was excruciatingly complicated. But I am a firm believer in Einstein's maxim that a theory should be simple enough to describe reality, but no simpler.


I agree with your statement that "a theory should be simple enough to describe reality." Graphs are simple Charlie, not as complicated as the model you've presented.

Quote:
I was dealing with describing parameter-driven message queuing architectures with dynamic binding to heterogeneous data stores. If you can show me a simpler data architecture that meets these requirements, then I will publicly acknowledge this on my blog. That's a promise.

If you can't show me this, then I say here that you are blowing smoke.


May I ask what any of this has to do with a CMDB? Dynamic binding is an implementation strategy for communications/integration and has nothing to do with Configuration Management. Dynamic binding to heterogeneous data sources is an ETL issue. Buy ETL tools like Informatica Powercenter for that. Configuration Management and a CMDB is about capturing, managing, storing, rendering, and understanding relationships, history, context, etc., not about dynamic binding to heterogeneous or even homogeneous data sources. Binding is about how you get the data in or out.

Quote:
Guerino1 wrote:
Rules for things like build, deployment, installation, instantiation, rollback, etc. are configurable items. They have been configurable items in IT for decades. Tools, like the ones you've pointed out, solve for only a very small percentage of the problem domain. I certainly hope that you're not pitching that these tools will cover the basics for an enterprise, because it would be a highly incomplete picture..


Don't know what you mean by "these tools." I *do* assert that the tools listed here:

erp4it.typepad.com/erp4it/2006/04/here_is_a_simpl.html

are the essential nucleus of tooling needed by the large scale IT organization. There are subtypes and some other nice to haves, but really that picture lays out the major 80% (or the 20% that do 80% of the work, if you will). What am I missing? Substance, if you have it...


Like you, I have managed IT in some very large and prominent enterprises, including some of the larger financial institutions in the world (Yes, I've dealt with and continue to deal in the "Bs", too). We now sell commercially. I don't see your assessment of these tools to be accurate. It doesn't mean that such tools aren't needed or don't add value but to say that they are "the essential nucleus" is not something that most CIOs/CTOs, and Enterprise Architects I know would agree with, and I know and deal with some pretty prominant ones.

Quote:
Perhaps your architects can educate you a bit on the fundamentals of cohesion and coupling.


I love this statement! Made me laugh out loud! God bless you for assuming that I don't have as much or possibly even more architectural experience than you.

Quote:
Quote:
I also don't agree that the term "knowledge management" has any place in this conversation. Knowledge management is about unstructured data, primarily. CMDBs are highly structured.


Guerino1 wrote:
That's too bad. A good CMDB is nothing more than a good KM system for IT. Not believing this is exactly where you start to limit what your CMDB can do and how it will be used. A CMDB is all about knowledge. If you don't believe me, simply ask yourself "why" you need a CMDB. Ask yourself "how" you intend to use it. You will find that its core purpose is to answer questions. If that's not the description of a KM solution, then nothing is.


And how then is a KM system, by your definition, different from any general BI system?


It's not. BI/KM/CMDB/Informatics/Geographic IS/etc. are all about seeing and understanding your enterprise. They're intent, in some way, shape, or form, is to mimic the brain. They've all just grown up through different areas of the enterprise. What many people don't see, yet, is that they're all converging organically (without explicit intent). The reason for this is very simple. They're all the same thing. As the technologies evolve to let people build them more effectively, you'll find that they fundamentally all do the same things. Analyze those systems and you'll see that the core requirements and features of each are fundamentally the same.

Quote:
Guerino1 wrote:
And, your statement about KM being about unstructured data is inaccurate. Knowledge Management covers "all" data and information, both structured and unstructured. Pick up any KM book and you'll find this.


What I pick up is the failure of the KM community to have much of any relevance to the data management or ITSM communities. It's a moribund almost-discipline, with a notorious track record of failure, that won't quite die.


I cannot agree with you more on this. One of the big drivers for KM failure has been lack of tangibility, when compared to other operational processes, such as Project Management, Change Management, etc. However, things like enterprise intergration, enterprise architectures, enterprise search, etc. are all starting to allow real KM to show itself in the enterprise. Simply think of the ERP for IT concept. If done correctly, it becomes the foundation for KM and finding, seeing, and understanding things across all operational domains becomes much easier. Correct? This is why we can do things like run a search and get categorized results back from all operational domains, with context, that allow you to drill, render, format, etc. to your heart's content.

Charlie, I am 100% on board with your ERP for IT philosophy and understand it to be truly visionary (I have to say that because I pitch ERP for IT every day!). I'm just not on board with your data model to get there. Please don't take it personally.

Also, if I don't address every line item in your responses, please understand that while I personally love these discussions and want to go on forever, I have my day job that calls me (unfortunately, even into the night!).

I certainly hope to have many more of these discussions with you.

My Best,

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


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

PostPosted: Fri Mar 09, 2007 12:15 am    Post subject: Reply with quote

Hello Christopher,

Quote:
So, if I understand you properly, you provide a simple interface for many different types of information received form different sources. Then you use the model of unified data types/terms to do this, which (the model) you don't want to present here.

Is that what you meant, or have I misunderstood you?


It's much more than a simple interface. We actually become a replacement strategy. We have many embedded tools and technologies that are pre-constructed, are ready to use, and already fully integrated to each other in the platform. So, when you turn it on, everything is ready to go... Project Management, Change Management, Incident Management, Document Management, etc., etc., etc.

It's a paradigm called "Software-as-a-Service" or "SaaS". Like Salesforce.com... Like CollabNet... Like Business Engine Networks BEN)... You just go to a URL in your browser and everything is there. No infrastructure for you to buy. No dedicated experts for you to hire. No excessively large IT footprints for you to deal with. No multi-year rollouts. Etc. Just subscribe to a browser connection and run.

I have to say that it is all very cool when you really look at it. Sometimes it blows my mind to see what we've achieved. But, in all fairness, others are achieving things like this, too. We're just fortunate because there is just so very little competition in our competitive space, while there is so much room for improvement.

I hope this answers your question.

My Best,

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


Joined: Mar 03, 2007
Posts: 33
Location: Minneapolis

PostPosted: Fri Mar 09, 2007 1:35 am    Post subject: Re: I realize you have a product to sell... Reply with quote

Initial reponse deleted... This is simply not constructive any more. I can address all of the above points in detail but there is no ROI in doing so.

Ending the thread is not acqueiscence.

-ctb
_________________
Charles T. Betz
Back to top
View user's profile Send e-mail
dpagucci
Newbie
Newbie


Joined: Mar 23, 2007
Posts: 8

PostPosted: Tue Apr 03, 2007 5:13 am    Post subject: Great discussion but did the original question get answered? Reply with quote

Wow. Your guys discussion was so far over my head that I think I was lost in the second paragraph of the first reply. I am not sure though that the original question was answered because of all the male Testosterone (or whatever the equivalent is for who knows more) being thrown around. I work for a somewhat large automotive manufacturer, in fact one of the largest in the industry. We have a 10,000 user network across the US, over 120 business applications (developed in house), VPN circuits to 1200 or so dealers and many Web portals and sites. All of the configuration data for all of these items is contained in an in-house developed CMDB. Our CMDB has an SQL backend with an MS Access front-end and it does all that we need for the present time. The CMDB has been interfaced with SMS and ManageNet for verification of certain CI's. I realize that this is not going to impress many and probably give you a few laughs because it really does use MS Access, but it does work effectively. My point is that a CMDB does not have to be so complex in design and have so many whistles and bells to be functional, not to mention it does not have to require a huge amount of money to purchase and then a team of specialists to maintain it as do many of the products on the market today. Management has concerns over the continued supportability of our CMDB and rightly so. We are currently in the process of evaluating a new tool to migrate into. What I am finding out that the solutions available today all require a huge amount of customization and the hiring of a support team to perform the customization and on-going maintenance. Is this really the case? I am planning on visting the web site mentioned in the previous posts however because it does appear to offer a viable solution for our requirements. I would like to say thank you for the information to the both of the previous posters.

Don Very Happy
Back to top
View user's profile
Display posts from previous:   
Post new topic   Reply to topic    ITIL Forum Index -> Configuration Management All times are GMT + 10 Hours
Goto page 1, 2  Next
Page 1 of 2

 
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.