Most of our troubles center on the role of Services in Sonar. I can see the reasoning for it to date, but they are just so thin at present: not holding inventory, IPs, locations, notes, speeds, quantities, custom fields, or really any kind of rich data at all.
The first major hurdle is the reliance on an account to give location, IP, and traffic data to a service. We have over two hundred services sharing at least one other data service on the account, almost always at a different location. I understand how this can be overcome by all of those accounts being shattered into children, but given that (as far as i can see) each location would also need to have and manage it’s own client area login / contact email for ticket management and self service, and any notes or ancillary data do not roll up or otherwise get aggregated, that starts to look less and less viable.
The second and much harder hurdle is in the lack of any kind of quantity billing. For example, we bill voip customers based on number of seats of various kinds, and I cannot see any way to make that change reliably given that services don’t contain quantities or costs per unit. Conceivably we could add or remove whole services that were each one seat, or maintain all of the pricing logic in some 3rd system that overwrote both the price and the item name every month with the updates, but neither of those seem like quality options. We have a variety of services that are much easier to handle by scaling up or down the standard per/unit rate, and at present we would either need to make a unique service for every variation, or again abandon Sonar having any real knowledge of our pricing and just writing it in from outside. (That is without touching on upload and download speed quantity pricing, which I can understand is a much more complicated question from a provisioning standpoint.)
Lastly, there is no concept of a customer’s “Order” for new services or even the start date of a service, outside of its billing. I can see how to manage a sales process using the Lead status and similar, but as soon as you want to add services to an existing account, or even sell multiple services that will be delivered on different dates, it totally breaks down. Best I can see would be taking the sales funnel “offline” and tracking pending services separately, before entering them into the system only on turn-up, but that destroys much of the value of the unified system with contracting built in.
In a different vein, the combo of monthly-only billing and paid/unpaid as an account-level not service level concept means I cannot see any way to manage domain registration and renewals out of Sonar, of which we have several hundred currently. (through ENOM)
(other significant but more minor issues exist as well, like lack of custom fields on services means we cannot authoritatively translate old system services to new system services, as there is no good place to store that data, and total ambiguity over device/ip/service relationship, for a customer with a CPE and two on-site PtP radios that we manage.)
You’ve got a really nice thing going with the ICMP and SNMP poller, logging, triggering, and schedules, but there are three essential (albeit difficult) components missing: Map Status display, dependency trees, and root-cause analysis in alerting.
Mapped status -
We still use and are forced to maintain The Dude simply because almost nothing else gives you such an effective status “christmas tree”. It sounds like your upcoming additions to the “Map” display may solve this problem though, depending on the details.
Dependency Trees -
If monitoring has no concept of “failure by device” vs “Failure Upstream”, any view you look at will be a haystack of red, with the one important needle tossed in the mix. On-tower and CPE-AP dependencies are definitely nice, but tower-to-tower dependencies are pretty much essential. “Problem at Location C - 85 services affected” is way more useful than “125 devices currently offline”
Root Cause Analysis -
This goes pretty deep, but at the most basic is simply making use of the dependency data, to whatever granularity it exists, to at least show the closest-to-root problems and hide issues that that are child results. At the best case, a warning level ICMP (etc.) result on a CPE triggers a retest of the parents back to root, looking for the point of greatest quality drop, raising that to alerting while suppressing downstream issues it likely caused. We’ve done some work on this in house that I’d be happy to share if it seems useful.
Hopefully that’s useful detail,