Business vs Service Level Agreements

[objectiser]

Hi

While reviewing the project in light of the BAM rename, we also considered the relationship between Overlord and more traditional management capabilities, such as RHQ, to identify where one solution may be more appropriate than the other. The answer we came up with was Business Level Agreements vs Service Level Agreements.

Service Level Agreements:

These tend to refer to metrics associated with a particular service, with the agreement specifying performance and availability criteria. The data is independent of the business transactions that have been performed using the service.

This is a perfect example of where a traditional management product should be used, as the SLAs can be evaluated against summary information collected from the service.

Business Level Agreements:

Business level agreements  relate to specific criteria associated with individual end-users or organizations. The policy enforcement example, distributed with the project, could be viewed as such an agreement, where a business user must not exceed their credit limit, otherwise they will be prevented from purchasing any more items. Another such example could be based on throttling, where a particular user can only perform a certain number of requests within a specified time limit.

So where the agreement requires stateful information to be maintained on behalf of the particular user, then the Overlord runtime governance capabilities may be more appropriate.

However in cases where a management capability is not available to monitor SLAs, the Overlord runtime governance capabilities could also be used for assessing service performance - however there is higher overhead for using Overlord for this functionality, and it may not be possible to assess service availability (unless the information is provided by a separate source).

Regards

Gary

[burmanm]

Hi,

While somewhat old thread, I beg to disagree. SLAs might very well include situations where business transactions are part of it. In integrations / message delivery business (be it SWIFT messages, EDI messages, invoices, orders etc) the basics of SLA are usually built on certain assumptions:

  - All messages that have been sent, are processed within a certain timeframe (this could be something like 30 mins to 24 hours).

  - No messages should be lost

This means one needs to create a single environment to monitor everything, both the business transactions (to verify that everything we've received has been processed and something hasn't got stuck to some service, because of deadlock or other event), and that the services are up. Traditional monitoring of API-speed could very well be quite irrelevant (these messages are often sent through old-fashioned-gateways, such as SFTP/FTP servers) as it's not interesting to any party. In these cases having just one monitoring tool would be quite important. Sending events from the BAM to the RHQ is quite "must-have" feature in my opinion. RHQ can already read Events, so I don't see any technical limitation from the RHQ's part, it's just that someone has to create that integration layer (RHQ plugin, or BAM sending events to RHQ).

[objectiser]

I don't believe the original post was stating these requirements could be provided by a single environment, just that there was a different focus, and that the first (i.e. SLA) could be achieved using a more traditional management system approach.

However the scenario you mention can be handled in one environment, using rtgov to monitor the business level requirements and report any issues to a management system via JMX - and then have that management system also monitor the availability of those services.