Rex:
Thanks for the feedback and some personal comments inline
Peter
From: Rex Brooks [mailto:rexb@starbourne.com]
Sent: Tuesday, 30 November, 2010 07:22
To: peter-oasis@justbrown.net
Cc: soa-rm@lists.oasis-open.org; soa-rm-ra@lists.oasis-open.org
Subject: Re: [soa-rm-ra] Some initial reflections and questions
My concern: Is this a proposal to rewrite the whole document?
[Peter:] No
If so, we can't do that. As I understood it, we were aimed at Section 3 only, with the definitions from, except as explicitly changed according to the meeting notes since, the 7-28-2010 Snapshot.
[Peter:] We’re not pruning a tree as much as weeding a garden. Pruning involves bring the tree back to a shape that we recognise and we are happy with; Weeding involves digging out stuff that shouldn’t be there in the first place and mustn’t take root. I don’t want to stretch the metaphor too far – suffice to say there are lots of inter-connects between sections that have to be rendered as a coherent whole. Before doing that, I want to be sure that some premises and assumptions were clear and agreed.
My concern with IEEE in relation to the testing section applies here and anywhere else as well. As long as we don't require its usage, I'm fine. As soon as we do that, we impose a financial burden on anyone wishing to use the RAF.
[Peter:] I agree. RAF Section 1.3.1. states that “This Reference Architecture follows the ANSI /IEEE 1471-2000 and ISO /IEC 42010-2007 standard”. “Follows”, not “conforms to” – I believe that gives us latitude to explain why using and following 1471 makes sense (I think it does, as long as we do so consistently) and quote/include excerpts to demonstrate this (under fair use rules). The relationship with IEEE 829 would be a little more complicated as implementation of it might
require use of subject matter covered by patent rights, as the standard itself explains.
Danny’s earlier question needs to be answered first and clearly: what part(s) of the proposed section on testing is foundational and architecture? Indeed, what is being tested? The alternative might be a separate document/white paper/TC spec as you hint
I wholeheartedly agree with deleting the conversational prose style, just not a requirement to apply it to the whole document.
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
--
Rex Brooks
President, CEO
Starbourne Communications Design
GeoAddress: 1361-A Addison
Berkeley, CA 94702
Tel: 510-898-0670