I think your question is quite generic, and we could spend hours trying to provide you with a proper answer.
Microsoft has decided to base the OS backups in VSS (snapshot), however, the snapshots will be using specific writer, depending on the data you would like to save.
Basically what I mean with this is that by default, the snapshots created by VSS by itself, will be only drive based and not application based backups.
If you take a snapshot of the F:\ drive, were you have the Exchange DB's (for example), this snapshot is not application aware, so I don't think this solution would be consistent 100%.
I would say it is always recommended/needed an external application to request, create and manage the snapshot, specially if you want to backup any particular application.
Hope that helps.
Does a Snapshot have the ability in itself to protect the data or does it have to be integrated with availble backups like networker is using now?
What sort of snapshot are we talking about here? VSS, VM, storage array based snapshot...?
VM snapshot is done by VMWare. As such, alone, they are good for OS, but not quite for databases. Backup applications in most cases will use integration with VADP these days to perform these. There is also certain level of integration with VSS snapshot framework as of ESX 4.1. As virtual machines within Vmware are mostly used for application servers and not database servers these snapshots are good fit in majority of cases.
Disk array snapshot are performed within storage subsystem and usually they may or many not be integrated with OS or application level using it (eg. VmWare, Oracle database, etc). Their integration with application/OS layer manages freeze on IO while snapshot is made and these are usually instant operations.
There is nothing wrong using both approaches nor single one - it entirely depends on design within your organizations and goals you are trying to achieve. Both approaches can be integrated with NetWorker (in case of disk storage arrays requirement is to use EMC's disk arrays).