So, to help you take your decision, I prepared the table below. Please keep in mind that it is not my intention to say which one is better (I have my personal opinion though), but only to show what are the differences (and common) points between them and let you take your own decision.
| Item | IBM TNPM | SevOne |
|---|---|---|
| Architecture | 5 specialized core components:
|
1 core component:
|
| Installation | Very complex. Can take a long time (days to weeks) | Very simple. Appliance or VM based. It is a matter of hours to install and start using |
| Upgrade | Very complex. Can take a long time (days to weeks) | Simple. Press the update button and it is done (complex architectures may demand some special care) |
| Scalability | Via hardware upgrade on each core component | Via cluster. Add another appliance side by side in cluster mode |
| SNMP collection | Using collection formulas. Can be easily customized | Using certified collection formulas. Usually needs SevOne intervention |
| BULK collection | Using PVLINE (proprietary) format | Using xStats component |
| Component Discovery | Using discovery formulas. Can be easily customized and allow custom properties | Not flexible. SevOne always discovers everything it can using SNMP walk. Allow custom properties |
| Component enrichment | Using inventory hooks | Using API |
| Licensing | Based on “class of devices” being monitored. Very complex | Per discovered and enabled object |
| Technical Portal | WebSphere based. Allow some flexibility and customization | Cannot be customized or changed |
| Services Portal | Supported | Not supported. Another solution needs to be used |
| Multi-tenancy | Supported | Supported |
| Reports | Cannot be created by the user | Can be created and shared by the user |
| Backup | Database backup | Not existent. To avoid data loss, another appliance needs to be paired in high availability |
| Cross collection | Supported, but complex | Supported |
| Grouping components (service like measurements) | Supported, but complex. Can use rules to group components | Supported but each component needs to be maintained manually or via the API |
| Historical data | Limited by the database storage size. Purge scripts can be used. | Usually limited to 1 year. This can be changed, but it is highly dependent on the local storage available on each appliance |
| Authentication | LDAP or local | LDAP, RADIUS, TACACS |
| Authorization | Based on roles | Based on roles |
| Data volume | Report generation and data processing are subject to speed degradation as the data volume increases | Report generation and data processing are NOT subject to speed degradation as the data volume increases |
| Data aggregation | Pre-calculated and aggregated before stored in the database. Stored raw data and aggregated data side by side | Only raw data is stored. Aggregated data is calculated during report rendering |
| Data export | Can be done using DataAccess component | Not trivial. API allows export of reports in CSV format, but not built for huge data export |
