3 Ways to Solve App Performance Problems with Transaction Tracking

3 Ways to Solve App Performance Problems with Transaction TrackingTransaction Tracking can provide tremendous insight into the performance and behavior of applications. However, this can be challenging when transactions traverse platforms and technologies.  Often it can be similar to tracking someone in the old Westerns where you follow the trail to the river and then lose track of where they went next.  Tracking MQ transactions can have this same hurdle to overcome with MQ running on diverse platforms spanning multiple locations.  MQ transactions typically interact with other platforms such as IBM Integration Bus (Broker) and IBM DataPower.  Visualizing a dynamic flow of transactions across all of these environments is well worth the effort as it greatly simplifies the problem detection process at the same time reducing the mean time to resolve problems (MTTR).

Concepts of Transaction Tracing

Package tracking is an analogy that can be used to explain the concepts behind transaction tracking.  A package is sent from location A to location B with tracking notices generated to let the sender know where the package is in-transit, when the expected time of arrival is and when it actually arrived.    Package Tracking is a combination of disjoint technologies, similar to the middleware environment.  The process of transaction tracking can be complex with cost and timeliness of delivery of major concern.  No matter how fast you deliver a package, someone always wants it quicker. The same problems affect MQ transactions, but instead of a package, it is a message that never seems to get to its destination fast enough.

There are a set of common questions users have about package tracking.  For the customer it might include:   where is my package or is my package progressing as planned? If you work for the shipping company, you are more concerned about: where the bottlenecks are in the system, how to solve a problem, stopping a problem from recurring and what issues can I expect tomorrow. As a technician, you would want to know where your failures are occurring and where you can make improvements.

Package tracking involves: delivering   packages, scanning them and exporting the events from the scanners into a database for later analysis.  The key to tracing anything is to create tracking events that capture the key events such a pick, pack or ship and what time these occurred

Transaction Tracking for MQ

There are a common set of  behavior patterns for MQ.  Each set of patterns can be unique.  Typically, you have senders and receivers as well as queues being processed with one or more queue managers communicating with each other. With multiple applications running on different servers, as in the package tracking example, every time a message gets sent or received, the details about that message and its processing should be captured and sent  to a central location.  This will provide the ability to understand what is occurring. If the transaction is stuck or slow, we know that we can react to it or produce warnings if the transaction takes too long.  We can also gather statistics along the way to see the duration of each step.  Capturing raw metrics about message flows and then correlating them together into a big picture can help the user solve performance problems faster.

Whether you are a corporate manager, Line of Business owner, application support group or IT infrastructure team, you need end-to-end visibility into the transactions that are relevant to you.

Stay tuned for the next installment in this series, “3 Ways to Solve App Performance Problems with Transaction Tracking”.

 

To learn more, watch the TechTalk here

4 Key Benefits from Using Self-Service for IBM MQ” Part 1 of 3

4 Key Benefits from Using Self-Service for IBM MQ" Part 1 of 3The concept of self-service has evolved over many years.  It has led to very important innovations and technology in many industries in the way we work and live.  Until the earliest 20th century, people who went shopping were entirely dependent on clerks.  They would go to a store and give a list of items that they needed to the clerk and those people selected their bits for them. Naturally shopping has changed dramatically with innovations such as supermarkets, malls and even today, internet shopping. When the first ATMs were introduced, there was a lot of fear in the part of banking organizations that customers would miss human interaction with their bank tellers. That fear went away when it became clear that these machines were a huge success.

The Benefits to Self-Service:

Human Empowerment: Users with self-service systems are able to do things for themselves that previously required help from a specialists.

Increased Efficiency: People are now able to do more with less by delegating some activities to users.  This enables a more economical use of resources.

Improved Productivity: With self-service, the specialists that we rely upon are now free to perform other tasks that deliver greater value to the organization. Also, user wait time has decreased.

Reduced Costs: Time consuming tasks that were previously performed by specialists are now delegated to users which has a great impact on reducing costs.

Essential Design Criteria for Self-Service:

Despite all of these benefits, there is an essential design criteria that we cannot forget about when talking about self-service.  You want to provide the benefits of ease of use to your end-users but the first and foremost criteria is protection and the well-being of the user.

Safety: All self-service systems focus primarily on protecting the underlying system of many issues that can either intentionally or unintentionally be created by the non-specialist. Protecting the integrity of the underlying system while still delivering the self-service benefit to the user.

Security:  Only the users can do what they are authorized to do.  Automatic teller machines and atms are the best examples.

Simplicity: Self-service users may have little or no training so the users have to be intuitive and must guide the users to do the right actions.

Scalability: The Self Service system has to be able to handle an increasing volume of the consumers. Self-service often leads to a high level of adoption to users than what was originally anticipated when these systems were put into use.

Self Service System for IBM MQ

A self-service system for IBM MQ has a number of potential stakeholders.  Naturally, these are the people in the middleware team but there are also other groups to consider that are involved with MQ monitoring as well.

Middleware team: Focused on proactive management of messaging middleware. They want to manage their environment

Application Support: Interested in faster time to repair (MTTR).  They want to identify the root cause of performance issues

Application Developers: Interested in continuous quality improvement of the new releases of the applications.

Enterprise Architects and Application Owners: Interesting in processing improving and reduce costs. They want to prevent performance problems from happening.  They also want to monitor their applications from end to end.

Application support, DevOps, and operations teams can have direct access to WMQ, test messages in development and quickly find the root-cause of production problems—without needing to call the Middleware Team. They do not need to know the internal mechanics of MQ in order to do their jobs effectively so their understanding of the internal mechanics of MQ is relatively limited. Since most of these stakeholders are not specialists in MQ, it is not surprising if they frequently contact their middleware team with inaccurate observations or questions such as: “MQ is broken, can you fix it?”, “MQ is slow,”  “I need a new queue so I can do some testing,” or “I need to be able to run tests.”  They can also rely on the MQ Specialists, the middleware team to address their issues if need be.

A fundamental ingredient to a successful self-service implementation is the act of delegating a specific set of selected activities to a broader group of people.  Middleware Teams can leverage easy-to-implement technology to empower their colleagues in application support, DevOps, and operations and also save themselves a boatload of time. Understanding the common requirements and user demands of these stakeholders is the key to providing them with an effective self-service system.

To learn more, read Part 2 of this 3 part series, “4 Key Benefits from using Self-Service for IBM MQ” and learn why there is so much interest in the self-service topic and typical user requirements for self-service for MQ.

For more information on how you can improve productivity, increase speed of delivery to customers and reduce costs, watch the TechTalk Boost Productivity using Self-Service for IBM MQ!

Was your software vendor acquired?

Nastel is the better and safer bet for middleware monitoring and management

Recently, one of the “big four” software firms was acquired by a group of investors led by Bain Capital.  This is good news as this shows that there is demonstrable health in the IT Sector in that investors are willing to take the risk and purchase a software vendor.  Continue reading