Part 2: Have We Missed The UCMDB But For The Probe?
In Part 1 we shared with you our astounding results regarding the tuning of the HPE UCMDB Data Flow Probe MySQL database (or, as we refer to it, “the Probe”). In short, with some strategic tuning, sync times were improved by an average of nearly 1000%, while greatly improving Probe survivability and reliability (for all HPE UCMDB users not yet on version 10.10).
In Part 2 we will be discussing the history leading up to this breakthrough, and some of the reasons why issues with the Probe may not have not been addressed until now.
It is our belief at Effectual that the Probe’s lack of performance and reliability has done more harm to capability and goodwill to UCMDB as a product than any other single contributing element. It has confused the real capabilities of HPE UCMDB with the unintentional limitations of the Probe. The unfortunate result of this misconception has been a generation of customer projects that have cut important value propositions short, and has created unwarranted skepticism towards integrating HPE UCMDB to other systems.
We believe in HPE UCMDB
If we had tried to keep these findings to ourselves, tried to sell this as a package solution, many of you would never see any benefits. And we think that’s just wasteful. Besides, we’d rather take the time to introduce you to Effectual: how awesome our solutions are, how excited we are for the future of HPE Software, and how we can help your organization in ways no one else can.
We are excited about our architecture, so we share it. We are excited about this probe breakthrough (and the Effectual Probe Tuning Package), so we share it. We’re committed to HPE products, that’s why our CEO posted a a comprehensive mechanical primer to the Probe issue on the HPE Support forum.
Our Packaged Enhancement Integrations (PIE) customers are the biggest winners from these improvements. But we are singularly committed to seeing HPE and every single HPE ITOM Service Management Software customer succeed in a better business outcome, even if they are not customers at Effectual. We firmly believe that HPE Software (and UCMDB in particular) is the lynchpin to the successful financial IT operations management transformation that is made possible with the “New Style of IT”. That’s why we’re not holding this back for our sales efforts, why we’re publishing and sharing everything we can.
Why is this problem just being addressed now?
The plainest answer is: We got to it as fast as we could! Effectual is a young company (we’re 3 years old as of June 2014), founded by former independent management consultants that focused on Mercury and HPE Software best practices. It has taken us a great deal of time, effort, and money to hire and train staff, architect, develop, and sell the vision we have for HPE Software, and then to actually implement production environments at fast, leading edge companies.
This Probe issue could have been uncovered at any point in the past 14 years: by Appilog, Mercury Interactive, HPE, or any of their consulting partners. But it wasn’t. Everyone has always understood that the Probe was a weak point in the UCMDB application, just never exactly how weak. Or that the problems were largely avoidable.
The work-around has always been to wipe out the Probe data out and start over again. This ineffectual fix has usually had to be applied every single day, across many Probes. This put a huge strain on the Probe and UCMDB, creating a process bottleneck, slowing down the entire system.
Up until now, poor performance of UCMDB has been a foregone conclusion, which has significantly limited customer adoption. The scope of the actual problem just couldn’t be clearly understood, much less completely solved, without the confluence of capable resources and combination of skills needed to align with the right size and type of production data sets. Without the alignment of these crucial elements, even disciplined testing would have been inconclusive or misleading. We are incredibly fortunate to have wonderful customers who have a mutual agenda for success in these endeavors.
Why didn’t HPE solve this problem?
Our opinion is that, as the vendor, HPE’s focus is on how their product might be used, but not fully on how it is used. This issue is compounded by the fact that there has never been any one way to use these tools. R&D just can’t build 1500 different versions for 1500 different use cases. There are simply too many moving parts of the tool, too many different ways customers use the UCMDB.
The fairest answer for HPE is that they have already identified the Probe as an issue in need of improvement. In UCMDB/UD 10.10 they have provided a different database engine for the Probe. This very well might end up being a good solution to this problem. However, existing customers that are suffering serious pain with MySQL-based Probes may not upgrade to 10.10 for a very long time. The irony is that the frustration customers feel with the MySQL Probe is so great that many of them will significantly delay upgrade because of that very frustration.
By necessity, HPE is focused on building features and capabilities. Since HPE’s [then HP] acquisition of Mercury, UCMDB has received a great deal of investment and improvement. In fact, the version 10.x History changes alone finally make a real Configuration Management System possible.
HPE is faced with the normal challenges of innovating in one of the world’s largest companies: a huge volume of customers each product team has to deal with, huge demands on time and funding priorities. Given these factors, potential risks, changes or new directions become incredibly complicated. Frankly, we doubt we could do better if roles were reversed. As we understand it, the HPE UCMDB and product teams are always strained.
This understanding of limitations informs the way Effectual develops our solutions and how we implement them. We make use of as much current technology as possible, and revise and upgrade customers universally as our process improves. But since elements that are likely to change are out of our control, we deliver our solutions with as little dependency on those elements as possible. Our adapters replace out-of-the-box, but do not deviate or lock customers into a particular use case or set of features.
The UCMDB and integration capabilities are really very amazing when used in a way that is possible – not the way any one person wants it to. For example, we have one PIE customer who has already shown they can upgrade different parts of their tool suite. We’ve integrated their UCMDB, ITAM, and ITSM, even their third party information provider tools, without any part of our CMS operations breaking when one part is upgraded or customized.
We don’t have a single HPE bug report open, since we have always been able to find a working solution that accomplishes the desired business outcome. With HPE’s existing technology, there is always a way. It’s a textbook case of why HPE can and should rely on partners like Effectual.
So no, HPE didn’t find this solution. But we contend that without being deeply involved with a customer over a length of time, without Effectual’s approach to high-performance integrations, without our real world data and all its wonderful ITIL relationships and value, significant testing and tuning just isn’t possible.
So why Effectual?
The short answer is because we could. We have the experience. Since we have very large customers actually using our PIE Solutions in production, Effectual is in the singular position to be the authority on high performing integrations and reliability. We were the only ones with the sample size necessary to run real testing, to get real results, to have a wide enough set of environments to be certain.
Effectual builds PIE based on UCMDB, ITAM, ITSM, and third party tools and data sources in order to help their customers pursue Service and Asset Configuration Management (SACM) business outcomes. This approach makes use of Data Flow Probes, enhanced adapters, and TQL to move data as quickly as possible through multiple-tiers of UCMDBs (as well as a number of non-UCMDB applications and data sources).
We design and implement solutions to be consistent across every HPE customer, so that once implemented they can be supportable by HPE and by the customer. We believe in scalability and efficiency. We don’t make brittle, “one-off” solutions. Since we don’t use federation (it’s wasteful), your data maps from one system into another. Our integrations keep the data synchronized behind the scenes, so it’s there when you need it. That’s why the increased performance of our Probe tuning is such a game changer.
Regarding the Probe itself, Effectual’s CMS mission requires that data from one end of their PIE framework (say Service Manager) needs to pass data (such as RFCs, Tasks, and Incidents or changes to Service Catalogs or Models) into (and out of) the UCMDB as frequently and quickly as possible. We had already solved writing, performance, and normalization issues by using highly tuned TQLs, multiple tiers of UCMDB, and different sets of reconciliation rules.
But Probes remained a foregone scalability problem. At some point, when a multi-UCMDB CMS reached 20 or 25 million CIs in size, the historically slow and unreliable behavior of the Probe would slow the system unacceptably. It would overcomplicate the architecture, confounding our efforts to keep real-time synchronization possible.
This problem obviously affects single-UCMDB customers more severely, with much smaller data sets, at a much lower threshold with only a single writer of bandwidth. One UCMDB customer we spoke with had data that was an entire year behind. Their probe processes had reached such gridlock that their data was completely out of date, without their knowing it. So…
We didn’t wait for this to happen.
Until now, poor Probe performance was just an ongoing problem that everyone simply took for granted. But we saw the problem, and realized we were in the unique position to solve it. And we did.
What if we’ve been wrongly blaming the UCMDB for the limitations of the poorly configured Probe? After years of facing this unintended behavior from the Probe, what if we had the wrong impression of the capabilities of HPE UCMDB all along? Now that the Probe is fixed, what if HPE UCMDB can actually scale to handle much more complex business needs than we’ve imagined possible?
We think this merits a conversation.