This is why we build VordelReporter. By sourcing its information from Vordel Gateways, it allows administrators to see in real-time who is using services. They can drill into individual gateways in order to see the usage and performance of services which are in that Gateway's sphere of control.
Using Gateways for SOA visibility is non-invasive, requiring no changes to the services themselves. By using the information from a product which is already deployed, the XML Gateway, it removes the danger of creating a new, standalone "SOA Governance silo".
You can do neat things like discover if a service is not performing to its SLA, and then take remedial action by offloading its XML processing on the Vordel Gateway where it benefits from XML Acceleration. Then you can see in real-time how the service response time increases. So you're actually solving a problem, using products which also perform other functions (acceleration, protocol mediation, content inspection) rather than just putting a "governance silo" in place for its own sake. With Gateways, if you discover that a service is running slowly, you an solve the problem by offloading processing onto the Gateway. With a standalone "SOA Governance silo", you can discover that a service is running slowly, but that is that.
Here's a short video showing the drill-down from a SOA topology, to a Gateway, to individual service invocations:
Paradoxically, one great feature of VordelReporter is that you don't even have to view its reports. How is that possible? The answer is that because VordelReporters real-time monitoring sources data from Vordel Gateways via a secured REST-ful pipe (here we are eating our own dogfood), can also simply send the metrics to products such as Oracle Enterprise Manager. This also helps SOA visibility, and is another example of using existing infrastructure rather than creating a "SOA Governance silo".
Tony Baer put it well back in January:
"...we also believe that the run-time governance of SOA or services cannot be divorced from the physical aspects of running IT infrastructure. Service level management of SOA services is directly impacted by how effectively IT delivers business services, which is the discipline of IT Service Management (ITSM). When there is a problem with publishing a service, it should become an incident that is managed, not within its own SOA cocoon, but as an IT service event that might involve problems with software or infrastructure."
http://www.sandhill.com/opinion/daily_blog.php?id=1&post=488
More on VordelReporter here
