Unlocking Insights and Visibility Into TIBCO With APM Software

TIBCO Software is a global leader in integration, API management and analytics. The company recently was named a leader in the Gartner 2018 Magic Quadrant for Full Life Cycle API Management report for the fourth consecutive time. TIBCO’s traditional strength in application integration is based on its enterprise service bus (ActiveMatrix BusinessWorks), message-oriented middleware (Enterprise Message Service and FTL), and off-the-shelf adapters for applications and other platforms.

TIBCO offers real-time analytics and operational intelligence, including process-intelligence Business Activity Monitoring (BAM) (in AMX BPM); business intelligence BAM, visual data discovery and predictive analytics (in Spotfire and R); business rule processing (in AMX Decisions); two stream analytics CEP platforms (BusinessEvents and StreamBase); and other capabilities.

Critical Banking and Infrastructure Dependencies Require Reliability

In large financial institutions around the world, critical processes such as online banking, mortgages and payments rely on TIBCO. If TIBCO systems were to go down, banking customers wouldn’t be able to get mortgage information, borrow money, or even pay their bills. Indeed, the importance of keeping TIBCO systems up and running is extremely high. It’s equally important for TIBCO users to identify issues, provide solutions, and respond immediately to potential problems as quickly as possible.

More Insights, Please

TIBCO’s product line is extremely powerful, but it can be complicated and expensive for many small and midsize business process management (BPM) projects. As I’ve seen quite a few times throughout my career, TIBCO can be a black box for companies, which usually lack the ability to see inside the code. The reason is that TIBCO users are not exposed to code, but instead use a GUI called TIBCO Designer to create integration projects for their enterprise environments. The good news is that application performance management (APM) software can provide insights into how TIBCO is working under the hood.

When you intend to monitor something as immensely complex as TIBCO, you need a good plan. The first step is to identify what is important and what is not. Therefore, your initial focus should be on identifying the most important business flows on the TIBCO side, and defining the most important business transactions on the APM side. Mapping the relationship between TIBCO workflows (customer/business journeys) and AppDynamics Business Transactions—a key monitoring component consisting of all required services in your environment—is the next logical step. (For a deeper dive into the philosophy of configuring BTs, read How to Identify Impactful Business Transactions in AppDynamics.)

Once mapping has been established, TIBCO users should be able to understand and ultimately resolve performance issues, as well as optimize infrastructure and application setup. But that’s just the beginning.

Dashboards for Real-Time Metrics

AppDynamics can enrich TIBCO monitoring by comparing real-time EMS metrics side-by-side with metrics measured by our Java agent in handy dashboards, providing useful insights into TIBCO’s performance. This is achieved by configuring the AppDynamics TIBCO EMS Monitoring Extension. You will need to give this extension access to your TIBCO EMS server. Our machine agent then uses the extension and feeds the data directly from the EMS server to AppDynamics, where we can display it side-by-side next to real-time metrics provided by our Java agents.

How About Some Alerts?

Of course, users also need to know when something is wrong—and not only by looking at a nice dashboard! This is why you should utilize the power of AppDynamics Health Rules, which leverage dynamic baselines to establish performance thresholds and configure them for Business Transactions. Once these rules are defined and configured, you’re all set: When AppDynamics detects a potential issue, it triggers a Health Rule and sends out a notification. This enables the user, with just a few clicks, to examine the Business Transaction snapshot and get code-level details for every anomaly, even under extreme load. Therefore, AppDynamics’ three-click drill down allows TIBCO customers to pinpoint issues in a very short amount of time.

In many respects, TIBCO is still a grey area for companies, as it is difficult, if not impossible to see its inner workings. (As mentioned above, TIBCO users never see the internal code, but instead rely on the GUI-based TIBCO Designer.) AppDynamics’ monitoring brings more insight into how TIBCO works behind scenes, and gives users a better understanding of how their configuration is tied to TIBCO code. Although it might not be meaningful to the user to see TIBCO code errors, this information could prove valuable to TIBCO support and lead to faster mean time to resolve.

A High-Level Overview

For companies using TIBCO as a backbone for their services, a cross-application flow view is exceptionally useful for seeing which applications are communicating with TIBCO. The screenshot below shows a practical, graphic representation of a TIBCO user’s environment in AppDynamics.*

AppDynamics can create an intuitive diagram of TIBCO workflows, such as one showing the health of each TIBCO operation translated into one or more Business Transactions.

Above you see a slightly different view, one more business-focused and based on normal APM data. However, if you need more detailed business-focused dashboards with funnel graphs, a number of unique transactions, or full end-to-end duration of each transaction, there is a way! All this and much more can be achieved by using AppDynamics Business iQ. (Read how AppDynamics Business Journeys provide a unified, end-to-end application view and help solve complex business problems.)

Global financial institutions depend on TIBCO’s real-time analytics and operational intelligence to keep their operations running efficiently. But TIBCO can be a black box for companies, which need a powerful APM solution to gain code-level insights into their environments and to resolve issues quickly.

*All screenshots shown in this article are not actual representations of TIBCO’s environment.

How Top Investment Banks Accelerate Transaction Time and Avoid Performance Bottlenecks

A complex series of interactions must take place for an investment bank to process a single trade. From the moment it’s placed by a buyer, an order is received by front-office traders and passed through to middle- and back-office systems that conduct risk management checks, matchmaking, clearing and settlement. Then the buyer receives the securities and the seller the corresponding cash. Once complete, the trade is sent to regularity reporting, which insures the transaction was processed under the right regulatory requirements. One AppDynamics customer, a major financial firm, utilizes thousands of microservices to complete this highly complex task countless times throughout the day.

To expedite this process, banks have implemented straight-through processing (STP), an initiative that allows electronically entered information to move between parties in the settlement process without manual intervention. But one of the banks’ biggest concerns with STP is the difficulty of following trades in real-time. When trades get stuck, manual intervention is needed, often impacting service level agreements (SLAs) and even trade reconciliation processes. One investment firm, for instance, told AppDynamics that approximately 20% of its trades needed manual input to complete what should have been a fully automated process—a bottleneck that added significant overhead and resource requirements. And with trade volumes increasing 25% year over year, the company needed a fresh approach to help manage its rapid growth.

AppDynamics’ Business Transactions (BT) enabled the firm to track and follow trades in real time, end-to-end through its systems. The BT traces through of all the necessary systems and microservices—applications, databases, third-party APIs, web services, and so on—needed to process and respond to a request. In investment banking, a BT may include everything from placing an order, completing risk checks or calculations, booking and confirming different types of trades, and even post-trade actions such as clearing, settlement and regularity reporting.

The AppDynamics Business Journey takes this one step further by following a transaction across multiple BTs; for example, following an individual trade from order through capture and then to downstream reporting. The Business Journey provides true end-to-end, time-enabling tracking against SLAs, and traces the transaction across each step to monitor performance and ensure completion.

Once created, the Business Journey allows you to visualise key metrics with out-of-the-box dashboards.

Real-Time Tracking with Dashboards

Prior to AppDynamics, one investment bank struggled to track trades in real time. They were doing direct queries on the database to find out how many trades had made it downstream to the reporting database. This method was slow and inefficient, requiring employees to create and share small Excel dashboards, which lacked real-time trade information. AppDynamics APM dashboards, by comparison, enabled them to get a real-time, high-level overview of the health and performance of their system.

After installing AppDynamics, the investment bank instrumented a dashboard to show all the trades entering its post-trade system throughout the day. This capability proved hugely beneficial in helping the firm monitor trading spikes and ensure it was meeting its SLAs. And Business IQ performance monitoring made it possible to slice and dice massive volumes of incoming trades to gain real-time insights into where the transactions were coming from (i.e., which source system), their value, whether they met the SLAs, and which ones failed to process. Additionally, AppDynamics Experience Level Management provided the ability to report compliance against specific processing times.

Now the bank could automate complex processes and remove inefficient manual systems. Prior to AppDynamics, there was a team dedicated to overseeing more than 200 microservices. They had to determine why a particular trade failed, and then pass that information onto the relevant business teams for follow-up to avoid losing business. But too often a third-party source would send invalid data, or update its software and send a trade in an updated format unfamiliar to the bank’s backend system, creating a logistical mess too complex for one human to manage. With Business IQ, the bank was able to immediately spot and follow up on invalid trades.

Searching for Trades Across All Applications

Microservices offer many advantages but can bring added complexity as well. The investment bank had hundreds of microservices but lacked a fast and efficient way to search for an individual trade. In the event of a problem, they would take the trade ID and look into the log files of multiple microservices. On average, they had to open up some 40 different log files to locate a problem. And although the firm had an experienced support staff that knew the applications well, this manual process wasn’t sustainable as newer, inexperienced support people were brought onboard. Nor would this system scale as trade volume increased.

By using Business IQ to monitor every transaction across all microservices, the bank was able to easily monitor individual trade transactions throughout the lifecycle. And by capturing the trade ID, as well as supplementary data such as the source, client, value and currency, they could then go into AppDynamics Application Analytics and very quickly identify specific transactions. For example, they could enter the trade ID and see every transaction for the trade across the entire system.

This feature was particularly loved by the support staff, which now had immediate access to all of a trade’s interactions within a single screen, as well as the ability to easily drill down to find the find the root cause of a failed transaction.

Tracking Regulatory SLAs in Real Time

Prior to AppDynamics, our customer didn’t have an easy way to track the progress of a trade in real time. Rather, they were manually verifying that trades were successfully being sent to regulatory reporting systems, as well as ensuring that this was completed within the required timeframe. This was difficult to do in real time, meaning that when there was an issue, often it was not found until after the SLA had been breached. With AppDynamics they were able to set up a dashboard to visualise data in real time; the team then set up a health rule to indicate if trade reporting times were approaching the SLA. They also configured an alert that enabled them to proactively see and resolve any issues ahead of an SLA breach.

Proactively Tracking Performance after Code Releases

The bank periodically introduces new functionality to meet the latest business or regulatory requirements, in particular MiFID II, introduced to improve investor protection across Europe by harmonizing the rules for all firms with EU clients. Currently, new releases happen every week, but this rate will continue to increase. These new code releases introduce risk, as previous releases have either had a negative impact on system performance or have introduced new defects. In one two-month period, for instance, the time required to capture a trade increased by about 20%. If this continued, the bank would have had to scale out hugely—buying new hardware at significant cost—to avoid breaching its regulatory SLA.

The solution was to create a comparative dashboard in AppDynamics that showed critical Business Transactions and how they were being changed between releases (response times, errors, and so on). If any metric degraded from the previous version or deviated from a certain threshold, it would be highlighted on the dashboard in a different color, making it easier to decide whether to proceed with a rollout or determine which new feature or change had caused the deviation.

Preventing New Hardware Purchases

After refining its code based on AppDynamics’ insights, the bank saw a dramatic 6X performance improvement. This saved them from having to—in their words—“throw more hardware at the problem” by buying more CPU processing power to push through more trades.

By instrumenting their back office systems with AppDynamics, the bank gained deep insights that enabled them to refine their code. For instance, calls to third-party APIs were taking place unnecessarily and trades were being captured unintentionally within multiple different databases. Without AppDynamics, it’s unlikely this would have been discovered. The insight enabled the bank to make some very simple changes to fine-tune code, resulting in a significant performance improvement and enabling the bank to save money by scaling with their existing hardware profile.

Beneficial Business Outcomes

From the bank’s perspective, one of the greatest gains of going with AppDynamics was the ability to follow a trade through its many complex services, from the moment an order is placed, through to capture and down to regularity reporting. This enabled them to improve system performance, avoid expensive (and unnecessary) hardware upgrades, quickly search for trade IDs to locate and find the root cause of issues, and proactively manage SLAs.

See how AppDynamics can help your own business achieve positive outcomes.

Why DevOps Often Fails in FinServ

Financial services organisations are often late adopters of new technologies and methodologies. There are a number of reasons for this, some related to the way regulators and auditors operate in the industry, others to the difficulties of replacing old systems and practices, which often scale to such levels that it’s not always feasible to replace them without significant disruption.

Furthermore, banks and other FinServ companies are often some of the oldest and largest businesses around, making technological innovation much more challenging than it might be for smaller and newer companies.

Despite these hurdles, large FinServ firms have been investing heavily in digital transformation programmes over the last few years, as modernising the technology stack becomes a competitive necessity. These programmes are aimed at aligning the bank’s technology with recent industry standards, as well as looking for new ways to improve the use of said technology. They often involve the adoption of cloud services, improved automation, better scalability, usage of IaaS/PaaS, and adoption of DevOps methodologies.

A transformative journey is challenging in so many ways. This blog will take a closer look at the DevOps adoption hurdles facing FinServ organisations in their digital transformation.

DevOps Challenges

Why is it so difficult to introduce DevOps in large FinServ companies? I have already highlighted some of the reasons why digitalising large financial services can be challenging, but what specific difficulties do organisations face?

Processes and Structure

By the nature of their business, financial services are heavily process-driven, relying on bureaucracy and structure established over a long period of time. They are also heavily regulated and audited and as such, must carefully consider potential changes such as new methodologies.

One area that might limit the success of DevOps methodologies is the segregation between development and production services. This segregation is driven by role-based access control, which in many cases doesn’t allow software developers to access production environments. As a result, DevOps teams—comprised mostly of developers—can’t access the very software they’re expected to operate in production.

Segregation is caused not only by regulations, but also by historical structure across many FinServ companies, where management of the support groups and development teams is shared only at the CIO level, which means that connecting the Dev and Ops is not always feasible.

Another common theme that separates Dev and Ops is the company’s budget structure. Here’s where two acronyms come into play: Change the Bank (CTB) refers to development projects and budgets assigned for short delivery durations (usually annual projects), while Run the Bank (RTB) refers to operational budgets that get renewed annually.

RTB (or business-as-usual, BAU) support teams are usually handed over completed projects/products that are ready for operations. They will start familiarising themselves with the new products, whereas the CTB teams will most likely be dissolved or move on to develop new products. This approach can conflict with the expected continuity of DevOps methodologies, where a team shepherds products through their entire lifecycle.

Here’s another interesting angle about the way budgets are processed in financial services: budget approvals often require committed financial benefits, which means that newly funded projects are expected to drive future savings. This approach doesn’t always align well with the actual need for DevOps, which is mostly about enabling growth and continuation, and not always cost reduction.

ITIL vs. DevOps

ITIL is a set of detailed practices for IT service management (ITSM). Many articles have addressed the ITIL vs. DevOps debate—whether IT organisations should choose one over the other, or whether DevOps can work together with ITSM disciplines. I’m not taking sides on whether the two are friends or enemies; however, the way ITSM/ITIL is often implemented in FinServ might limit the benefits of DevOps.

One example is the frequency of releases, a core tenet of Agile and DevOps. It’s difficult to operate DevOps methodologies where there are frequent release freezes, or expectations that release cycles adhere to approval processes that may take weeks before a release can go ahead.

One FinServ organisation I worked with was aiming to drive their digital transformation programme as a standalone development entity with full autonomy. The teams were highly innovative and started developing products using cutting-edge technology and DevOps practices.

However, when the programme started looking into the practicalities of releasing products to production, the teams had to take several steps back and reconsider their technology decisions, some of which weren’t approved as part of the organisation’s technology stack. The teams were also required to prepare support handover documentation and follow existing change management procedures. Furthermore, they weren’t allowed access to production environments.

This example highlights the fact that even cutting-edge technology programmes must consider the existing technologies and methodologies used by the organisation, as they’re not likely to be allowed to ignore them.

Skipping the Agile Phase

Since FinServ firms are often late adopters of new technology, they have opportunities to skip, or leapfrog, incremental stages that other enterprises and industries have gone through. But while there are advantages to leapfrogging a few steps, these maturity phases are often necessary for successful implementation.

In DevOps, many organisations and industries have experienced long periods of introducing, fine-tuning and mastering agile development methodologies, which were later complemented by DevOps. While FinServ orgs are trying to move from structured, waterfall-based methodologies straight to DevOps, this transition introduces maturity risks that are not easy to overcome.

When speaking with colleagues in financial services on this topic, I often hear quotes like: “The terms ‘Agile’ and ‘DevOps’ are used as excuses for lack of planning.” I’ve also witnessed a few examples where projects were approved and funded with no clear target deliveries and dates—all on the basis that “This is Agile.”

How FinServ Can Make DevOps Work

Looking at the challenges described above, successful introduction and adoption of DevOps methodologies in FinServ sounds difficult. But being aware of these challenges—and carefully considering them as part of the digital transformation programme—can help prevent most known issues. Here are some suggestions and shared experiences.

Consider a hybrid approach: Don’t get caught up in a quest for DevOps purity, but instead focus on achieving successful agile development. Introduce operational methodologies that contribute to improved agility, mostly where role-based access control and segregation of duties are required by regulators.

Bring Dev and Ops closer: Focusing on DevOps can alienate production services teams, as their roles are theoretically under threat. However, the support of these teams is often critical to the success of new methodologies.

There are a few ways to achieve better relationships between existing support teams and new DevOps teams. Examples include:

  • Integrate support staff into the DevOps pods.

  • Introduce site reliability engineering (SRE) teams that, in addition to providing support services, also focus on DevOps autonomy and reduction of overhead. These teams can eventually integrate with production services.

  • Invest in skilled operations: For Ops teams to become agents of transformation, they need to have the right experience, exposure and skills. In addition to investing in experienced staff, you must provide existing staff with development opportunities.

Another way to introduce DevOps methodologies in FinServ is to identify independent business areas, projects and products that can be delivered and operated using DevOps practices.

There are a few examples in the industry where senior managers gave full backing to DevOps methods in certain projects or product lines. In these successful adoption examples, the DevOps teams managed to isolate their deliveries from the wider technology and process-related dependencies.

One caveat: Having such isolation during development, delivery and operations is rarely feasible in FinServ, so these examples are not common.

Investment in Tools

While the general use of technology in FinServ may lag behind that of other industries, budgeting for some of the best tech tools has never been a problem, and that includes DevOps tools.

The use of tools for development, deployment, testing automation, pipeline automation, analytics, etc., is a must-have for DevOps enablement. But it’s not only about the right tools, it’s also about the successful adoption and use of these tools.

A mature CI/CD process can encompass a significant part of ITSM requirements, and provide governance and confidence in the release process. And with good, well-adopted deployment tools, developers won’t need to access production servers during the release process. Successful adoption of the right monitoring and analytics tools will also provide the information that DevOps teams need to capture and troubleshoot potential faults—again, removing the need for access to production environments.

Summary

A significant gap remains between IT industry gurus who often live and breathe DevOps, and financial services enterprises which—despite their best efforts—face many hurdles when trying to introduce these methodologies. The good news is that FinServ can make DevOps work by embracing a pragmatic approach to DevOps, improving relationships between existing support teams and new DevOps teams, investing in the right tools for DevOps enablement, and other steps.

AppDynamics has been used by many of the top financial services organisations in their own digital transformation journeys. Learn more about how AppDynamics can help accelerate your own DevOps adoption.

Improve the Productivity of Relationship Managers and Financial Advisors with Business iQ

Every job has its mundane administrative tasks, and we all hate them. In the world of wealth management, relationship managers are pressured to serve as many existing customers and prospects as they can with the ultimate goal of increasing the assets under management (AUM)—one of the key metrics used to measure their productivity. Similarly, in the insurance industry, financial advisors are driven to maximize their time with clients. Administrative tasks are not only irritating, they also reduce a salesperson’s paycheck by cutting into his or her time with customers.

But organizational forces in both the wealth management and insurance industries are conspiring against their top revenue generators. According to Seismic, a staggering 65% of a relationship manager’s time is spent on business processes like account opening, accessing collaterals, and creating customized portfolio review with customers.

In the last few years, financial institutions and insurance companies have sought to free up their salespeople by investing in productivity tools. Mobile apps, in particular, hold the promise of speeding up processes like filling out client forms for clients, creating proposals, and building portfolios. They are also, in theory, a great way to deliver real-time market insights.

But mobile apps are only effective when relationship managers and advisors use them.

AppDynamics Business iQ allows organizations to measure the effectiveness of their mobile apps by providing a window into user behavior. In the example below, I show how a financial institution can instantly see how many relationship managers have clicked on a market insight to access AI-driven financial advice—a killer feature for increasing AUM. The dashboard, which I created in the AppDynamics demo environment, also shows how many relationship managers proceeded to “Add to Cart” and re-balanced their clients’ portfolios. We see that as relationship managers moved through the funnel, they increasingly abandoned the app. The overall conversion rate is just 5.62%. Slightly over one in twenty relationship managers used the application to send a proposal to their clients.

Below, I show how to a create conversion funnel using a built-in widget. It is as simple as going to the Add Widget tab and selecting Analytics and Funnel Analysis.

 You then select the business transaction that you’d like to include in the conversion funnel.

You can also quickly design a custom widget to highlight information such as the relationship managers who are generating the most new business.

Figure:  RMs with the highest new AUM

Or see at a glance the relationship managers who are sending the highest number of proposals. Moreover, you can break down the proposals by customer type. So you can see which customer type (Silver, Gold, Platinum, Diamond) the relationship managers are creating the proposals for. In the example below, you can see that relationship manager “aleftik” is sending all 960 proposals to only “Silver” tier customers. Relating the previous graph where the highest AUM is “aleftik” and he focuses all his effort to selling to the “Silver” tier customers, it appears that this is a desirable behaviour and strategy that the business should educate and share among other relationship managers.

Figure: RMs with the highest “Send Proposal” Transactions

Moving beyond the performance metrics of individual relationship managers and financial advisors, you can combine technical and performance metrics in order to see if updates to an application are negatively affecting sales performance.

You can see from the above conversion graph that version 2 of the code has significantly reduced the slowness (yellow and orange color within the bar) for Portfolios Summary page, positively impacting the conversion ratio from 5.53% to 14.52%

The business may also want to identify relationship managers who are not using the new productivity tool enough. Below is a way to create such a list of managers with the least number of page hits.

Figure: Number of page visit on “Market Insights” by RMs in ascending order

You can even put all of this together to have a customizable dashboard combining both technical and business performance metrics. At a glance you’re able to see the new AUM achieved by the wealth management group using the iPad application, transaction health of each key business process, top performing relationship managers and the products sold, as well as relationship managers who have yet to adopt the new application as a productivity tool.

With AppDynamics Business iQ, institutions do not need to wait for a month or a week to see business insights in relation to application performance and user behaviour. All the information is available at a glance in real time.

3 Reasons Financial Services Companies Need APM Right Now

Financial Services companies operate in a difficult environment. Many of their applications are absolutely vital to the proper workings of the global economy. They are one of the most heavily regulated industries in the world, and they are a constant target of hackers. Their systems need to be available, performant, and secure while generating the revenue sought by Wall Street and their shareholders.

In this article we’ll take a look at 3 factors that impact revenue and how APM is used to mitigate risk.

1. Customers Hate to Wait

Losing a customer is a bad thing no matter the circumstances. Losing a customer due to poor application performance and stability is preventable and should never happen! If you lose customers, you either need to win them back or attract new customers.

Fred Reichheld of Bain & Company reports that:

  • Over a five-year period businesses may lose as many as 1/2 of their customers
  • Acquiring a new customer can cost 6 to 7 times more than retaining an existing customer
  • Businesses who boosted customer retention rates by as little as 5% saw increases in their profits ranging from 5% to a whopping 95%

Based on this research, you should do everything in your power to retain your existing customers. Providing a great end user experience and level of service is what every customer expects.

APM software tracks every transaction flowing through an application, recognizes when there are problems and can even automatically fix the issue.

FS Transaction View

Understanding the components involved in each servicing each transaction is the first step in proper troubleshooting and problem resolution.

2. Customer Loyalty = Revenue Growth

On the flipside, better performance means more customer loyalty and, as a result, revenue gains. The Net Promoter methodology, developed by Satmetrix in cooperation with Bain & Company and Fred Reichheld, is a standard way to measure customer satisfaction. Satmetrix developed the Net Promoter methodology, which is an indexed measure of customer loyalty. In their Net Promoter whitepaper, Satmetrix discovered a direct correlation between high customer loyalty scores and the rate of revenue growth for those companies. The paper showed that the higher the customer loyalty score a company achieved, the higher their rate of revenue growth over a 5-year period.

With applications playing a dominant role as the most common interaction between company and customer, it is imperative that customers have a great experience every time they use your application. Slow transactions, errors, and unavailable platforms leave customers dissatisfied and will reduce your loyalty score. Over time, this will have a significant impact on revenue.

So if we accept the premise that performance should be top-of-mind for anyone with a critical banking or FS application, what do we do next? How do we improve our application management strategy to prevent loss of revenue and improve customer loyalty? The answer: by taking on a transaction-based approach to application performance management.

APM software tracks the performance of all transactions, dynamically baselines the normal performance, and alerts when transactions deviate from their normal behavior. In this manner you’re able to identify performance problems as they are beginning instead of waiting until customers are frustrated and abandoning you applications.

FS Business Transaction List

List of business transactions classified by their level of deviation from normal performance.

3. Transactions = Money

Transactions are the lifeblood of banking. From making an online payment or converting currency to buying or selling stock, just about everything a bank does involves transactions. Furthermore, a significant portion of banks’ revenue comes from transaction fees for activities ranging from ATM withdrawals to currency conversion and credit card usage. For these fee-based transactions, the faster you can ring the cash register (response time of business transactions), the more money you will make and the better likelihood that your customer will come back to you for their next transaction.

With this in mind, it is imperative that IT organizations take a user-centric, or rather, transaction-centric approach to managing application performance.

APM software provides context that enables you to understand the business impact of failed and/or slow transactions. The data gathered by APM software can be used to focus on improving functionality that is used most often or responsible for the most revenue.

FS Prioritization

Having various data perspectives allows application support and development teams to prioritize what needs to be updated in the next release.

If you aren’t using an APM tool yet, or if your APM tool isn’t providing the value that it should be, then you need to take a free trial of AppDynamics and see what you and your customers have been missing.

The Digital Enterprise – Problems and Solutions

According to a recent article featured in Wall Street and Technology, Financial Services (FS) companies have a problem. The article explains that FS companies built more datacenter capacity than they needed when profits were up and demand was rising. Now that profits are lower and demand has not risen as expected the data centers are partially empty and very costly to operate.

FS companies are starting to outsource their IT infrastructure and this brings a new problem to light…

“It will take a decade to complete the move to a digital enterprise, especially in financial services, because of the complexity of software and existing IT architecture. “Legacy data and applications are hard to move” to a third party, Bishop says, adding that a single application may touch and interact with numerous other applications. Removing one system from a datacenter may disrupt the entire ecosystem.”

Serious Problems

The article calls out a significant problem that FS companies are facing now and will be for the next decade but doesn’t mention a solution.

The problem is that you can’t just pick up an application and move it without impacting other applications. Based upon my experience working with FS applications I see multiple related problems:

  1. Disruption of other applications
  2. Baselining performance and availability before the move
  3. Ensuring performance and availability after the move

All of these problems increase risk and the chance that users will be impacted.

Solutions

1. Disruption of other applications – The solution to this problem is easy in theory and traditionally difficult in practice. The theory is that you need to understand all of the external interactions with application you want to move.

One solution is to use ADDM (Application Discovery and Dependency Mapping) tools that scan your infrastructure looking for application components and the various communications to and from them. This method works okay (I have used it in the past) but typically requires a lot of manual data manipulation after the fact to improve the accuracy of the discovered information.

ADDM1

ADDM product view of application dependencies.

Another solution is to use an APM (Application Performance Management) tool to gather the information from within the running application. The right APM tool will automatically see all application instances (even in a dynamically scaled environment) as well as all of the communications into and out of the monitored application.

Distributed Application View

APM visualization of an application and it’s components with remote service calls.

Remote Services 1

APM tool list of remote application calls with response times, throughput and errors.

 

A combination of these two types of tools would provide the ultimate in accurate and easy to consume information (APM strength) along with flexibility to cover all of the one off custom application processes that might not be supported by an APM tool (ADDM strength).

2. Baselining performance and availability before the move – It’s critically important to understand the performance characteristics of your application before you move. This will provide the baseline required for comparison sake after you make the move. The last thing you want to do is degrade application performance and user satisfaction by moving an application. The solution here is leveraging the APM tool referenced in solution #1. This is a core strength of APM and should be leveraged from multiple perspectives:

  1. Overall application throughput, response times, and availability
  2. Individual business transaction throughput and response times
  3. External dependency throughput and response times
  4. Application error rate and type
Application overview and baseline

Application overview with baseline information.

transactions and baselines

Business transaction overview and baseline information.

3. Ensuring performance and availability after the move – Now that your application has moved to an outsourcer it’s more important than ever to understand performance and availability. Invariably your application performance will degrade and the finger pointing between you and your outsourcer will begin. That is, unless you are using an APM tool to monitor your application. The whole point of APM tools is to end finger pointing and to reduce mean time to restore service (MTRS) as much as possible. By using APM after the application move you will provide the highest level of service to your customers as possible.

Compare Releases

Comparison of two application releases. Granular comparison to understand before and after states. – Key Performance Indicators

Compare releases 2

Comparison of two application releases. Granular comparison to understand before and after states. – Load, Response Time, Errors

If you’re considering or in the process of transitioning to a digital enterprise you should seriously consider using APM to solve a multitude of problems. You can click here to sign up for a free trial of AppDynamics and get started today.