Skip navigation
All Places > CA Infrastructure Management > Blog > Authors lunda04

CA Infrastructure Management

5 Posts authored by: lunda04 Employee

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.

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.

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. 


Why should you read my blog?

Posted by lunda04 Employee Sep 18, 2017

Good day to all in this, my first blog post. I’m Dan Lundwall, a principal Services consultant with CA. Since joining CA in March 2006, my emphasis has been on two products, CA Spectrum and CA SOI.


Because I’ve often read blog posts that lead me to ask, “Why should I listen to you?” I thought I’d tell you a bit about my background and experience.


In 1994, I had worked at a health provider services company in Salt Lake City, UT for 15 years, dealing with the more difficult datacom issues. As the senior data communications analyst, I was tasked with finding an enterprise management system to manage our network and WAN environments. I invited four major players to our company and gave them exactly one week to implement a proof of concept implementation of their respective network management solutions.


The only company that provided a viable solution was Cabletron Systems, with their product called Spectrum. I was absolutely amazed by what Spectrum could do. For the first time I saw in near real-time not only WHAT my network looked like, but also HOW it was performing. Most important for me, I saw root cause analysis at work.


With no hesitation, I purchased Spectrum. I liked the solution so much I joined Cabletron in 1996 as a Spectrum engineer. I’ve been enjoying the ride ever since!


In 2006, CA Technologies purchased Concord (which had acquired Aprisma, the software arm of Cabletron)—and I moved to CA along with Spectrum. In this job, I get to help organizations with their enterprise management requirements by bringing my 23 years of experience to bear.


Why did I take your valuable time to lay out my Spectrum experience? To demonstrate that I’ve been on both sides of the aisle, as it were: I was a customer for much longer than I’ve been a vendor. 


Why is this important? Because it gives you a sense of how I work with customers. As a customer, I demanded a lot from my vendors. When a vendor promised something, you can bet I held him or her to it. If they were 1 minute late to a meeting, I canceled the meeting and found another vendor who came to meetings on time. It didn’t take long for vendors to understand that I held them to a much higher standard than most customers.


Customers have every right to demand the best from vendors. In fact, vendors should demand the best from themselves—otherwise, they won’t be vendors for very long. I know what it’s like to be a customer: That’s why I’m so passionate about delivering what I promise.


Just as my experience and customer-oriented perspective are the inspiration for my work with customers, they will also inspire my blog posts. And that’s why I think it will be worth your time to listen to me. I’m also very interested in listening to you, so I welcome your comments on this post and my upcoming blogs around CA Spectrum and CA SOI.