Skip navigation
All Places > CA Infrastructure Management > Blog > 2017 > December
2017

When using media for connecting and sharing information in short, efficient increments, families and friends turn to Facebook, Snapchat, and Instagram, career professionals use LinkedIn, and others turn to Twitter.

 

When monitoring a business, think of dashboards as social media for IT: a platform to socialize information, provide context, move people to action and build ties through data with people who share common interests and goals.

Just as with other social media, there are good practices, rules, and considerations for getting value from IT dashboards—and costly pitfalls of “bad dashboarding.”

The dashboard creator needs to consider:

  • Who is my audience?
  • What information needs to be presented?
  • What is the frequency for refreshing data? What is the frequency for viewers to consume data?
  • How can data be organized to provide helpful context and avoid misinterpretation, or worse, misuse?
  • What actions might we expect viewers to take based on the information?

 

At a minimum, your dashboard strategy for CA Performance Management (CA PM) should address two key dimensions: the intended audience and the desired benefits of viewing the information.

 

Just as it is good practice that tweets are segregated from professional LinkedIn group postings, Snapchat conversations, Facebook pages and Tweets, it is good practice to segregate dashboards by audience and desired benefits. The key point is to tailor dashboards to specific audiences: A dashboard should not morph into a forum for all relevant data for disparate audiences. Potential benefits of dashboards include:

  • Driving continuous improvement of applications, networks or business services
  • Increasing data transparency across IT teams and business stakeholders
  • Improving alignment throughout the business and promoting better business decisions using valid data

 

The benefits of a strong dashboard strategy are slightly different. These include:

  • Frequent (or timely) use of dashboard data
  • Confidence in shared data
  • A healthy ratio between time spent consuming data and time needed to derive insights from the data and develop a plan of action
  • More efficient cross-team communication

 

Let’s look at each type of dashboard.

 

Operational dashboards

These dashboards monitor services that change frequently and track performance of key metrics and KPIs. Data updates very frequently, normally every five minutes. Viewed throughout the day, they often monitor progress toward a known goal or against a specific benchmark. Many enterprises prominently display operational dashboards for all to consume—looking for insights to change behavior and drive incremental, continuous improvements.

Dashboard creators should have a solid understanding of the data’s context. For CA PM, the design may be applicable to multiple sets of CA Performance Center groups for quick, easy changes to the data group represented geographically or by business unit, data center, or other relevant data segmentation required by technical data consumers.

Some metrics that CA PM customers include in operational dashboards are:

  • Amount of traffic through key network links
  • Resource usage (CPU, memory, etc.)
  • Website activity

Strategic dashboards

These dashboards monitor KPI status. Data is updated less frequently than on operational dashboards. Most strategic dashboards are viewed a few times per day by executives. The key is understanding how the current state of KPIs impacts the business.

The dashboard creator needs to understand what the business day looks like: Does it follow the sun or do we need to establish business-hour reporting using site groups in CA Performance Center?

Some metrics that CA PM customers include in strategic dashboards are:

  • End-user experience
  • Application usage rates
  • Availability of key resources

Analytic dashboards

These dashboards analyze large volumes of data to investigate trends and discover business insights to ensure that the trends fit business goals. In CA PM, analysts use scorecards and metric projections to predict outcomes. These dashboards can be updated less frequently as long as the data is accurate and current when viewed.

Some metrics that CA PM customers include in analytical dashboards are:

  • Top-viewed web pages
  • Percentage of visitors on mobile devices
  • Average time spent at the website

Parting Words of Advice

Dashboard formatting and graphic design are important, but dashboard design starts with knowledge of the audience and the type of dashboard the audience requires to align IT goals with larger business goals. From there, you can make intelligent decisions about important data, where that data resides, and how to best represent the data.

Well-designed, frequently viewed dashboards can be an effective business tool. By monitoring your current state, you can make incremental changes to your business that over time, deliver substantial results and ongoing learning.

So don’t fall into the “set it and forget it” trap with dashboards. Take a more agile approach to using dashboards that can meet new challenges as the business evolves:

  1. Plan to adapt each dashboard over time: Start small and build on successes.
  2. Monitor usage by group or individual and by dashboard element, and map actions taken to insights derived from specific data.
  3. Focus on top-most priorities; question the value of secondary priorities until teams are confident that the highest priorities are being successfully attained.

Comments or questions? Please post them below—I value your feedback.

One of my challenges on nearly every project is the almost inevitable conversation about resilience. You see, the duet between high availability (HA) and disaster recovery (DR) is like modern jazz: complex, elusive and hard to define.

 

All customers understand the importance of their platform: It must be available very close to 100% of the time, and if a disaster occurs, it needs to be revived very quickly. What organisations may not have considered in any real detail is precisely how critical the platform is, what kinds of disasters are likely to strike, and how to recover from disaster.

 

Let’s get something straight from the start: The logistics of HA and DR have little to do with technology. Rather, they are driven more by business needs and operational requirements. If organisations start with this in mind and leave technology until later, everything will work out better in the end.

 

Let me lead you through the process.

 

Your first task when aiming for resilience is to examine your business needs and understand the impact of platform unavailability for various lengths of time: ten minutes, an hour, a day, a week or more. What will you lose operationally, contractually and monetarily in each scenario? What are other potential business impacts? Only when you understand these issues can you formulate a plan to ensure that your platform meets your needs.

 

High Availability

What should emerge from this analysis are definitions of tolerable outage, data loss and recovery time. For instance, HA is typically expressed as a percentage, often 99% or higher, usually computed with a downtime calculator, which you can find online. (By the way, the data used to compute this percentage is probably more useful to the architect than the percentage—which is really just a convenient number to plug into presentations.)

 

Why is the data more useful than the percentage? Well, outages rear their ugly heads in many forms, and downtime duration varies. So if you have a 99.9% availability target, that translates to an outage of 8 hours, 45 minutes and 36 seconds each year, or 1 minute, 26 seconds per day. But those figures are quite useless, unless you can predict (and you cannot!) that you will have only one outage that won’t exceed 8:45:36.

 

That’s where scenario-building comes in very handy. Perhaps you anticipate a couple of complete outages and a few partial outages. For a partial outage, can you divide outage duration by the overall effect? In other words, does a one-hour outage affecting 10% of users translate to 6 minutes (10% of an hour)? Whatever data is available, allow for several scenarios. Previous experience of the solution or platform should help you do that; even for new systems, vendors like CA have data about reliability and potential threats to availability. What you should aim to end up with is a matrix of possible failures, with downtime attributed to each, and a recovery plan for each failure.

 

At that point, you have something you can apply to the technology and begin to build resilience.

 

So is that it? Actually, no. You may find that the technology doesn’t support what you need to achieve or that the cost is way beyond the benefit. Now it’s time for manipulating the possibilities to an availability percentage that is technically and financially viable but also meets business needs.

 

Disaster Recovery

DR is a different beast altogether: The possibilities are endless and the cost/benefit curve can get very steep very quickly. My first question to customers is, “What disasters do you anticipate?” Predictably, a typical answer is “A plane hitting the building”—an unfortunately understandable, but not very useful, response. Nevertheless, the question provokes meaningful discussion.

 

DR is so much more than replicating data in a second data centre—a frequently stated goal that is often not the best or most effective answer. As with HA, look at the business case and identify the recovery time objective (RTO) and recovery point objective (RPO), two essential parameters of a disaster recovery plan (DRP).

 

Don’t immediately accept the first RTO and RPO handed to you: Make stakeholders justify them. Only then can you start to create a DRP. You may find that a second data centre is not necessary—it may be more effective to build from backups in a recovered data centre or a cloud environment. Having collateral sitting around doing nothing while waiting for a disaster can be expensive and is often unnecessary.

 

So, I hope the message is clear. Put away thoughts of technology and think about your business objectives first. That will likely give you an easier and cheaper route to resilience—and that would be music to your ears.

 

Inquiring minds want to know: What business objectives are presenting challenges to you now? Let us know!

Did you know we have over 10,000 followers in the Infrastructure Management community?  We have folks in here that are our 'regulars' and then we have those that jump in to ask a question, get what they need and leave. We have lurkers, stalkers and all sorts of visitors.. the community thrives with the vast personalities, thoughts, opinions and ideas! 

 

However, I am starting to wonder if you folks are actually in the right place.   It was about a year ago that we moved some products into their very own communities and we'd like to make certain that you are actually following those new spaces.  It's important to us as a company and trusted partner to make sure that you are receiving timely information about the product(s) you care about.  So .... this begs the question... are you in the right place? If not, let's get you there.

 

If you are not following the correct product community you might be missing out on:

-Product specific events (webcasts, roadmaps, askCA)

-Announcements (Product or Community Specific)   

-Interesting Blogs and Documents like Tech Tips

-Interaction with Product Managers and Support Engineers for the product(s) you care about

-Networking with like-minded folks

 

Plus, if you are asking questions in the wrong place, it may take longer for you to get an answer!   

 

Here is a quick product-to-community table.  Be sure to FOLLOW the communities that matter to you!

 

Do you care about?Then follow this community

CA Unified Infrastructure Management (UIM)

CA Unified Infrastructure Management 
CA UIM for z SystemsCA Unified Infrastructure Management 
CA SpectrumCA Spectrum 

CA Performance Management

CA Performance Management 
CA eHealthCA Performance Management
CA Virtual Network AssuranceCA Performance Management
CA Service Operations Insight (SOI)CA Service Operations Insight (SOI) 
CA Network Flow Analysis (NFA)you are in the right place. Stay here! CA Infrastructure Management
CA Application Delivery Analysis(ADA)

you are in the right place. Stay here! CA Infrastructure Management

 

looking for Gigastor? CA Gigastor removed as a category in community. What you need to know

Other Products:  

  • Mediation Manager
  • Unified Communications Monitor 
  • NetVoyant
  • SystemEDGE
  • Virtual Assurance for Infrastructure Managers (VAIM)

you are in the right place. Stay here! CA Infrastructure Management

CA Capacity Management

CA Capacity Management 

CA DCIM

If you are looking for CA DCIM please go here: DCIM, NSM 

CA NSM

If you are looking for CA NSM please go here: DCIM, NSM 

 

It very well may be the case that you will follow numerous communities.  Whatever your situation, we are here to help you find what you need quickly.  I suggest this additional directory:  Community Hack - Find Your ES Product and MF Product Communities 

 

You can also unfollow a community if you need to change the community you are following and want to limit notifications as a result.

 

Prior Announcement on this subject: (December 2016)

 

and there is more you can read in the Training Community

How to Access and Join the Communities 

Following a Tag 

 

Feedback always welcome, message me MelissaPotvin or leave a comment.