Michael,
I had a chance to look through this and have some overall comments.
- At line 2318, you added some words on risk but it seems strange where placed because it’s followed by a list of benefits and then followed again by a list of risks. Any reason your text shouldn’t be an addition to the list of risks?
- Need a clearer connection to having maintainable connections (not just text to be edited) from service description to collected information needed for management. Consumers (including those creating compositions) need information to determine sufficiency of service considering. Management will have an interpretation of this information but not necessarily the final word.
- In section 5.3, there are a bunch of short blurbs on an endless set of manageabilities. What I get is life cycle manageability is the ability to manage life cycles, …, X managemeability is the ability to manage Xs. Does the elaboration through some 400 lines really add anything that couldn’t concisely be presented as a bullet list in one page?
- Is the term service contract used the same way as in other parts of the document? This term has a lot of use in the vendor and user world but little firm understanding beyond the idea that a WSDL defines an interface. This often gets swallowed in SLAs. I think we need to take this on at some point and I haven’t checked to see whether other discussion in sections 3 and 4 are sufficient.
- In section 5.3.5, the detail on what constitutes infrastructure is beyond the scope of the RAF. However, the immediately following list of things needed for service management is thought-provoking, but it should not be presented as a complete list.
- How is section 5.3.6 different from what is in the section 5.3 life cycle chunk and how should it relate? (Above, I questioned whether the 5.3 detail is needed.)
There seems to be a few things on which we need to focus:
- Management to operationalize governance
- Monitoring so you have data from which to get status and make decisions
- Specific things to manage in a SOA ecosystem that weren’t of consequence in traditional systems
Capability to manage seems to require policies from governance translated to rules and regulations that get to specifics and then measurement and feedback on the specifics.
Ken
---------------------------------------------------------------------------
Dr. Kenneth Laskey
MITRE Corporation, M/S H305 phone: 703-983-7934
7515 Colshire Drive fax: 703-983-1379
McLean VA 22102-7508
Gentlemen,
I have modified Management Concept section and offer it for your review.
The modification are based on the RAF version: Editors’ Draft, 17-01-2011 (Starting Point: Draft 04 21 Dec 2010).
I have incorporated together my own changes, the text prepared by Dan Haston and the comments received from Boris.
(In this version, one service is still considered as a potential resource for another service, i.e. I have not changed the definition of 'resource' in our Glossary)
All pages of the attached document are split into two parts - the original text of Editors’ Draft, 17-01-2011(left-hand side) and modified text (right-hand side). All modifications are written in blue. The line numbers in the modified text (right-hand side) should be ignored.
The texts comprise 3 parts:
· first part contains fragments that precede the Management Concept section but refer to management
· second part is the Management Concept section itself ( the full text )
· third part contains fragments that follow the Management Concept section and refer to management (mainly in Glossary)
In addition to changes related to management, I have used (and correspondingly defined) a new term that allows us to clearly distinguish between technical/IT 'system' and 'SOA-based system' scoped enterprise-wide: I proposed and have used the term SOA-based solution. The term 'solution' carries a connotation of combination of technical and manual/human/business means.
I hope to discuss attached document in the next Telcon if agenda permits.
Regards,
- Michael