Dear DCML TC Members,
Below are the minutes from the August 2
and August 3 DCML TC meetings. Please let me know if there are any edits or corrections
that should be noted.
August 2, 2005
J. Darrel Thomas - EDS
Tim Howes - Opsware Inc.*
Robin Dasham - Phoenix
Zulah Eckert – BEA
Jamie Clarke - OASIS
Update on Use Case – Darrell
MSFT is reviewing material, also DT
contacted Andrea and Cisco guys regarding consolidation of efforts. Should
have feedback from MSFT regarding construct of system definition model and how
DCML should map to layers above and below.
TMF - OASIS exchange - simply have
individual member from TMF exchange information with OASIS committee
eTOM - work is in process mapping
integrated service model. Perception is that the model is too detailed and is
not conducive to easy adoption. eTOM comparison - DCML could make impact in
salient etiquette (rules) that could be used to construct name space. Rule 1 -
do not recreate data. Second step would be verification and construct
validation. There have been many standards and proprietary efforts in detecting
data but nothing that rules the data.
Configuration management problem - Having
a rule construct the data ensures standardization of configuration management
versus vendor specific approaches that is counterintuitive to this approach.
For example, naming conventions are not standardized and are focused on vendor
interpretation. Current focus has been to have a set of problem calls
go away versus making the problem go away.
Fundamental areas for comparison - DCML
is compared to CIM / WYSM - do a gap analysis.
Action Item: Possibly review use cases in
eTOM as an example – owner open?
Action Item: Robin and David to create
first pass of Laws of Configuration Basic guidelines and commandments for
creation and instantiation of data center information - allow information to be
attached is a problem - should be referenced what do we see as the most
important rules for data center.
DCML to affect the religion and base line
practice about anecdotal data configuration
Simplified mapping of the problem statement
August 3, 2005
Attendance: Zulah, Fred, Darrel, Robin,
As defined in Sun reference book, the run
book manages data center operations. This is an ITIL compliant model. Getting
people to adhere to standardized run book is one of largest issues that DCML
may need to address
Maximize standardized configuration with
some flexibility. Should read from existing element and configuration management
systems. Rule of consumption is part of control elements.
One of the current issues with
configuration management is the passivity associated with validation. The
runbook example that Robin showed provides this function but it is mostly
manual in nature and tends to be labor intensive
Proving the data is problematic. ITIL
does a good job of protecting this process
1. Rules how to create, change, and
2. Need an information/data model
This illustrates a cascading model of
what is controlled and what is not controlled.
Find what makes sense to start with the
rules based off of business needs. For example, if DCML was to focus on
standard server build processes, the resulting efforts could be registered with
ISACA as it meets processes (which are ITIL)
ITIL as process, CoBIT as adherence, DCML
as substantiation of model.
Need to have a common information model
which is how to stop data silos from occurring. It may be a difficult position
for a standards org to take. This would include capturing of library of what
configurations should be
Metadata extract aggregation structure–
how to map existing or new data within the model. Attributes that everything
within the data center would have mapped to them.
ACTION: Sarah to confirm with OASIS about
possible integration of a WIKI collaboration tool on the website to assist in
providing a forum for TC members to outline problem statements that they would
like DCML to solve.
ACTION: Face-to-face – end of August /
beginning of September either on West Coast. Initial comments indicated that
Zulah and Fred would be able to attend on these dates.