How to Identify Impactful Business Transactions in AppDynamics

New users of APM software often believe their company has hundreds of critical business transactions that must be monitored. But that’s not the case. In my role as Professional Services Consultant (EMEA) at AppDynamics, I’ve worked at dozens of customer sites, and the question of “What to monitor?” is always foremost in new users’ minds.

AppDynamics’ Business Transactions (BTs) reflect the core value of your applications. Since our inception a decade ago, we’ve built our APM solution around this concept. Given the critical importance of Business Transactions, you’ll want to configure them the right way. While AppDynamics will automatically create BTs for you, you’ll benefit greatly by taking a few extra steps to optimize your monitoring environment.

APM users often think of a BT as a technical transaction in their system, but it’s much more than that. The BT is a key component of effective application monitoring. It consists of all required  services within your environment—things like login, search and checkout—that are utilized to fulfill and respond to a user-initiated request. These transactions reflect the logical way users interact with your applications. Activities such as adding an item to a shopping cart or checking out will summon various applications, databases, third-party APIs and web services.

If you’re new to APM, you may find yourself asking “Where should I begin?” By applying essential best practices, BT configuration can be a smooth and orderly process.

Start by asking yourself two key questions:

  1. What are my business goals for monitoring?
  2. What pain points am I trying to address by using APM?

You may already know the answers. Perhaps you want to resolve major problems that consume a lot of your time and resources, or insure that your most critical business operations are performing optimally. From there, you can drill down to more specific goals and operations to focus on. A retail website, for instance, may choose to focus on its checkout or catalog operation. Financial services firms may focus on the most-used APIs provided for their mobile clients. By prioritizing your business goals early in the process, you’ll find BTs much easier to configure.

AppDynamics automatically discovers and maps Business Transactions for you. Actions like Add to Cart are tagged and traced across every component of your application and visualized on a topology map, helping you to better understand performance across an entire application.

It’s tempting to think configuration is complete once you’ve instrumented with an agent and start seeing traffic coming in. But that’s just the technical side of things. You’ll also need to align with the business, asking questions like, “Do we have SLAs on this?” and “What’s the performance requirement?” You’ll also need to establish health rules and work with the business to determine, for instance, what action to take if a particular rule is violated.

Choose Your BTs Wisely

At a high level, a Business Transaction is more like a use case, even though users often think of it as a technical transaction. Sometimes I must remind users: “No, this activity you want to monitor is not a business transaction. It’s just a technical functionality of the system, but it’s not being used by a customer or an API user.” These cross-cutting metrics may be better served by monitoring through views like Service Endpoints or specific technical metrics.

Be very selective when choosing your Business Transactions. Here’s a rule of thumb: Configure up to 20 to 30 BTs per business application. This may not seem like a lot, but really it is. One of AppDynamics’ largest banking customers identified that 90% of its business activity was reflected in just 25 or so business transactions.

It’s not uncommon for new users to balk at this. They may say, “But we have many more important processes to track!” Fear not: the recommended number of BTs isn’t set in stone, although our 20-to-30 guideline is a good starting point. You may have 20 key Business Transactions and another 20 that are less critical, but you really want to monitor all 40. You can do this, of course, but you’ll need to prioritize these transactions. Capturing too many BTs can lead users to miss the transactions that are truly important to the business.

Best Practices

During APM setup, you’ll have many questions. Should you work exclusively with your own technical team? With the application owner? The business that’s using the application?

Start with these three key steps:

  1. Get to know your business.
  2. Identify the major flows.
  3. Talk to the application owner.

 

Whenever I’m onsite with a customer, the first thing I advise is that we login as an end user to see how they use the system. For example, we’ll order a product or renew a subscription, and then track these transactions end-to-end through the system. This very important step will help you identify the transactions you want to monitor.

It’s also critical to check the current major incidents you have, or at least the P1s and P2s. Find out what problems you’re experiencing right now. What are the major complaints involving the application?

Focus on the the low-hanging fruit—your most troublesome applications—which you’ll find by instrumenting systems and talking to applications owners. This will deliver value in the early setup stage, providing information you can take to the business to make them more receptive to working with you.

Prioritize Your Operations

Business Transactions are key to configuring APM. Before starting configuration, ask yourself these critical questions:

  1. What are my business goals for monitoring?
  2. What pain points am I trying to solve with AppDynamics?
  3. What are the typical problems that take up my time and resources?
  4. What are the most critical business operations that need to perform optimally?

 

Then take a closer look at your application. Decide which operations you must focus on to achieve your goals.

These key steps will help you prioritize operations and make it easier to configure them as Business Transactions. Go here to learn more!

Preparing for PSD2: Some Critical Considerations

In just three months European banking will undergo a seismic shift brought on by a regulatory event known as the revised Payment Services Directive. Starting in mid-January, banks and other financial institutions will be required to make customer account information available to approved third-party applications via open APIs. The dry technical specifications are not exactly holiday reading, but they describe a game changer so consequential industry pundits are calling it the banking sector’s “iPhone moment.”

For the first time in their long and storied histories, the great European banks are going to find themselves competing on a purely digital playing field. Yet outside a handful of internal development groups, few organizations are prepared to address the far-reaching impacts of what will soon be the new status quo. Regrettably, the consequences for the unprepared are likely be severe.

Most technologists understand PSD2 will fundamentally alter not only payments delivery but also the way their organizations attract and retain customers. They are simply too overwhelmed by the immediate demands of compliance to address longer-term considerations. The European Banking Authority only published the final guidelines for banks and other financial services companies in mid-July. Since then hundreds of development teams have been scrambling to create APIs and applications to access them.

The reality is that APIs and apps alone will not be enough to ward off disruption. According to a research analysis by Accenture, banks in the United Kingdom are poised to lose up to 43% of their payments revenue as a result of the directive and developments like Apple Pay. Accenture says European banks are at a crossroads—either they must resign themselves to a new status as “banking utilities” or they must embed themselves in their customers’ lives like never before.

If they choose the latter path they need to act now to safeguard their relationships with their customers. Not only must they provide innovative services that take care of their customers’ daily needs, but these services must be at least as good as those offered by competitors who are using their data. The good news is banks will have a built-in advantage right off the starting block. Seven out of ten consumers trust their banks to handle their payments over other providers, Accenture found. But the banks’ biggest advantage—their customer data and the relationships it describes—is also their biggest weakness.

Although the effects may not be felt immediately, with time the new services made possible by PSD2 will place an unprecedented load on banking systems as competing payment providers call on the banks’ APIs. Banks risk losing their customers if their digital systems fail to perform. According to the AppDynamics App Attention Span Study, 80% of respondents deleted an app because of poor performance. Scalability will become an even bigger challenge.  At any given moment, any of the more than half dozen PSD2 APIs will be pulling information from tens of internal systems. It should go without saying that an issue within any one of those systems will affect performance. The risk of failure is literally exponential.

My colleague, Andy Skelton, recalled what happened when the bank where he was working exposed an underwriting service as an API a few years ago. The goal of the API was to drive new business, and it succeeded so dramatically that it revealed issues around capacity. Marketing activities by other organizations were generating enough demand to create a slowdown, exacerbating spikes caused by poor internal communication. The DevOps team faced the difficult decision of which requests it should throttle–the bank’s own or those coming in over the API.

The same scenario is likely to play out in the early days of PSD2. At a minimum DevOps teams need to monitor the systems that support the new APIs, and understand how the APIs are being consumed. Tracking data in the aggregate won’t suffice. Banks will need to make sure that API calls are driving business, and they will need to be able to distinguish good partners from bad ones who may be abusing an API or unintentionally performing the equivalent of a denial of service attack.

With development teams stretched to their limits, technical leaders are pushing back on new initiatives. But they cannot postpone thinking beyond PSD2 if they want to establish first-mover advantage. Now is the time to make strategic choices about opening up banking data beyond the requirements of PSD2. For example, banks are in a position to offer far more useful bill-paying portals by establishing relationships with companies outside of the financial sector. Imagine, for example, a service that provides a customer personalized guidance and coaching on achieving his or her financial goals and that also presents approved relevant, real-time and geo-targeted offers from third-parties.

As Field CTO for EMEA at AppDynamics, I work with financial institutions to increase their speed of innovation. These days I feel a bit like Lincoln Steffens, the American journalist who after visiting Soviet Russia at the beginning of the last century famously remarked: “I have seen the future, and it works.” The great changes inspired by PSD2 are happening today. Developers and DevOps teams are getting ready. A few are already poised to take the lead. Their message to the rest of the industry? Catch us if you can.

Learn more about how AppDynamics Business iQ helps businesses compete in the digital playing field.

Firaas is Regional CTO EMEA working with clients to convert performance insights into business outcomes. He is also responsible for setting AppDynamics’ regional product strategy. Before joining AppDynamics he held various positions in IT leadership at Credit Suisse.

Digital Transformation in the Retail Banking Industry

Like other industries did before it, retail banking is riding a bucking bronco of digital transformation. While customer satisfaction levels drop and government rules and regulations continue to expand, retail banking seeks new ways to adapt to the massive changes in how consumers interact and use financial products and services.

However, unlike other industries such as book publishing that have been rocked by the tsunami of digital changes in the marketplace, companies in the banking sector also have to comply with extensive regulations intended to protect consumers. In confronting this new landscape, banks are looking at better ways to use their existing data in real-time to improve customer experience and loyalty, comply with a growing number of government rules and privacy laws, and consolidate disparate IT systems in their current infrastructure. Banks must provide a seamless experience for customers no matter which product or service they choose.

Digital Banking

Retail banks have gone digital — using online channels (e.g., mobile, web, etc.) and new technology to improve customer experiences and employee productivity. Common programming languages used in banking include Python, C++ for speed, C# for trading platforms, Java, Scala, HTML5, and .NET. This allows the institutions to introduce new features and services rapidly without the need for constant updates from vendors. It also reduces errors that are due to lack of manual oversight.

The network becomes more virtualized — rather than each router and switch on the system with set data paths solely on the destination address, a centralized controller creates the optimal path based on predetermined criteria set by the network operator. Operations can be managed with a small set of software tools, allowing users to achieve business objectives and KPIs faster and easier as the organization becomes more adaptable to change.

In essence, banks are becoming technology companies — they want to embrace a software-defined business structure because they have no other choice. Customers don’t think of banks as an offline or online institution. To them, it is all the same, and they expect to have a positive experience no matter which channel they use to obtain service. If a consumer does all their banking through an app on an iPhone, that becomes their entire banking experience. Without a robust mobile app, banks are short-changing their future because customers will gravitate to more technology-savvy institutions.

Slow Adoption

One of the reasons banks are slow to adapt to a digital world is that it costs a tremendous amount of money and time to change out legacy systems. Integrating new digital technologies with legacy backend systems requires an enormous amount of capital investment. Furthermore, massive changes increase the risk of exposure to potential security problems, which are a constant threat.

Microservices and Containerization

Like many traditional businesses that have maintained legacy enterprise systems for decades, retail banks are stuck between relying on the tried-and-true monolithic legacy systems that already work and moving to provide innovative services and technologies to a mobile-first consumer community that craves the latest technology. One way retail banks meet this challenge is to adopt cutting-edge technologies such as microservices, containerization, and APIs.

Microservices are applications made up of independent processes that talk to each other using APIs. Each process handles a single small task, allowing developers to build highly modular software applications that can be rapidly developed, modified, and deployed — and also reflect individual business units and initiatives in contrast to mini-projects and individual features.

Containers allow users to run software on multiple computing environments without worrying about the type of underlying OS, network, or infrastructure. Each container has a full runtime environment — an app and its libraries, dependencies, and config files. This enables it to run on everything from virtual machines to a cloud-based PaaS.

Legacy Systems

One of the major benefits of these technologies is that a retail banking firm can implement them alongside their legacy system. They can adopt new ideas and approaches without threatening the stability of their current operation. This way, they will meet their obligations to government regulations such as Dodd Frank, Solvency II, and BASEL III. With containers and microservices, retail bank DevOps can rapidly update new features and functions without the threat of a company-wide outage or performance hits.

In effect, banks should be less concerned than they were in the past about owning and maintaining their entire IT infrastructure. Instead, different functions are broken into components, some of which will be managed by third-party providers. This reduces technological overhead and increases the number of resources available on a strategic level.

Lacking the Human Touch

Software-defined banking may reduce the trust of some consumers because of the potential reduction in human interaction. Traditional banks have an advantage over Internet-only banks because their customers can get to know the manager and employees at a local branch. If consumers have a problem, they can turn to people they know to help resolve the situation. Local branches may also provide some services that are not available to consumers online. This is especially important for local businesses that rely on banks to provide capital for purchasing inventory, equipment, and business expansion.

As software systems continue to evolve and become more efficient, the need to employ additional staff across the institution diminishes. This can have a drawback effect over time as customers who prefer to work directly with bank employees may discontinue patronage.

ME Bank Adapts to Digital

One example of a forward-thinking financial institution is ME Bank in Australia, which won a Mozo award in 2016 as the Expert’s Choice for Australia’s best bank. Owned by a consortium of super funds, ME Bank started in 1994 by offering home loans and has since expanded to offer credit cards, personal loans, automobile loans, insurance, and other services.

In a recent interview with Business First magazine in Australia, ME Bank’s CEO, Jamie McPhee, talked about the challenges of banks adapting in the digital era. He said that we are moving from the industrial age of mass production to a new era that uses data to create a better customer experience. The digital transformation, he said, is affecting every business.

When he took over the CEO position in 2010, McPhee immediately began employing digital tactics. His belief is that banks who survive in the new digital age can adapt technology to meet customer expectations and demands. While many banks are incorporating newer technologies, McPhee went a step further, creating a shift to a “digital first” philosophy.

He was also a leader in the move toward mobile banking. Early on, McPhee recognized the rise of mobile banking and the desire for consumers to complete transactions through smartphones and other portable devices. He noted the success of ING Direct, which launched in 1998 without any brick-and-mortar locations, yet garnered 5 percent of the retail banking market in short order. McPhee’s efforts have paid off. In 2014, ME Bank garnered a profit of almost $37 million (AUS).

ME Bank’s experience is instructive. They realized that successful banks, and indeed businesses across the industrial spectrum, must customize data to meet customer expectations, needs, and desires.

Management and Monitoring

Retail banks can minimize and prevent UX issues by deploying software that manages and monitors the performance of their applications, alerting them to problems well before they reach crisis levels. Application performance management (APM) tools such as AppDynamics alert your internal teams to problems in the critical transactions that power your business. By monitoring software and performance optimization, you can detect serious issues before your users do, which helps maintain the level of service your customers expect.

Learn More

Find out more about our product or start your free trial today.