7 Replies Latest reply on Jun 8, 2018 8:40 AM by George Hayward

    How TrueSight should be

    Patrick Mischler
      Share This:

      A lot of us who work with TrueSight are still think that the product goes in the right direction. However, the big "but" hangs in the air. We know all the complaints we have and we know all the complaints the users have we have TrueSight implemented for. We know all the phrases

       

      • Please make this usable!
      • Why is this and this missing?
      • Why untill here and not a step further?
      • Was this tested in a first place?
      • Why can't I see this? Where is the transparency? e.g. agent based thresholds
      • and so on

       

      We all know: complaining is so easy.

      Somtimes it helps, but most times it doesn't really help.

       

      Let us try another approach. Let us describe how TrueSight should be. Maybe this helps more than just complaining.

       

      Ok, where should I start? Let us start at the bottom: the PATROL Agent. How should it be? First, it should be easy to install. Idealy it should leverage the installation mechanisms the operating systems provide. The agent is the starting point. Everything else (KMs, etc.) should be deployable from the TrueSight infrastructure. Obstacles like accounts and passwords should be left out (e.g. like already possible on Windows). There should be simple ways to debug the agent. For example, the PATROL Agent logs should be automaticaly centralized through the existing connectivity or at least it should be possible to fetch them on demand throught the TrueSight UI. Also the creation of a diagnostic report must be possible. I also imagine that there is a at the glance view for the agent which provides all necessary information like versions of agent and KMs, all installed components, the configuration and other runtime information.

       

      Next step: configuration. There should be a structure which allows intheritance. I think, we all have kind of a default configuration. Every further configuration should be only the delta to the default. This should work in every direction. Adding something to the default, removing something from the default and customization of the default. Have I left something out? For specific configuration tasks also a kind of "expert mode" would be helpful. It should be possible to switch in export mode in any configuration and directly modifying the resulting configuration variables. Of course configurations should be exportable and copyable. There has also to be an import function in the UI. Also an advanced tagging functionality should be provided.

       

      Big topic: the TrueSight UI. Right, everything should be possible from a single entry point. Of course it has to be performant. It must be intuitive and as simple as possible. Data like operating system, operating system version, tags, hostnames etc. should be available for creating groups. All graphs should be exportable and it should also be possible to export the data as csv or similar format. The user should have the possible to compare measurements also from multiple devices. The user should be able to leverage highly customizable dashboards and if possible be able to create his own custom dashlets.

       

      What do you think? How should your TrueSight be?

        • 1. Re: How TrueSight should be
          EDOARDO SPELTA

          Hi,

          in my opinion the complaints mentioned are such because they refer to features and scenarios that people expect to find and be tested in the product and that are totally missing or malfunctioning or working in an unexpected way where "unexpected" means that even if something turns out to be working by design, the design maybe needs to be reviewed. Complaining is easy, i agree, but it's often due to frustration. And frustration comes from bad experiences. And bad experiences come from flaws in the design.

           

          "Please make this usable" means that whoever designed it, didn't actually used it or did not get any feedback from somebody who actually used it. The community is here to provide feedbacks but product design shouldn't rely so much on it. Users and customers are not doing UATs !

           

          "Was this tested in a first place?": Nobody expects bug-free products, but a better QA is required. Again, users and customers are not beta-testers.

           

          "Why is this and this missing?": when many people ask this question about the same thing, there's a good chance that somebody forgot something somewhere. From my point of view, we're falling back in the first two cases (make this usable / was this tested)

           

          "Why can't I see this? Where is the transparency?": falls back to "please make this usable"

           

          "Why untill here and not a step further?": if the step further is small, it might as well as fall back to "please make this usable". If it's larger, than the community can give it's feedback and help BMC to focus on a specific direction.

           

          My two cents..

          • 2. Re: How TrueSight should be
            Patrick Mischler

            Hi Edoardo,

             

            Thank your for your input. You mainly focused on the complaining part.

            I was more focused on the "how it should be" part.

             

            Regards,

            Patrick

            • 3. Re: How TrueSight should be
              EDOARDO SPELTA

              That's because all the IDEAs in the community are meant to address the "how it should be" part !!

              • 4. Re: How TrueSight should be
                Patrick Mischler

                Right, the IDEAs. A good approach but in reality they are not much better than dhe old days RFEs. I have opened dozens of IDEAs in the last few years. Only a fraction was implemented or taken under consideration. A lot of them are in "Product team review" for months. You could argue that some of them are not prepared good enough and that might be true. I doupt that BMC can develop a good product only based on the IDEAs in the comunity. What has to be done is field research. Go to the people and talk to them, look them over the shoulder while they are working. And this should not be done by some high flyer product responsibles/managers. It has to be taught to the developers what makes a good and workable product.

                • 5. Re: How TrueSight should be
                  EDOARDO SPELTA

                  I totally agree with you and subscribe every word, however writing in this post what we would like to see in TS would make this post a collection of ideas and we would be back to the beginning. There's plenty of detailed discussions about BPPM/TS in this community, but they accomplish nothing if we (users and such) are the only one involved and if everything that involves a good review of the design is ignored.

                  • 6. Re: How TrueSight should be
                    Bertrand Martin

                    To me, TrueSight should be like BMC Portal used to be, with a few tweaks:

                    • use modern Web technologies (Portal was developed like 12 years ago...)
                    • collect with PATROL Agent+KMs instead of RSM+PMs

                    There was a lot of things that were made right in BMC Portal (for those of you who remember it...):

                    • automated (and managed) upgrade of PMs
                    • deployment of PMs
                    • load balancing of the RSMs
                    • configuration profiles
                    • regex-based thresholds for text parameters
                    • 7. Re: How TrueSight should be
                      George Hayward

                      I'd add a couple of other nice Portal features:

                      - Easy creatable custom PM using OS command, really good on Unix where you could grep/regex the exact figure you wanted.

                      - Regex to filter virtual servers you wanted to monitor.

                       

                      I'd keep the RSMs as well for agentless.