Skip navigation
All Places > CA Infrastructure Management > Blog > 2017 > September
2017
lunda04

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. 

lunda04

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.

As SaaS-based solutions become more prevalent, the traditional solution architect’s role—articulating and delivering solution designs—is becoming obsolete. Many ancillary tasks that go with this core skill, such as platform sizing and effort estimation, will also fade away as SaaS takes hold.

 

So do these developments mean that architects no longer add value to software solutions?

As an architect who loves his job and wants to stay employed, I’m glad to report that the answer is a resounding “No!”

Just as so many other jobs have evolved and adapted to the application economy, solution architects need to bring their other skills to the forefront. From my perspective, it’s a simple case of doing more of the activities we had to sacrifice when we were so busy designing solutions. But here’s the real revelation (and the good news for architects and clients alike): These other activities are just as essential to solution success as good design, and we should find time for them even in non-SaaS implementations.

I would hazard a guess that everyone reading this post has lived through a situation in which a carefully designed solution loses value over time due to poor adoption. Who better than an architect, who knows a given solution inside and out, to add value to the team using the solution through training, troubleshooting and management? Architects have seen some organizations fail and others succeed, and they can share best practices with your organization to make sure it falls squarely in the latter group.

SaaS solutions are not dogged by implementation complexity and long delivery times; they usually are evaluated and pressed into production almost immediately. As a result, customers may not have run through their budget. Wise customers don’t funnel all of the remaining funds to another initiative; instead, they apportion part of it to keep an architect on to assist with rollout and adoption. This is where the solution architect can really add value at little cost.

You may be saying, “This still requires the architect to work side by side with the customer on configuration, people and process as we have always done.” But consider this: Most customer user groups are distributed, so the architect needn’t be on site, which of course saves travel costs.

Working remotely, architects can live with customers’ solutions on a daily basis, using the plethora of communications tools available to us. We can be part of their team—when they need us—and use our wealth of experience to progress them on their solution journey. Just as a SaaS solution offers a subscription service for software, the architect can offer a subscription service for his/her experience. This is a much more fluid, effective model for our journey with the customer than ad hoc, infrequent visits with them when they are stuck on an issue. We can be with the customer every step of the way to ensure that their success is maximised.

As SaaS becomes the norm and customer knowledge declines due to redirection of resources to on-premise solutions, the architect is the front line in ensuring that customers have continued success with SaaS solutions.