wearnest@teleflora.com - 31 October 2008 04:26 PM

Logically a website is a child of a webserver application. Regardless of whether I choose to implement the website CI as an SI or BAI, the parent/child relationships should be configurable, hence the possibility of either of the two lines below:

model.addContainment(si_new, si);
model.addContainment(si, si_new); 

Which again begs the question, is there a way to explicitly assign a host to an SI?

Apologies, an edit went missing on my post that should have answered that question.

I’m afraid that that isn’t the way the Foundation Model and the TPL code that assists in making the maintenance of it simple works. That model expects you to build SoftwareInstances to represent the fundamental functional blocks of software that supports your business services. It then expects you to aggregate the components of the service upwards into second order SIs and BAIs. Essentially it models business service hierarchy rather than internal software structure. I’ve attached a slide from one of my presentations that shows this, though it is a simplified case.

In the evolution of the core model in the 7.1.x product you are using website and other application substructure is not ignored. It is regarded as interesting properties of those services so that you can model further services based on the evidence that that particular IIS server is running the website that supports it.

In the forthcoming 7.2.x series of releases we have added a nodekind to the core model explicitly for flexible modelling of the substructure of application servers to support exactly the uses you are considering where we need to delve deeper into application servers, database, webservers etc, but sadly that is not yet ready.

These issues do not arise if you add additional nodekinds to the taxonomy, it only arises as the SoftwareInstance nodekind has a specific expected structure which a large number of helper functions construct and expect. This was a pragmatic decision as it is the major way people extend our model to capture their bespoke software and business services and we did not want them to have to learn the intricacies of our technology in order to achieve this.

I cannot recommend you a way of forcing a relationship to be built to the Host other than using addContainment. The removal rules and other maintenance functions in the system expect the model to be built in this hierarchical fashion and disrupting this would cause side effects.

It is certainly possible to achieve what you want but it will take more advanced customisation to add dedicated entities to the taxonomy and extend the reporting and visualisations in the product. As Paul said over on the custom attributes thread we are not a general purpose CMDB although in the absence of one the technology is certainly flexible enough to be extended to cope. This is a more advanced customisation and would be better carried out, at least initially, with the assistance of our services organisation or one of our partners.

If you want to use the core model out of the box then we need to find a way to express the structure you need to support your problem in a way that works with the expectations of that model. Almost always if you approach the problem from the view of the service the servers are providing that tends to be the solution.

I cannot recommend you a way of forcing a relationship to be built to the Host other than using addContainment. The removal rules and other maintenance functions in the system expect the model to be built in this hierarchical fashion and disrupting this would cause side effects.

I’ve been combing through the TPL documentation trying to learn as much as I can about writing patterns and I ran across something interesting.

Where additional relationships are required, they can be created explicitly. For each relationship defined in the taxonomy, a corresponding function is also defined in the model.rel scope.

So after looking through the Taxonomy I figured out that this little be of code does exactly what I’m looking for and allows me to keep the logical hierarchy that a website exists within a webserver.

Any particular reason for not recommending this approach?

I’m starting to work on extending the taxonomy and this discussion has been enormously helpful in understanding the way to define the relationships. As you mentioned, perhaps the out of the box model isn’t the best solution for our environment and the extensibility of the Tideway application will give me a lot of room to expand.

wearnest@teleflora.com - 03 November 2008 11:43 PM

I cannot recommend you a way of forcing a relationship to be built to the Host other than using addContainment. The removal rules and other maintenance functions in the system expect the model to be built in this hierarchical fashion and disrupting this would cause side effects.

So after looking through the Taxonomy I figured out that this little be of code does exactly what I’m looking for and allows me to keep the logical hierarchy that a website exists within a webserver.

model.rel.HostedSoftware(Host := si_host, RunningSoftware := si_new); 

Any particular reason for not recommending this approach?

The reason I can’t recommend that approach is the removal rules and other maintenance functions in the system (not to mention the visualisation tools) expect this relationship to be in a hierarchy.

From our point of view of building a map of applications and services this makes sense as logically the service being provided has a website as it’s component parts and that website is served by a farm of webservers.

However the issue of this built in behaviour goes away if you use taxonomy customizations because it is only around the specific Host:Host:HostedSoftware:RunningSoftware:SoftwareInstance relationship.

I’m glad it’s starting to make sense to you and you’ve manage to gain something from my rather epic posts, thanks for sticking with it.

What I’d suggest is that we look to modelling a website as a Detail node, which is coming up in the next release. I’m happy to provide some taxonomy fragments for this and to help you through this initial extension if it helps you assess our technology. Would you be able to fire up Visio/PowerPoint (or some other diagramming tool) to send me an image of the model you are trying to build?

As an example I’ve attached a quick simplistic sketch of the model I’d build that would work within our overall model. You can see how the FOO website service contains the IIS servers 1 and 2 and because of this is related to Hosts A and B automatically, whereas the BAR website service contains the IIS servers 2 and 3 and therefore automatically linked to Hosts B and C. You’ll notice that IIS server 2 and Host B are “shared” by the model of the FOO and BAR website services; this type of sharing is fine in the node:relationship:node model, in fact it’s one of the reasons we use it.

So I can easily traverse down from the “Teleflora Website” SI to all the Host nodes supporting it or the IIS servers supporting it. From an IIS server I can traverse up to see which services I may impact if I change the config of that server.

I’ve gone for broke and done a second sketch where I assume you might want to group a number of website services together as part of some business process. It’s a naive example but I’ve grouped them together in a “Webpresence” BAI for the EMEA region. You can see how the BAI contains the webserver services and automatically links to the Host nodes.

Now I can traverse down from the Webpresence BAI or up allowing me to quickly build reports and understand impacts of actual change or potential change.

Charles, that is a pretty close example to what I had sketched out (see attachment). I think the main differences that we are looking at are those between the deployment model of “what components are installed where”, and the logical model of “what components make up this process”. To me, the relationships in the deploymet model are like having a big bucket of components that may or may not even talk to each other. In the logical model, I see the relationships being more transaction based, showing how to get from one component to the next. These are two very different modelling approaches for the same information. IMO, the true value of a CMDB is being able to overlay both of these models for impact analysis, risk assessment, capcity planning, etc. I really don’t expect the visualizations to be 100% hierachical.

While Tideway Foundation claims to not be a full scale CMDB, it has been a struggle for me to understand Tideway’s approach, because some of the out of the box relationships are deployment based (DDD) and some are very logical model based (but I think I’m making progress).

I’d be interested to see what the Detail node would allow. I’ve also been considering creating a generic CI that would be somewhat of a placeholder for details related to Host and SI nodes, such as file shares instances, local administrator instances, etc. These definately do not fit within the Host or SI node type, but could easily be considered their own CI and more than just an attribute of their related Host or SI.