SevOne and TNPM. A technical comparison.

Some people have asked me about SevOne and how does it compare to TNPM. Some even ask if they should migrate from TNPM to SevOne. My answer is...it depends.

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: Database DataMart DataView DataChannel DataLoad	1 core component: SevOne appliance
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