SSL Certificate Discovery Reaches 1.0

Posted on by

Traversys are proud to announce that we have updated our SSL Certificate extension for BCM Discovery to include an automatic installer, with dashboards and reports.

Our SSL Certificate Extension can provide insight into:

  • Signing status (self-signed or Certificate Authority)
  • Certificate Lifecycle
  • Serial Numbers
  • Encryption Level

Certificate capture works independently of the Discovery scan, meaning certificates can also be captured for servers that are not part of targeted scanning.

Supports versions 10.2 – 11.3 if BMC Discovery.

Talk to us today about enabling this for your Discovery solution.

Automating The Department of Redundancy Department

Posted on by

This post was first published by Wes Fitzpatrick on LinkedIn (19th Feb 2015). It has been edited and updated.

In recent times I’ve had the privilege to sit in on client meetings with small businesses who are moving from paper-based system to a partially or fully automated ITSM process.

It’s a great boost to see a customer who is excited by the reduced time, reduced cost and efficiency that a new system is going to bring – especially when you are the one who is going bringing it to them! It’s where you can immediately see the benefits of introducing ITIL to a system where it is only vaguely understood. Something that you can often lose sight of working in well-established larger organisations.

That said, it never ceases to amaze me during scoping exercises how often a customer wants to replicate the the paper system in the automated one.

Working with a product like Ivanti’s Cloud ITSM or ServiceAide, customisation is not a problem – there’s very little you can’t do to customise it to your own processes, however one of the questions that should be asked before blindly accepting requirements is why?

In Change Management for example, a paper-based process might require 3 different sign-off’s which is an easy trap for an executive to translate as 3 additional approval stages that need to be added to the automated system. But if the automated system allows you set up a CAB, notify all 3 people at once, set the approval rates – there may really be only one approval stage needed. In such examples, I’ve seen far too many situations where 3 stages have been created, rather than trying to help the customer to realise the benefits of automation.

The danger by trying to replicate as much as the paper-system as possible – you’re potentially cancelling out the benefits and efficiency the system brings.

It’s important to look at your current process and question what are the intended outcomes, particularly in light of the objectives behind automation. Rather than look at things from your processes to introduce to automation, try to look for things that automation can help you leave behind.

Why do I now have to do Application Modelling… again?

Posted on by

Featured Image: CC BY 2.0 zeitfaenger.at@flickr.

This article was first published by Wes Fitzpatrick on LinkedIn (5th Sept 2014). It has been edited and updated.

This is a variation on a question I was asked often as a consultant during workshops for new customers using BMC Discovery.

For the last few years Discovery has had CAM (Collaborate Application Modelling) and more recently they have introduced ‘Start Anywhere Application Modelling’ (no acronym, but why not SAAM?). Of the former my unfiltered opinion is that it’s shite, plain and simple. I’ve attempted to use it on occasion but have always had trouble getting it to present exactly what I was expecting. Of the latter, it looks very nice and shows promise, unfortunately I haven’t had much time to play with it. However, regarding SAAM, what looked like a new approach to modelling using the open standard JSON, quickly got locked up and it appears that you can only really create Application Models for the specific appliance you are working on – another missed opportunity if you ask me!

Perhaps I’m just old-hat and set in my ways, I know my opinion on CAM is not alone, but I have come across other less experienced users who are happy with it. But nothing can currently beat the flexibility and versatility of using TPL and building patterns. Of course, this comes with the cost of training and/or hiring someone who can program using TPL.

So what is ‘TPL’?

TPL is a mixture of programming and a markup language – for someone with no exposure to programming at all this can be a steep learning curve that simply can’t be covered in just 1 or 2 days of training labs. Many people I’ve spoken to have come away from a Discovery training course feeling that they just didn’t get enough of the application mapping part of the course, and consequently have had to outsource application modelling anyway.

BMC brought out CAM to address this problem, but as I’ve indicated above, it was a steaming turd for most users. They’ve now attempted to remedy this with SAAM – as I’ve said, it’s a much better step in the right direction, but now we’ve lost the ability to replicate and share! Other companies are out there – our friends at Tekwurx have uControl – which offers a simple to use UI, and Traversys can offer you a comprehensive in depth introduction to TPL, either with some one-on-one remote sessions or with downloadable course material you can learn at our own pace.

But why doesn’t Discovery do this automatically?

Well, the answer BMC – and I myself – might give you, is that Business Applications typically represent the ‘custom’ or ‘service’ part of the business. Discovery will automatically get you the components such as databases, web servers and other middleware, but what it can’t tell you is what underlying service these components support. Only you (or the business) know which database is depended upon by which app server, which in turn supports which service. Furthermore, although communication is automatically discovered e.g. from database to web server, only you or the business knows what communications are relevant and critical. In such, to model a monitoring application, you don’t necessarily need to include every agent installed.

An analogy might be buying an expensive piece of software for your home PC like Adobe Photoshop. Now you have the tool and all the plugins which will allow you to tweak your photos and images to perfection – but what Photoshop can’t provide is the actual expertise and the changes you want to make. That task is down to you to do yourself – or to hire an expert to tweak your photos.

BMC Discovery is still a ‘best in class’ tool which gives you a complete picture of your estate along with the ability extend and tweak beyond it’s core functionality. Few other discovery tools on the market are as open, allowing you to see exactly how something was inferred and giving you complete control over your data. However, like expensive imaging software, unless you know what you’re trying to accomplish and how to use it, you need to become an expert, purchase additional software, or hire an expert to get the most out of it.

If managed correctly, the extra cost of 3rd party software, training or professional services should pay for itself in the savings seen to the business through identifying critical dependencies, security risks, server consolidation opportunities, licensing audits and storage management.

Talk to us today about getting some training on TPL.

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.