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

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.