Is One Really Enough?
In the first blog, we covered the common confusions and misperceptions regarding discovery tools and why, in many cases, multiple discovery tools are required. In this second blog, we provide prescriptive guidance, including lessons learned, to select and support a successful implementation of one or more discovery tools.
A brief recap
As covered in the previous blog, there are many different discovery tools in the market. Each tool has its strengths and limitations. In most cases, there isn’t a single discovery tool that can meet the needs of everyone within an organization. When assessing and evaluating discovery tools, you must first understand the origin which commonly exposes the core strengths and limitations. This first step helps start the discussions when identifying requirements across your organization.
Basic lessons learned
Based upon my years of working with organizations on a range of fronts including IT asset management, software asset management and IT service management, I’ve boiled the basic lessons learned regarding the assessment and evaluation of discovery tools down to four basic considerations:
- Clarify and align the specific requirements
Don’t assume. Be specific and ask “How?”, not “Can you?”
Call me Captain Obvious but surprisingly, organizations often move too fast before understanding their specific discovery needs. In the case of a Software Asset Management (SAM) program, you must have clear understanding of the platforms, vendors, titles and license models that are in scope. Then you need to determine if the tool(s) support each of these requirements. Keep in mind, no tool supports all platforms, license models and software titles out of the box, particularly when it comes to software license compliance. However, there are tools which provide much more coverage than others. You should understand the tools and their coverage up front to ensure proper expectations are set. It is common for those who start a SAM program to assume the tools support these various areas only to find out they don’t, which commonly results, best case, in an increase in cost and effort and/or worst case, program failure. Please refer to the What is Software Asset Management? blog for more details on the fundamental truths of SAM. - Don’t try to fit a square peg into a round hole.
Don’t force it.
In other words, don’t try to force an existing discovery tool to deliver what it was not intended to do. I have seen numerous organizations try to extend (i.e. code for customization) a discovery tool to do more than the core capabilities. This approach may be more practical in the early (less mature) stages, but as an organization grows and matures, the risk increases. In many cases, the cost and effort also increases to where the organization is forced to revisit their discovery strategy and look for another tool – or additional tools. This is a very common scenario for those trying to leverage existing discovery tools for software asset management (SAM). If a discovery tool is not designed for SAM, particularly software compliance, most organizations quickly run into limitations (e.g. multi-platform, multi-vendor, complex licensing) resulting in an increase in costs and efforts to achieve their goals – which in turn forces them to revisit their approach and current tools. A common example is when the data center team is looking for a discovery tool and they start using a discovery tool which originated from the distributed side. In many cases, the data center team will eventually expose limitations on key requirements including application dependency mapping and server software discovery. The distributed discovery tool may have these capabilities, but when you dig into them, the effort needed to configure and create the content becomes impractical. - Think strategically, but implement tactically.
Plan for the future now.
With any program (notice I didn’t call this a project, nor a discovery project, because discovery needs span many disciplines), one must balance the needs of today with the future. It is not always easy to confidently anticipate future needs, especially with the velocity of innovation and platforms, but if you continually prioritize and plan your roadmap, you can make more informed decisions on your discovery path including tools, process, people and data. My point here is to put some weight into your future needs when deciding on solutions today. There are many discovery tools in the market with a wide range of capabilities. For example, with my focus on ITSM and ITAM, it is common for organizations to start with more traditional discovery tools which may find most (if not all) devices and at their core are “informational” – providing key information about each device. Then move to the next level, which includes more actionable discovery capabilities including “Client Management” and “End Point Management” tools. These types of tools typically go beyond discovering devices and provide management capabilities (e.g. remote control, software delivery, patch management) for devices ideally across supported platforms. Another common area of focus is the data center, which typically requires more in-depth details on data center devices including their components (e.g. clusters), relationships and services. Application dependency mapping is a common need and capability in this area. - Rationalize and align.
Remove redundancy and align tools, data, teams and process.
Due to the likelihood of multiple tools, groups and processes, one should step back and evaluate the “bigger picture” to expose opportunities to consolidate and simplify across the organization. First, one must understand the capabilities across the discovery tools and the roles they support. This too can expose an opportunity to rationalize and consolidate data and capabilities across solutions. Second, from a data perspective, there is the risk of data duplication, which should drive one towards developing a set of rules/priorities to support data consolidation, avoiding data conflict. This applies to discovery tools which accept other sources, or a CMDB and/or asset repository designed to consolidate data from many sources. And lastly, with the consolidation of tools and data, one exposes the opportunity across the teams (including processes) to remove duplicate efforts to streamline and align teams to work more efficiently.
In Summary
A wide range of discovery tools exist in the market today, which can be a source of confusion for organizations, and typically no single discovery tool can meet the needs across an organization. The rapid rate of innovation will continue to drive the evolution of discovery tools (think cloud, IoT, virtualization, APIs, etc.) requiring organizations to continually assess requirements to align and optimize for your business. This is a journey, not a destination.
As a first step, understanding the origin of a tool can sometimes expose a solutions strengths and limitations. It is essential that organizations evaluate their discovery needs across the company to expose current solutions, redundancies and needs. From this consolidated view, there are 4 basic rules of thumb to consider when building out a consolidated discovery plan: (1) Don’t assume – understand the requirements and be specific; (2) Don’t force the tool to do more than it was designed to do; (3) Plan for the future now; (4) Rationalize and align. Keeping these concepts in mind when building or maturing your discovery solution will increase your chances for success.
For more information on the range of BMC’s discovery capabilities, please refer to:
BMC Remedyforce Agentless Discovery and Client Management
See John’s other blogs on asset and discovery management.
Start Discovering Now
These postings are my own and do not necessarily represent BMC's position, strategies, or opinion.
See an error or have a suggestion? Please let us know by emailing blogs@bmc.com.
