Concerned partner, or intrusive tool vendor? Tell me.

This week I have been involved in a series of discussions about the upgrade of the Jazz products from their 2.x versions to the 3.x versions.  As we discussed some of the challenges that our customers have faced, and the impact that an improved upgrade process would have, we were at a loss for being able to assess the impact to ALL of our customers.  We know the customers that we have sold products to, but we don’t know how big their Jazz repositories are, we don’t know how many licenses have been deployed,  and we don’t know how the products have been deployed.  So we began to discuss how to best find out some basic information from our customers.  People began to discuss how we should best ask our customers for this information.

After a few minutes of discussion, it occurred to me that we were thinking about this all wrong.  Why should we constantly be calling our customers and asking them about their Jazz deployments?  The Jazz servers capture a number of statistics about themselves and the repositories that hold their artifacts.  You can see these in the administrative reports available on your Jazz servers.  If we could somehow harvest this information from our customers who have deployed the Jazz solution, then we would be able to be more proactive about the advice and guidance that we give our customers.

My idea is to have a small task that runs each time the data warehouse jobs run (typically nightly).  With each run, a small email is written which contains some basic high level information, which then gets sent back to the Jazz team.  The email is in plain text, so customers can easily monitor (and scan) the information that is being sent out.  Each server would have a switch where they could configure if the emails are sent out at all (so customers could elect not to participate), and a setting to configure where the email is sent (for those customers that want to review the contents of the email before forwarding to the Jazz team).  The basic information to collect would be the following:

  • License usage – average, and peak for each license type
  • Repository sizes
  • Number of application servers, type, and locations (ie. a customer may have one JTS, one RTC, and two RQM applications, in different data centers, deployed)
  • Type of application server used (Tomcat or WAS), and type of database used (DB2, Oracle, SQL Server)
  • Basic REST response times (as a rough measure of performance)
  • Potentially a series of simple performance metrics

I would then propose that we make this information readily available on, with customer names obscured, so our customers would be able to see what other Jazz deployments look like.  Are there other customers using the full set of CLM tools?  How many other customers are using two RTC applications sharing the same JTS?  Are our repositories considered large?  In addition, we would be able to monitor customer situations and offer predictive help.  We might also find that customers using the full set of CLM tools have RTC repositories that grow at an average rate of 20% per year, while stand alone RTC repositories only grow at a rate of 15% per year.

So now I have a question for the people who read this blog.  Does this seem like a good idea for you and your organization?  Does this seem like a vendor that is looking to work with it’s customers to monitor it’s deployed products to improve them, or an intrusive vendor seeking to grab and gather information for their own use?  Would you turn on this capability?  Would you find value in seeing these metrics on  Are there things that I should include in my list of collected data?  Things I should take out?

I am looking for feedback on this idea.  If I get enough support for this, I will try to promote it so that it is included in a future version of the Jazz products.  So don’t be shy – let me know what you think.


5 thoughts on “Concerned partner, or intrusive tool vendor? Tell me.

  1. John Kohl

    I work on another product that has little insight into which platforms our customers actually use. I like the idea, but I recommend treading very carefully, in order to retain the trust of customers.
    I’d default the reports to “off”, have a question during the installation process (a new Installation Manager panel, perhaps, for the server bits) asking if the customer wants to opt-in to reporting anonymized usage data.
    And then proceed to a configuration panel with IBM reporting addresses as default locations, editable for the customer to choose their own internal addresses in place of IBM.

    Plenty of end-user products ask for similar permission, this is a little bit more to ask because it’s not a single end user but an organization’s use that would be summarized.

    1. Gregory Tasonis

      Tox, I like it. Most customers are loathe to hear from vendors as they think it’s just a disguised sales pitch. This is a great way to add value.

    1. dtoczala

      Ben, I would love to just have a random sampling of customer deployed technologies. It would give me a better feel for the technologies out there that our customer base really depends upon, and would help us to influence the standard topology’s ( moving forward.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.