Skip navigation

IDE for Patterns (and Other Ideas)

score 55
You have not voted. Not Planned

BMC Discovery (ADDM) is a great product.  There are still a number of Opportunities for improvement that that would allow me to freely give it 5/5 stars.

 

My Top List of Opportunities (Currently)

 

1) No IDE.  The key to development productivity, is the speed of failure.  If you have to iterate 30 times before getting a piece of code to run - there is a huge difference between 10 second re-execution time and 2 minute re-execution time.  It is probably unrealistic to expect BMC to write an IDE for TPL.  However what about allowing Python code to be embedded in TPL?  If a Python API is maintained and published, over time all TPL could be migrated to Python.  I don't know if this is feasible - but I suspect that many of the building blocks are already there?   Yes? No?  If we were allowed to use Python, then there are many free Python IDEs (such as pyCharm) that we could use (or install on the appliance) in order to test our code.

 

2) Script Errors and deciphering them.  Discovery failures (Script Failures) should only be created if they really is something that an Administrator needs to look at.  At the moment, the volume of failures is in the thousands or tens of thousands; they are not useful!  I still find it incredible that ADDM still just throws away stderr.  It makes it much harder to debug UNIX failures.  Also, it would also be great if Customers could interpret Support zip files (this would take a load of BMC Support)  I have looked at many zip files - but they are really hard to navigate.

 

3)  Duplicate Hosts.  Discovery has got to be accurate.  Duplicate hosts is a problem for all downstream CMDBs.  Just look at the number of posts on this community associate with "Duplicate Hosts".  This is big.

 

4) Ease of Administration.  Clusters was a big step forward  - but there is still so much that could be done.  For example:  For large customers, managing (a) subnets and (b) scanning schedules, (c) firewall rules; (d) which scanner to use - is a big task.  I suggested a Proxy for UNIX before.  Imagine if you just had one Cluster in the corporate zone and them Proxies in all the perimeters.  You then just added a huge big list of subnets to the Cluster.  The Cluster then automatically worked out which proxy to use based on initial nMap result and lowest latency and then just automatically redistributed the list of subnets and created discovery schedules  This would make Discovery so much easier to manage.  OK This is not a reality now - but in 10 years - all discovery products will have this type of automation (or something similar).  This is just one idea - to make Administration easier.  I bet the BMC Developers have dozens of others.

Comments

Vote history