Re: RE: RE: [soa-rm] about PoSO and Microservices

["Mike Poulin" <mpoulin@usa.com>]

William,

 

Question 1: I understand the line of your thoughts. but cannot fully agree with it. 'Abstract' architectue is deeper than it seems at a glance: this is about architectural models, competing models, srchitectural solutions based on business capabilities (e.g.) that include planned resources (not realised yet), and alike. An Architecture follows certain principles while arbitrary implementations of the Architecture allow (themselves) certain deviations from those principles. Architectural Governing aims to returning the implementation under those principles.

 

When we talk about SOA, we mean Architecture. There are 2 types of debts: architectural and implementational/development. Architectural debts are the deltas between an adherence to the principles + ontology and comporomised architectural solutions (grounded onto contextual reality). Development debts are the deltas between architectural solutions and their implementation that deviates from the specified models, principles + ontology.

 

Thus, ontology is anout what should be; specification is what it is afterwords. I think, what I said above fits with your "Once you place an actual, real physical components in the architecture it becomes an implementation." Thus, we have to define the ganularity of abstraction to be enforced before we may put "real physical components" in place.

 

Question 2: I agree with you. Still, what is a variation of SOA? Recall modern definition of Business Process, which includes 1)(full) logic of the process execution; 2) promised functionality and anticipated RWE; 3) intermediary interfaces with SLAs for communication between the process' steps and the environment. A change in the logic of the process results in creating a new process, not its variation. IMO, only certain chnages in the  interfaces and SLAs lead to process variations.

 

 

Regarding ISO 704:2009(E) in your explanations, it seems to me a bit updide-down. SOA is about functionality and meta-data; data itself is a lower concern. A SO Archtiecture in your example is a Mouse; an Architectural model is a Multi-Button Mouse. What are the properties and what are the characteristics so far in the Architectural model? OK, a property is a number of buttons, thier colour, shape, etc. Characteristics are quality of serface, light reflection, sensitivity to a touch, etc.

Why "The purpose of the abstraction is to identify common features in a set of properties."? IMO, a purpose of the abstraction is defining certain functionality and the outcome (RWE) - they both go first; the properties are aspects of a specification for implementation; I do not see any abstraction in properties. Moreover, "delimiting characteristics differentiates concepts" sounds to me like a child differentiates parents. Delimiting characteristics differentiate implementations of the same concepts.

"The set of characteristics that form a concept is the intension of the concept" - yes,  set of characteristics form form something; why it is the initial concept and its intension and not something totally different?

 

- Michael

 

Sent: Wednesday, September 30, 2015 at 3:13 PM
From: "Sweet Jr., William H" <wsweet@mitre.org>
To: "'Mike Poulin'" <mpoulin@usa.com>, "Natale, Bob" <RNATALE@mitre.org>
Cc: "soa-rm@lists.oasis-open.org" <soa-rm@lists.oasis-open.org>
Subject: RE: RE: [soa-rm] about PoSO and Microservices

Mike,

 

Question 1. If the issue is the literal difference  between architecture vs architecture implementation, IMO  this is  the same question as: abstract class vs concreate class; virtual method vs implemented method. Abstract and virtual are signatures with no real, concrete implementation. An architecture starts abstract, describing types of entities, but listing no actual entity. Once you place an actual, real physical components in the architecture it becomes an implementation.

 

Question 2. The boundaries of SOA and categories of entities included within SOA (the extension of the SOA concept) speaks to how we define the concept of SOA. I continue to be surprised how difficult and technical it is to define an seemingly simple concept. Defining types and variations of SOA will be a significant exercise.  

 

I cannot immediately answer the SOA boundary question. I can suggest a methodology which will produce an answer. I rely upon ISO standards in Data Harmonization and Terminology. To begin with ISO 704:2009(E) Terminology Work – Principles and Methods,  Concepts have properties. For analysis of a concept, the properties are abstracted to characteristics. The purpose of the abstraction is to identify common features in a set of properties. For example, given the concept of a mouse. Mouse1 has the property of 1 button, Mouse2 has the property of 2 buttons. The abstracted characteristic is a mouse has one or more buttons. Similar concepts have shared characteristics, delimiting characteristics differentiates concepts. Identification of the concept’s unique combination of characteristics helps defines the concept and situates the concept within a network of related concepts. The set of characteristics that form a concept is the intension of the concept. The set of objects included within the concept is the extension. Necessary characteristics are true for all objects in the extension of the concept. A sufficient characteristic may not be true of all objects in the extension, but any object that has a sufficient characteristic is within the extension. For example, the concept woman has numerous characteristics. Not all women have given birth. However, being human and having given birth are sufficient characteristics to belong within the extension of the concept woman. Essential characteristics are both necessary and sufficient.  

 

 

 

From: Mike Poulin [mailto:mpoulin@usa.com]
Sent: Wednesday, September 30, 2015 6:00 AM
To: Natale, Bob <RNATALE@mitre.org>
Cc: Sweet Jr., William H <wsweet@mitre.org>; soa-rm@lists.oasis-open.org
Subject: Re: RE: [soa-rm] about PoSO and Microservices

 

William,
your suggestion raises serious questions that are the cornerstones of many debates on this topic. Actually, there are two fundamental questions, IMO:
 
1) Where an Architecture ends and its Implementation starts?
          - for this, I have a definition of an Architecture that many consider too restrictive (because it clearly surfaces fallacy claims of the architecture subject vs. discipline. E.g., ‘people’ is not an architectural element, though it is very important to the operations of a business/technology system)
 
2) What are the boundaries of service orientation? If a certain category of entities adheres to _only_ a few PoSO, not to all, may it be considered service-oriented and to be a Variation of SOA or this is a Variation of SOA Implementation (then, who cares!?..). What constitutes that we still deal with a Variation of SOA or ‘this’ is not SOA already?

 

- Michael

 

 

Sent: Tuesday, September 22, 2015 at 2:16 PM
From: "Natale, Bob" <RNATALE@mitre.org>
To: "Sweet Jr., William H" <wsweet@mitre.org>
Cc: "soa-rm@lists.oasis-open.org" <soa-rm@lists.oasis-open.org>
Subject: RE: [soa-rm] about PoSO and Microservices

Excellent advice, William. (Needs to be adopted in many other contexts by many other groups and individuals.)

 

Avanti,

BobN

 

From: soa-rm@lists.oasis-open.org [mailto:soa-rm@lists.oasis-open.org] On Behalf Of Sweet Jr., William H
Sent: Monday, September 21, 2015 8:21 AM
To: 'Mike Poulin' <mpoulin@usa.com>; Rex Brooks <rexb@starbourne.com>
Cc: soa-rm@lists.oasis-open.org
Subject: RE: [soa-rm] about PoSO and Microservices

 

Very informative article! I am wondering how we can help the industry reach this level of specificity in understanding  the relationship between SOA and the various implementation “styles”.  REST, ServiceComputing, Microservices and more are variations of SOA which are always susceptible to an interpretation  which separates the variation from the main body of SOA work, resulting in “reinventing the wheel”. To help the industry avoid this, perhaps we should include in our SOA ontology a subclass of SOA tentatively named Style or Variation, which is then specialized for each variation capturing what makes the variation unique. Perhaps this would help eliminate some confusion currently found in discussions of variations.

 

William

 

From: soa-rm@lists.oasis-open.org [mailto:soa-rm@lists.oasis-open.org] On Behalf Of Mike Poulin
Sent: Sunday, September 20, 2015 7:26 AM
To: Rex Brooks <rexb@starbourne.com>
Cc: soa-rm@lists.oasis-open.org
Subject: [soa-rm] about PoSO and Microservices

 

Gents,

here is my short overview on how Microservices "compliant" with Principles of Service Orientation

Regards,

- Michael