Here's another useful metric when reporting on how your SOA initiative is progressing.
Tracking how services are leveraged across each organizational unit and rolling that information up to the enterprise level provides the enterprise adoption rate. This metric indicates how pervasive the use of services is across an enterprise. However, this metric is not necessarily easy to quantify. For example, given an enterprise that comprises five organizational units, if only two of the units are leveraging services, is the adoption rate of our enterprise at 40 percent? What if 80 percent of the total IT spend is within these two organizational units? Is the adoption rate of our enterprise now at 80 percent?
A more accurate and measurable approach for reporting the enterprise adoption rate begins with a catalog of IT resources that span the enterprise. After determining how many of the applications within the catalog are actually leveraging services, determine the total number of applications that are candidates for an SOA implementation or integration. The product of this review (applications using services/total candidate applications for leveraging services) is a realistic enterprise adoption rate.
If the data is available, integrating this metric with actual IT spend provides the weighted enterprise adoption rate, which is an even more compelling value-based metric.
I also bring this out in the September 2009 edition of Microsoft's The Enterprise Journal (http://msdn.microsoft.com/en-us/architecture/aa699435.aspx)
Wednesday, August 12, 2009
Tuesday, August 11, 2009
SOA Metric: Consumer-to-Service Ratio
The next time you're asked to provide insight into how your SOA initiative is moving along, try using the Consumer-to-Service ratio.
This is a useful metric to track primarily because each reuse averts the costs of developing, operating, and maintaining a new single-purpose service. The idea is that as the number of consumers increases for a service, the return on the costs—both initial and ongoing—that is attributed to that service increases.
However, use caution when you report this metric. As the number of consumers increases for a service, the reliance on that service increases, which exposes the enterprise to an increased consequence of failure. Because scalability is the result of design, implementation, and infrastructure choices and investments, as more consumers begin to employ and rely on a service, the workload of that service increases and could potentially move beyond the limits that the service was expecting—thus, increasing the likelihood of failure. Finally, with consumers converging into a single point, the ability of a service to mature over time becomes increasingly more challenging and costly, as any change to the service requires an increased investment in impact analysis, regression testing, and coordination across the enterprise.
I also bring this out in the September 2009 edition of Microsoft's The Enterprise Journal (http://msdn.microsoft.com/en-us/architecture/aa699435.aspx)
This is a useful metric to track primarily because each reuse averts the costs of developing, operating, and maintaining a new single-purpose service. The idea is that as the number of consumers increases for a service, the return on the costs—both initial and ongoing—that is attributed to that service increases.
However, use caution when you report this metric. As the number of consumers increases for a service, the reliance on that service increases, which exposes the enterprise to an increased consequence of failure. Because scalability is the result of design, implementation, and infrastructure choices and investments, as more consumers begin to employ and rely on a service, the workload of that service increases and could potentially move beyond the limits that the service was expecting—thus, increasing the likelihood of failure. Finally, with consumers converging into a single point, the ability of a service to mature over time becomes increasingly more challenging and costly, as any change to the service requires an increased investment in impact analysis, regression testing, and coordination across the enterprise.
I also bring this out in the September 2009 edition of Microsoft's The Enterprise Journal (http://msdn.microsoft.com/en-us/architecture/aa699435.aspx)
Subscribe to:
Posts (Atom)
