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

Within the Service Desk Manager's "Web Screen Painter" (WSP) there exists an option "Schema Designer". This feature allows you to create custom database tables and columns, which you can use within Service Desk Manager.

 

I've compiled a few useful documents for the Communities that provide some details on how the Schema Designer works, as well as some useful things to look into in case you run into an issue.

 

1. You can find the full documentation on the Schema Designer here:

How to Modify Schema Using Web Screen Painter - CA Service Management - 14.1 - CA Technologies Documentation 

There's a lot of information how to use the tool.

 

2. This document provides some additional information on some things to look into if the schema publish fails:

Web Screen Painter schema modification - How it works and what to check if it goes wrong. 

 

3. This document provides some specific details for using the schema designer in an environment with Advanced Availability enabled:

How to Perform Schema Changes using Web Screen Painter on Advanced Availability Configuration 

No one is more important than our customers. That is why we need your feedback on the CA Service Management solutions and our support of them.

We recently launched a Customer Feedback Survey for CA Service Management (includes CA Service Desk Manager). This few-minute survey enables us to gauge your satisfaction with the product and our support of it. Thank you to those of you who have already completed the survey. But we need to hear from more of you! 

Our CA Service Management product team, including Product Management, Product Marketing and Support, reads each and every survey submission to help make our solutions and support better.

So please take a few minutes and complete this survey by clicking on the Survey icon below.

Click Image to
Complete Survey

Make sure to, click the "Finish" button at the bottom of the last page of the survey to submit your responses.

We're looking forward to hearing from you!

New All-Session Guide (Attached file)Click to View

Make sure to check out the attached new Service & Asset Management

All-Session Guide. Here you can view all titles, speakers, dates, times and

locations for the sessions. The guide can:

 

  • Help you decide whether to attend
  • Help you justify attending
  • Help you decide what sessions to attend
  • Be a useful resource to print and carry with you at CA World

 

You can also visit the on-line CA World Session Catalog for more details and where you can find the Agenda Builder to set up your schedule for CA World.

 

Meet Hundreds of CA Service Management and CA IT Asset Manager Colleagues

If you haven't yet registered for CA World, do it now and join the hundreds of ITSM and ITAM attendees who have registered so far.  If you haven't been to CA World before, it is more of a user group than a conference; information and idea exchange and education are key objectives. There is tremendous value connecting with this many peers, with CA executives, and with CA's service desk, service catalog, SLM and ITAM experts from Product Management, Services, Engineering and more.  Click here to register.

In times past the only avenue for communication to Service Desk Manager through web services involved using SOAP calls. More recent releases now also provide the ability to communicate through REST web services calls, and in fact the Service Management mobile application communicates via REST as well. After deploying REST you may wish to test the communication, but aren't sure how. I'd like to highlight a very useful document that provides a detailed step by step guide on how to use the tool "SoapUI" to test RESTful web services calls. If you're starting to prepare to use your own REST applications, or plan to use the mobile app, this is a great guide to assist in your testing.

 

Is there a tool I can use to test CA Service Desk Manager REST Web Service functions? 

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.