Realizing a BSM solution is a complex task and has a lot of challenges involved which are not just technology related but also related to process, organization, cultural and expectations. Lack of standardization of the process for implementing BSM is a major factor resulting in failures and unmet expectations. Most companies planning/currently trying to implement BSM have enough tools to implement the solution. But the vendors trying to sell there solutions do not realize that with no standard tools for designing BSM views, the challenge is in a totally different dimension.
In this article, my focus is on principles/implementation guidelines for realizing a BSM solution leveraging the existing tools which are accepted by the organization. Following are few ‘Mantras’ that if practiced with discipline, provide successful, accurate and adaptable BSM solution that more than a handful of executives can look forward to. (After all BSM is not just about executives, it’s also for a line manager and the engineer who ‘makes things happen’ on the ground). So without further ado here are the principles/implementation guidelines:
- Know Your Business Drivers
Before knowing the underlying Business drivers, you are not going to get anywhere. When documenting what is to be done (requirement analysis), try to know the underlying motives for the solution?
- Is the sponsor/s looking at using it as a Governance solution for enterprise/line of business which does not have tangible assets (Like applications) to manage?
- Is the sponsor/s looking for this solution primarily for SLA or regulatory reasons?
- Is the sponsor/s looking for this solution to analyze the resource utilization and strategic growth planning?
- Is the sponsor/s looking for reducing failures, restoration times, problem isolation ?
Know your Business Drivers and document them with priorities, this will allow you to gain authority on what value proposition needs to be created for verifying the success. Most often the client stakeholders of BSM expect some working solution as soon as possible. Set the expectations!!
2. Know the end goal before starting implementation
I am a big believer of Agile Business sustenance theory (only those who are swift to adapt sustain, rest die!!), but WE should not panic to deliver working solution increment in first 6-10 weeks (depending on the size of the solution). Ensure all crucial aspects like Drivers, Value, Stakeholder Categories, Stakeholder concerns, Quality requirements, Commonality/variability factors and Business/Service/Engineering views are documented well enough for you to feel comfortable on what needs to be done.
(Important Tip: Use SEI standard documentation templates for documenting your solution, this will ensure complete coverage of information required. Yes it is exhaustive, but necessary. )
3. Use mind mapping technique to build view design
Not many simple, easy to use tools exist for view designing for a BSM solution. In past I have seen consultants from the ‘big 4’ companies struggling with views (or what they called designing) on office tools while customers were speeding along on their talk and thoughts. This makes me wonder, Why do the BSM vendors completely ignore BSM design tools even with no major offerings in market space?
I have experienced that mind maps really works for designing BSM views as they are easily available and synchronize very well the business thoughts/flow. What is even more appealing about mind maps is that they very often need no refinement before your view is complete after a meeting/discussion with stakeholders. Benefit of using mind maps are instant feedback, increased speed and velocity. (Doing this will make design and development very agile)
4. Ubiquitous language
If you are not aware of Domain driven design concepts and you are into BSM, you are ignorant of a very powerful technique to bump up effectiveness in solving the business problem. Forming a common set of terminologies based on domain will get you through the design phase with accuracy, precision and facilitate a disciplined approach. Form a set of common domain language and use it. This really helps, especially brings precision to your Key Business/Quality/Performance indicators.
5. Start small and simple, BIG BANG DOESN’T WORK
Take a meaningful Business driver, analyze and discover resources (infrastructure, network, applications) and show value in an end-to-end scenario, this will draw interest, attention and more resources to accomplish further value. It will also provide an opportunity to get immediate feedback and agility.
6. Leverage existing application (this might get me shot!!)
My principle is that if you have a culture of using tools from a vendor, stick to them unless they do not meet expectations. BSM is not about redefining tool set!!
7. Tiered approach is better than professing ‘Enterprise’ Approach
Don’t fall in the ‘Alignment Trap’, although standardization is important, don’t pressurize teams to use the same fancy dashboard which are recommended by enterprise groups, instead try to leverage what they already have and fill the gap of information they need for what is important to them to expand and retain their business value.
8. Don’t forget to check on traceability
Tracing to-and-fro from the solution to Business objectives is an important exercise that should be practiced periodically; make sure you have set aside an hour every fortnight for this. It is very easy to get side-tracked with information from multiple silos (often time single silo can also be enough to loose focus).
9. And finally, “Organizational Value” cannot be achieved off the shelf
There is nothing like ‘8 hours to BSM’. Don’t entertain phony sales presentations and save your customers some money, ensure you and BSM stakeholders focus on value and not tools. WE should not forget the fact that BSM is not only about building a solution, it is also about ensuring quality, ease of access, aggregation of right level of information and encapsulation (information hiding) based on stakeholders.
This post provides a brief insight into each of the principles that i have experienced to be successful while ‘working on the ground’; if you would want to know more on this or provide your feedback, please leave a comment or get in touch!! In the next post, I will share insights on attributes of a successful BSM implementation.
Comments on this entry are closed.
@robinharwani
All excellent things to consider!
A few questions/points:
– What’s SEI documentation? Any references? Do you have any examples (scrubbed) that can be shared?
– Great point on mind mapping. I use Freemind myself for this process. (http://freemind.sourceforge.net/) There are also some nice flowcharting and UML tools that work well. The trick using any tool in this agile design process is to have worked through a typical flow in advance. Have some example shapes or branches. Know how to use the keyboard shortcuts, etc. There’s nothing wrong with Visio if you know how to really use it.
– Your domain knowledge point is key, especially for the typical monitoring tools group who’s charged with deploying BSM in many environments. They’ve got to “talk the talk and walk the walk” when they collaborate with application development and support groups. Do your homework up front. Know the lingo, terminology, architectures, protocols, code/languages, etc.
– Adding to your last point on organizational value, failing to focus on the people, process, procedures, workflows, organizational change, etc. to fully adopt a BSM culture is more often than not a leading cause of BSM initiative failure.
Keep them coming!
Doug