Category Archives: grid

Deploying Discovery: Who are your Stakeholders?

Posted on by

In my first post on the subject of developing a business case, I discussed the importance of defining objectives, and not just in terms of server counts, but factoring in costs and organisational structure. In this post, we’ll look at stakeholders, not just identification, but how to manage them and what considerations need to be given to make Discovery a success.

You have an executive mandate and – hopefully after much deliberation over the precise costs and benefits – you have executive approval, but at this point, who else in your company knows? The answer is usually no-one. During my time as a consultant, usually the first anyone below executive level had heard of the project to implement Discovery was when I approached them for information, change approval or even sign off. As you can imagine, this has the potential to lead to considerable delays as you go through the ’20 questions’ routine – where were these people when the workshop was taking place?!

At this stage let’s be honest, it’s not unheard of for a solution to be brought in as a pet project of an executive director, or to replace another tool, or even a deal made at the golf course. This is hardly the fault of the vendor or a mark against the solution itself, but nevertheless these scenarios can lead to a degree of hostility towards the new solution and the project team. In one short project which required access to a number of database solutions (part of an enablement of a migration away from those very products), I had a sysadmin who ignored all my emails and phone calls until the last week of the project. He then proceeded to email the project board to complain that I was inexperienced and had not given them enough time to provide the information requested. Thankfully, on this occasion, the team manager had my back; I wish I could say that was always the case, but when it isn’t, it can then backfire in a very gradual way. If a project team starts to see themselves as undervalued and under attack, before you know it valuable resources will be leaving your company and in turn your project high and dry, taking their knowledge and experience with them.

Discovery can potentially impact everyone – because it is potentially touching all aspects of your infrastructure – hardware, software, databases, networking… Therefore, everyone in your company is a potential stakeholder.

Even where communication has gone out, and the project methodology has been defined, it’s rare to find that it has been followed through to the extent that it needs to be. Basic things like nominating a senior user and end-user handover can be completely forgotten until the project is well underway. It’s important than, that even if not all stakeholders are not considered or consulted when bringing in a new product like Discovery, effort is put towards linking the desired outcomes to the roles required to effect those outcomes. The list of considerations below are by no means exhaustive, but should be reviewed as a minimum, to avoid costly delays and re-scoping:

Company Culture

  • Do you’re employees embrace company goals? Are they aware of the latest technology trends? What is their ‘risk appetite’ and attitude towards change? The answers here are going to be important for determining how to go about building acceptance and formulating your communication strategy.
  • Is your organisation flat or operate several layers of skills, experience and management? Do workers report to the same people who are line managers? Will communications and mandates from high executive level above filter down to the implements, or get lost in the fog of management layers?
  • Does your company operate informal, open-door policies, like a ‘family’ – or is it formal, procedural and authorisation based?

It should go without saying that the more formal, procedure-based and layers of management that exist in your organisation, the longer it will take to get a solution rolled-out. It is also likely that they are change averse and may require some kind of risk assessment. The important thing to realise is that Discovery can potentially impact everyone – because it is potentially touching all aspects of your infrastructure – hardware, software, databases, networking… and feeding all that into your ITSM processes. Therefore, everyone in your company is a potential stakeholder.

Building Acceptance

  • Have your cyber-security team reviewed the impact of Discovery? Are they aware of the project and it’s implications? Do they require any specific auditing such as ISO27001?
  • Do the objectives for Discovery (e.g. to replace another tool) impact your employees or users? Even if Discovery is only part of a greater enablement project to replace other tools, employees whose work and skills are tied to those toolsets will be motivated to see it fail, and be likely to raise as many objections as possible, regardless of merit.
  • How will you get buy in to the project? How will you reduce bureaucratic stonewalling? Are the benefits clear? Often times resistance can be overcome by identifying indirect benefits or even opportunities through extension of Discovery. Nobody can complain if you can demonstrate how the discovered data will make their jobs easier.
  • Do the end-users have a choice in using the Discovery product when all is said and done? A tricky question if you’ve already made a license commitment, but if you’re only putting it out as one of several alternatives (particularly if those alternatives are already installed) it will be a use-case failure, even if your implementation comes in under budget and ahead of schedule.
  • Is there a cost for non-compliance? Who will be billed for success/failure? There will be little interest in rolling out a new tool for existing infrastructure where there is no accountability for saying no. Similarly, no-one wants a bill sent to them for something they didn’t request, and didn’t budget for. This should be factored into the communication strategy.

Security is a key aspect here – making an expensive license commitment only to find that half of your (assumed) benefits are wiped out by strict security policies is a costly exercise. Ensure cyber-security are consulted before you sign the deal; ensure they are satisfied with the product – or that you raise/authorize the necessary exceptions. A solution like BMC Discovery is a secure and proven tool, but the degree to which it captures data and the large amount of ports used rightly makes some security heads nervous, and they can be unhappy if left out of the loop at initiation.

Communication Strategy

  • Is the deployment of Discovery organisation-wide, or limited to selected business lines, customers or accounts? The larger the project, the more the onus is on leadership to communicate and spread awareness of their mandate.
  • Are there clear lines of escalation? It seems awkward to consider the escalation process before you begin, but you’ll be thankful for a clearly defined process when (yes, I said ‘when‘) you hit that inevitable conscientious objector who knows everything they need to know about the domain they manage and they don’t need Discovery thank-you-very-much.
  • Are your project team and infrastructure people onsite, spread out among locations, or completely remote? Do they work in different time-zones? Time zones and remote working are going to increase the timescales you need to work with but they’re also going to slow down communication.
  • What communication tools will you have at your disposal? What are the most effective? If your company has access to social messaging and social networking tools this could cut down on unnecessarily large email threads and distribution-lists (both of which tend to get ignored).
  • Who needs to know and what do they need to do? There is a tendency on large projects with lots of teams to hold meetings with up to 100 people in attendance, where possibly only 10 are needed. Larger meetings tend to create an ‘audience mentality’- if participation and discussion is necessary then keep the meetings small and split them up.

If you’re working across timezones, you should bear in mind that some regions have a work-culture that means employees will down tools at 4.55pm and be out of the office at exactly 5 –  this can lead to at least 18 hours before receiving a response to even a simple question (assuming they even have the answer)! it seems ridiculous but this can mean getting agreement on even minor technical details can take weeks if it involves coordinating with several people across the globe.

Meetings need to have clearly defined agendas with owners and actions. Sometimes scheduling regular progress meetings can keep people on track, but if the meetings are undefined with no-one chairing or no decisions to be made, then some people may choose to skip them altogether. Before scheduling a meeting question what the desirable outcome is, what decisions need to be made otherwise it’s really serving no purpose but as a time-vacuum. PM’s need to be bold in holding people accountable and defining decisions taken, actions, owners and deadlines.

Finally, for a global deployment, effort should be made to publicize the project via company newsletters, managerial meetings and any other communication channels. Don’t just leave it to the project team to approach the whole organisation out of nowhere. Most likely your project team will be made up of employees new to the tool or the company, and possibly one or two external consultants. new employees and contractors will be inexperienced with your company culture and hold little to none of the political capital needed to ‘get things done’. Similarly, a vague project mandate dictated from the clouds above holds little influence over developers and sysadmins at the coalface – communication needs to be clear, authoritative and backed by measurable outcomes or consequences.

Disco Enhancements Browser Extension version 1.3 Released

Posted on by

This release contains a rework of the back-end code to make the extension work with version 11.2 as well as maintaining a fluid experience in both version 10.2 and 11.0/1. It’s actually an improvement in the code, I’ve managed to tidy it up and remove some messy workarounds but not all of them. So the extension does throw up some console errors, but from a user perspective it’s unnoticeable.

It’s a continual game of catch-up with BMC as they tweak their interface for BMC Discovery even on minor releases. Version 11.2 is no exception – the banner has changed, and some CSS form elements ID’s have changed.

To accommodate the CSS changes, the Generic Search Query box has been moved to the top of the page content and expanded. My own experience with copying and pasting queries caused me to find the smaller box more limiting – and of course it makes support across 3 versions of Discovery easier.

The extension has been tested on Firefox in unsigned mode and works without any tweaking. However attempting to upload it for signing to AMO did alert me to errors in the manifest (Chrome Web Store seemed to accept it with the Mozilla required ‘ applications’ key). I guess I’ll have to create a duplicate repository with a separate manifest after all.

There is the thorny security issue around using insertAdjacentHTML(), see this:

if (xhttp.readyState == 4 && xhttp.status == 200) {
  pageDiv.insertAdjacentHTML('afterbegin', xhttp.responseText);

I confess this is hacky workaround to get it to pass some html from a text file to the page. Mozilla security will reject this. I’m not yet smart enough to know how to implement a workaround…. more late night studying ahead for release 1.4 I suspect.

A premium version will be on it’s way. This will add the possibility to view and run the last query under the Generic Search Query box, amongst other functionalities. The core version will remain free and all the code will be published under the MIT license on GitHub.

Get the free extension for Chrome.

Developing a Business Case for BMC Discovery (ADDM)

Posted on by

As a contractor and solution architect, my involvement in most BMC Discovery deployments has usually come long after the business case has been determined, agreed and approved. By the time I’m on the scene, there should already be a PM, a statement of work with agreed deliverables, and a project plan – it’s then in my hands to deliver on what was promised. If the sales team and the executive have not been cutthroat about prices and scope, then this gives me plenty of time and budget to not only deliver on objectives, but also provide some value add.

Unfortunately, this is not always the case – cost and time factors will affect executive decisions, and pressure to make a sale will also cause vendors to over-promise. I’ve witnessed this at almost all stages in the project lifecycle – from presales to run, and with the exception of projects I’ve been brought in specifically to ‘rescue’, it’s not pleasant to be sitting at the end of the process having to explain to the customer why they’re not getting what they expected.

With this in mind, I want to share, from my experience, what factors need to be considered when putting together a Use Case for BMC Discovery. I have always considered BMC Discovery is a best-in-class tool with a lot to offer in terms of both revenue opportunities and savings. I hope this will help you to see the same, and avoid false expectations, unexpected costs and unworkable timescales.

Conducting the Cost/Benefits Analysis

…it’s not enough to simply list a number of benefits – they need to be applicable in some way to your organisation; many stated benefits may not be suited to your company… climate control and parking sensors are nice benefits for a car, but there’s little benefit to be had installing them on a motorbike.

First and foremost, it’s important to get your objectives clear, and linked to measurable financial benefits. This sounds a bit obvious, but you’d be surprised how much of this is lost when it filters down to those in your company whom this solution is foisted upon. In order to determine these benefits you need to consider whether your main goal of using BMC Discovery is to realise revenue opportunities (such as billing in a managed service), make efficiency savings (such as data centre migration), avoid risk and penalty (such as software audits), or a combination of all three.

It’s quite likely that you have been sold on all three benefits with a couple of dozen additional benefits thrown in. However it’s not enough to simply list a number of benefits – they need to be applicable in some way to your organisation; many stated benefits may not be suited to your company. For example, your company may be similar in many ways to others benefiting from Discovery, like a car is similar in many ways to a motorbike – both have a engines, pedals, speedometer, seating and similar purposes. Add-ons like climate control and parking sensors are nice benefits for a car, but there’s little benefit to be had installing them on a motorbike.

There are several factors to consider that should not be ignored in assessing the costs and benefits for your business case, not least these:

  • Licensing
  • Hosting
  • Security
  • Acceptance
  • Resourcing (Project and Operations)
  • Support
  • Data Quality

Up to, and as of version 11.x, BMC Discovery is licensed primarily on server count, with additional option of purchasing storage discovery and extended data pack (including End-of-Life and hardware reference data). When considering licensing, the obvious question is going to be a ballpark figure of how many servers are in your estate; but in determining viability of the Business Case, you also need to ask the following questions:

  • If part of managed service, how are you billing your customers? Can the costs be recuperated from server count alone? If you bill based on service, server count cannot be guaranteed to meet your revenue objectives and you would be better to focus on cost reduction.
  • How is your company structured? Is it one entity with centralised management, or a federation of accounts or companies, with separate financial structures and billing methods?
  • Will the licensing, project, support and or hosting cost be covered in a central budget, or distributed along lines of business?
  • Do you require data segregation for regulatory compliance, customer or cyber-security policies? This is critical to determining hosting and resourcing costs – ignoring this question could lead to major adjustments to the business case further down the road.
  • Is your infrastructure hosted in one or two places (physical, logical) or is it sparse and unconnected? Similar to the question above, this needs to be considered in estimating hosting requirements. It could mean the difference between 2 and 20 appliances!
  • What is your target infrastructure beyond servers? What percentage of discovery have you agreed on? What attributes are critical? In my experience 85% is realistic, 95% is optimistic, 100% is fantasy – just like anti-virus software, you’re only as good as your last scan and your environment is constantly evolving, not to mention there are always exceptions that can’t be discovered due to various reasons.
  • Is your infrastructure managed in-house, offshore, or it is outsourced? If outsourced, will existing contracts cover the obligations of a successful deployment? If you use offshoring, the cost may be cheaper, but be prepared to extend your timelines anything up to 6 times for effort involved. If outsourcing, make sure the contract covers all prerequisites of deployment or be prepared to sacrifice some success criteria.
  • Does your team, or department have the prerequisite skills for Discovery and data quality analysis? This is going to affect your resourcing costs, particularly if you find 3 months into the project that you have to hire relevant subject matter experts (SME) because the team you assembled doesn’t know what they are doing. If you are using an offshore model double your due diligence efforts!

Finally, after assessing all the questions above and risks that they represent, it’s worth considering if there are any other projects that may benefit, or be impacted by, the deployment of BMC Discovery. There may even be some projects that will impact Discovery itself.

  • Are there projects involving the existing CMDB that will impact the sync timescales?
  • Are there tools or projects that can be replaced by functionality from Discovery?
  • Are there tools or policies that will have an effect on the timescales or functionality of Discovery?

Arguably, some of these questions can be addressed by vendor Proof of Concept and workshops before the project plan is developed, but in many cases I’ve seen spend commitments and project plans made before many of these questions are answered (or answered insufficiently), well before a qualified SME is hired and by then it’s too late.

There are other considerations that I hope to go into in future posts, but addressing these questions at the outset will give you a good firm foundation to base your Business Case on, and avoid even more expensive adjustments later where the reality on the ground hits.