RE: [public-xg-usdl] <none>

You have it exactly right.

 

Ken Blackwell
VP & Chief Architect, Service Assurance

CA Technologies
Tel: +1 203-733-5381
Ken.Blackwell@ca.com


 

From: Oberle, Daniel [mailto:d.oberle@sap.com] 
Sent: Thursday, March 31, 2011 3:56 AM
To: Blackwell, Ken; public-xg-usdl@w3.org
Subject: RE: [public-xg-usdl] <none>

 

Dear Ken,

yes makes sense and I got the idea. One could represent such information as "capabilities" in the functional module. This would look something like

 

<Service>

...

    <Name>Gmail</Name>

   ...

    <FunctionalElements>

      <Capabilities>

        <Capability>

          <Name>1GB Mailbox size</Name>

         ...

        </Capability>

        <Capability>

          <Name>10 preprocessing rules</Name>

         ...

        </Capability>

 

Although structured and "at the right place", this solution is of course quite "loose" since it basically boils down to free text hindering comparability.

The ideal would be domain-specific extensions of the language which are at the heart of variant management (cf. other threads in the mailinglist). Attributes such as mailbox size then should become part of the language looking something like this

 

<Service>

...

    <Name>Gmail</Name>

   ...

    <FunctionalElements>

      <Capabilities>

        <Mailbox >

          <size>1 </size>

         <unit>GB</unit>

         ...

 

I assume the latter would be the preferred solution for you since comparisons are facilitated? 

The solution we proposed for variant management would allow users or some "consortium" to extend USDL via tool support incl. government.

 

Best regards,

Daniel

 

 

 

From: Blackwell, Ken [mailto:Ken.Blackwell@ca.com] 
Sent: Dienstag, 22. März 2011 21:44
To: Oberle, Daniel; public-xg-usdl@w3.org
Subject: RE: [public-xg-usdl] <none>

 

Hi Daniel, 

 

Sorry to be slow in responding.  Have been slow in everything lately as am very busy.

 

To your question, we generally think of cloud services at a higher level than IaaS.

While nothing should preclude a service comparison at a lower level, we think the urgent problem is much higher.

 

So, rather than thinking of EC2, it might be most constructive to consider Gmail vs. Yahoo Mail vs HotMail as our use case.

 

Some attributes of functional comparability might be:

1)      Total mailbox size

2)      Number of configurable preprocessing rules

3)      Integrations with Facebook and other social media

4)      Browsers supported

5)      Mobile devices supported

6)      Min/Max/Average times from message received by the service until it shows in the inbox

7)      Ability to block an incoming address

8)      Web service APIs available for integrations with other apps

9)      ...

 

Obviously most of these are specific to a particular class of service (Email), but USDL should have the ability to embed custom metadata attributes and for particular types of services (email, ERP, Payments processing, whatever) the industry can then coalesce around common attributes for a specific type of service based on industry specific standards, whether formal or defacto.

 

Make sense?

 

Ken Blackwell
VP & Chief Architect, Service Assurance

CA Technologies
Tel: +1 203-733-5381
Ken.Blackwell@ca.com


 

From: public-xg-usdl-request@w3.org [mailto:public-xg-usdl-request@w3.org] On Behalf Of Oberle, Daniel
Sent: Tuesday, March 08, 2011 7:32 AM
To: public-xg-usdl@w3.org
Subject: RE: [public-xg-usdl] <none>

 

Dear Ken,

thanks a lot for your explanation. As mentioned yesterday in the telco I deem this use case as one out of two required "implementations" of USDL for continuing down the path of W3C.

 

I got a good high-level idea out of your explanations so far. I'd be interested in a concrete example, however. Say Service A is amazon's EC2 and Service B is a similar one by a competitor. As you have written below you would like to compare if they are functionally similar. So what would you consider "functional" in the case of amazon EC2? 

 

Best regards,

Daniel

 

From: public-xg-usdl-request@w3.org [mailto:public-xg-usdl-request@w3.org] On Behalf Of Blackwell, Ken
Sent: Mittwoch, 2. März 2011 21:21
To: public-xg-usdl@w3.org
Subject: [public-xg-usdl] <none>

 

Hi All,

I have had on my list for some time now to email the group some information and perspectives from IT management point of view.  Finally cleared a few days on my calendar to concentrate on this and my book chapter...

First, some background.  CA Technologies is in the system management encompassing system monitoring, automation, security, and a host of other domains.  We are investing very heavily in the cloud space across all of our domains.  One of the most important new developments from CA is what we call Cloud Commons and the Service Measurement Index or SMI.

You can read all about it at: http://www.cloudcommons.com/servicemeasurementindex/-/asset_publisher/M69c/content/how-smi-scores-are-calculated-and-what-they-mean?redirect=http%3a%2f%2fwww.cloudcommons.com%2fservicemeasurementindex%3fp_p_id%3d101_INSTANCE_M69c%26p_p_lifecycle%3d0%26p_p_state%3dnormal%26p_p_mode%3dview%26p_p_col_id%3dcolumn-2%26p_p_col_count%3d1

The Clould Service Measurement Initiative Consortium, lead by Carnegie Mellon University in Silicon Valley has taken ownership of this proposed standard so it is not unique to CA.

So what is SMI?  It is a set of business-relevant Key Performance Indicators (KPI's) that provides a standardized method for measuring and comparing business services.  It looks at things like performance, reliability, cost, and other quality metrics to provide an overall rating of the service so that two similar services can be compared.

The inputs to Cloud Commons SMI is observed, either human or machine, KPI data that is entered by the community.  The idea is to replicate for cloudl service ratings what Amazon has done for rating products on its website.  Over time, let the community coalese around an opinion of a service based on real-world observations.
The community can then go to Cloud Commons and look at community ratings to decide which of  set of "similar" servcies best suites their needs for a particular purpose.

And that is the rub; that word "similar".  I have complained for some time that we are focused on grading two services, say A and B, to compare their fitness for a particular business purpose based on observations of IT metrics, but we have not addressed the the upfront problem of determining if A and B are functionally "similar".
We have tended to gloss over that question and focus on what we do well which is monitoring and measuring IT metrics.

After complaining about this problem for some time internally to CA, I was asked by our CTO to join the USDL effort to help work towards a solution..

I am going to be focused on providing feedback to this team on the comparability aspects of services defined in USDL.  This is related to searching which is already identified as an important aspect of USDL.
Ideally, i would like to come up with a way to augment the SMI score with a something like a Service Equivalency Index that can advise the consumer of how similar two services are.  

I hope this provides some context and a complimentary point of view to the group.  My availability to focus on this effort varies greatly from week to week, so I probably won't be as consistent as I would like, but I'm always monitoring the effort and happy to hear your feedback to the ideas above.

Regards,

Ken Blackwell
VP & Chief Archtiect
Service Assurance Business Unit
CA Technologies
+1 (203) 733-5381