SOA-RAF meeting on time today [was: [IEEE-P1723-discuss] comments on TOG

Ken,
This is good, sorry I couldn't get comments back to you.
I'm in Phoenix this week and my ignorance of US geography and time zones meant that I overlooked a clash of meetings. I am chairing a 2-hour meeting starting at 11.45, so will basically only be able to make roll-call and quorum, little more...apologies

Best regards,
Peter

Sent from my phone - apologies for brevity and typos: it's hard writing on a moving planet

From: Ken Laskey
Sent: 05/02/2013 20:21
To: IEEE P1723 Discussions
Subject: [IEEE-P1723-discuss] comments on TOG SOA RA

I have just completed my review of The Open Group SOA RA. (My apologies for considerably lagging the IEEE schedule, but my major focus had been getting the OASIS SOA-RAF to Committee Specification.) The following comments focus on several points that were previously noted.

Overall, there is a lot of insight and good information in this document but it is a very difficult read as structured. Part of this relates to the previously raised questions on the use of Layers, and the following will raise some specific areas where difficulties in understanding arise. Secondly, a set of comments will note the need for clarification on how this document applies "in an organization" vs. cross-organization or enterprise.

This email will also give suggested actions for TOG and IEEE.

1. Layers, Capabilities, ABBs

- The document is written with an emphasis on "layers" as an essential organizing principle; however, the document provides no explanation of the criteria for identifying a layer or how layers interact. Diagrams such as Figures 9 and 10 are useful to show which ABBs interact but the layer in which the ABBs reside does not provide greater context or clarity. Moreover, one could take the interacting ABBs and completely reassign the layers (or remove the layers altogether) and the information conveyed by the figures would remain essentially the same. For example, the Integration Layer includes mediation, messaging, and logging/auditing. These are all essential pieces but why are these in this layer rather than in their own layers or part of another one? Why aren't all the event-related ABBs in an Event Layer? The text often uses the construct of "the abc ABB in the xyz Layer" but the layer phrase does not provide any distinguishing value.

- Capabilities get captured as an undifferentiated list inside layers and have insufficient context. For example, in section 14 (Quality of Service Layer), authentication, authorization, encryption, and auditing (capabilities 9-12) are separated from access control aspects (capabilities 21 and 22). The presentation has the capabilities at the same level without any indication that some are at a lower level of granularity and contribute to others at a higher level. In the Integration Layer, the "ability to authenticate/authorize for service invocation and message routing" is listed as a capability, but it is not clear until later that this is not a major contribution of this layer but is related to access control and other ABBs that will be introduced even later.

- Some ABB definitions contain a great deal of detail, often providing context for themselves and numerous other ABBs; it would be very useful if this information was given more prominence than being embedded in the ABB detail. Other ABBs have minimal information that leaves many questions. For example, the Legacy System ABB detail only states "this ABB describes the legacy systems running in the Operational Systems Layer". Is this ABB only for description? Does this ABB generate a description? What constitutes this description? Where does one find this description?

- The level of detail throughout the document is not applicable to all likely readers and it is not easy for a particular audience to find material most relevant to their needs. For example, my experience has often been with projects interested in basic search and basic retrieval, especially enabling this in a consistent manner across distributed sources that they can access but do not own. Where is basic search? Where is basic retrieve? What service or combination of services enables someone to do this?

It would likely be more useful for the material to be partitioned by role (e.g., a consumer of information services) and the activities of interest to those roles. What activities are of interest to a developer and where do developers need to immerse themselves in detail for their contributions? (Infrastructure developers may have different interests than composition developers.) What activities are of interest to consumers and their needs? Where do we make use of opacity so the consumer role sees outcomes with little, if any, knowledge of the developer details? That would make the read a lot easier for consumers and for developers. Then, given an area of interest, what ABBs come into play? When there are common ABBs across roles, like security, the text should make the commonalities obvious rather than appear redundant.

*** Suggestions for TOG: At a minimum, provide explanation of what constitutes a layer and give rules/guidance for how layers interact. When introducing a list of capabilities, note when these are major contributions of the current layer being discussed vs. capabilities which primarily originate in other layers. Try to minimize redundancy when giving lists of capabilities and the corresponding ABBs. If possible, take interaction detail that often falls in the x.3 and/or x.4 sections and use this explanation as a basis for providing context across layers before getting into the sections with each layer's details. This would focus more on business activities rather than a bill of materials.

*** Suggestions for IEEE: TOG may not want to take on a restructuring of the document along the lines of roles and associated activities. However, this may be added value that can be a focus of IEEE work. In addition, IEEE should consider other suggestions given above that TOG may not wish to address.

2. Organization vs. ecosystem

- There are numerous places where the document talks about "in an organization" and it is unclear how the point applies in a SOA ecosystem that spans organizations. Some examples are:

-- The Information Aspect is responsible for manifesting a unified representation of the information aspect of an organization …

-- SOA Governance ensures that the services and SOA solutions within an organization are adhering to …

-- This ABB enables organizations to organize, govern, and manage their valuable assets scattered throughout the enterprise and to encourage re-use of existing assets within the organization.

-- … provide their own sub-architecture for managing the flow of data across the organization.

- Terms such as organization, enterprise, and the SOA ecosystem need to be defined with respect to each other. Given these terms, when do items discussed "in an organization" naturally extend across organizations and where are additional challenges (and possibly ABBs to address these) likely needed?

- Figure 21 shows a common adapter used by two different service components. This seems to imply a shared entity at the coding level rather than common access through a service. Would a more cross-organization approach be to use Adapter 2 as part of a service that enables access to Application 2 and then any consumer, including service compositions, could leverage the single service? This would also avoid propagating changes to different instances of Adapter 2. How does the process shown in Figure 21 or the suggestion above differently support interaction outside a single (or multiple tightly bound) organization(s)?

- Governance is a particularly challenging area when we are trying to coordinate among independent entities with their own rules and processes. Much of the discussion in the RA implies (even if it is not explicitly stated) that there is a "top" (e.g., CIO) to the organization and everything is coordinated (mandated?) from the top rather than among independent contributors.

*** Suggestions for TOG: Explicitly address how references to "an organization" relate to multiple interacting organizations. This may be possible through a definition and then consistent use of terms or may be able to be explained in a dedicated, overarching section. Uses of the term organization should be considered for whether any limitations are implied.

*** Suggestions for IEEE: Work by IEEE, whether a direct derivative of TOG SOA RA or separately developed, should consider whether items are equally applicable across organizations as they are within a single organization.

The TOG SOA RA shows the results of significant work by people having a close interchange of ideas. Any such documents (including the ones produced by the OASIS TC) then have the challenge of being accessible to an audience beyond its authors and their shared understanding. The comments in this email are meant as a collection of observations from someone for whom the content should be accessible and useful, augmenting existing knowledge and providing insights. I hope the comments provide ideas for both TOG and IEEE going forward.

Ken

---------------------------------------------------------------------------
Dr. Kenneth Laskey
MITRE Corporation, M/S H305 phone: 703-983-7934
7515 Colshire Drive fax: 703-983-1379
McLean VA 22102-7508

soa-rm-ra message