Engineering, Product

How to Ensure Your Applications Meet Business Goals

By | | 6 min read


Summary
Ready to take action to capture business value? Here’s how to connect application and business performance in a few simple steps.

It makes sense that every application you use should provide tangible business value. But IT has long been stymied in proving this is true.

Traditional monitoring tools let you know how your systems were performing but offered little insight into whether a delayed response from a database—or any other performance issue—was having a cascading effect on business goals. Conversely, web analytics tools revealed how website interactions affected revenue but failed to connect adverse user behavior—like a spike in abandoned shopping carts—with a root cause.

For years, this lack of visibility has been accepted as the status quo. No longer. CIOs are increasingly taking action to capture business value. In this blog post, I’ll explain how you too can monitor your applications to ensure they are contributing to business goals as well as meeting more traditional IT performance benchmarks.

To begin, you’ll want to put together a cross-functional team that includes someone familiar with the application or applications in question from a technical perspective, someone from operations who is familiar with production support of the application, and someone who has a high-level understanding of the value the application provides to the business. This team will be responsible for defining the value of the application in measurable terms and identifying the relevant use case(s).

Defining Business Value

Applications that have a significant impact on business results usually fall into three buckets. The first bucket is obvious: Externally facing applications that bring in revenue like eCommerce or Bill Pay immediately affect the bottom line if they slow down or become unavailable. What needs to be determined by the team is how many dollars are at stake under different scenarios. In the second bucket are externally facing applications that mediate customer interactions and are generally not directly linked to revenue. However, these apps, which allow a customer to check an account balance, look up product information, or request help from a service rep, can be closely tied to other important metrics like new signups, adoption of new products and services, and customer churn. Performance failures affect those metrics, which in turn affects revenue. Over time, the poor performance of these apps will erode the value of a brand. The third bucket includes internally facing applications that deliver core business functionality like underwriting, policy quoting, and order fulfillment. The apps in this bucket drive revenue, but it is more common for them to affect metrics related to employee productivity. If these applications go down, employees are not able to get work done.

Other apps may not have a noticeable impact on the outward-facing business if they go down, but their effect on productivity and employee morale makes monitoring necessary. These include internally facing tertiary applications that handle human resource functions like onboarding, employee wellness, or expense management.

Establishing a Use Case

Once the business value of an application is determined, the next step is to understand your use case. Common use cases include business health monitoring, user journey monitoring, business journey monitoring, customer segment monitoring, and release validation. I’ll explain more about each use case below. While it is typically easier to brainstorm your own use case after learning what others have done, I expect many companies will end up creating their own unique use cases or blending common use cases together.

Business Health Monitoring: This applies to business owners who want to understand the impact of application performance on key business drivers. An example is an e-commerce site managing sales for different brands. The business owner is interested in conversion rates, the number of orders processed, total sales, and the percentage of customers moving into a loyalty program. He or she uses business health monitoring to determine the root cause behind a change in a KPI. For example, a decline in sales may be caused by an application error or a business problem.

User Journey Monitoring: User journeys are the pathways that users take through an application from start to finish. Applications that benefit from user journey monitoring are those in which the business has a vested interest in the user finishing a journey. These can be as simple as a conversion funnel for a user attempting to buy a book or a complex combination of searching, quoting, and purchasing an insurance policy. We want to understand where our users are falling out (or choosing not to continue) during their journeys so we can easily determine if their behavior is caused by application issues or something external to the application.

Business Journey Monitoring:  Rather than analyzing performance through the lens of a user, business journey monitoring is a way of evaluating the success of a holistic business process. The challenge is that a business process is likely to span applications, services, and events and involve multistep workflows. Looking at whether a complex process is meeting business objectives typically involves breaking it up into milestones and events that comprise those milestones. For a loan application, these would include submission, documents verification, credit approval, insurance underwriting, and final approval.

Customer Segment Monitoring: Identifying the most valuable users of an application and protecting them from performance problems is one way of ensuring better business outcomes. Take the case of an insurance company that manages a portal for financial professionals who want to purchase annuities on behalf of their clients. The professionals with the largest books of business are likely to generate the most revenue for the insurance company. By segmenting customers into tiers based on their number of clients, the insurance company can create health rules around their most valuable users and prioritize their issues.

Release Validation: Whether you are updating an existing application in your data center or migrating to the cloud, you need to be able to compare the before and after state of the application in reference to business KPIs. If you operate a hotel chain, your KPIs will likely include total revenue, average daily rate, and number of bookings. If KPIs fall after a new release or migration, you will want to determine the root cause and prioritize the resolution based on its impact on revenue. You may also want to measure how well a new release improved those KPIs to help validate the decision to invest the time and resources to improve that application.

Executing a Use Case

After you have determined the use case that is appropriate to your business, you will need to identify key metrics. Metrics can be as simple as the dollar value in a cart for an eCommerce application or the size or type of an internal transaction for an underwriting application. As you identify your metrics, you need to decide how you want to tell the story. It’s typically best to start with a whiteboard session where you outline what you want your dashboard(s) to look like.

This helps ensure that a layperson will be able to quickly and easily understand if the business is healthy or not.

The final step is to define your data collectors and build your dashboard. You will also want to create alerts if trends begin to deviate from established baselines. You are now ready to let the rubber of business value, use cases, and key metrics meet the road of real-time data. As you learn how application performance is affecting your business, you can now act on those results!

Learn more about how AppDynamics helps you drive business performance through application performance with Business iQ!