Skip navigation
All Places > CA Service Management > Blog > 2017 > March
2017

In my last post, I defined the problems inherent in blurring the lines among the domains of IT asset management, systems management and service/configuration management. 

You can help your organization avoid the confusion by clearly distinguishing among the three goals—and the groups responsible for meeting those goals. I know—it’s easier said than done—but here are some tips:

Assign a person or team to handle financial IT asset management—to account for each IT asset the organization owns. They need to receive all records of IT purchases from Purchasing and all records of discovered and managed computer systems from Systems Operations. A solution such as CA IT Asset Management, which compares the two sets of records and documents lifecycle data such as make, model, location, and status for each computer system, will be invaluable to the team.

and

Assign a person or team to handle systems management—to ensure that all network systems conform to policies. They need to coordinate with the security team for security policies, the operations team for standard configuration policies, and the software distribution team for required/allowed software, patching, and reporting. A solution such as CA Client Automation is essential for supporting these activities and discovering computer systems on the network.

and

Assign a person or team to handle services and configuration management—to minimize downtime, outages, and operational errors by governing the configuration of business-critical applications and services. They need to coordinate with the application, release management and change management teams to model the authorized configurations of new applications and services when they come online and throughout their lifecycle. A must-have for this team is a solution such as CA Service Desk Manager, which captures the authorized configurations and relationships among the components that support the application or service. Another must-have is a solution like CA Configuration Automation, which discovers the configurations and relationships of the components (such as web servers, database servers, and application servers), compares the discovered configuration with the authorized configuration and identifies gaps.

Yes, this effort requires discipline—but it can be done. Your organization will thank you.

Trap? What Trap?

The term "IT asset management" is inherently confusing. 

To some people, it might mean:

I want to manage IT assets from a governance perspective: I want to make sure the assets (desktops, servers, etc.) have a common configuration, meet my basic security policies, and have a standard set of software. (A better term for this is "systems management.")

To others, it might mean:

I want to manage IT assets from a service perspective: I want to make sure my business-critical applications are up and running, that we’ve recorded their current configuration and relationships, and that we can detect configuration changes that could affect their function or availability. (A better term for this is "service/configuration management.")

And to still others, it might mean:

I want to manage IT assets from an accounting perspective: I want to know what assets I own, if there’s a gap between the most recent inventory and my records of owned assets, and the location and status of all assets. This is “pure” IT asset management.

To recount, there are three domains: IT asset management (ownership of IT assets), systems management (governance of IT assets) and service/configuration management (governance of services/applications). 

Here's a typical breakdown of the data divisions among these domains.

In some circles and contexts, all domains are called IT asset management, which always leads to confusion and often to deployment of inappropriate software solutions.

A frequent example of this confusion is that many shops confuse a CMDB with an asset repository. A hardware asset repository should contain only physical items that have been purchased, while a CMDB contains configuration items (CIs) that represent a virtual server, a service or a process. The CMDB should contain only CIs that support a service or application, yet I often get requests from clients to include everything we can discover on the network in the CMDB.

To add to the confusion, the three domains contain overlapping data. For instance, a particular server could be an asset under financial control, a system that needs to comply with software, security and configuration policies, and a component of an application or service. So from a data perspective, it makes sense for these domains to share data, but that leads to blurring the lines among them.

The negative consequences of blurring the lines among these domains can be serious.  For example, using all of your discovery data (from systems management) to populate your CMDB (configuration management) can cause your CMDB to become unmanageably large. The CMDB will include items that don’t support critical services, and it won’t include undiscoverable components that support your services, such as processes. Using the same discovery data to populate your asset database (IT asset management) makes it impossible to audit your owned assets against inventoried assets, because you have made your database of inventoried assets your master list of owned assets. As a result, the main function of IT asset management, IT asset governance, fails.

Now that I’ve laid out the problem, you’ll want a solution. Tune in to my next post, coming soon, for my recommendations.

In the meantime, if you’ve experienced other negative consequences of blurring the lines among these domains, feel free to leave a comment.

If you’ve ever worked for, supported, or were a customer of a managed service provider, you’re probably used to reviewing service level agreements, objectives, critical success factors, KPIs, and related reports. Most customers examine recent performance, compare results to their objectives or service level agreement, and provide a historical view as to how the provider has managed the service.

 

In this post I’ll share how to go beyond stating known historical facts and metrics of a service and leverage them to achieve value realization.

 

When you look at service management proactively, you may think about knowledge, problem, and change management—but it doesn’t have to be overly complicated to the point where you need to reexamine your existing processes or methodologies. All you need to do is collect your current report types—all of them—and move from a “prove” perspective to a “show” perspective.

 

Prove: Demonstrate the truth or existence of something by evidence or argument.

Show: Allow a quality to be perceived; display.

 

Confused yet? Stay with me.

A common report you may be used to seeing is an incident response report. With this typical report, you might prove that specific support groups or individuals are (or aren’t) meeting expectations—and it could stop there. Look beyond response data to information such as categorization, time of day, and volume.

 

Categories

Since categories allow us to track and monitor areas of risk or improvement for the service, you can use category information to find areas where your service provider can add considerable value. All ticket types should be aligned to a specific category ; request and incident categorization by month and quarter should take precedence. For example, you may notice that 50% of incidents are related to the reporting category across one or more report sub-categories. That should be a red flag to take a deeper look into those tickets. To do that, engage an architect or support resource to explore workarounds or enhancements that could potentially lower the number of report-related incidents.

 

Ticket Volume

Ticket volume and time of day information can help you correlate burn rate and work effort. It can also help you correlate known environment activity such as bulk onboarding or a new release due to short-term ticket spikes. For contracts that limit the number of incident or request tickets the provider should handle during a set period of time, you and your service manager should monitor ticket volume closely. As far as burn rate is concerned, the service manager can investigate ticket volume by assignee vs. the assignee's time entry for a specific period. This is more of an internal control process to ensure that the service provider is not overcharging the customer or burning through a fixed price contract too quickly. Controlling these areas and forming a plan to combat these trends will lead to value realization over time.

 

Value Realization

Shifting from proving that objectives have been met to showing customers value by helping them mature and improve their service demonstrates that the service provider cares about quality, professionalism, and going beyond the delivery standard towards reaching long term business objectives. If your service manager doesn’t follow the above steps, your awareness of the importance of these steps can help you collaborate with him/her to deliver added value to your company. If your service manager does follow the above steps, he/she is a leader who may quickly become indispensable to your company. Show your customer value and you will both inherit the success.

The Digital Transformation of Information in the Application Economy

The end goal isn’t deploying apps—it’s successfully executing a business strategy. Traditionally, after an enterprise defines its strategy, the IT organization delivers an information lifecycle that meets business needs: an effective infrastructure (especially apps) and information and services that will meet strategic milestones.

The information lifecycle design needs to cover all aspects of the service, notably:

  • An app that supports business requirements and the app’s design lifecycle, which is its complete lifetime, from conception to decommissioning.
  • Information to feed the app, which generates additional information. The information lifecycle is the process of planning, harvesting, organizing, retrieving, using, securing, distributing, changing and disposing of information.
  • A data management lifecycle, which organizes data into tiers based on data criticality, cost and speed. Policies help automate data migration between tiers.

 

You may be thinking, “We have a well-thought-out IT service management (ITSM) strategy supported by ITIL 2011. Doesn’t that cover the business strategy and information lifecycle strategy?”

As mentioned in our previous post , the lessons of the past don’t always apply in the application economy.

The ITSM strategy differs from business and information lifecycle strategies in that most infrastructure services support the business of IT, not the larger enterprise, which demands effective processing of information captured by applications. Companies that leverage this difference are industry leaders.  

A key way that the app economy has changed ITIL and the information lifecycle is that managing information is key to delivering successful apps. As a result, ITSM strategy owners need to actively identify and develop new business services.

Because enterprises rely on IT operations, failure to involve IT from the get-go yields inadequate support of the services/apps in use or—worse—major roadblocks when testing reveals that the service/app doesn’t support business strategy.

ITSM strategy owners who want to lead their companies to app economy success need to ensure that their business unit counterparts are aware of IT infrastructure capabilities and the impact of changes to the information lifecycle.

Next steps

Next time we’ll talk about data capture and its challenges: privacy, optimization, cost, compliance, and big data. Until then, let us know how you have adapted the information lifecycle to meet your app economy needs.

The application economy is all about customers interacting with your brand through apps instead of passively experiencing traditional messaging and venues. One early lesson of the application economy is that app users rightly expect accurate, useful information.

 

Brian Johnson, Nora Osman, @RobZuurdeeg and I have co-authored a new IT service management book, ITIL and the Information Lifecycle. The book discusses information as the lifeblood of the application economy, explores ITIL’s impact on the app economy, and examines how the app economy has changed ITIL and the information lifecycle.

 

This is the first of several blogs that will give you a taste of information’s digital transformation across agile management, DevOps and security in the application economy.

 

A Reintroduction to Information Management

Consumers like apps that are simple to download, install, use and update—no training necessary. Information—an app’s engine—is processed through a lifecycle adapted to the needs of application economy companies. Information management governs lifecycle activities: planning, harvesting, organizing, retrieving, using, securing, distributing, changing and disposing of information.What we sometimes forget is that the lifecycle is the reason information management technology was created—not the other way around.Without reliable, consistent information, transactions would be inefficient. Performing standardized, repeatable actions with inconsistent or unreliable information results in untrustworthy outcomes and ill-informed decision-making. That’s why information management is so crucial in the app economy.

 

Enter the IT Service Management ITIL version 2011 lifecycle. ITIL is a framework that provides guidance on delivering IT services by walking practitioners through several stages.

 

Why Is Information Management So Important?

In IT service management, we consider information in the form of business processes (banking, manufacturing, government) and IT services (the actual apps): The process is what a company does, and services are what the company delivers.

 

A Reintroduction to Information Management

  1. Strategize (the information’s business purpose, demand, cost, value)
  2. Design (performance, security, availability)
  3. Transition (deployment, testing, change management)
  4. Operate (security access, event management, incident management)
  5. Continuously improve (reporting, monitoring)

 

Because information management is important, it’s crucial to understand the impact of the information lifecycle and ITIL on the app economy and vice-versa. As we’ll discover together, lessons of the past don’t always apply. Companies that leverage the differences will be industry leaders.

 

Next Steps

Next up, we’ll talk about how information flow affects business strategies. Until then, we welcome comments on how you’ve adapted the information lifecycle to meet your app economy needs.