Assessing Demarcation Points
Having established the profile of the application, its path through the network, and the pattern it leaves behind, you can start to assign demarcation points for monitoring performance. These fall where the responsibilities of the customer and IT service provider (in-house or outsourced) start and stop.
Where you draw the lines depends on the following:
Business arrangement (such as outsourcer or internal service provider)
Application-delivery requirements
In an ideal world, no demarcation lines would exist. Application support would be delivered on an end-to-end basis, with the application treated as a whole, and a single entity would be responsible for every aspect of the delivery process, from the server through the network and subsequently on to the client and the desktop.
In the majority of cases, this is not achievable, because many different skill sets are involved in each step of the delivery process, and this may not be the most optimum method from a business perspective.
Figure 7-1 illustrates a simple network scenario, including a WAN, access circuits, and LAN equipment and services. From this schematic, you can start to set demarcation points for network responsibility.
Figure 7-1 shows an example of defining boundaries for the measurement of application delivery, making it possible to develop a clear set of procedures for performance deterioration.
The demarcation point represented by the inner circle (circle number 1) is that of the traditional telecommunication services, where responsibility ends at the edge of the network just as it enters the customer tail (access) service.
This demarcation point is useful from a carrier perspective, but has little relevance for end users, because they just see the network as a transmissions path.
In circle number 2, the telecommunication's responsibility has been taken a little further to cover all aspects of the WAN delivery up to the point of delivery at the customer premises.
Circle number 3 expands the responsibility and covers the point at which the LAN interface is presented to the customer site.
Finally, circle number 4 covers the client/server LAN area, concentrating on the delivery to the relevant hosts.
Figure 7-1 A Simple Example of Demarcation Points
Each of these areas can be delivered as either an individual or a combination approach to the delivery model. For example, you may want to just purchase a link from a carrier. In that scenario, you simply apply the demarcation point at the end of the link, define metric collection at that point, and effectively monitor and report on your application delivery relevant to that endpoint. (For details, see Chapter 8, "Monitoring the Delivery.")
You may then want to assign more of the responsibilities to different departments within your own organization. For example, the network delivery team assumes responsibility for the delivery mechanism from where they pick up delivery from the carrier, to the point at which it is delivered to the interface of the internal switch. Responsibility then moves to the LAN or server administrators.
For example, Acme Electronics is an electronics retail firm, and they have recently moved to sell their goods online (in addition to their traditional storefront operations). Their business objectives are straightforward. They intend to migrate 80 percent of their sales revenue from their retail outlets to the web-based offering. In addition, they want to ensure that each customer will have to wait no longer than 8 seconds for online confirmation of an order.
Acme's network has recently been outsourced, and at the time they moved to the web service, they had a network carrier providing connection between their web server and the warehouse database system.
Acme's responsibilities include the web server, warehouse database system, associated LAN systems, and connection to the Internet. The carrier's responsibility includes the carriage of data between the web server and the warehouse database system.
After you have defined these areas of responsibility, you can start to assign equipment within each of these areas to the responsible parties. You may break an area down to whole equipment (such as a router or switch) or down to a specific interface. This demarcation is sometimes made easier by understanding who owns the equipment. In an outsourced agreement, for example, all network infrastructure may be supplied by the outsource company; therefore, demarcation points for that path or process clearly reside where the outsource equipment meets the customer equipment. It should be added that, in these scenarios, the cabling is quite often overlooked and can cause a contention if the fault is found to reside between the customer and outsourced equipment. Therefore, any agreement should clearly state cabling and interface conditions.
From Acme's perspective, this can be further defined, with the server administrators taking responsibility for the web server and database server (including software and hardware) and the network engineers taking responsibility for the LAN components of the network.
By taking your profile and reference point, and then matching it to your demarcation point, you are in a position to write the service level agreement (SLA), bearing in mind three basic rules:
Keep it simpleIf it is too complex, the SLA will never be agreed to or implemented.
Stick to businessIt is no good having a perfect SLA unrelated to the actual business objective.
Minimize overheadYou are in business to make money, not administer an SLA.
When defining demarcation points, consider aligning with metric collection locations. This will be dealt with more in the "Defining Metrics" section of Chapter 8, but the concept should be considered at this point. The theory is as follows. A demarcation point is a strategic connection point in the conversation transmission. By observing specific conditions (metrics) at this point, you can gain a quick and inductive view of the application's performance. In a sense, you are looking for these demarcation points to become the natural aggregators of an application's performance issues.
One of Acme's business objectives is to have no user waiting for more than 4 seconds to receive confirmation of an order. For the order to be confirmed, the web server must receive notification from the warehouse database that the product is in stock. So in Acme's network, a strategic connection point is the warehouse-facing network connection on the web server. From here they can track the request from the web server to the warehouse database, and the response from the warehouse server to the web server.