Middleware-SOA-SLA-relationship

Figure 6 SOA and SLA

Middleware-SOA-SLA-relationship

We discussed in last chapter about relationship between EA and middleware. In the following chapter, I would like to present you an arrangement regarding relationships between Service Level Agreements (SLA) and middleware. Therefore, I try to define common and different scope and activities between SOA and SLA. Furthermore, we need to achieve a common reference architecture and Terminology, in order to help for establishing common understanding on SLA & middleware, and also SOA. It’s necessary for an enterprise framework to avoid inefficiencies as a result of duplicated working on same areas.

SOA: Business Perspective

As mentioned, we can define SOA from business-, architecture-, and implementation-perspectives. The relationship between SOA and SLA could be represented from business perspective. SOA, as software for cooperation and change, is a set of activities that a business wants to expose to its customers and partners or other portions of the organization. Business perspective can be demonstrated with process model (see figure 1 SOA and SLA).

SLA

We can find in Wikipedia following description:

“A service level agreement is a negotiated agreement between two parties wherein one is the customer and the other is the service provider. This can be a legally binding formal or an informal "contract" (for example, internal department relationships). Contracts between the service provider and other third parties are often (incorrectly) called SLAs — because the level of service has been set by the (principal) customer, there can be no "agreement" between third parties; these agreements are simply a "contract." Operating Level Agreements or OLAs, however, may be used by internal groups to support SLAs.”[i]

Simple to say, SLAs are protected agreed upon at the interface with the service consumer. It can be intern (Operational Level Agreement - OLA) or extern (SLA).

Relationship between SLA & SOA

Figure 1 shows SOA and SLA position in middle of software tiers. SOA separates business logic (IT) and Process & Rules (business activities). The Criteria for SLA are for example:

• response time/ transaction time
• rejected transaction counts
• maximum number of simultaneous access
• GUI, etc.

In additional, it is possible to define the intra-relationships between (internal) groups/departments with OLAs (operating level agreements) in an enterprise. The objective of the OLA is defining clear responsibilities for the service provider's internal support relationships. This will allow management and teams to a standardized arrangement for their cooperation. If cooperation between SOA and SLA is well-defined, then we can talk about a manageable SOA!

See: Figure 6 SOA and SLA