RE: [dcml-appserv] Datacenter Service Hierarchy

[Andre Kramer <andre.kramer@eu.citrix.com>]

The hierarchy should also capture middleware services. Obviously, terminal services and MetaFrame presentation server should be a modeled layer. I'm also a member of the OASIS WSRP TC and Portlets as well as their producer & consumer services are another form of user facing presentation services.

 

Regards,

Andre

 

Andre Kramer,

Citrix Systems, Inc.

 

---

From: Thomas, Darrel [mailto:darrel.thomas@eds.com]
Sent: 20 December 2004 02:38
To: 'Mark Darbyshire'; Barak Perlman; dcml-appserv@lists.oasis-open.org
Subject: RE: [dcml-appserv] Datacenter Service Hierarchy

 

hello Barak/Mark,

 

I think we're on the same page with the hierarchy, I'd like to see it in diagrammed form with definitions, as we were attempting to do such at our last DCML.org mtg.  I believe that Industry Services are directly pointed at vertical business sectors that are repeatable in their domain (I.e., Healthcare, Travel and Transportation, Government, Security & Privacy, Manufacturing, Automotive, etc.).  These in turn are decomposed into Business Process Services, then decomposed to IT Services (or App/Web Services) to IT Services, to Resources/ManagedElements.

 

Another thought would be to look at the ITIL aspects as parts of the Framework section of DCML, which is where the management oversight happens that would govern inputs from Apps/Services.  I'd like to see other opinions here...

 

So, would Printing and Directory Services be considered foundational IT Services?  Likely.  how about AAA, or IT domain Services, such as Network IP Services, or Storage compositive services (on TOP of a storage resource, SAN, port, IP address, etc.).

 

we should enumerate a comprehensive list to to the hierarchy correctly...

 

jDT

 

BTW, I also believe that we should leave human resources out of the work right now - we're trying to discern the electronics ready aspects of DCML.  the human aspects are the dynamics that inhibit the standardization, but must be factored in their relationships to managed things in the environment that DCML articulates. 

 

---

From: Mark Darbyshire [mailto:markd@tibco.com]
Sent: Sunday, December 19, 2004 6:58 PM
To: Barak Perlman; dcml-appserv@lists.oasis-open.org
Subject: Re: [dcml-appserv] Datacenter Service Hierarchy

Barak,

I'll add my view. I understood Business to have its normal 'non-technical' meaning and that (as we're all in IT) an IT Service would be a possible implementation of a component or function of such and such a business. Example: I think CRM is a component of an IT implementation of the business of a call center. This is obviously not the only use of a CRM and equally a call center can be implemented without one. So, in short, I support your new hierarchy, but I would like to see a seperation (still) of Business Process and IT Service. Also, I think we've tried to keep humans out of this so far.

As an aside, I think we've kept humans out of the DCML purview. I for one would like to continue in this vein. What do others think?

I hope I've provided some clarification,

MarkD.

Barak Perlman wrote:

Hi,

 

Following our discussions from last week I want to comment on the Datacenter Service Hierarchy presented.

This actually relates to the definitions of the terms we use.

The terms used in the proposed hierarchy are:

• Industry
• Business
• IT Service
• Resource -> ManagedElement

 

There are no suggested definitions for those terms (not any that I found in the DCML docs that is).

 

I looked for reference at the terms used in the ITIL for example:

Industry - isn't defined

Business - isn't an item by itself (a business unit is for example)

Service (referring to IT service)

Resources

 

System

Host is what we call a server, including the application running on it

 

I suggest we first define the following:

• Everything one can manage can be a ManagedElement, not just the Resources. An IT service, one is sure to manage, for example can be a ManagedElement as well.
• As suggested, a resource can be any combination of resources as well.
• An IT service is easily defined. It could also be comprised of a combination of any IT services.
• By a business I think we should refer to an IT service that serves a business purpose. The term that was used was Business Process Service, why not keep it?
• Industry still needs better definition

 

Specific examples would get us going easily...

• A server is a resource
• A bunch of servers are yet another resource
• A Storage device is a resource
• An IT personnel is a resource
• A web service is an IT service
• A naming service is an IT service
• Printing is an IT service
• CRM is a business (I suggest we call it a business process service)
• A call center is a business (I suggest we call it a business process service)

 

Some questions and suggestions

• As the name of the TC goes - what is an application?
• I think that by application we actually refer types of Services
• How do we relate to the Networking TC?
• Is Networking a Resource?
• Is Networking a Service?
• I suggest we let Networking be a combination of Resources and Services
• How do we refer to the SW application part of the service?
• We defined the web application by a group of resources but the web application doesn't have to be part of the resources
• How do we refer to the web application SW?
• We can enlarge the server resource as the ITIL does to include the application it runs. This would mean that a service is comprised of physical resources, logical resources (i.e. application SW) and human resources
• How do we differ between IT services and business process services?
• I think we should allow both of them to be types of services
• The only difference is the User/Customer perspective
• This means that Business Process Services are just another type of services

 

The new proposed hierarchy looks like:

• Industry (needs better definition)
• Services - Business Process Services, IT services
• Resource - Physical Resources, Logical Resources, Human Resources

Where all of the above can be ManagedElements.

 

Barak Perlman

VP R&D

             

Direct  +972 3 608 1604

Office   +972 3 607 4243

Fax      +972 3 607 4242

Cell      +972 545 245 604

 

-- 

Mark Darbyshire, Ph.D.

Senior Solution Consultant,

TIBCO Software

Phone: +1 9175433099 / +33 688457575