Skip navigation
All Places > CA Service Management > Blog > Authors arcda02

CA Service Management

4 Posts authored by: arcda02 Employee

In the IT universe, we have continuous integration, continuous testing, continuous delivery, continuous deployment, and continuous service improvement, just to name a few. The overall intent is to automate as much as possible to reduce risk and, yes, bring continuous business value.

 

If you follow DevOps, you probably have a good grasp of the meaning and significance of most of these terms. However, you may not know as much about continuous service improvement (CSI), since it’s not typically mentioned in the same breath with the others. In official ITIL books, CSI is described as a key phase and good practice in implementing IT service management. In this post, I’ll provide a definitive description and talk about how CSI should be used in conjunction with the other “continuous” buzz phrases mentioned above. For dessert, I’ll throw in some thoughts on how CSI fits into the scrum framework.

 

CSI is a phase that a service goes through in the IT service management lifecycle. (Other ITIL phases, which are out of scope for this post, include service strategy, service design, service transition and service operations.) The goal of CSI is to ensure that a service will continue to align to an organization’s business needs, even as those needs change. CSI uses knowledge management good practices that transform data into information then into knowledge and finally into wisdom, which is used for implementing the correct improvements. Using metrics to identify and implement improvements to IT services that support business processes, CSI is also a great way to determine an IT service provider’s performance by quantifying the provider’s value.

 

Ready, Set, Go

 

Step 1 of the seven-step CSI process is identifying the strategy for improving the service. Identifying the strategy requires us to understand and define the organization’s goals and vision for the improvement and how the improvement would impact business needs.  

 

Step 2 is the very important step of defining what should be measured, a step that will drive the metrics on which we build reports. For reports to be truly useful, we need to define—up front—the services we should measure, why we should measure them, their key performance indicators, and how a successful service would perform. 

 

Step 3 is creating a metrics baseline. To do that, we need to determine who uses the services and when and how they are used.

 

Step 4 moves us from raw data to information by processing the service’s data from, say, a gap analysis. In step 5, we analyze the data and compare it against goals we defined in step 1. We use the quantifiable knowledge to determine if we were successful in making an improvement.

 

In step 6, the results are presented to stakeholders. We determine action plans, road maps, etc. 

 

In step 7, the improvements are implemented.

 

At that point, the process begins again, focusing on improvements to new or existing services. 

 

 

CSI and the Scrum Framework

 

As a CA Services architect who designs and implements our solutions, I appreciate using an industry good practice such as CSI to quantify ROI and/or a service improvement and demonstrate an implementation’s success.

 

However, can CSI, an IT operations process, be integrated into a scrum framework or DevOps process? To answer this, let me walk you through a typical scrum process:

 

  • To get the ball rolling, a product owner, who represents the end user, has a product improvement idea and convinces stakeholders to fund the improvement: CSI step 1 helps here. 

 

At that point, a scrum master is engaged to facilitate the sprint that will deliver the product improvement. A delivery team (engineers, architects, etc.) decides how to do the work. The product owner, scrum master, and delivery team make up the scrum team. The scrum team has roughly 30 days (a sprint) to deliver the product improvement. To get there, they take these steps:

  • The product owner creates a product backlog of requirements or user stories: this is a good place to apply CSI step 2. 
  • The rest of the scrum team refines, updates and prioritizes the user stories. The delivery team develops a release plan that maps user stories to sprints and develops the code, architecture, and infrastructure. The team identifies tasks, discusses issues, makes cost and timeframe estimates and implements continuous integrations and continuous delivery processes. The team also defines what “done” is: CSI steps 3 and 4 help with these processes. 
  • Once the tasks are complete, stakeholders are invited to a sprint review, which typically includes a product demo and a walk-through of user stories: This aligns well with CSI steps 5, 6 and 7.

 

The last phase of the scrum framework is the sprint retrospective, in which the scrum team reflects on recent improvements, identifies how it can become more efficient and makes adjustments for the next cycle.

 

CSI is not only a useful tool in and of itself; it also can help us facilitate and manage the scrum framework. To continue this conversation, please visit me at CA World 2017, where I will present a session on leveraging ITIL to quantify business value (session AMT32T) or connect with me on Twitter @DarrenArcangel or LinkedIn.

The Digital Transformation of Information in the Application Economy: Part 5 of Five

Before we can manage data, we have to understand and define it. Here we’ll highlight a couple of aspects of data management across these lifecycles. Our new book, ITIL and the Information Lifecycle, gives more detail.

IT organizations need a clear understanding of what data means to its users. Whether data comes from a tablet, smartphone, or even a mainframe, data definition needs to be obvious and meaningful to everyone concerned.

The Big Picture: Your Application Portfolio

Apps are written to manage and transform data into knowledge. When designing data for an app, developers work from a vision of the data that the app will use. For example:

  • A customer orders a tee shirt online
  • The customer registers a complaint online: the shirt arrived in the wrong size
  • After the customer returns the shirt, the customer service rep initiates the process to send a new shirt in the correct size

A data model—a blueprint of an app’s entities, attributes and relationships—helps us visualize those entities, attributes, and relationships and communicate how the data work together:

  • Entity: an object such as a customer, product (the tee shirt), or flight reservation
  • Attributes: the entity’s characteristics, like the shirt’s size
  • Relationships: associations among entities, such as between a customer and the online customer service rep.  

The challenge is designing apps that integrate with and add value to a company’s app portfolio. When one app’s business rules or end-user requirements differ from another department’s, the apps’ data models are incompatible.

That’s when developers need to step back to gain a broader vision and establish corporate-wide data definitions, which are essential in enforcing standards that facilitate application integration. A data model can provide a relatively simple abstraction of a real-world environment—in this case, your app portfolio.

Application Data Models and IT Service Management

Data models are stored in database management systems. Objects (“entities” in databases and “services” in CMDBs) run in memory in web and application servers; they are secured and distributed across the infrastructure. IT departments manage and deliver these assets in the form of services.

To manage service quality, IT departments use best practices known as IT Service Management. For instance, if the service desk needs to assess a change’s impact on an application, it uses a service-level configuration model, a specific type of data model in a CMDB that aligns relationships and attributes to services.

Since the model is at the service level, it helps IT assess the change’s impact, plan releases and orchestrate migration of apps across environments.

So data models help us visualize and communicate a real-life application environment and configuration models help us understand relationships among services, applications, and infrastructure. Data flow across application development and IT Service Management help us meet service-level targets, capture changes to an application or service, improve adherence to standards, and identify costs.

In case you missed it, here are the links to part one, two, three and four.

Questions? Comments? 

The Digital Transformation of Information in the Application Economy: Part Three of Five

 

We all know that sound business decisions require a single version of the truth. And anyone who has worked on large-scale enterprise data warehouse projects knows that capturing data presents numerous challenges.

Data from business units don’t necessarily provide sufficient context because the data aren’t centrally managed. Another challenge: Shadow IT departments in separate business units often lack governance and serve only unit needs.

Of course, the ultimate goals are a targeted, enterprise-wide growth strategy that works for all units, ensuring efficiency across all units and aligning to corporate data standards, quality and sources.

 

Compliance with Data Regulations is Key

Another challenge is regulatory compliance, a critical requirement for most companies. Because non-compliance may mean financial penalties, all units, including IT, need to adopt compliance policies.

Data privacy challenges are especially daunting, and the data privacy discipline is experiencing a digital transformation. Smartphone apps capture personal identifiable data that app creators must protect; encryption safeguards can be established, but collection and storage are in digital format by default.

 

Data’s Business Value Can Change the Game

Organized data drives the strategic analysis and decision-making that fuel growth. Business leaders must understand their entire service portfolio and draw the line on what’s in and what’s out.

Decisions should emphasize market conditions, the demand for services, and the cost of business assets. The challenge, of course, is in the details—the data we need to collect, store and analyze.

In the first blog in this series, Rob Zuurdeeg and I wrote that success in the app economy depends on managing the information that powers our apps. Our second blog concentrated on information lifecycle design. Next, we’ll discuss data organization and knowledge management best practices.

 

Until then, we’d love to hear from you if you’ve encountered challenges other than those discussed here.

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.