An important aspect of performance (and other) monitoring is where the observer stands when looking at the IT scenario. Each participant has a different view of what is bad performance - network, database, web, system, user personnel, management and external people - customers, regulatory bodies etc. These are what I call viewpoints, a popular concept in IT architecture design methods.
Start with APM and Viewpoints - Part 1
Operations Viewpoint
Operations people, but not the business user and others, will be desperately interested in:
■ % Utilizations
■ Wait times
■ Disk space used
■ Disk I/O Throughput
■ Disk I/O response time
■ Memory % used
■ Page rate
■ etc. etc.
End User Viewpoint
The previous factors are meaningless to the user of the application, who is more interested in:
■ Response times ( which depends on overall latency, percentiles, variations but they are not interested in that detail)
■ Variability of that response; large variations equal poor productivity via irritation and loss of concentration
■ Throughput of work where applicable
■ Availability
■ Other "speed" factors relating to their work
Business Manager Viewpoint
This viewpoint might reflect that of the end user is some respects, but will often be even more general:
■ What is the time between receipt of an order, shipment, invoicing and reconciliation?
■ Is the customer satisfied with this?
■ Can we speed up the processes without excessive cost?
■ Other business aspects
There are other people who will have different requirements and perspectives of performance: service desk, external customers, especially website users, and possibly regulatory bodies. They are important and in performance life, one size does not fit all.
The Outcome
When considering performance management, which is more than simply monitoring, the differing requirements (viewpoints) of various stakeholders needs to be taken into account. It is often difficult to retrofit analysis of performance data to cater for people not considered at the design stage. You may be asked by the CEO, out of the blue: "Why do we take 2 days to issue an invoice after shipment while competitor X takes one?"
Role of the SLA
Whose level of service (quality of service, QoS) are we talking about? Basically, all the types of person outlined above. This (rather these) QoS are usually formalized in a Service Level Agreement or SLA. This will dictate what needs to be measured and analyzed:
"If you can't measure it or derive it, you can't report it."
"A service-level agreement (SLA) is a contract between a service provider and its internal or external customers that documents what services the provider will furnish and defines the performance standards the provider is obligated to meet." [WhatIs.com].
The trick here is to marry these viewpoints which means translating the operational data into service level agreement (SLA) terms and hence into stakeholder perspective, another word for viewpoint All this is complicated when one moves from the relatively simple classical IT environment to the mixed web and application environments, rendered even more difficult to fathom by virtualization and clouds.
The Endpoint
There is no reason why external customers shouldn't be part of any SLA drawn up if the APM setup is designed to cover all important stakeholders.
In addition, it should be transparent to the stakeholders outside operations whether the system runs native, virtualized, in a cloud or in a series of school exercise books. The APM design with these differing viewpoints in mind is the key aspect of this.
Dr. Terry Critchley is the Author of "Making It in IT", "High Performance IT Services" and “High Availability IT Services”.
This blog was created from extracts from Terry Critchley's book: High Performance IT Services [ August 25 2016]
