It's true that SCOM in its current version still leaves much to be desired, at least as far as I am concerned.

Having said that, SCOM 2007 it is a big improvement over its previous version, MOM 2005, and that's encouraging for the future. There are a lot of SQL monitoring features that come out-of-the-box, and database blocking is one of them.

So the issue is not that monitoring of database blocking is not available, but that the standard functionality out-of-the-box is not sufficient if one wants detailed information on the blocking event plus the ability to archive the blocking-event info in a table for later analysis.

That's where customization comes in. Arguably, one doesn't need SCOM, or any other monitoring tool for that matter, to monitor blocking and archive the information. This can be done simply through SQL scripting in every single instance that one needs to monitor. But think of the situation where one needs to monitor 50 or 100 SQL instances. Think of the effort involved in deploying the script 100 times (once on every instance), and the effort required to make changes and maintenance on that script during its lifecycle. Or, if one does it in a smarter way, think of the effort required to keep a lookup table, containing info of all SQL instances that need to be monitored, up-to-date so as to use it with a tool like Integration Services to loop through the instances and apply the monitoring script in one go.

With SCOM, discovery of which SQL instances to run monitoring scripts to is simple and is done once; when a new Windows computer is added to the network. As long as the SCOM Agent has been deployed on the managed computer and the Microsoft SQL management packs have been imported, SQL instances installed on a SCOM-managed computer WILL BE MONITORED from then onwards. Of course, as with any tool, SCOM can fail too, and one needs to be proactive and monitor SCOM failures and fix them promptly. There are ways for automating that as well. But the automatic discovery and monitoring of SQL instances and databases by SCOM removes a lot of the manual work involved in making sure SQL scripts run on all instances all the time.

Regarding the effort required to learn how to customize and work with SCOM: it's true that it is a steep learning curve. Having worked it out for a few case scenarios already though, it is now child's play. I have created monitoring scripts for a variety of situations, such as monitoring configurational changes, database-mail failures, backup file sizes, long-running processes etc., and for every new scenario I just take one of my existing scripts and mould it to the new requirements within the day. I have worked with several other monitoring tools, such as IDERA and SQL Sentry, and none that I've seen provide the flexibility SCOM does to mould existing out-of-the-box functionality to fit one's needs quickly and efficiently.

The scalability, maintenability and customization SCOM provides are huge advantages in my opinion.