This is really the last post in this series! Although there are many more components to be discovered the main purpose of these series to understand the changes and where they are coming from.
Part 3 – System Center Operations Manager 2012 “More that meets the eye” Part 3–SCOM2007R2-SCOM2012……
Part 4 – System Center Operations Manager 2012 “More that meets the eye” part 4–SCOM2007R2-SCOM2012
I will describe My personal view on these changes and how we can use these in our benefit to even more strengthen the System Center Suite.
My personal view on SCOM 2012 and the future….
Let’s take this a step further. I have been thinking about these changes and how to benefit from them and take this another step further, which I think with a little effort is around the corner for both these products.
Service Manager is used to gather information across the System Center Suite. It will pull data from the other products by using connectors.
The following exist nowadays in SCSM:
- SCOM Alert Connector – Automatically create tickets from alerts.
- SCOM CI Connector – CMDB ci’s can be synced from SCOM to SCSM.
- SCCM CI connector
- AD Connector
All these connectors are 1 way from …. to SCSM and SCSM is just the “collector” of all information.
But is this where it should end?
In my opinion definitely not!
We use Service Manager for Service Management based on ITIL and MOF which is where it should be.
Because we now have the same properties as within SCSM we have both products inline with each other but…….
The properties on the classes.
In SCOM we always require discovery rules to identify properties of a CI.
In SCSM we never use discovery rules but edit the CI directly.
In SCOM we use discovery rules to populate the properties. The discovery rules will detect these settings on the agents and reflect them in the console as properties. This is nice but also a burden if you want more non standard properties like for the new Service class.
In SCSM we don’t require discovery rules since the objects living in SCSM can be automatically filled or manually. This is one of the biggest changes between both products.
But….how are we going to fill all those nice properties now also living in SCOM? Like the status, priority or classification property?
I have been thinking about this one and there are multiple ways…..!!!
You could write some discovery or workflow in SCOM which reflects the status, priority or classification of the agent or any other component.
Or leave them blank or hide them in SCOM 2012.
But does this make sense?
No way I have these properties and I want to use them
But how to fill the properties?
Create registry key on every agent to show the status of the agent. Next create a discovery rule to populate the property in SCOM.
Although this will work like a charm and was the way to go when you want to set custom properties like status before. (Production, test environments etc.)
But personally I think this is nice but we should looking at better and nicer ways to achieve this.
Besides this most properties are not be defined by a SCOM admin or IT Pro it is really not their responsibility.
Let’s step back for a while:
Service Manager is our product for Service Management.
Operations Manager is our product for health monitoring.
Wouldn’t it make more sense if we use Service Manager for these properties instead of SCOM?
Yes!!!! definitely will since these are all related to Service Management and should be set by user responsible for service management not the IT pro.
Lets take the Service Class and its properties:
- Display Name
- Service Description
- Bunisess Detailed Description
- Is Business Service
- Owned By Organization
- Availability Schedule
- Object Status
- Asset Status
The properties like Is Business Service or Classification are properties which really need to be set in SCSM.
These are not properties a SCOM admin or IT Pro should be responsible for and need to be set at a higher level in the business.
So we really don’t want to define these in SCOM but instead these need to be set in SCSM!
Well should we hide these or leave blank?
No we just need to set them in SCSM and offer a connection from SCSM to SCOM to “transfer” these from SCSM to SCOM.
Basically what I am thinking of is create another connector.
SCSM –> SCOM
We can set this connector to only transfer the SCSM properties to SCOM so the other connector can exist but needs to have the same flexibility to point out which properties should live in SCOM and which in SCSM.
Next synchronize both products and we have all the properties living in SCOM as well
I think this is a thing we really want to have and is the way to go for full integration. I can think of the other products in the suite as well where this will be handy. Let me explain on the SCOM example.
When we have the classification, status and other properties we can easily create views based on these properties.
A couple of examples of which I think are really valuable:
CI Status – Status is derived from SCSM since this is not the health status but CI status like In repair, Production. We could even run a workflow to set systems in maintenance when they have been set to repair in SCSM. (Automatically)
Classification – especially in financial customers they have classification of the systems which require special care and high security.As soon as there are issue’s on those systems or services it is crucial and the SLA clearly state how to handle these systems.
But in the SCOM console or the guy watching the console has no idea.. seeing these kind of info in your console would definitely speed up the process.
Not every alert is a incident, allot of them are telling you to take action before it results in an incident. That’s where the difference of event management and incident management kicks in.
With the possibility to transfer these properties this will be way easier to identify if they are allowed to directly act.
Most of these systems are not everyday systems and admins are not allowed to directly resolve issues on these systems and need to go to an approval process.
If this is directly in SCOM they immediately know the impact or process that needs to kick in before they act on the events.
It is now easy to create a view with High classification services.
And more important the classification can and will be set by someone responsible for the classification. Something which is nowadays based on the judgment of the guy behind the console….
These will get you to a more and better automated solution.
For full automation to work you require a couple of more components which aren’t available.
Setting service management properties at the service management level. We need to have a connector which will transfer these properties to the other systems.
SCSM –> SCOM connector
SCSM –> SCCM Connector
SCSM –> ….. Connector
This way we can bring the products more together and leave the service management decisions at the service management level!
I know this will take some effort for it to get working but at least SCOM should be a 1 + 1 since the platforms are both the same I see no problems here.
And when you clearly set which properties can be altered we can leverage this easily
If you are still not convinced to use the full System Center Suite we can also put in a Task in SCOM which leverages a form to fill in the properties in SCOM only.
This can be as easy as a management pack with a custom task! And in theory I have done this already in SCSM many times so should be pretty easy.
And to put the icing on top if we can also use the same approach for our custom created properties we are done
But to get back to a more realistic level of what we can implement today:
Custom task in SCOM – the custom task the Community can step in If nothing is changed or added I will write the MP to do this, no probs.
Getting properties form SCSM to SCOM – Orchestrator saves the day and makes this possible as soon as they are released
Even without a fully native integration we should be able to pull this off. If the properties are exposed in the final version the same way as in the Beta version of SCOM 20120 that is……….
With the addition and interaction of SCOM and SCSM I think we are approaching a new era for the System Center Suite.
Although there are still some major steps to take we are now seeing the products getting more and more inline with each other.
One would be the connector talking both ways to be able to fully set service management at the service management level in Service Manager instead of the separate products.
With the opportunity Orchestrator will provide us, we will be able to provide the solutions in my example even without a dedicated connector.
Next would be to take full advantage of all products together!
And to get even a step further can’t wait to hear more on the beyond 2012 releases which should be really really interesting.
Besides this there is allot more to explore and discover and then I am talking mainly at the authoring level for SCOM 2012 and for SCSM 2010 and SCSM 2012 as well!
note to myself:hmmm maybe need to start an authoring week instead of just an “Authoring Friday” !
When The products are final I will definitely do a check up on this series and add a dedicated geeky authoring series as well where we will be talking code! Yeah!!!!