OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

soa-rm-ra message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [soa-rm-ra] SOA RA Management Section


I think that we will schedule some time tomorrow to discuss the mgt section
On Sep 14, 2010, at 1:57 PM, Hestand, Dan wrote:

> Boris,
> 
> You are absolutely correct! The problem I've encountered is that so little thought is put into the management aspects because there is the belief that traditional IT management can be used. This creates an imbalance because of several factors but including bad or misleading metrics, applying inappropriate management to certain elements, or even plain losing track of some things.
> 
> BTW, I received your comments but have not had an opportunity to thoroughly consider them. I apologize for the delay in letting you know this. Thank you for the input, too.
> 
> Dan Hestand
> Lead Software Systems Engineer
> The MITRE Corp
> 781.271.3755
> phestand@mitre.org
> 
> 
> -----Original Message-----
> From: Lublinsky, Boris [mailto:boris.lublinsky@navteq.com] 
> Sent: Monday, September 13, 2010 3:39 PM
> To: Hestand, Dan; Laskey, Ken; soa-rm-ra@lists.oasis-open.org
> Subject: RE: [soa-rm-ra] SOA RA Management Section
> 
> Dependencies management becomes a double edged sword. On one hand a service is opaque to its user and its functioning is visible only to service implementer. On another hand, an implementer does care a lot about dependencies. I assume that from the ecosystem point of view this becomes a balancing act. 
> 
> -----Original Message-----
> From: Hestand, Dan [mailto:phestand@mitre.org] 
> Sent: Monday, September 13, 2010 1:46 PM
> To: Laskey, Ken; soa-rm-ra@lists.oasis-open.org
> Subject: RE: [soa-rm-ra] SOA RA Management Section
> 
> Ken,
> 
> Thanks for the response. I'll try to address your questions here:
> 
> I don't expect that there should or will be a single lifecycle used by all. In fact, there are probably multiple lifecycles involved in just a single organization. However, 1) Consideration for how to manage the lifecycle of services must be made, and 2) those considerations must be reconciled or have some mapping into the larger concerns of the ecosystem. It is a (hard) part of governance to ensure that those concerns have been clearly defined and agreed within the ecosystem.
> 
> The main goal of management in the SOA ecosystem should be to create an environment in which all of the participants present a consistent picture of managed capabilities. To do otherwise could undermine trust, particularly if there is a perception of inequitable treatment. So governance specifies what it requires of participation within the ecosystem with respect to management such that there is consistency in the data and representation. Management then uses that consistency to support the operation of the ecosystem through e.g., enforcement or at least alerting of SLA violations. Management must ensure conformance to governance policies and record/report incidences of non-conformance. In the case of peer-peer environments, the question of who this information is reported to must be resolved through governance policies.
> 
> What I was trying to convey with the "description of dependencies" is the need for management services to potentially have insight into dependencies that are generated within the ecosystem, not within the implementation of services because management is concerned with the global view of the ecosystem. In this regard, I believe management services have a somewhat privileged status (despite my fair and equitable clauses), and because of that also require careful consideration about what access is permitted to the management information. If the management services consume data that might not be available to other services, then the infrastructure must protect that information. What is made available to non-management consumers is processed to a normalized form that is appropriate for activities such as service discovery. The limits to transparency, I think, are to perhaps only consider first order dependencies, i.e., those that are immediately adjacent in a dependency graph. Certainly that is what most systems I've seen do. If you manage the first order dependencies of each node, then any changes or effects can be propagated through those connections to their immediate dependencies. I understand the limitations of this but practically it's easier and ultimately makes use of the trust inherent in the ecosystem (assuming no malicious intent).
> 
> Summary: Management in the SOA ecosystem should not overly constrain capabilities but should state requirements for what's expected. Because of the unique perspective management (and security) have of the ecosystem, there may be a need for a more detailed understanding of the ecosystem.
> 
> Maybe more verbiage than you expected but I'm still in dissertation mode. Sorry! I hope I've at least answered your concerns.
> 
> Dan Hestand
> Lead Software Systems Engineer
> The MITRE Corp
> 781.271.3755
> phestand@mitre.org
> 
> -----Original Message-----
> From: Laskey, Ken 
> Sent: Monday, September 13, 2010 12:14 PM
> To: Hestand, Dan; soa-rm-ra@lists.oasis-open.org
> Subject: RE: [soa-rm-ra] SOA RA Management Section
> 
> Dan,
> 
> Thanks for getting this out.  In general, it seems pretty consistent with
> what else we've been saying throughout the PR2 document, but I'll leave it
> to those more involved in management to debate details.
> 
> The one part where I'd like some clarification is Lifecycle Management.  In
> particular, are you saying there has to be be one lifecycle used by
> everyone?  From current experience with numerous agencies, I know that will
> not fly.
> 
> When you talk about "managed capabilities applicable to a SOA ecosystem",
> can these be structure or underlying assumptions that guide specifics
> generated by individual organizations, with the intent of having some
> consistency in what is generated and how it is represented?  For example,
> Lifecycle Management in concept may be fundamental but different groups may
> have different defined lifecycles or different levels of detail for specific
> parts of the lifecycle, e.g. developers having more development details.
> Management could define "requirements" of a lifecycle without specifying THE
> lifecycle.
> 
> One other point: when you talk about "a description of the dependencies", to
> what extent is this hidden by opacity?  A provider says a service average
> availability over, say, a 4 wk period will be at least 92%.  The provider
> knows its dependencies and states 92%, and the consumer trusts that number
> (or not) based on information that is limited in detail at some level.
> Furthermore, if A depends on B and C, and B depends on D and E, and C
> depends on ..., stating "all" dependencies doesn't scale.  Where should we
> have visibility and where does opacity set in?
> 
> Ken
> 
> ---------------------------------------------------------------------------
> Dr. Kenneth Laskey
> MITRE Corporation, M/S H305              phone: 703-983-7934
> 7515 Colshire Drive                                    fax:
> 703-983-1379
> McLean VA 22102-7508
> 
> 
> -----Original Message-----
> From: Hestand, Dan [mailto:phestand@mitre.org] 
> Sent: Friday, September 10, 2010 12:57 AM
> To: soa-rm-ra@lists.oasis-open.org
> Subject: [soa-rm-ra] SOA RA Management Section
> 
> I'm delivering the management section in a standalone form. It is not in the
> template form so I did not want to put it directly in the site because it
> doesn't fit in any bin there. It also does not include UML models. I have
> purchased MagicDraw Personal Edition but given the time and the other
> demands on my priority list, the images will have to follow with the correct
> template format later.
> 
> I apologize for not getting this out earlier but I was diverted by a tasking
> that was marketed as a high priority.
> 
> Anyway, here it is. Take it apart. It resembles the old section in structure
> because I made my notes as I read through the old section and that is the
> order they came in. It contains material that I feel is necessary to say
> about management and its relationship to other aspects of SOA. I also took
> liberties with the term "Manageability Capability" which I find cumbersome
> and not very informative, mostly because to me "manageability" is a
> capability and adding "capability" to it is like naming an interface
> TheInterface interface. My opinion, so feel free to disagree. Much of the
> stuff is from my experiences going into different organizations and seeing
> things that were either appalling or enlightening. Odd that it was never
> moderated to the middle of those.
> 
> Feel free to email me directly with comments, criticisms, or questions. Or
> we can do it in the telecon later.
> 
> Thank you for your patience.
> 
> Dan Hestand
> Lead Software Systems Engineer
> The MITRE Corporation
> phestand@mitre.org
> 781.271.3755
> 
> 
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 
> 
> 
> 
> The information contained in this communication may be CONFIDENTIAL and is intended only for the use of the recipient(s) named above.  If you are not the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this communication, or any of its contents, is strictly prohibited.  If you have received this communication in error, please notify the sender and delete/destroy the original message and any copy of it from your computer or paper files.
> 
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
> 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]