Comments inline
From: Rex Brooks [mailto:rex.brooks@ncoic.org]
Sent: Tuesday, 30 November, 2010 07:58
To: peter-oasis@justbrown.net
Cc: soa-rm@lists.oasis-open.org; soa-rm-ra@lists.oasis-open.org
Subject: [soa-rm-ra] Further Thoughts: Re: [soa-rm-ra] Some initial reflections and questions
Hi Again Peter,
Before I get into my further thoughts, I want to thank you and Chris for taking on this work and sincerely hope you will agree to continue even if you don't get a mandate to rework the entire document. Remember, we spent 4.5+ years getting to this point and many of the things you bring up were considered in one form or another along the way, and, significantly, for me at least, we already have a lot of followers using parts of what we have done, so there are more reasons than simple stubbornness for not wanting to redo the whole enchilada.
[Peter:] Thanks, and understood
Now to the two specific further thoughts that arose from looking through the attachments and rereading the message:
1. Are there IPR issues with using a diagram directly from IEEE 1471?
[Peter:] ‘Fair use’ rules would apply but I’m getting legal advice on this to be sure.
If not, and as long as it is confined to Section 3 and the distinction of Ecosystem, I won't be roadkill for not adapting it, but it makes me nervous about the consequences of possibly starting a dialog between two Standards Dev Orgs. I would prefer if only the Ecosystem were shown, and not the other items since it could be construed that if we don't say how we are different from each other item, then we must necessarily be endorsing it. I would prefer keeping the distinction to words that specifically state that we are referring only to what constitutes an Ecosystem in the RAF.
[Peter:] The whole draft spec is the ‘Foundation’ not just section 3, no? This doesn’t seem clear at present, will references peppered throughout the text to “this Reference Architecture…”, rather than “the Foundation…”. Hence my question: is the RAF a collection of viewpoints that we recommend are brought to bear in defining a specific RA? If not, I am not clear what RAF “is”, beyond those viewpoints. I think it is more than an academic point – if we baldly state that an ecosystem is made up of a system, environment and stakeholders, it is difficult to argue that it also a viewpoint. There’s the rub, for me at least.
2. We have not yet introduced the "design/designer" viewpoint. I don't think it is helpful to introduce it now. My &.02, the architect is the designer.
[Peter:] This underlines my point that there is another significant actor other than consumer (expressing ‘need’) and producer (offering ‘capability’) in any SOA system: ‘need’ has to be captured, formalised and engineered into a solution, the capability. That seems to be what we’re getting at with ecosystem, but IMO it does throw up a concern about how loosely we are using ‘viewpoint’.
Cheers,
Rex
On 11/29/10 7:47 PM, Peter F Brown (OASIS Individual Member) wrote:
Hi:
Chris Bashioum and I have now been through the whole RAF drafts dated 28 July and 17 November, as well as the mass of materials submitted separately, discussed on list and at various TC meetings.
Before we commit to a series of specific edits, we would like a “reality check” on some of our reflections, to be sure that we are all on the same page. I would like us to discuss the numbered points below at our meeting this Wednesday. Based on feedback from that meeting, we can proceed with the detailed proposals for the “strawman”…
If you reply on the list (encouraged in advance of the meeting) – please
indicate which of the following points you are replying to – this will make threading conversations on the separate points easier.
avoid sending us marked up copies of the word document – instead quote the line number(s) from the 11 Nov text (line numbers with tracked changes on and markup visible – yes, they change otherwise)
Here we go:
We propose to edit and remove all conversational style in the text. This document is a proposed standard, not an essay.
Avoid “use/mention” constructions, except in the introduction: “You should do x”, rather than “This document describes how you should do x”.
We propose to include Figure 1 from the IEEE 1471 document – (the diagram of the conceptual model of architectural description) as it helps clarify both the terms used and the context of the RAF.
We want to make a clearer distinction between the IEEE 1471 definition of “system” and the proposed RAF definition of “ecosystem”. The IEEE document states that “..the term system encompasses individual applications, systems in the traditional sense, subsystems, systems of systems…whole enterprises, and other aggregations of interest” – which could be understood also by the term ‘ecosystem’. Instead, and to be clear, we propose to understand RAF “ecosystem” to encompass the IEEE concepts of System, Environment, Stakeholder, and (possibly) Mission. Is this a correct assumption? We could highlight this in an annotated version of the IEEE diagram.
We have concerns about the definitions, scope, and naming of the three ‘viewpoints’. Before addressing those, however, we would like to gain “buy-in” for the following:
The IEEE standard defines both the term viewpoint and library viewpoint - “A viewpoint definition may originate with an [Architecture Description], or it may have been defined elsewhere. A viewpoint that is defined elsewhere is referred to in this recommended practice as a library viewpoint.”. Our question is therefore, in the terminology of IEEE - Is the RAF a “set of library viewpoints recommended for use (as viewpoints) in the description of a reference architecture”?
See attached annotated IEEE diagram that captures these two ideas.
WRT to specific viewpoints outlined in the RAF, we see a distinction between viewpoints 1 and 3 that use essentially UML static models; and viewpoint 2 that uses dynamic models. Viewpoint 1 (“Service Ecosystem”) addresses and explicitly references enterprise constraints and context in which a system will be developed and is concerned with definitions and ownership; Viewpoint 3 (“Owning SOA”) also covers enterprise constraints but more from concern with governance in the broadest sense; Viewpoint 2 (“Realizing SOAs”), on the other hand is concerned with applying enterprise optimizations and constructing, exposing and interacting with services: this viewpoint makes more use of dynamic models. Colloquially, we could talk about viewpoints 1 & 3 being about “doing the right thing”, whereas viewpoint 2 is about “doing things right”. This brings us to a crucial question:
Is the Service Ecosystem strictly speaking a viewpoint or an amalgam of (parts of) viewpoints? If we take ecosystem to encompass the IEEE concepts above (service + environment + stakeholders + possibly mission) then it cannot also be a viewpoint (except possibly at a meta-level, and we don’t want to go there). A viewpoint should reflect a “related set of concerns”. We identify three distinct sets of concerns that, today, are rolled up into one, viewpoint “service ecosystem”. Although there may be overlap with the other two viewpoints (‘Owning SOA’ and ‘Realising SOA’), it might be more accurate to explicitly reference these three sets, currently implicit in service ecosystem, as three viewpoints - broadly speaking reflecting:
Consumer concerns – how to represent the various ‘universes of potential consumers’ (‘consumer archetype’?); how services/capabilities are ‘discovered’ and ‘understood’ by potential consumers, how to model consumer ‘needs’ and ‘goals’ (if it is indeed possible); and test/determine when that need is met through delivery of some RWE by a service;
Design concerns – how consumer needs are captured and formalised as system design requirements;
Producer concerns – how to represent capabilities (for example as service descriptions) and test whether a capability brought to bear as a service actually delivers the RWE that a consumer needs.
This triangle, of ‘need > requirement > capability > need’, for us sums up the essence of SOA: whereas requirements and capabilities are often modelled to ‘mirror’ the respective roles of consumer and producer, the consumer rarely participates in defining requirements but is seeking satisfaction for a need (requirements that are defined, measured, etc. elsewhere). I’ve tried to capture this in the informal sketches attached.
Best regards,
Peter
+--------------------------------------------------------------+
| Peter F Brown |
| Independent Consultant |
| Transforming our Relationships with Information Technologies |
| www.peterfbrown.com |
| @pensivepeter |
| P.O. Box 49719, Los Angeles, CA 90049, USA |
| Tel: +1.310.694.2278 |
+--------------------------------------------------------------+
---------------------------------------------------------------------
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