-----Original
Message-----
From: Andre Kramer
[mailto:andre.kramer@eu.citrix.com]
Sent: Monday, December 20, 2004
6:17 AM
To: 'Thomas, Darrel'; 'Mark
Darbyshire'; Barak Perlman; dcml-appserv@lists.oasis-open.org
Subject: RE: [dcml-appserv]
Datacenter Service Hierarchy
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:
- 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