Skip navigation
All Places > CA Infrastructure Management > Blog
1 2 3 Previous Next

CA Infrastructure Management

96 posts

As I mentioned in previous posts, I’d like to discuss a topic that really gets the adrenaline pumping for a certain in-crowd: CA Spectrum topology mapping.


If you’re like me, you’re frustrated by views that show so many tiny device icons that the view is almost useless. When you try to zoom out to see all devices, they are so small that you can’t read their names—or anything else. Is too much of a good thing a good thing? I think not: If you can’t see all the devices in a view, what’s the point in having the view? 


Of course, you rely on seeing how your devices are connected to one another: This connectivity mapping is how CA Spectrum accurately determines the root cause of a device not responding to polls.  But having too many devices on a single screen can be self-defeating.


Let’s take a closer look.


CA Spectrum lets you create four different device model views: the topological view (aka the universe view), the location view (aka the world view), the TopOrg view (or organizational view) and global collections. As Spectrum’s default view, the topological view places models in OSI Layer 2 and Layer 3 views after an autodiscovery or after a device is modeled. You can copy/paste models from the topological view to other views to achieve your desired look and feel.

Before we dig into the meat and potatoes of topology mapping, here are a few hard and fast fundamental rules that CA Spectrum is built on:


#1: CA Spectrum ALWAYS understands the relationships between devices modeled in CA Spectrum IF those relationships have been built. 


#2: CA Spectrum doesn’t have to show users everything it understands about the relationships between devices that have been resolved. 


#3: CA Spectrum builds a connectivity map for each resolved device. If the resolved devices are in separate topological views, Spectrum creates off-page references to the devices in another view. (Another tricky situation arises when you have 100s of off-page references in a view—stay tuned for a post on that topic.)


With these fundamental rules in mind, let’s discuss the often hated (but always required) methodology for creating topological views that don’t require users to view all devices in a single view. 


When you’re looking to reduce your MTBF, any technique or procedure that allows this to happen is worth taking a second look. To this end, I will give you my take on how to map out your Spectrum topology views to promote an environment that HELPS you troubleshoot issues vs. HINDERS troubleshooting.


Remembering rule #1, Spectrum doesn’t care if a view has 10 device models or 300. But because users have to look at the views, the number of device models does make a difference in how we see the network—and therefore, how we should model our enterprise. Below is a screenshot of an actual Spectrum environment (you’ll immediately see the challenge it presented):



As a matter of fact, I had to use Adobe Photoshop© to get the above image, as I didn’t have a monitor large enough to display a 6128x4280 pixel image! In real life, users would have to use the scroll mechanism to see the entire view.


You may recall that I was a customer long before I was a vendor, so I know what I needed as a customer. That’s why as a vendor, I’ve developed a style that responds to what I needed as a customer. In this case, I want to reorganize the view so that it allows me to quickly see how the devices are interconnected, how they behave, where they have issues and how they correlate with other devices.


To do that, my first requirement is to create smaller views so that a typical user can read them. My second requirement is to logically separate devices so as not to produce more off-page references than I can manage.


Fortunately, my first requirement doesn’t require much knowledge about the environment—I just need to see a logical separation of the devices. From the image above I can see that many routers are connected to a main router right smack in the middle of the view. This is my starting point. Looking at the routers connected to the main router, I notice that they’re in remote locations (like stores or branch offices). With this information I devise a plan to create a view that allows me to see the same information but in an easily readable format.


I grouped the remote routers together (using their assigned numbers) and created containers for them. I then cut and pasted the groups of routers together and placed them in the containers. I added annotations in the view so that I could easily and quickly identify the remote routers and where the problem devices reside. Here is my final view:


Wow! I can read everything on the screen and see how the components are connected, starting from an MPLS provider cloud down to the remote routers. Information is presented in an intuitive dashboard that lets users see the health of the enterprise’s network at a glance. This is a view we can all understand. The outcome? More accurate and rapid problem isolation that can be used to facilitate troubleshooting when those inevitable problems occur. It also lets users prioritize work by criticality and/or the most profitable services.

So, is too much of a good thing a good thing? The answer is a resounding “No!” More importantly, can too much of a good thing be managed so that it becomes a good thing? This time, the answer is “Yes.” Can you do it?  Of course! As I’ve shown here, managing topological views isn’t rocket science—it just takes a little investment of your time to make it happen.

Hit me with your thoughts and questions below! Thanks.

Though Unified Communications consists of a broad portfolio of communication services, such as video conferencing, desktop sharing, and instant messaging, perhaps the most sensitive to network performance is Voice over IP (VoIP) because it is consumed in real time by the human ear. Consider the potential difference between a cell phone conversation using packetized speech and a conversation carried by a Constant Bit Rate network such as the Plain Old Telephone Service (POTS).


Quality of Experience Measurements

Mean Opinion Score (MOS) is the industry standard for measuring the quality of a voice conservation over telecommunication networks. MOS originated from listeners in a quiet room giving their opinion of voice quality on a scale of one to five, five being the best. Its purpose was to evaluate different speech encoding techniques and effects of long-distance (Toll) calls. Today, MOS can be calculated using metrics such as latency, packet loss and jitter. Variations in these metrics affect the quality of a user’s conversation and, in-turn, MOS. MOS may be different for each user in the conversation.


Latency is the average one-way delay calculated from the origination to the destination party. It includes propagation delay (affected by distance), network delay (affected by queueing in the network), and packetization delay (affected by the type of speech encoder used for the call). A network reroute may increase the distance. Network congestion from excessive traffic may increase network delay. Sophisticated speech encoding algorithms may increase packetization delay. Latency below 150 milliseconds is considered acceptable. If latency is much higher, the conversation is like using walkie-talkies where everyone has to say “over.”


Packet loss is the percentage of data packets that were not received by the end user. Since VoIP uses the User Datagram Protocol (UDP), these packets are not retransmitted. Loss can be due to bit errors caused by cabling issues (particularly in an office environment), but is more commonly due to discards caused by traffic overloads. Loss percentage greater than one percent begins to impair a call. Packet Loss Concealment (PCL) attempts to mask the effects of lost packets. This may sound like chirps or clicks to the receiver.


Jitter is the variations in delay among the arrival times of packets. A voice packet typically carries 20 to 30 milliseconds of speech. If a packet is delayed more than 20 milliseconds, there may be no speech to play for the user. PCL is used to mask the effects of late packets.


Monitoring and Managing

Monitoring and maintaining network performance is important to manage the end user’s VoIP experience. CA Unified Communications Monitor monitors the metrics that affect the user’s Quality of Experience, alerts on degradation, and helps isolate the source of problems to specific locations. CA Performance Management and CA Network Flow Analysis further isolate the problem such as bit errors, packet loss, mismarked Quality of Service traffic, or sources of congestion.

Share Your Experience

What has been your experience managing Unified Communications?

In my previous blogs I explained what business services are, why we need them, and how we can use them. Today, let’s dive deeper into how to leverage CA Spectrum to create business services in CA Service Operations Insight (CA SOI).


As you may know, the first iteration of CA Spectrum, CA Spectrum Service Manager, was the “grandfather” of CA SOI. Since its inception back in the Cabletron days, Spectrum was the original standard for managing one’s network. In other words, like the ring in the Lord of the Rings trilogy, Spectrum is the original enterprise management tool that ruled them all!


If you’ve installed Spectrum and your user status gives you authority to view Spectrum Service Manager (SSM) options, you’ve probably seen the SSM menu option on the right side of the CA OneClick web page. If you’re in the OneClick Java console and click on the Tools menu, the SSM menu options appear at the bottom. Click on the Service Dashboard view to see business services that have been created; if none have been created, the dashboard will be blank. A clean slate to start off with!


Let’s discuss business services in the context of SSM. Upon opening the SSM editor you have the option to create or edit business services. If you choose to create a service, the SSM editor will open a dialog window asking for basic service information: name, description, etc. The meat and potatoes of creating the service goes into effect when you focus on the middle section of the window, where you identify and define the resources (known as CIs) used in the service. As you recall from my previous posts, defining a business service starts with identifying each CI that plays a role in the service. This logic holds true in the SSM environment.


This is where the maturity of CA SOI shows through as compared to Spectrum’s SSM. In SSM you can create containers, called resource monitors, that group any number of Spectrum models together. In the resource monitor you group CIs that will affect the business service in similar ways. In doing this, you’re applying a policy to the resource monitor that defines a significance level to CIs. In other words, the policy answers the question, “How does degradation or outage of the CI(s) affect the service?”. In CA SOI, you can also combine CIs into groups and assign policies to these groups that answer the same question. The critical advantage of CA SOI over Spectrum’s SSM is that in CA SOI, individual CIs (not just the groups) contain a significance value, a level of granularity that greatly enhances the ability to define how the CI will affect the service. 


To refine a business service and allow for a more granular service health approach, you can create additional resource monitors and/or define custom policies.


Two great advantages of creating business services in SSM is that you can maximize CA Spectrum’s ability to use its root cause analytics engine, which allows users to identify the true cause of an outage, and CA SOI’s ability to import services from SSM to CA SOI. Once the service is in CA SOI, you can further refine the business service by, for instance, applying different significance levels to each CI. Creating services in SSM and importing them to CA SOI allows you to define a business service while capitalizing on the domain manager’s (in this case, CA Spectrum) inherent abilities. 


In CA SOI, you can also import services from other domain managers, such as CA APM, CA UIM, etc. This enables the user to exploit the best of each domain manager within CA SOI, giving the user a true end-to-end, comprehensive inside look into each business service. 


So as in the Lord of the Rings, the ring (or in this case, the enterprise management tool) that ruled them all is a great place to start in building out business services. Let’s get started!


My inquiring mind wants to know: What challenges have you run up against when defining and managing services?  Please let us know by posting a comment below.

Today many companies around the world choose a Cisco networking infrastructure to service their physical and virtual networking needs for enterprise and data center operations. Cisco is incorporating various new technologies, like the Cisco Application Centric Infrastructure (ACI) and software defined networking (SDN) into their networking equipment. These enterprises are planning to migrate to the latest SDN based technologies to help IT engineers improve their network infrastructure. However, new technologies cause disruptions in existing monitoring strategies. This includes mirroring technologies for packet and flow data e.g. switched port analyzer (SPAN), remote SPAN (RSPAN), encapsulated remote SPAN (ERSPAN), and VLAN access-list (VACL) that have issues with encapsulation and other new technologies.

This creates a need to have a visibility architecture to overcome the limitations and maximize the use of the Cisco equipment, while at the same time, having the right monitoring solution would enable monitoring of application performance on the underlying network.

In this blog, we will review a few challenges with packet capture in the ACI network and then discuss the solution to overcome this challenge and perform network troubleshooting.


Challenges of Data visibility in ACI

The Cisco ACI architecture focuses on distributed applications. It uses a centralized controller and an overlay structure to create, deliver, and automate application policies throughout the network. Access to data monitoring can be accomplished either by use of taps or SPAN-related technology, depending upon the architecture implementation. However, issues like duplicate packets and the need for data filtering capabilities still exist and creates a significant burden for many monitoring tools. For instance, redundant traffic streams and a distributed leaf and spine architecture means that one should tap in multiple places to collect all the monitoring data needed in this architecture. This creates a significant amount of duplicate data from the BiDi taps that needs to be removed from the monitoring stream. To complicate matters, leaf portions of the networks are running at 40 Gbps and the spine portions can run at up to 100 Gbps. Removal of 40 Gbps duplicate packets can be very expensive for any monitoring tools at line rate.

VXLAN headers are often used to create the ACI network overlays. Unfortunately, many monitoring tools do not understand the VXLAN headers, so they need to be removed from the monitoring data by an NPB before the data can be sent to the tool(s). SSL encrypted data issues are often another problem for tools as well. Besides the ACI architecture, there are concerns with using SPAN and SPAN-related technologies in an ACI environment.


The Combined Solution

CA Tech and Ixia (a Keysight business) have partnered together to provide a powerful solution to overcome the above challenges and provide the right solution for your monitoring needs.



CA Application Delivery Analysis can help you prove how well your network delivers applications to users with application delivery analysis of performance and availability of SLA measurements. It helps you focus investments on the areas that require it most and later quantify the before and after, validate the impact of those changes and verify your investment decisions. Ixia’s Network Visibility Solutions (NVS), including TAPs and network packet brokers (NPB), complement CA application delivery solution to create the best-in-class scalable and resilient application monitoring solutions that IT professional need and want to purchase.

Ixia’s NVS solutions helps to remove unnecessary packet data and packet headers (at line rates of 40 Gbps or higher) before transmission across the network. It provides data filtering, aggregation and packet slicing capabilities. It can perform data rate throttling and load balancing to reduce 40 Gbps traffic so that it can be processed easily by CA Application delivery analysis solution.


Below diagram shows a simple network deployment of combined solution.



Feel free to reach out to me at AnujGupta for more detailed discussions on this topic.#

Joint solution empowers IT with visibility into cloud to ensure optimal end-user experience.

Today, the business leaders move their services to the public cloud without consulting or even notifying IT of the change, until an issue arises. While this has become common, IT teams are still responsible for finding and fixing problems, remaining accountable for not just performance and security but also for the end user experience. And the challenge of maintaining control does not stop with the initial deployment. From a recent Gartner survey on the cloud monitoring challenges, more than 50 percent engineers said they were “blind to what happens in the cloud” while 32 percent cited visibility gaps and the majority felt the data shared by cloud providers did not meet their needs.

Notwithstanding, moving applications to the public cloud creates stumbling blocks for application and IT teams, as they no longer have the visibility needed to be effective. Yet it is critical that applications continue to deliver high levels of responsiveness and availability—at all times, no matter if the application is deployed in the data center, private cloud, public cloud, or a combination of all three.


The good news is that, the CA Technologies and Keysight (Ixia) have teamed together to develop a best practices approach to monitor packet data in the cloud. The joint CA Application Delivery Analysis (CA ADA) and Ixia CloudLens™ solutions provide the end-to-end response-time-monitoring capabilities that the IT team needs to track and optimize the end-user experience, no matter where the application is deployed. With CA ADA, which provides deep insight into TCP/IP conversations across multi-tiered applications, you can quickly identify the domain in which issues arise, so you can do faster incident triage and resolution. Ixia’s visibility solutions complement CA ADA by providing the full end-to-end visibility of physical, virtual, and cloud network traffic it needs. The joint solution can detect user experience issues as they occur and before customers become aware, so they can be quickly addressed.





CA Application Delivery Analysis (ADA) provides the end-to-end response-time-monitoring capabilities that the IT teams need to measure and report on the performance of applications across your infrastructure, quickly isolate and fix performance bottlenecks, and optimize the end-user experience. The solution is efficient to deploy and manage, delivering performance and availability measurements that are based on real multi-tiered application response times, without requiring synthetic tests or agents. CA ADA continually collects performance metrics, automatically establishes intelligent baselines, and instantly generates alerts when performance starts to deteriorate. Convenient application scorecards provide an at-a-glance view of critical application performance, while SLA reporting summarizes both performance and availability of applications.




After my recent blog on performance dashboards, I want to follow up by clarifying some IT terminology prevalent in the modern software factory: business intelligence (BI) and business analytics (BA). While superficially similar, there’s a very important distinction between the terms:

  • BI uses past and current data to generate insights to improve near-term success for the organization
  • BA analyzes the same data with a different goal: to help the organization make well-informed assumptions, uncover or anticipate trends, and prepare the organization for the future


We immediately see a distinct difference in these definitions: BI provides insights to optimize the organization for near-term success, while BA is used to prepare the organization to adapt to a foreseeable future landscape. Optimizing a business versus adapting a business is a huge distinction: A blacksmith in 1910 would use BI to understand that he needs fewer horseshoes in inventory, but BA would be more likely to tell him he needs to get into the tire business.


That’s not to say that BI is less important than BA; past and current data are always crucial in creating and maintaining efficiencies as well as identifying and resolving operational and strategic issues in order to optimize the business in the present. Despite the need to anticipate the future as accurately as possible and position our organization to thrive in a changing world, we’ll always need to understand our present state to increase productivity and limit costs—the perennial, all-important fundamentals.


While BI will always be useful, the modern economy is defined by change, and as we all know, change in IT leads to more change in IT—causing the pace of change to accelerate. For that reason, analysis of big data is very valuable in understanding where organizations (and society at large) are headed. Because consumer choice is a dominating force that compels technological change, collecting consumer data allows analysts to use data mining, quantitative analysis and predictive modeling—all elements of BA—to adapt a business to align with consumer trends.


Keep in mind that BA is different from data science. Most would agree that data scientists do not try to answer specific questions; rather, they examine data and allow the data features (aka the data itself) to guide the analysis.


BI—knowing how many horseshoes to keep in inventory—has always had a place in the business community. BA—learning that tires are the future of transportation—has become a more and more important tool. Organizations are investing more resources in data warehousing and huge data stores, cleaning up and maintaining data integrity, and new and sophisticated analysis techniques. As they do, organizations will look to CA and other state-of-the-art technology companies for the best tools and the best practices.


I'm a Sr. Services Consultant with CA Services; I look forward to using my experience to respond to your comments and questions.Please post them below—I value your feedback. 

Further to my previous post Part 1: Bridging the Gap with Application-Aware Network Performance Monitoring (AA-NPM) where-in I had discussed on the challenges of monitoring application performance from a network perspective and lack thereof of such solutions and why they are more relevant than ever, this post looks at possible solutions from CA technologies that enable application-driven network performance management (ANPM). These solutions deliver comprehensive, centralized views of all the metrics and measurements needed to understand, manage and optimize performance of critical applications running on the network.


CA Technologies delivers several robust products, including CA Application Delivery Analysis, CA Network Flow Analysis, and CA Unified Communications Monitor which can be used in tandem or individually, to address a range of technological and business imperatives. Through these integrated solutions, an enterprise can leverage a unified view of all the metrics being gathered, including application response times, network flow data, resource capacity, voice and video quality of service and more. Further, these offerings feature the open standards support that enables them to be effectively integrated with a range of third-party and custom IT management tools.


CA Application Delivery Analysis (ADA)

Understanding application response times between infrastructure components is critical to managing end-user experience, which is ultimately the most important measure of network performance. CA ADA delivers an end-to-end response time monitoring solution that enables your IT team to gain the insights it needs to optimize the end-user experience. With CA Application Delivery Analysis (ADA), you can isolate the source of bottlenecks and verify the performance of applications delivered over the network.


CA Network Flow Analysis (NFA)

NFA allows administrators to quickly troubleshoot issues, identify top users and applications, implement service quality policies and track their efficacy. With these capabilities, your administrators can manage the capacity of network resources to maximize the service levels of the most critical applications and services. It offers the visibility needed to distinguish between personal and business, and lower and higher priority activities, and to determine how the network is prioritizing various types of traffic, including rich-media applications.


CA Unified Communications Monitor (UCM) helps to:

  • Track the specific performance metrics—such as mean opinion score (MOS), jitter, latency, call volume and utilization—that you need to maximize the quality of experience delivered by voice over IP and video applications
  • Measure the impact of unified communications traffic on other applications
  • Monitor quality, device health and performance of voice and video applications
  • Gain the insights you need to identify type-of-service misconfigurations
  • Report on key call set-up metrics and monitor calls in real time



With the comprehensive, robust capabilities of AA-NPM solutions from CA Technologies, the network team can gain the visibility and intelligence it needs to understand the network within the context of the applications and services it supports. These solutions provide the visibility you need to efficiently manage complex, demanding enterprise networks. With these capabilities, an organization can realize a range of benefits:

  • Boost service levels by delivering the immediate alerts, fast insights and intuitive workflows needed to reduce downtime and performance issues.
  • Better manage costs and resources by providing data-driven insights regarding network capacity, quality of service policies, infrastructure investments and planned application and service roll-outs. These solutions also provide the insights to make more informed investment decisions to address evolving technical and business requirements.
  • Deliver more business value by enabling organization to start making decisions based on rich data, rather than guesswork. By managing networks with a focus on optimizing applications and business services, your IT team can get out of reactive firefighting mode, and elevate the dialog with business leadership and users to focus on proactive planning, decision making and cost management.


To conclude, managing networks so they support optimal application performance has never been more challenging, or more critical. By leveraging AA-NPM solutions from CA Technologies, an organization can harness the robust and comprehensive capabilities it needs to understand and optimize how business-critical applications perform on the network.


Follow me on Community AnujGupta

Today, a large number and wide range of applications are running on enterprise networks, including latency-sensitive voice and video traffic, critical business applications and more. The increase in the number of applications and the varied nature of application traffic traversing the network place increased demands on network capacity and make it all the more challenging to manage network performance.


Many administrators are trying to manage their networks with basic network fault and availability monitoring tools. While these tools are fine for managing network devices and links, they don’t deliver the fundamental insights administrators need to understand application performance and network traffic flows. With this limited visibility, administrators can’t truly track and optimize application performance, and as a result, organizations suffer from poor service levels, suboptimal configurations and investments and inefficient operations—which can all have a significant impact on business performance.


Lacking this application-level visibility, your organization’s IT and operations staffs are apt to contend with significant challenges as follows:

  • Lower priority and personal user activities consume excessive resources, while the performance of critical business services suffers from costly outages and significant performance issues.
  • Long time taken to isolate and troubleshoot application performance issues.
  • Difficulty understanding how network changes and new infrastructure investments will affect different applications, leading to un-intended degradations and outages.
  • Money is wasted on underutilized infrastructure.


All these challenges can have a significant negative business impact, potentially eroding user

productivity, revenues and customer loyalty. That’s where an AA-NPM solution is critical. An AA-NPM solution integrates these vital entities of application and underlying network infrastructure and provides complete visibility into the business-critical applications and their dependencies.



 AA-NPM solutions provides

  • Improved User Experience and better Visibility into IT Infrastructure using single comprehensive dashboard view of their critical business applications and underlying network infrastructure.
  • Clear business co-relation and value-add by seeing how vital modules of IT and business services performs on the underlying It infrastructure that are responsible for the health and availability of critical applications.
  • Faster Troubleshooting of Problems by finding root cause, as well enabling an engineer to prepare for the future and perform proper capacity planning during the peak usage hours.
  • Enhanced Productivity and Optimal Budget Usage by reducing mean time to repair (MTTR) and improving the overall quality of service.


Bottom line, AA-NPM tools effectively enable IT professionals to gain the insight they need into the interplay of all the infrastructure elements that comprise the user experience of a web-delivered application. They provide a mechanism for monitoring and managing application and network infrastructure as a single entity.


See Part 2: How CA helps in Application-Aware Network Performance Monitoring (AA-NPM)? of the series to learn how CA Technologies help provide network visibility for optimizing the use of business critical applications.


Follow me on Community gupan22

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 


If you are looking for CA DCIM please go here: DCIM, 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. 

I confess: I’m a poacher turned gamekeeper. For those of you not familiar with this rather English idiom, it means that I was once the perp, but now I’m the cop.


In my formative years, when I was keen to impress any way I could, solutions to problems would just spring from any coding language I thought appropriate at the time. I’ve probably left thousands of lines of Shell, Java, Perl and PHP script in my wake, with nary a care for future support or development.


Often, when we coders are in a tight corner or perhaps not familiar with current trends or available tools, the temptation to write our own solution is compelling. We say, “I have knowledge of the problem” and “I have the skills.” What we may not have is a view to where our solution may go, the pressures that will be brought to bear on us and the solution in the future, and the fate of others who have to sail in our wake.


For me, the epiphany was an integration I wrote to solve a problem between two systems that would not normally be connected. Neither vendor had considered integrating with the other, and there was no out-of-the-box solution. That was great for me: eight weeks of playing with code was a joy, and I completed the job to specification.


Returning six months later to resolve a problem, I noticed significant changes to the code base. What had happened in the meantime was twofold. First, unanticipated new features had been added; second, these new features had been added by other coders. The result was something of a mess: My once elegant solution had become not only an organically grown mess but also a support nightmare, hard to extend and creaking at the seams.


In a more controlled development environment, these support and extensibility factors would have been addressed from the start and delivered as an agile code stream that could be useful for years to come. In a less controlled environment, that usually doesn’t happen.


These days, I’m inclined to block this kind of quick coding customisation activity unless I’m convinced there’s no other solution and that the customisation will not require huge future development or excessive support. Another criterion for success is that the customisation must be very well documented and understood by future parties—and that usually means it has to be simple.


I recognise that it’s not always possible to meet these criteria—sometimes you just need to automate or glue things together, and that often requires some sophisticated code. Products don’t always go in the direction you need them to, and sometimes specific local requirements need a solution outside of the vendor product’s capability.


So what’s the answer? Well, CA Automic (and CA IT PAM before it), enables programmers’ flair for creativity, letting us solve problems ourselves whilst providing a controlled and supportable environment with tools that accelerate development, add security and enable logging.  These tools offer much more than just point integration or simple orchestration solutions. They should form the backbone of an environment and be the first port of call when we seek to automate or integrate.


My advice is this: To let your creativity be burden free and build supportable solutions for the future with confidence, set yourself up for success by using the right tools.


Happy coding!

I recently came across a project requirement calling for an encrypted version of a VOIP protocol; I couldn’t fulfill the request, because the software didn’t support encryption of the protocol. However, I was able to resolve the issue by asking a simple question: “Is encryption an actual security requirement or is the possibility of encryption driving the request?” The latter was the case, and the issue was resolved.


That scenario got me thinking about a similar experience I had a few years ago, before I joined CA, that also illustrates how we can get so enticed by the lure of technical possibilities that we abandon practicality and common sense. I often tell the following anecdote because it shows how we can fall victim to techno-think that impedes—rather than facilitates—success.


I was asked to join a project that had been running for quite some time and had hit the bumblers because a key requirement had not been met. The customer had requested a GUI refresh rate of five seconds for a monitoring tool. Nearly 99% of customers request a refresh rate of 60 seconds, which was the default.


Five seconds simply wasn’t practical—or even possible, what with screen flashing/flickering and resources issues lurking in every corner. Nevertheless, the team had valiantly tried everything they could to make it work, to no avail.


My boss at the time asked me to see what I could do. Knowing that the chances of fixing this issue were very low, I had to think of a different approach. At my initial meeting with the team, the PM explained that the specs insisted on the five-second refresh rate. And there it was in black and white: a standard templated document with many boxes to fill, one of which said “Screen refresh rate: every 5 seconds.”


I said I would like to contact the architect so that I could understand the reason for the request. I was told he was a radar specialist and had returned to another unit of the organisation; they would call him for me.


That bit of information about the architect led me to put 2 and 2 together: At the time, typical CRT radar screens had a refresh rate of 5 seconds. I surmised that this was why the architect set this requirement, and that the requirement did not reflect the monitoring team’s operational needs. The architect confirmed my suspicion.


I was then shown to the monitoring suite and introduced to the two guys who monitored the systems on a 24-hour rotation. This got me thinking, “What happens when they take a break?” As you might expect, they stagger their breaks. I cheekily asked, “What happens when one of you is on a break and the other needs a bio break?” Looking a little non-plussed, one guy said, “Well, we just go.” The nearest rest room was at least a 3-minute walk away, so I estimated around 7 minutes for a round trip. If the 5-second refresh rate requirement were in effect, that would equate to 84 screen refreshes. When I pointed that out, they came to the realization that a 60-second refresh rate would be fine.


 My point—and I do have one—is that technical problems don’t always call for technical solutions; often, taking a wider view can solve an otherwise thorny problem. That’s something we should all remember in our tech-centric lives.

Many of my customers have benefited greatly from this hard-learned truism: If you don’t measure anything, everything that happens is significant. And if you measure everything, nothing that happens is insignificant.


To get full value from your business services and the software that facilitates them, it’s important to measure business services. The difficulty lies in creating a reasonable yardstick that allows everyone from the CIO to the mailroom clerk to measure how business services contribute to revenue generation and/or the organization’s goals.


That’s not the only nuance of measurement. As we covered in my last post, each business service has several components—switches, routers, database servers, web servers, application servers, etc. When I work with a company to implement CA SOI, our first order of business is to determine which business services CA SOI should monitor, and drilling down, whether all or some of a service’s components should be monitored. 


Here’s a scenario: To have a fighting chance of competing with its major competitors, XYZ Airlines wants its ticket-buying process to be as easy as possible. Like 9 out of every 10 companies that ask for CA Services’ help with monitoring, XYZ is currently not monitoring any of its business processes. XYZ’s assumption is that monitoring the network is the logical place to start.


Has your company had discussions along these lines? Rather than help you monitor the network, which either is the environment for business services and/or one component among many components of business services, I encourage customers to adjust their view and understand why it’s important to create and monitor business services.


The best way to play out the above scenario is this: A CA Services SOI expert works with the company to identify each step of the process for purchasing a ticket on (The exercise can be replicated for each step in other business service processes, such as getting seat assignments and buying products onboard the plane.) The questions we ask include, “Do we need to monitor all steps? If not, what steps are already monitored, what steps need to be monitored and what’s the best monitoring tool for each step?”


Many things have to happen on the back end for a customer to buy a ticket. The customer’s request goes to one of three or four ticket processing servers that back up one another. To create a viable business service, the Services expert needs to know how many servers there are and whether they are backed up round-robin style or lay in wait for a server to break down. The ticket purchasing software may have to go to a database to pull data from or to another website. Encryption and firewalls are necessary. Many parts of the network infrastructure are relied upon to deliver packets to and from websites, servers and databases.


The next step is to determine the metrics. What is the SLA for each business service component? The SLA is the litmus test, the quantification of each component’s importance. If the website takes 10 seconds to load a ticket, it might as well be 10 years. That needs to be flagged. Tools like APM, ASM and Spectrum quantify that response time and give alerts on response times that fall outside of the SLA. Other elements that can be measured are tests, APM calls, traffic on the network, and routers that have gone down and cause traffic to be detoured all over the world before getting to its destination.


Next up is determining which tool is the right tool for measuring each component. One of the reasons I’m so passionate about CA SOI is that it doesn’t require us to understand or plan for every contingency from the start; in that sense SOI is unique. We can start at 60,000 feet with the basic components, and as the team starts to understand the components of a business service, such as credit card processing details and other back-end intricacies, we can add devices that deal with those steps. All of these things have to work in synchronicity to create a great user experience, but with CA SOI, we don’t have to start in the weeds. The more you develop your business service, the more accurate the SLA becomes.


It’s a waste of time for a group of IT people to put 80% of their effort into finding the 20% of issues that cause 1% of the problems. The big issues are usually the issues that bring a system down. Prioritizing issues is key to success, and that’s where CA Services can help.


Learn more about CA Services and CA Application Performance Monitoring and Management.


Please comment with your experiences, questions or suggestions/requests for future posts.


The ABCs of Business Services

Posted by lunda04 Employee Sep 27, 2017

I’m hoping you’re here because you read my first post, in which I introduced myself and attempted to answer the all-important question, “Why should I even listen to you?” I’m also hoping you’re here because you want more info on my passions, CA Spectrum and CA Service Operations Insight (SOI).


In these posts, I could tackle any number of topics that would help customers who want to corral their processes for monitoring and measuring business services, and I will. But in this post, let’s talk about an issue that affects everything an organization does to improve those processes. It’s actually sort of a pet peeve of mine—the confusion about what a business service actually is.


I’m not the only consultant who has worked with customers who don’t know the true definition of a business service. Often, my first order of business when I work with customers is to help them understand what a business service is and identify their mission-critical business services, so that we can monitor and measure what really matters to their success.


So in this post, I’ll take you through the process of definition and identification—that way, you’ll be ahead of the game when your organization decides to monitor and measure business services.


Business Service: A Definition

First, let’s put an easy-to-remember, jargonless definition of business services on the table. Try this:

A business service is a service that an organization delivers to external users (customers and partners) or internal users (employees or organizational members). The components of a business service can be any combination of applications, servers, network devices, storage gear, and IT services, just to name a few. At for-profit organizations, business services are income generators that make it easier and quicker for customers to procure goods or services. At organizations that are not necessarily for profit, business services must be mission critical to organizational goals. Overall, any business service worth its salt must be a critical success factor.


To put some meat on the bones of the above definition, here are some examples: The Internet- and phone-based applications that airlines use to sell tickets, banks use to provide financial services, the U.S. Army uses to deliver real-time info to front-line forces, and retail merchants use to sell goods to consumers are all business services.


Customers often misidentify resources that support a business service, such as a network, as business services. The trick of the trade is to identify business services that are critical success factors in processes and/or applications that facilitate a given critical task.

Building Business Services

After identifying a business service, we must conduct a mapping operation that analyzes each resource that helps to deliver the business service and determines the associations and relationships these resources have with other resources.


Equally important is an analysis of how a business service would be impacted if a resource were to go down or become degraded. Lastly, we need to identify a way to quantify business service degradations and/or outages so that we can create a service level agreement, the business service’s “report card” showing how well the service is performing. This is the essence of building business services.


My next blog will discuss building a business service in more detail, so please join me then.