Skip navigation

Loose Coupling

11 posts

I'm sure Microsoft had good reasons for doing this, but from my perspective the default settings for tabbed browsing in Internet Explorer 7 are simply ridiculous.  So ridiculous I had to blog about it.


So if you're like me you're too busy to go figure out why the IE Tabbed Browsing feature doesn't seem to work right.  With "Tabbed Browsing" you expect to see tabs instead of new windows, right?  That's not the default.  More ridiculous - if you launch a browser URL from another application, it WILL appear in a tab inside an already-open browser window.  So you end up with all these unrelated pages in one window, and all the related pages are scattered around different windows.  AAAGGGHH.  I lived with this for quite a while before somebody mentioned that I can control this behavior with settings.


Internet Explorer 7 CAN and SHOULD work better for things like BMC Remedy applications (and probably most others as well).


First there's settings for Tabs on the Tools-->Internet Options General sheet:  Click that:



If you click the Settings button under Tabs, you will see the settings (which were set this way by default, and will return to this by clicking the handy "Restore defaults" button):



Is that standard IE or some weird IT profile unique to BMC?  I'm sure somebody would love to explain why these are the defaults, but I like to have links launched in another tab so everything I click through stays in the same window.  And I like to have unrelated things that I launch from email, Windows Explorer, etc. launched in a new window so I can see the title on the Windows task bar.  So here are the settings that work best for me, particularly when using BMC Remedy ITSM:



There are many things that baffle me here, like if IE knows enough to "decide how pop-ups should open" why doesn't it do that by default?  Or always open links in a new tab like Firefox.  If I let IE decide, it opens links in a new tab like I would expect.  Maybe I'm just tired and confused.  There are frequently asked questions like mine here:


Anyway I hope that helps if you happen to come across this and didn't realize you were living with weird behavior.  I mean the way Internet Explorer behaves!!

Van Wiles

Fixing it the Right Way

Posted by Van Wiles Jul 18, 2009

I have a couple of anecdotes to share and then I'll get to my point about software, particularly related to BMC Service Level Management.


In practically any "problem scenario" there is usually a "right way to fix it" and many other ways to fix it that are faster, cheaper, and "less than ideal".  Finding the "right way" may take time to understand the problem.  I'm sure you have experienced this if you have ever dealt with a car mechanic.


I once tried to explain to a colleage in another software organization that "slowness" can be a good thing in software development.  I think he raised his eyebrow and changed the subject.


I think the worst line of code I ever saw was an "if" statement in a C program (in a software product that is now thankfully dead) that spanned 10 lines and included multiple levels of nesting and Boolean conditions.  It took me about a day to understand that program before I decided to re-write the whole thing because the structure of the resulting code had become so convoluted.  This didn't happen the first day the code was written - it was the result of years of software maintenance and shortcuts or "low-risk" choices that left the code in that state.  Nobody wants to re-write production code because of the time and risk involved.


I think the point is that every development task involves choices that may have long-term consequences.  Bad choices can  leave you wrestling with alligators.  As my parents used to say, "haste makes waste".  Especially true in software maintenance.


Now for a more concrete case.  I was working on SLM 7.5 a few days ago for a software training session, and noticed that my SLM Trends dashboard displayed duplicate entries for certain Agreements.  These agreements were related to multiple contracts.  Instead of getting one line for each Agreement/Contract, I got two.


I tracked this down to a form that indeed showed four entries, two for each Agreement/Contract.  There should have been only two.  My first instinct was to delete the two entries that appeared to be in error.  But I didn't understand why these entries appeared in the first place so I spent a couple of extra hours researching.


It turns out that this form was a join form, in which the join criterion used a non-unique qualifier to find related entries.  So each of the two Association entries was related to the same two Compliance entries, resulting in what appeared to be four entries.  The "right fix" was actually to change the join criteria to use a unique qualifier. Voila - now there's one line per Agreement/Contract!


So I learned a lot of cool stuff about SQL joins and Remedy join forms.  But this also reminded me that finding the right fix is worth the wait.  If I had deleted those two entries in the join form I probably would have created multiple other data problems that would surface later and be very difficult to understand or fix.  (I'll probably post something about this in the SLM forum, but suffice to say there is a defect filed for this).

-by Van Wiles, Technical Marketing


Here are some reasons why a federation of MDRs implementing the CMDBf specification still needs a “Single Source of Truth” and how to implement it…


For many years, BMC has been promoting a federated CMDB approach that features a centralized repository of configuration information, providing federated access to extended information from management data repositories (MDRs).  I would like to refer to this centralized repository as a “configuration directory” since this more clearly identifies its purpose.


Standards are emerging that enable multiple MDRs to form a CMS (Configuration Management System, a collection of MDRs with discovery, data management and human interfaces).  I have worked on one such effort, the CMDB Federation specification that is now being finalized by the CMDBf workgroup in the DMTF.


The question must be asked – is a configuration directory still necessary once these standards have reached viability?  There are some very good arguments to be made for NOT maintaining a centralized repository such as a recent blog by Glenn O’Donnell (, but I have some practical concerns with a purely federated approach.  There are also good reasons to consider certain MDRs as “master” for the classes of information they provide, so I think Glenn makes some very good points that are consistent with our approach.


I believe that for the foreseeable future, a CMS still requires a configuration directory for a few important reasons.




Even though MDRs may maintain more accurate, complete, and up-to-date information about certain configuration items, the information about relationships to other configuration items may not be available in the same MDR.  Maintaining these relationships across MDRs without a configuration directory will present problems for scalability and data integrity.  Every relationship must have two endpoints, and the identity of these endpoints must be persistent and unique.  This CAN be accomplished without a configuration directory, but is logistically difficult to maintain potentially many cross-repository references.


Normalization and Reconciliation


Multiple MDRs may have information about the same class of configuration items.  Normalization and reconciliation of this information requires careful planning and in some cases, human intervention.  Perhaps this process can be embedded into rules to enable normalization and reconciliation on-the-fly, but this makes many risky assumptions about accuracy and scalability that are un-proven in a large scale implementation.


Registration and Query


Without a configuration directory, configuration information must be gathered in real time by either a sequence of queries to each MDR, or by querying a federating MDR that delegates the query and aggregates the result.  In practical terms, any large implementation would probably cache the results of these queries and attempt to minimize large cross-repository queries.  Thus, whether the synchronization of information from multiple repositories is maintained by a caching mechanism or by registration and periodic synchronization, the end result is effectively the same.  This is one reason why the CMDB Federation specification defines a Registration service – not to register MDRs (which would more likely be done in a web service registry), but to register the persistent identity of “items” that form the core configuration directory.


Authorization and Change Management


Probably the most important reason to maintain a configuration directory is to provide a consistent and reliable source of information for the change and release management processes.  While discovery of the actual configuration items may provide the most accurate and up-to-date information, that does not mean that it represents the authorized configuration.  There may be an error in the configuration that is revealed by discovery.  Without a configuration directory, each MDR would be responsible to maintain the authorized configuration, and provide consistent ways to detect and report differences between the authorized and actual configuration records.




To summarize, the use of federated MDRs to report detailed, up-to-date information about configuration items and associated records is a key feature of a Configuration Management System.  The ability to access and exploit this information will be enhanced by the CMDB Federation standard, and hopefully by some standardization of data model mappings in the future.  But the practical implementation of a CMS still requires a federating CMDB that provides persistency, rationalization, and uniform authorized access to a Single Source of Truth about the core configuration items.


It is still a recommended best-practice to minimize the scope and level of detail in the configuration directory to those items (and the properties of those items) that are required to support the configuration and change management processes of ITIL.  The CMDB Federation standard (when finalized) will support and enhance this approach.

The postings in this blog are my own and don't necessarily represent BMC's opinion or position.
-by Van Wiles, Technical Marketing


You may have thought I had something to say about the global economic malaise (which I do) but this is not the forum!  Of course I am talking about creating information systems that survive in the chaos we call IT.  Well, let's just say it's "managed chaos".


Why does IT tend toward chaos?  My personal opinion - because it can.  Software is a very volatile material, easily changed, difficult to understand and manage.  Sort of like trying to shovel fog out of the driveway.  In the midst of this fog we have boxes of steel and wires.  Lots of wires.


If you live in this fog, here are a few tips for dealing with it.


Identify constants

Probably the first thing to do when you can't see anything is to feel around in the dark for solid things that don't move.  Partly this is because they hurt when you run into them, partly because you can count on them being there next time.  In my hazy metaphor these are business services.  They still move, but not so fast that you can't find them the next time you walk in the fog.  You can build interfaces around these things that last longer that way.  The simpler the interface, the more durable it is.  So keep things simple.


Design for uncertainty

This is a hard thing to do, which will lead to my next tip.  Even though you may create very stable systems and well defined simple interfaces, others may not play by the same rules.  So your system should tolerate unexpected changes.  You may be talking to "Harry" one day and "Harriet" the next, but if you still speak the same language you can still communicate.  If not, try adding to your vocabulary.  I have seen a lot of cases where communications broke down because of very petty differences.  (I'm talking about integrated systems here.  Just because an interface is missing a parameter, or the format of one parameter changes, does that mean you should just throw an error and refuse to talk?  How about throwing a warning and trying to get along.)


Set a little aside for a foggy day

Tolerating change can be a bit more expensive than just creating monolithic hard-wired systems.  If you manage a project budget, I suggest you invest a little more in a service-oriented design because it will pay dividends in reduced cost of ownership.  Those dividends can be reinvested in the future, so instead of fixing yesterday's interoperability problems you are adapting to tomorrow's business requirements.  If I were developing software again, I would definitely think about spending an extra hour or two on interface design and error handling to save those all-night phone calls later.


Bee flexible

Bees can fly because parts of them are stable and other parts move so fast you can't see them.  The parts that need to move in an IT system are the business rules and processes.  So these should be adaptable to fit your business needs.  Some parts need to move very fast; others don't.  Things that are not designed to move when they need to move tend to break.  I once made a belt out of wood (and lots of hinges - a college exercise in creativity).  I once wrote code to simulate a bug because another system was expecting that bug and didn't work without it.  Browsers tolerate a lot of HTML errors.  It's better to adapt than to wait for everybody else to change.


Identify and manage changes

You don't have to work at the Service Desk for long before you recognize the value of Change Management.  Those constants you identified earlier better stay constant, or a lot of processes will break.  When those things move, everybody in the fog needs to know about it.  Lighthouses prevent shipwrecks.  Sonar prevents shipwrecks even bettter.  Configuration and Change Management can help you steer through the fog.

The postings in this blog are my own and don't necessarily represent BMC's opinion or position.
-by Van Wiles, Lead Integration Engineer

Continuing explanation (in the context of the CMDB Federation workgroup) of the use of records to model items of similar types.

Since I am clarifying some things today, first I should clarify what I can clarify about CMDBf workgroup activities at DMTF.


I can state my opinions about what is going on in the CMDBf workgroup, including giving some insight about what I am thinking in the meetings, but I cannot really say what the workgroup has decided or is considering. Therefore, please note that whatever I say about this workgroup is my personal opinion and is subject to change or different interpretation from other members of the workgroup.


OK, disclaimers aside - things have changed slightly since we started the CMDBf workgroup at DMTF (as you would expect unless we are just wasting our time!)


In a previous posting about modeling CIM_VirtualComputerSystem I indicated that the best way to expose a sub-classed model in CMDBf is to associate an item with records of each class in the inheritance hierarchy. This would still work (and may suit your purposes), but an MDR is also allowed to return an item with a record that has the properties of the requested recordType even though the recordType has a different name.


Ah - let me clarify with an example. Let's assume (contrary to my last post on this subject) that the MDR implementation model

CIM_VirtualComputerSystem as one big record with CIM_ComputerSystem and all other parent-class attributes. The CMDBf client issues a query for items with CIM_ComputerSystem records and certain propertyValue constraints. It is legitimate for the GraphQuery operation to return these items with:


  • One CIM_VirtualComputerSystem record (where the client must assume that the MDR considers CIM_VirtualComputerSystem to be a subclass of the requested CIM_ComputerSystem recordType).
  • One CIM_VirtualComputerSystem record and one CIM_ComputerSystem record (thus the client can tell explicitly that this item matches the requested recordType). For efficiency the Query service may choose to factor out the common properties from the CIM_VirtualComputerSystem records that are returned.


If I were implementing a CMDBf Query service I would choose the latter approach because the client will not need knowledge of the inheritance model to understand why the operation returned CIM_VirtualComputerSystem in response to its CIM_ComputerSystem query. There is also the possibility that this knowledge could be conveyed in the XML schema or other mechanism, but this places a pretty big burden on clients who don't understand my data model.

One more note on the subject of CIM_VirtualComputerSystem - its usage is apparently being deprecated by CIM (see in favor of simply using CIM_ComputerSystem with a CIM_HostedDependency relationship to another CIM_ComputerSystem. What? This is presumably because so many management systems have a hard time distinguishing between virtual and physical systems.


There's also an issue of how a Query service interprets a request if the MDR has something like BMC_ComputerSystem when the client asks for CIM_ComputerSystem. The GraphQuery operation may return these items with:


  • One CIM_ComputerSystem record (where the Query service maps its BMC data model to CIM), or
  • One CIM_ComputerSystem record and one BMC_ComputerSystem record, so the client gets both perspectives


Again I would choose the latter approach, but I can't really factor out any properties from BMC_ComputerSystem because BMC_ComputerSystem is not formally derived from CIM_ComputerSystem and does not have an identical set of properties. It's just another record which the client may choose to use or ignore. If the client just wants CIM_ComputerSystem records, it can use the contentSelector/selectedRecordType to screen out the BMC_ComputerSystem noise.


I hope this gives you some more perspective and clarity. Things are a lot more clear for me, but that is mostly because I just cleaned my glasses!


The postings in this blog are my own and don't necessarily represent BMC's opinion or position.
-by Van Wiles, Lead Integration Engineer

A possible answer to the question of how to model CIM associations in CMDBf.

Last time I posted a question - to see if we can move toward a resolution on the question about modeling a CIM association using CMDBf relationships. William Vambenepe replied to me on his blog here:


Basically his answer can be summarized as: (a) Some authoritative group like the CMDBf workgroup defines a convention for mapping CIM association roles to CMDBf source and target, and/or (b) CMDBf workgroup provides an ontology language that allows records to be related to each other (e.g. RDF/OWL semantics.)


While I like his proposal about a naming convention for relationship records (such as CIM_Dependency_from_Antecedent_to_Dependent), it would allow any implementation to model the source/target direction either way. At least it would be definitive about the role of source and target for that relationship. I also like the idea of having an ontology language to describe the record types more thoroughly, but I would not want to force MDRs and consumers to read and understand the ontology in order to use the interface.


I guess in a perfect world everyone would model it the same way, so if we said "source is always the first role and target is always the second role" we would at least have a simple match most of the time, and the naming convention would confirm the roles of source and target.


Note that an ontology language or some embeded mapping of data models allows an MDR to return records it considers to match your query, even if the record type has a different name. Here's an example.


Assume I could have this i1 -r1-> i2 <-r2- i3 graph in a CIMOM where:

  • i1 has a CIM_ComputerSystem record
  • r1 has a CIM_ParticipatingCS_from_Antecedent_to_Dependent” record
  • i2 has a CIM_Cluster record
  • r2 has a CIM_ConcreteDependency_from_Dependent_to_Antecedent” record
  • i3 has a CIM_Organization record

So in English I have an organization which depends on a cluster of computer systems.


Now I want to see what computer systems support this organization. I can invert r2 as CIM_ConcreteDependency_from_Antecedent_to_Dependent (vr2) and have this: i1 -r1-> i2 -vr2-> i3. Now I can query i1 to i3 via CIM_Dependency_from_Antecedent_to_Dependent with depthLimit 2 or more and find this graph. Great! But I made a couple of assumptions that the casual observer might not have noticed:


  • CIM_Dependency is a superclass of CIM_ConcreteDependency and CIM_ParticipatingCS. We have decided it is OK to match a record type which is considered to be of the same type as the request, even if there is no strict XSD extension model to validate this.
  • We are also considering defining a way (via RDF/OWL) to expose theseclass relationships.
    An MDR could respond with an inverse relationship that satisfies your query, even though this relationship record does not actually exist in that form (really a special case of the previous item).


Reversing direction in the underlying data store query could be challenging, but that’s why we hire geniuses (well maybe we need a few more).


The postings in this blog are my own and don't necessarily represent BMC's opinion or position.
-by Van Wiles, Lead Integration Engineer

How do you model a dependency relationship in a directional metamodel? This question is surprisingly difficult to answer.

First I must apologize for not posting anything for the last two months. I guess I had writer's block. Then again I know some who would prefer to get more meaningful posts less frequently, so at least I can satisfy the latter part of that preference!


So we have this question about how to expose an existing CIM association as a relationship using the CMDBf metamodel. Take CIM_Dependency for example. It seems that about half of all CIM associations are based on CIM_Dependency so answering this question may be generally useful.


CMDBf would require the MDR to represent a CIM_Dependency association as a relationship between two items, where the relationship has a record of type CIM_Dependency (and maybe other records too). So far, so good (a no-brainer if you have been following my blog or other CMDBf activities).


Now - how do you represent the Antecedent and Dependent properties of this record? The first part of the answer is not too hard - a concatenation of the existing Key properties of each CIM instance will work within a CIM Object Manager. But how do you relate Antecedent and Dependent to CMDBf source and target in the relationship metamodel? That's the tricky part (and very important for an MDR, I might add). In the picture below, can you tell whether Computer System depends on Person (like server depends on administrator) or Person depends on Computer System (like I depend on my laptop)?

If your MDR implementation decides that the Antecedent role maps to the relationship target and my MDR implementation decides that Antecedent maps to source, we won't have interoperability even though we are both using the same data model (!!) In other words, our MDRs may not reconcile or respond to a query with predictable results. A graph traveral from one MDR to the other may get stuck in between.


It would be a lot easier if every Association in CIM had a sense of direction, like "depends on" for example; then it would be grammatically obvious (at least to someone who understands English) - source depends on target. I suspect it's a bit late for that wish to come true.


There may be a couple of ways out of this modeling conundrum. The CMDBf workgroup at DMTF could define how to map these basic CIM association REFs to source and target and ask every MDR implementation that supports CIM to follow these conventions. That's a real possibility and easy to implement if we catch every MDR before they go with their own instincts.


I had another way out, but got lost in the maze. Help! I'm waiting for someone else in the workgroup or in my little blog world to make a better suggestion.


The postings in this blog are my own and don't necessarily represent BMC's opinion or position.
-by Van Wiles, Lead Integration Engineer

This entry illustrates ways to model a CIM_VirtualComputerSystem in CMDBf.

Here's an example that will illustrate how multiple records are used to represent a configuration item in CMDBf notation.


Let's assume I have an MDR that has information about VMWare guest systems. The question for CMDBf is - how will I expose this information to a federating CMDB or other CMDBf query client? One really good way is to map the information to the Common Information Model (I'll use version 2.16 for this example).


CIM_VirtualComputerSystem in CIM 2.16 is a subclass of CIM_ComputerSystem, which is a subclass of CIM_System, which is a subclass of CIM_EnabledLogicalElement, ...


In CMDBf parlance, there is an item representing this virtual machine (virtual "lump of plastic and steel" as some in the committee call it.) Then there are records describing this item.


Now, I could take all the inherited attributes from those CIM classes and make one big CIM_VirtualComputerSystem record. This would be really easy to process, but it leaves out some important functionality. What if I want to query for all Computer Systems or all Systems in general? This could only be done with a very complex query searching for all possible subclass record types.


Alternatively (and recommended), I can model the VM as an item with a CIM_VirtualComputerSystem record plus a CIM_ComputerSystem record, plus a CIM_System record, all the way to a CIM_ManagedElement record. This will allow maximum flexibility for the query client to find exactly the items it needs to query.


Now a more difficult question - if I want to use the Registration service of CMDBf and mass-register all my VMs, should I register each item with all these records? That could be a lot of network and parsing overhead. Plus, I wouldn't expect the federating CMDB to replicate and store all this information.


Probably the best answer is to associate another record with the item that provides just enough information to identify the item. This record should indicate that the item is a virtual computer system with a certain name and other identifying properties, possibly combining attributes from multiple superclasses. There is no standard schema for these identifying records today - this is an open question for the community to answer. Your feedback is welcome!


The postings in this blog are my own and don't necessarily represent BMC's opinion or position.
-by Van Wiles, Lead Integration Engineer

Some references to applications and technology enabling Business Process Management using Service Oriented Architecture.

I just got a "blast from the past" question about applications that are packaged with process models and monitoring (see


The new wave of applications are things like Oracle Fusion Applications (, the next generation of SAP Business Suite built on NetWeaver ESOA (, and even the latest BMC Remedy IT Service Management built on the Remedy Service Process Management platform(,,0_0_0_1805,00.html).


The trend then and now (since it’s been almost a year since I posted that) is to build the business logic and rules using tools that business people can understand, then use this business logic to generate the technical implementation required to execute and monitor the processes. Since I wrote that, many of these companies have acquired additional SOA technology through M&A and partnerships, including the BMC acquisition of RealOps for IT service automation.

Note: for SAP, Oracle and some other packaged business applications, you can get higher-level process models that are application-independent from IDS Scheer AG ( For business rules, many of these vendors use Corticon ( or similar Business Rules Engines.


The postings in this blog are my own and don't necessarily represent BMC's opinion or position.
-by Van Wiles, Lead Integration Engineer

The CMDBf 1.0 spec could be implemented in many ways by many parties.

Here are a few ways the CMDBf 1.0 spec (not a standard yet) can be implemented.


First - it is important to understand that the spec describes web services. These services can be written and delivered by anyone, not just the vendor of a particular CMDB or MDR. So let's say there are three scenarios (there may be more):


1. Each CMDB and MDR vendor produces its own CMDBf services for its own product lines
2. Third-party software vendors produce CMDBf services for popular CMDB and MDR products and market these adapters independently
3. Consulting service providers produce CMDBf services for custom applications to be used with other CMDBf implementations


I will guess that these are all viable options and could very well come to market in the reverse order from above (custom implementations first).


Second, the spec can be implemented in many ways - "push-mode", "pull-mode" or both, varying levels of query support, varying record types, etc.


Now comes a tricky question - can you market these adapters without a common data model, or an exponentially-expanding set of data-mapping objects? The point here is that some maturity will be required before this is really plug-and-play.


So, leaving the modeling/mapping question aside for now, let's see how a third-party could produce adapters for a pair of MDR's. I'll start with a picture.


In the picture above, all the CMDBf services and processes are provided by a third-party (call it Lavender Software.) Lavender has adapters for each MDR proprietary interface, plus transformers to register items and relationships from Vendor A to Vendor B CMDB, and a User Interface to query the registered CMDBf Query Services.


This picture could change if one or both vendors produce their own CMDBf services and the customer wants to switch. In this case, Lavender Software might provide a way to switch services to another vendor. In this case, you can imagine that it would be much less painful to exchange information between CMDBf services in a common format, at least in the case of registration. Additionally, it would be really helpful to the query UI if items of like-kind had common type-names (like Incident or Computer System for example).



In the final picture, vendors A and B have provided XML schemas and registration processes for their services, and a contract integrator has been hired to connect the services. All that is required is for the contractor to use the registered services and provide a query client interface for the customer.



Final note: open standards and open source go together like shoes and socks (except that standards smell better with age.) There is an open source project giving some very interesting insight on a CMDBf implementation over SML/CML starting here: This is part of the Eclipse COSMOS project which is sponsored by some of the original consortium companies. It should be a useful starting point if you are interested in implementing CMDBf.


The postings in this blog are my own and don't necessarily represent BMC's opinion or position.
-by Van Wiles, Lead Integration Engineer

What's going on in my year 2008 (I think)...

I haven't posted lately - if you subscribe to this blog, I'm still here!


The CMDBf consortium work has wrapped up - I plan to be actively participating in the DMTF committee to support CMDB federation now. I'm working on another post about CMDBf records in the meantime, while the DMTF committee is getting ready to launch.


In other areas, I'll be supporting development efforts to integrate with BMC Atrium technology. I expect this technology to expand well beyond CMDB this year, so remember that "BMC Atrium" is not synonymous with "CMDB". As always this will involve a lot of learning for new releases and features. It will also require some leadership as we develop a methodology for validating and certifying interoperability.


Anyway - I wish you a safe and prosperous New Year wherever you are!


The postings in this blog are my own and don't necessarily represent BMC's opinion or position.

Filter Blog

By date:
By tag: