Untitled Document
Any computer system, whether centralized or distributed, needs governance.
This can take the form of monitoring and systems management, and may be as simple
as ensuring only authorized users have access to services. Or, it may be as
complex as guaranteeing high levels of availability or reliability.
As distributed systems have grown in scope and scalability, spanning multiple
organizations with different infrastructures and trust boundaries, governance
has becomes even more difficult -- and even more important.
Successful governance requires some form of management, monitoring and administration.
SOA governance is the discipline of creating policies that can be communicated
between interested parties as well as enforced, and has aspects within the design-time
and run-time areas of service development and deployment.
Therefore, in order to govern a SOA infrastructure such as an ESB, there needs
to be a framework in place that allows policies and Service Level Agreements
(SLAs) to be defined, enforced and audited across multiple security and identity
domains. Such a framework must be able to define policies for individual services
and then either enforce them or provide means by which they can be managed and
enforced by some other component within SOA.
However, just as SOA is not simply a technology, governance is not something
that has to be implemented by software. Of course it can help, but it's neither
necessary nor sufficient to gain successful governance of your SOA deployments.
In fact, there are certain metrics associated with SOA governance that software
would find difficult or impossible to measure.
So what sorts of metrics should we be interested in monitoring? There are the
usual candidates such as response time, reliability and performance, but successful
SOA is driven by business requirements, which include:
- Return on investment (ROI) per service: A common theme in any technology
deployment measurement, ROI can be difficult to measure for SOA. For example,
if the developers working on the service split their time across a number
of other services implementations, it becomes hard to track the time and money
spent on each service. However, ROI is critical for obvious reasons. If you
spend more money developing the service than it helps generate, then maybe
you need to look at your overall strategy, including development and implementation
processes. Of course some loss leaders are always necessary, but they should
be the exception to the rule. What further complicates this metric is that
some services may only perform a business task in conjunction with others,
such that the ROI for a service should actually be measured across the composition.
Note that when measuring ROI in relation to SOA, it does not necessarily mean
that a specific service must generate revenue.
1
Print this article
Email this article
Talk Back!
Write to Editor
