The white paper you have is a great document to help explain the how-to or best practices for service modelling (especially if you are using BMC Service Impact Manager), but as you've noted, it was written back in 2005. It doesn't need updating in terms of core concepts, but it would be useful if it was better aligned to Atrium CMDB in its current incarnation, along with examples.
The Business Domain aspects could be modeled as Organization CIs (or similar). The intent I guess is to provide a grouping of Business Functions, which are in turn collections of related business processes.
We've opted for a simpler approach of keeping Business Service at the upper level of our model (we don't model the actual processes or functions, yet). From there we decompose into supporting technical services, applications and underpinning infrastructure (computer systems, software servers, databases etc).
I have a question on this and I may need to post it to the BCO group but thought I would try here first.
If we keep with the CMDB best practice of the Business Service at the top of the model and everything flowing downhill to the servers and such this causes an issue when we try to integrate with BCO as according to the documentation and the tests that I performed the model has to be built the other way around with the business service at the bottom and the servers and other components above it.
So has anyone else ran across this issue and if so how did you rectify it? Or did you have to completely go against the best practice and set your models according to the way BCO wants them?
This is all OK. The BCO diagram is 100% correct and I think the only confusion is that you talk about the Business Services at the top of the model (correct) but everything flowing 'down' from there. There's not really an 'up' or 'down' in this so much as the direction of the various relationship classes we use to model things. The BCO model does show the Business Services at the 'top' of the stack along with dependency relationships (the red ones) pointing TO them. The way this is read when explaining the model is that the destination in a dependency relationship is effectively the dependent object (or consumer) and the source is the provider. So, top down, the Business Service CI at level 2 depends on (or consumes) the Application CI at Level 3, and so on. If you read the model all the way through like this, you will see it makes sense. Another way to look at this is to think about Impact. Impact direction is typically the same as the Dependency direction, so again looking at the diagram, the Computer System impacts the Software Server (i.e. if the Computer System were to be unavailable, then the Software Server will be impacted).
It can become a little confusing when looking at this model once in the CMDB in the Atrium Core Explorer views, since by default, that tool will show the diagram you've provided upside down. i.e. Business Services at the bottom. The arrow directions will still be the same of course. Fortunately in the latest versions of Atrium, BMC have provided the option to have Explorer flip the model and allow it to be rendered as above.
Thanks Carey that helps to clear up quite a few misconceptions I had garnered over the years.
When starting from scratch, there are some many ways to go. With BMC presenting so many options (ADDM, Atrium, Remedy, BPPM,.....) in different delivery formats (onsite, RemedyonDemand, RemedyForce), finding exact information is somewhat difficult. I agreed that the 2005 paper while helpful in a general sense, it does lack in the "How" with the current BMC features.
I talked with a consultant yesterday and their reply was less than encouraging. There was a lot of "depends on" comments. I have learned that most can tell you "what to do", but there is very little "how to do" since every situation is different.
Thank you for your advice on keeping things simple. It is very easy to get distracted by all the "what to do" frameworks/blueprints.
Alec Waugh wrote:
...it does lack in the "How" with the current BMC features...
...their reply was less than encouraging. There was a lot of "depends on" comments...
...I have learned that most can tell you "what to do", but there is very little "how to do"...
...advice on keeping things simple. It is very easy to get distracted by all the "what to do" frameworks/blueprints.
I think your statement nails it. I have yet to see a solid example of how everything can work together; what is the best practice design. I think many organization are inventing the CMDB/Service wheel on their own. While understandably each organization has it differences, largely our data centers and how we deliver services are the same. At its core there are servers, network storage, application and network devices that connect all of these things. Things can be standalone or clustered. Why are there so many different answers and not even some basic blueprints of a real-world model that is usable between all BMC products? Customer should be supplied with a starting point and some guidance instead of questions.
Great comments Jason. We achieved most of what BMC can offer in the BSM dream/nirvana at my last job. While it wasn't the only thing we worked on, it took the best part of three years for myself in the CMDB space and a colleague in the BEM/SIM/BPPM space to make it happen. I was lucky to be working with one of the smartest and most experienced people in that BPPM area. Certainly in this region (and if you asked him he'd probably say the world :) )
I can be confident we tackled it in a sensible way because the bulk of what we did with either process, customizations, configuration etc is now offered by BMC and called service Resolution. ;)
The point of all this is that we had to work most of it out ourselves. The tools were mostly all up to the task so kudos to BMC, but the real world guidance we needed was mostly not there or hard to find.
I think if we had to, we could sit down and write it all down, but that's not a customer's job is it?
Thanks for validating I am not alone in thinking this. Frankly my organization doesn't want to spend 3 years on the BSM dream/nirvana (and your situation sounds like a best case scenario). The return just isn't there for us considering all of the effort to figure it all out and then add the expense of the products. We are a healthcare organization not a CMDB/Asset Management organization. When we look at all of the people and product it would take to get this "stuff" off the ground it and then maintain it, it really doesn't align with our healthcare mission.
Maybe if there was a blueprint of how it can be done and a framework (for a lack of a better term) of what/who we need, etc. we might be able to get a return out of it. As it is now it is just too much trial and error that would detract from our core mission. To be honest having our questions answer with questions was a major factor that killed our CMDB/ITSM project.
I have mixed emotions on finding this discussion thread because I now have validation of my frustration with the BMC documents. Many of these documents are just fantastic blueprints to a conceptual construct for planning an organization's approach to each ITIL framework aspect. I have desperately sought any type of similar blueprint for practical application of these concepts into an organization using BMC's tool set with little luck. I cannot imagine why BMC leadership allows such a major gap to exist when even a few basic examples could open the door to so much more business for the company. Sometimes I feel like BMC leads us to the center of the labyrinth of ITIL utopia then disappears to leave us, the customer, to find our own way back out with no tools except the memory of their guidance into the maze.