Figuring Out How IT, Analytics, and Operations Should Work Together

Figuring Out How IT, Analytics, and Operations Should Work TogetherA new set of relationships is being formed within companies around how people working in data, analytics, IT, and operations teams work together. Is there a “right” way to structure these relationships?

Data and analytics represent a blurring of the traditional lines of demarcation between the scope of IT and the responsibilities of operating divisions. Consider the core mission of the modern IT department: Taking in all the technology “mess” (often from several different divisions), developing the necessary competencies, and delivering savings and efficiency to the company. Many IT organizations, having achieved this original mission, now are turning to the next thing, which is innovation.

Enter data and analytics, which provide an opportunity for such innovation. However, data traditionally is owned by the business, and analytics is valuable only to the extent that it is used to make business decisions, again “owned” by the business. For IT to operate in the data and analytics space often takes realigning roles and responsibilities.


This article originally appeared in .  To read the full article, click here.

Is Cloud Data Safer Than On-Site?

Is Cloud Data Safter Than On-Site?The use of cloud computing, SaaS services, and remote working has meant that rather than data being stored on a single on-site server accessed only from a networked computer, it can be accessed from anywhere in the world. This has meant that employees can now work from anywhere they want without missing any data or information that may be stored in a specific server. It has essentially been one of the most important elements in the globalization of business.

However, with this power also comes significant debate around data security.

There are some strong arguments it is safer both in the ‘on-site’ camp and in the cloud, but which is ultimately the safest?


This article originally appeared in The Innovation Enterprise .  To read the full article, click here.

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 3 of 3

[This is Part 3 of a 3 part series. Catch-up with part 1, here.]

Using a Self-Service Dashboard:

Observing real-time metrics and comparing how they change over time is fundamental for early warning performance alerts. Users can browse historical metrics, view anomalies and then take action to ensure alerts are generated as soon as they reoccur.

Creating a Self-Service Dashboard:

A self-service dashboard should not be difficult to create; otherwise, it may be abandoned before value is received.  It must be a very simple guided process that the MQ administrator follows to create the monitoring dashboard.  The three most important questions that must be answered before building a dashboard, include:

  • What are the key metrics and events that need to be monitored?
  • How are these metrics going to be interpreted?
  • When are notifications set or actions invoked?

A wizard based approach is ideal when subject matter experts want to rapidly, create monitoring dashboards.  This approach is without any need for programming or scripting.

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

3 Steps for a Wizard Based Approach:

First Step: Select the MQ metrics for the events you want to monitor.

Second Step: Specify the rules for interpreting these metrics and events

Third Step: Specify the conditions for raising alerts and sending notifications or performing actions on behalf of your user.

Self-Service Access to the MQ Estate:

There are several groups of stakeholders within the enterprise that need access to the MQ Estate but their requirements may be very different. Application support teams may only need to view status information.  For example, they need to see if a queue manager or a channel is running in a production environment.  Whereas other teams may need to do other things such as browsing messages on specific queues.  In order to create test data, your application developers may need the ability to work with messages.

Application Developers or DevOps specialists might need to take specific actions such as creating, moving, copying, editing, or rerouting messages on a set of queues in development.  Alternatively, they could be creating test queues, topics or subscriptions used by an application or other self-service use cases.

We need to keep in mind our design goals for self-service. 

These are comprised of:

Safety: Protect the MQ Estate

Security: Deliver highly granular, role based security to our users

Simplicity: Delegating selected tasks to DevOps teams and other stakeholders in the organization

Scalability: To a large number of users

Today, in most organizations, only a small number of MQ administrators are authorized to do these tasks.  If we are going to authorize various stakeholders such as application developers or support teams to do specific functions on specific MQ objects, we will need a security facility that enables secure delegation of authority and granular control over privileged access.

Security Management for the Self-Service System:

In order to delegate authority to our stakeholders and enable them to do specific things in a controlled way, our facility needs a security manager.  It must be easily deployed and managed by the MQ administrator who assumes governance of this system.

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

The MQ admin can specify MQ objects, a list of authorized actions and a granular set of authorizations that together determine what the user in a certain role is allowed to do. Any one of these roles can contain multiple authorizations. For example an MQ admin can assign a role such as administrator or a message browser role to a user or a group of users.

Once roles are assigned, a stakeholder such as an application developer would have the authority to view MQ objects they are entitled to see and perform actions they are authorized to perform. These activities would be accomplished via a self-service application running in a web browser.


A self-service system for IBM MQ has a number of potential stakeholders in addition to the middleware team, including:  Application Support, Application Developers, Enterprise Architects, and Application Owners. User empowerment is one of the key benefits making this technology extremely compelling for enterprises.  Users are now able to do things themselves that previously required help from MQ specialists or the MQ administrators.

Self-service for MQ delivers increased efficiency and improved productivity The time it takes to complete a task decreases as the user with a problem can address it themselves.  At the same time costs are lower as problem resolution time shrinks.

The key ingredient in a successful self-service implementation is the act of delegating a specific set of selected activities to a broader group of people. When are building a self-service system, never forget the goals of: safety to protect the system, security to control authorization, simplicity to guide the non-specialist and scalability to handle increasing user volume.

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!

What does Pokémon GO have to do with Transaction Tracking?

Pokemon-GoPokémon GO, the new game from Nintendo is hot.  It’s on the news and its being used in political campaigns from both parties – (Pikachu is on the presidential campaign trail it seems).

This innovative game avoids tethering a player to a game console and instead players get up, travel and try to find Pokémon in the real world.  Location-based augmented reality is the name they are giving to this new approach to gaming. It seems as if the developer of this game was responding to the age-old complaint that video games are unhealthy as you just sit in one place and stare at a screen. Continue reading

How to Win your Customers for Life with Predictive Analytics

How to Win your Customers for Life with Predictive AnalyticsWinning your customer for life is a challenging task for organizations. How can you connect with your customer and how can you ensure that they stay with your organization for a long time? Questions that many organizations face.  Fortunately, with the advance of big data and predictive analytics, it has become a little bit easier for organizations.

View Full The Article

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