Idea ID: 2761674

handling of "Managed State" vs. "Actual State“ in SMAX (or with SMAX and native CMS integration)

Status : Waiting for Votes
Waiting for Votes
See status update history
over 1 year ago

In the classic Service Manager -  UCMDB integration, we have the capability to open change records based on actual CI changes, plan CI attribute updates in change records and verify the execution of changes against discovered CI attributes.

 

This capability is currently not available in SMAX.

It would be good to have those use cases added to the SMAX / CMS solution in future, especially with a native CMS integration.

 

While I haven't seen this implemented (using Service Manager; I received feedback that the functionality is good but to the efforts to maintain are to high) very often, I think especially security / compliance requirements are becoming more important nowadays, while the customers become more mature.

This topic appears in RfPs pretty frequently and could be a competitive advantage (again).

Also Bafin (the organisation that is responsible for banking supervision in Germany) is asking for those capabilities.

 

So what I would like to see in "SMAX - CMS" are the capabilities to:

 

  • React to unplanned Changes (discoverd by CMS / UD)
  • Record planned CI attribute values vs. actual CI attribute values
  • Enable Change record / process execution (done in SMAX) verification (via CMS / UD)

 

Thanks

Tags:

  • Maybe storing all data in SMAX is not the way to go.

    The CMS has the capability of storing different states per CI (actual / authorized). Basically, that's the functionality, that was used by the CM module.

    Why not use that capability and build a module in SMAX, which has federated access to the CMS data/states and compares those states. If it matches, it's fine. If it differs, the module (maybe we call it "Configuration Manager" ) can directly check, if there are existing changes for that particular CI (which should appear as related records already now?!).
    If there is a change, saying, that the actual value is the correct one, the authorized state will be updated, the change is closed.
    If there is no existing change, some kind of unplanned change will be created, meaning: someone will have to check, why the actual state differs from the desired state.

    Yes, these thoughts do not cover all possible cases, but it's just the beginning of thinking of possible ways to build a functionality, which is completely missing at the current time.

  • Excellent idea, as I have seen the requirement in more than three recent RfPs.

    The "must" in this would be:

    some mechanic which allows

    1.  to compare the "desired value" which is stored in SMAX CMDB data
    2. with the incoming "actual value", sent from UCMDB to SMAX
    3. and then searches for matching SMAX changes for that CI
    4. if a changes are found, suggest to attach the UCMDB data record to one of the found changes.
    5. And if no change exists
    6. create an "accept or roll back" change in SMAX

    Step 4 will cause some headache, I know, since SMAX will have to invent a way to divide further handling into
    - "user accepts the attachment of the UCMDB data record"
        and then she selects the change this UCMDB data record will be attached to
    and
    - "user denies the attachment of the UCMDB data record"
        --> continue with above step 6.

     

    I strongly suggest to run step 4 independent of any "planned value" in the existing change, as the value would have to either match exactly or SMAX would have to allow a RANGE of acceptable values.
    E..g.
         "Physical Memory shall be between 16300 and 16500"
    instead of exact value match
         "exactly 16384"

    The "exact match" mechanics was/is available in Service Manager and has proven to be problematic. Customers who did trials sooner or later decided against using this approach, since the change handling becomes tedious.

  • Thank you for sharing your idea! It’s open for comments and kudos, and we’re looking forward to input from the community. Once there is enough community traction, it will be further reviewed by the product team.