APM needs to take into consideration a variety of technology layers as it cuts across the IT landscape. This could include devices in use to access the application (desktop, laptop, PDA, smartphone, tablet, handheld, wearable), a variety of networks over which the application is accessed and over which the application accesses data (routers, gateways, wiring, Internet backbone, mobile networks, WiFi, LAN, WAN, Bluetooth, NFC, etc.), firewalls, protocols (TCP/IP, DHCP, SMTP, HTTP, DDNS, UPNP, PPPoP, FTP, DNS, ARP, RARP, and ICMP), cloud environments (such as SaaS, HaaS and PaaS), servers (web, application, database) and platforms (.Net, Java, PHP).
Businesses and their need for APM
APM is important for any business that addresses customers, regardless of the fact that they are internal or external. This means it is critical to B2C and B2B organizations. Both types of organizations must bear in mind that APM must meet the demands of scalability and availability which are essential to maintain competitiveness. It is therefore necessary to understand that APM can reveal areas for improvement in the performance of applications. Some examples are:
- Identifying which applications and application transactions have maximum users.
- Measuring end user response time accurately & helps identify the presence of a genuine problem.
- Isolating issues related to a single region/desktop/across region.
- Establishing time taken for each transaction process and potential scope for improvement.
- Demarcating the extent of issues faced due to technology layer restrictions, by the end user, network, and DC; and within DC the application server, database, and middleware.
- Highlighting technology areas that act as bottlenecks in the process, by isolating the particular domain or underlying technology that is causing the issue. The tool can accurately pinpoint a problem area from a multiple technology stack.
- Isolating the application code, module or line to identify the segment that is consuming excessive resources and affecting the process.
While APM upside is significant, it has its limitations:
- APM can help identify problems -- however, to arrive at solutions operating teams must use their knowledge and experience of technology and business.
- Output quality will depend on input quality. If data entered is incorrect, the output too will not be reliable. Hence teams that understand both business and IT should handle APM.
- APM cannot read through the code of certain applications that do not expose their code or internal protocols
But the more critical aspect about applications is user expectations. Today, an increasing number of services are going online and are always available – these include email services, digital storage, online shopping, bank accounts and utilities. Users expect these services to be highly responsive. They don’t want to wait for anything. Emails must open instantly, financial transactions must be completed in seconds, files must be uploaded to cloud storage services without a hitch, and medical records must be accessible at all times and so on.
Availability and speed have become so critical that an Amazon study shows that a 100 millisecond improvement in web site page load times can lead to a 1% increase in revenue. Google/Double Click have found that click through rates increased by 12% on advertisements that were 1.5% faster. Users have the same expectations from their enterprise applications.
Choosing the APM solution appropriate for the process
How can enterprise applications demonstrate the same traits that users have come to expect from their personal applications? This is where the selection of an appropriate APM solution requires a thorough study of the business and its processes. The decision making process involves six phases (see Figure 2: Giving Your APM Decision-Making the Right Direction).
Giving Your APM Decision-Making the Right Direction
1. Define business objectives - improving revenue, resources consumed, cost of downtime, reducing failed transactions, etc.
2. Define technical objectives to meet business needs - increase throughput, automation, application availability, improved SLA, etc.
3. Mapping APM to business objectives
4. Understanding APM in the organization’s technology fitment: Implementation and support capabilities.
5. Understanding APM capability and scalability
6. Understanding pricing options.
Once the first two critical phases are defined, we suggest adopting this framework to arrive at a score for each of the phases from 3 to 6 as follows -
- Mapping ATM to business objectives: 20%
- Understanding APM in the organization’s technological fitment: 30%
- Understanding APM capability and scalability: 25%
- Understanding pricing options: 25%
Four of the six phases have assigned scores (see Figure 2 for details of scoring). The final tally can help decide on the appropriate APM to adopt. For example, if the focus of an organization is on deep diagnostics and end user response monitoring for intranet users, the process will most likely go through the following steps:
- Technology Mapping to Objective: Define the users that need performance tracking and detailed diagnostics. Does the user require deep dive diagnostics and end user response monitoring or both? This is crucial as some tools have restrictions of the number of diagnostics applicable.
- Tool Capability and Scalability: Run checks across applications to establish the purpose of the deep dive and the level of granularity required for the target users. Follow up with tests of compatibility and explore the potential for scalability in the future and limitations, if any.
- Implementation and Support Capability: Accurate evaluation of these capabilities is essential before customizing the product to suit the user.
- Pricing: Run a cost-benefit analysis before starting the exercise, keeping in mind the long-term benefits of the exercise. Such an approach can provide an analysis at each appropriate level and will address the requirements of multiple stakeholders (see Table 1: Stakeholders benefitting from the APM process at different levels).
Such an approach can provide an analysis at each appropriate level and will address the requirements of multiple stakeholders (see Table 1: Stakeholders benefitting from the APM process at different levels).