Issue 18688: UPDM DoDAF lacks a concept for Service Orchestration (updm-2-0-rtf) Source: Thematix Partners LLC (Mr. Lonnie VanZandt, lonniev(at)gmail.com) Nature: Enhancement Severity: Significant Summary: Of the available DoDAF Service concepts, neither ServiceAccess nor ServiceDescription is an adequate concept for expressing collaborations of multiple Services such as one does in a SOA ServiceArchitecture. The lack of a concept like HighLevelOperationalConcept, say "ServicesOrchestration" or "ServicesCollaboration", for the SvcV-1 makes it difficult in UPDM DoDAF to model SOA Service Architectures. One has to borrow an instance of concept called "ServiceAccess"--which is poorly named and which suggests the means of accessing a single entity--and then claim that the borrowed ServiceAccess instance is really only an abstraction for representing a particular instance of an orchestration of multiple Services. One names it with its type as, say, "Service Orchestration for Situation X : ServiceAccess", and then uses its StructuredClassifier and its BehavioredClassifier natures in order to draw the orchestration of multiple ServiceAccess properties just as one uses UML's composite structures metamodel to model similar collaborations for Highlevel Operational Concepts, Systems Internal Interface Descriptions for systems collaboration in CapabilityConfigurations, SysML IBDs, and etc. ServiceDescription is a derivation of ArchitectureDescription that is, itself, an extension of Package. The intended purpose of ServiceDescription is for the documentation of the purpose and of the elements of a Service. Because of this documentary intention and because Package is not intended to be a suitable metaclass for the modeling of composition hierarchies, ServiceDescription, too, is not appropriate for the concept here called "ServicesCollaboration". Recommendation: either add <<SOAML::ServiceArchitecture [Collaboration]>> directly into UPDM or add <<UPDM::ServicesCollaboration [Class]>> to UPDM so that one can model Services in Composite hierarchies like they can model conceptually similar collections of parts in contexts in other notations. Resolution: Revised Text: Actions taken: April 25, 2013: received issue Discussion: End of Annotations:===== m: webmaster@omg.org Date: 25 Apr 2013 13:47:44 -0400 To: Subject: Issue/Bug Report X-Brightmail-Tracker: AAAAAA== X-Brightmail-Tracker: AAAAAA== ******************************************************************************* Name: Lonnie VanZandt Employer: No Magic, Inc mailFrom: lvanzandt@nomagic.com Terms_Agreement: I agree Specification: UPDM Section: 8.2.1.2.4 FormalNumber: dtc/2012-12-17 Version: 2.1 Doc_Year: 2012 Doc_Month: December Doc_Day: 17 Page: 207 Title: UPDM DoDAF lacks a concept for Service Orchestration Nature: Enhancement Severity: Significant CODE: 3TMw8 B1: Report Issue Description: Of the available DoDAF Service concepts, neither ServiceAccess nor ServiceDescription is an adequate concept for expressing collaborations of multiple Services such as one does in a SOA ServiceArchitecture. The lack of a concept like HighLevelOperationalConcept, say "ServicesOrchestration" or "ServicesCollaboration", for the SvcV-1 makes it difficult in UPDM DoDAF to model SOA Service Architectures. One has to borrow an instance of concept called "ServiceAccess"--which is poorly named and which suggests the means of accessing a single entity--and then claim that the borrowed ServiceAccess instance is really only an abstraction for representing a particular instance of an orchestration of multiple Services. One names it with its type as, say, "Service Orchestration for Situation X : ServiceAccess", and then uses its StructuredClassifier and its BehavioredClassifier natures in order to draw the orchestration of multiple ServiceAccess properties just as one uses UML's composite structures metamodel to model similar collaborations for Highlevel Operational Concepts, Systems Internal Interface Descriptions for systems collaboration in CapabilityConfigurations, SysML IBDs, and etc. ServiceDescription is a derivation of ArchitectureDescription that is, itself, an extension of Package. The intended purpose of ServiceDescription is for the documentation of the purpose and of the elements of a Service. Because of this documentary intention and because Package is not intended to be a suitable metaclass for the modeling of composition hierarchies, ServiceDescription, too, is not appropriate for the concept here called "ServicesCollaboration". Recommendation: either add <> directly into UPDM or add <> to UPDM so that one can model Services in Composite hierarchies like they can model conceptually similar collections of parts in contexts in other notations. From: "Levine, Leonard Frederick (Len Levine @ DISA) CIV DISA EE (US)" To: Lonnie VanZandt CC: Juergen Boldt , "issues@omg.org" , "updm-2-0-rtf@omg.org" Subject: RE: issue 18688 -- UPDM 2.2 RTF issue Thread-Topic: issue 18688 -- UPDM 2.2 RTF issue Thread-Index: AQHOQpRHd28T7qdAekKnl1GFXVa4LpjtLBdw Date: Mon, 29 Apr 2013 13:12:17 +0000 Accept-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [214.21.83.188] X-Virus-Scanned: amavisd-new at omg.org Content-Transfer-Encoding: 7bit Wouldn't this issue be ripe only "when" UPDM (or successor UAFP) addresses orchestration under BPMN? In UPDM 4.0 requirements? Under UPDM 5 Year plan, BPMN Profile may not come until "UPDM 4.0 (UAEP) RFP issued [around] Mar 2015". See " c4i/12-12-05: UPDM 3.0 roadmap slides", December 2012, Slide 21, OMG Member Only site http://www.omg.org/members/cgi-bin/doc?c4i/12-12-05.pdf Len Levine Defense Information Systems Agency (DISA) ATTN: Leonard F. Levine /Code EE31 P.O. Box 549 Ft. Meade, MD 20755-0549 Room A4B57D Telephone: 301-225-7497 Mobile: 703-861-4822 NEW E-MAIL (June 2012): Leonard.F.Levine.civ@mail.mil -----Original Message----- From: Juergen Boldt [mailto:juergen@omg.org] Sent: Friday, April 26, 2013 11:38 AM To: issues@omg.org; updm-2-0-rtf@omg.org Subject: issue 18688 -- UPDM 2.2 RTF issue From: webmaster@omg.org Date: 25 Apr 2013 13:47:44 -0400 To: Subject: Issue/Bug Report X-Brightmail-Tracker: AAAAAA== X-Brightmail-Tracker: AAAAAA== ******************************************************************************* Name: Lonnie VanZandt Employer: No Magic, Inc mailFrom: lvanzandt@nomagic.com Terms_Agreement: I agree Specification: UPDM Section: 8.2.1.2.4 FormalNumber: dtc/2012-12-17 Version: 2.1 Doc_Year: 2012 Doc_Month: December Doc_Day: 17 Page: 207 Title: UPDM DoDAF lacks a concept for Service Orchestration Nature: Enhancement Severity: Significant CODE: 3TMw8 B1: Report Issue Description: Of the available DoDAF Service concepts, neither ServiceAccess nor ServiceDescription is an adequate concept for expressing collaborations of multiple Services such as one does in a SOA ServiceArchitecture. The lack of a concept like HighLevelOperationalConcept, say "ServicesOrchestration" or "ServicesCollaboration", for the SvcV-1 makes it difficult in UPDM DoDAF to model SOA Service Architectures. One has to borrow an instance of concept called "ServiceAccess"--which is poorly named and which suggests the means of accessing a single entity--and then claim that the borrowed ServiceAccess instance is really only an abstraction for representing a particular instance of an orchestration of multiple Services. One names it with its type as, say, "Service Orchestration for Situation X : ServiceAccess", and then uses its StructuredClassifier and its BehavioredClassifier natures in order to draw the orchestration of multiple ServiceAccess properties just as one uses UML's composite structures metamodel to model similar collaborations for Highlevel Operational Concepts, Systems Internal Interface Descriptions for systems collaboration in CapabilityConfigurations, SysML IBDs, and etc. ServiceDescription is a derivation of ArchitectureDescription that is, itself, an extension of Package. The intended purpose of ServiceDescription is for the documentation of the purpose and of the elements of a Service. Because of this documentary intention and because Package is not intended to be a suitable metaclass for the modeling of composition hierarchies, ServiceDescription, too, is not appropriate for the concept here called "ServicesCollaboration". Recommendation: either add <> directly into UPDM or add <> to UPDM so that one can model Services in Composite hierarchies like they can model conceptually similar collections of parts in contexts in other notations. Juergen Boldt Director, Member Services 109 Highland Ave Needham, MA 02494 USA Tel: 781 444 0404 x 132 fax: 781 444 0320 www.omg.org [] smime.p7s smime.p7s X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on saturn.nomagic.com X-Spam-Level: X-Spam-Status: No, score=-38.1 required=4.1 tests=ALL_TRUSTED,HTML_MESSAGE, TJ_DODAF,TJ_UML,TJ_UPDM autolearn=disabled version=3.2.5 Date: Mon, 29 Apr 2013 11:41:28 -0600 From: Lonnie VanZandt Reply-To: lvanzandt@nomagic.com Organization: NoMagic, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 To: "Levine, Leonard Frederick (Len Levine @ DISA) CIV DISA EE (US)" CC: Lonnie VanZandt , Juergen Boldt , "issues@omg.org" , "updm-2-0-rtf@omg.org" Subject: Re: issue 18688 -- UPDM 2.2 RTF issue X-Enigmail-Version: 1.5.1 X-Virus-Scanned: amavisd-new at omg.org X-Brightmail-Tracker: AAAAAA== X-Brightmail-Tracker: AAAAAA== BPMN process orchestration is related but separate. This issue addresses the difficulty in modeling SOA Service Architectures within UPDM, or any collection of collaborating externally-acquired services. Regarding the roadmap, Slide 17, the SOA capabilities are shown as appearing in 2007 in DoDAF v1.5. Therefore, this issue is addresses existing capabilities within DoDAF and UPDM and not future ones. Furthermore, we are soliciting issues against the current implementations of UPDM and the UDPM team will then triage those and schedule the votes on their resolutions as appropriate to honor the roadmap. (It is not the responsibility of the individual raising the issue to withhold issues until the implementation reaches applicable roadmap milestones.) I went looking for some supporting material to illustrate to what I am referring when I am speaking about "Service Architectures". I found some material and these two come from an Intergraph powerpoint. My area of concern is "Big SOA" as the second graphic illustrates. Lonnie VanZandt Chief Architect No Magic, Inc. Mailstop: 700 Central Expressway S, Suite 110, Allen, TX 75013 Office: 637 Witter Gulch Rd, Suite 425, Evergreen, CO 80439 Direct: 303-900-3048 Fax: 303-482-2943 Email: lvanzandt@nomagic.com Skype: lonnie.vanzandt On 4/29/2013 7:12 AM, Levine, Leonard Frederick (Len Levine @ DISA) CIV DISA EE (US) wrote: Wouldn't this issue be ripe only "when" UPDM (or successor UAFP) addresses orchestration under BPMN? In UPDM 4.0 requirements? Under UPDM 5 Year plan, BPMN Profile may not come until "UPDM 4.0 (UAEP) RFP issued [around] Mar 2015". See " c4i/12-12-05: UPDM 3.0 roadmap slides", December 2012, Slide 21, OMG Member Only site http://www.omg.org/members/cgi-bin/doc?c4i/12-12-05.pdf Len Levine Defense Information Systems Agency (DISA) ATTN: Leonard F. Levine /Code EE31 P.O. Box 549 Ft. Meade, MD 20755-0549 Room A4B57D Telephone: 301-225-7497 Mobile: 703-861-4822 NEW E-MAIL (June 2012): Leonard.F.Levine.civ@mail.mil -----Original Message----- From: Juergen Boldt [mailto:juergen@omg.org] Sent: Friday, April 26, 2013 11:38 AM To: issues@omg.org; updm-2-0-rtf@omg.org Subject: issue 18688 -- UPDM 2.2 RTF issue From: webmaster@omg.org Date: 25 Apr 2013 13:47:44 -0400 To: Subject: Issue/Bug Report X-Brightmail-Tracker: AAAAAA== X-Brightmail-Tracker: AAAAAA== ******************************************************************************* Name: Lonnie VanZandt Employer: No Magic, Inc mailFrom: lvanzandt@nomagic.com Terms_Agreement: I agree Specification: UPDM Section: 8.2.1.2.4 FormalNumber: dtc/2012-12-17 Version: 2.1 Doc_Year: 2012 Doc_Month: December Doc_Day: 17 Page: 207 Title: UPDM DoDAF lacks a concept for Service Orchestration Nature: Enhancement Severity: Significant CODE: 3TMw8 B1: Report Issue Description: Of the available DoDAF Service concepts, neither ServiceAccess nor ServiceDescription is an adequate concept for expressing collaborations of multiple Services such as one does in a SOA ServiceArchitecture. The lack of a concept like HighLevelOperationalConcept, say "ServicesOrchestration" or "ServicesCollaboration", for the SvcV-1 makes it difficult in UPDM DoDAF to model SOA Service Architectures. One has to borrow an instance of concept called "ServiceAccess"--which is poorly named and which suggests the means of accessing a single entity--and then claim that the borrowed ServiceAccess instance is really only an abstraction for representing a particular instance of an orchestration of multiple Services. One names it with its type as, say, "Service Orchestration for Situation X : ServiceAccess", and then uses its StructuredClassifier and its BehavioredClassifier natures in order to draw the orchestration of multiple ServiceAccess properties just as one uses UML's composite structures metamodel to model similar collaborations for Highlevel Operational Concepts, Systems Internal Interface Descriptions for systems collaboration in CapabilityConfigurations, SysML IBDs, and etc. ServiceDescription is a derivation of ArchitectureDescription that is, itself, an extension of Package. The intended purpose of ServiceDescription is for the documentation of the purpose and of the elements of a Service. Because of this documentary intention and because Package is not intended to be a suitable metaclass for the modeling of composition hierarchies, ServiceDescription, too, is not appropriate for the concept here called "ServicesCollaboration". Recommendation: either add <> directly into UPDM or add <> to UPDM so that one can model Services in Composite hierarchies like they can model conceptually similar collections of parts in contexts in other notations. Juergen Boldt Director, Member Services 109 Highland Ave Needham, MA 02494 USA Tel: 781 444 0404 x 132 fax: 781 444 0320 www.omg.org [] signature13.asc signature13.asc From: "Levine, Leonard Frederick (Len Levine @ DISA) CIV DISA EE (US)" To: "lvanzandt@nomagic.com" CC: Lonnie VanZandt , Juergen Boldt , "issues@omg.org" , "updm-2-0-rtf@omg.org" Subject: RE: issue 18688 -- UPDM 2.2 RTF issue Thread-Topic: issue 18688 -- UPDM 2.2 RTF issue Thread-Index: AQHOQpRHd28T7qdAekKnl1GFXVa4LpjtLBdwgABQTgCAAAM+cA== Date: Mon, 29 Apr 2013 18:15:46 +0000 Accept-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [214.21.83.188] X-Virus-Scanned: amavisd-new at omg.org X-Brightmail-Tracker: AAAAAA== X-Brightmail-Tracker: AAAAAA== Lonnie, Points taken. I concur this issue is in scope for UPDM/UAFP Version 3.0. FYI: My favorite SOA citation is the one that I read in depth but is somewhat dated and predates the SOA standard: Thomas Erl, Service-Oriented Architecture: Concepts, Technology, and Design, 2005, Chapters 6.6, .Orchestration., and 6.7, .Choreography., as well as Erl , SOA Principles of Service Design, 2007, Chapter 13 (13.6) on Composition and Orchestration. The book isn.t at hand but I remember it does have some handy, dandy high-level graphics. Len From: Lonnie VanZandt [mailto:lvanzandt@nomagic.com] Sent: Monday, April 29, 2013 1:41 PM To: Levine, Leonard Frederick (Len Levine @ DISA) CIV DISA EE (US) Cc: Lonnie VanZandt; Juergen Boldt; issues@omg.org; updm-2-0-rtf@omg.org Subject: Re: issue 18688 -- UPDM 2.2 RTF issue BPMN process orchestration is related but separate. This issue addresses the difficulty in modeling SOA Service Architectures within UPDM, or any collection of collaborating externally-acquired services. Regarding the roadmap, Slide 17, the SOA capabilities are shown as appearing in 2007 in DoDAF v1.5. Therefore, this issue is addresses existing capabilities within DoDAF and UPDM and not future ones. Furthermore, we are soliciting issues against the current implementations of UPDM and the UDPM team will then triage those and schedule the votes on their resolutions as appropriate to honor the roadmap. (It is not the responsibility of the individual raising the issue to withhold issues until the implementation reaches applicable roadmap milestones.) I went looking for some supporting material to illustrate to what I am referring when I am speaking about "Service Architectures". I found some material and these two come from an Intergraph powerpoint. My area of concern is "Big SOA" as the second graphic illustrates. Lonnie VanZandt Chief Architect No Magic, Inc. Mailstop: 700 Central Expressway S, Suite 110, Allen, TX 75013 Office: 637 Witter Gulch Rd, Suite 425, Evergreen, CO 80439 Direct: 303-900-3048 Fax: 303-482-2943 Email: lvanzandt@nomagic.com Skype: lonnie.vanzandt On 4/29/2013 7:12 AM, Levine, Leonard Frederick (Len Levine @ DISA) CIV DISA EE (US) wrote: Wouldn't this issue be ripe only "when" UPDM (or successor UAFP) addresses orchestration under BPMN? In UPDM 4.0 requirements? Under UPDM 5 Year plan, BPMN Profile may not come until "UPDM 4.0 (UAEP) RFP issued [around] Mar 2015". See " c4i/12-12-05: UPDM 3.0 roadmap slides", December 2012, Slide 21, OMG Member Only site http://www.omg.org/members/cgi-bin/doc?c4i/12-12-05.pdf Len Levine Defense Information Systems Agency (DISA) ATTN: Leonard F. Levine /Code EE31 P.O. Box 549 Ft. Meade, MD 20755-0549 Room A4B57D Telephone: 301-225-7497 Mobile: 703-861-4822 NEW E-MAIL (June 2012): Leonard.F.Levine.civ@mail.mil -----Original Message----- From: Juergen Boldt [mailto:juergen@omg.org] Sent: Friday, April 26, 2013 11:38 AM To: issues@omg.org; updm-2-0-rtf@omg.org Subject: issue 18688 -- UPDM 2.2 RTF issue From: webmaster@omg.org Date: 25 Apr 2013 13:47:44 -0400 To: Subject: Issue/Bug Report X-Brightmail-Tracker: AAAAAA== X-Brightmail-Tracker: AAAAAA== ******************************************************************************* Name: Lonnie VanZandt Employer: No Magic, Inc mailFrom: lvanzandt@nomagic.com Terms_Agreement: I agree Specification: UPDM Section: 8.2.1.2.4 FormalNumber: dtc/2012-12-17 Version: 2.1 Doc_Year: 2012 Doc_Month: December Doc_Day: 17 Page: 207 Title: UPDM DoDAF lacks a concept for Service Orchestration Nature: Enhancement Severity: Significant CODE: 3TMw8 B1: Report Issue Description: Of the available DoDAF Service concepts, neither ServiceAccess nor ServiceDescription is an adequate concept for expressing collaborations of multiple Services such as one does in a SOA ServiceArchitecture. The lack of a concept like HighLevelOperationalConcept, say "ServicesOrchestration" or "ServicesCollaboration", for the SvcV-1 makes it difficult in UPDM DoDAF to model SOA Service Architectures. One has to borrow an instance of concept called "ServiceAccess"--which is poorly named and which suggests the means of accessing a single entity--and then claim that the borrowed ServiceAccess instance is really only an abstraction for representing a particular instance of an orchestration of multiple Services. One names it with its type as, say, "Service Orchestration for Situation X : ServiceAccess", and then uses its StructuredClassifier and its BehavioredClassifier natures in order to draw the orchestration of multiple ServiceAccess properties just as one uses UML's composite structures metamodel to model similar collaborations for Highlevel Operational Concepts, Systems Internal Interface Descriptions for systems collaboration in CapabilityConfigurations, SysML IBDs, and etc. ServiceDescription is a derivation of ArchitectureDescription that is, itself, an extension of Package. The intended purpose of ServiceDescription is for the documentation of the purpose and of the elements of a Service. Because of this documentary intention and because Package is not intended to be a suitable metaclass for the modeling of composition hierarchies, ServiceDescription, too, is not appropriate for the concept here called "ServicesCollaboration". Recommendation: either add <> directly into UPDM or add <> to UPDM so that one can model Services in Composite hierarchies like they can model conceptually similar collections of parts in contexts in other notations. Juergen Boldt Director, Member Services 109 Highland Ave Needham, MA 02494 USA Tel: 781 444 0404 x 132 fax: 781 444 0320 www.omg.org [] smime1.p7s smime1.p7s From: "Laursen, Kent" To: "Levine, Leonard Frederick (Len Levine @ DISA) CIV DISA EE (US)" , "lvanzandt@nomagic.com" CC: Lonnie VanZandt , Juergen Boldt , "issues@omg.org" , "updm-2-0-rtf@omg.org" Subject: RE: issue 18688 -- UPDM 2.2 RTF issue Thread-Topic: issue 18688 -- UPDM 2.2 RTF issue Thread-Index: AQHOQpReYNFjlhyomkSLjvHn2GqHfpjtdD2AgABLNgCAAAmVAP//xmmA Date: Mon, 29 Apr 2013 19:09:28 +0000 Accept-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [107.201.230.55] X-Virus-Scanned: amavisd-new at omg.org X-Brightmail-Tracker: AAAAAA== X-Brightmail-Tracker: AAAAAA== Lonne and Len, Don.t have time at the moment to address this issue with due diligence, but to chime in. I have found that one of the impediments to .Big SOA. or Enterprise SOA is the lack of understanding, decomposition and factoring for the business process. In other words a lack of business process modeling discipline. To get the right collection of services with the right collection of information, i.e. the enterprise vocabulary of nouns and verbs ,requires a robust business analysis. One, albeit overly simplistically stated, method for deriving services is to decompose business processes to the point where the actions are unambiguously automated by one (maybe more) services in the execution of the business level action. For this to work sensibly, as well as support orchestration and automation, we need a clear and traceable metamodel from the business level to the systems/automated level. This gets back to the logical service issue I posted some weeks ago. So if getting to the SOA, and orchestration thereof, involves a traceable decomposition of business process (or Operational Activity) to discrete automations, then we probably need to clean up the path between abstractions. Notice the problem in the attached image. Regards, Kent From: Levine, Leonard Frederick (Len Levine @ DISA) CIV DISA EE (US) [mailto:leonard.f.levine.civ@mail.mil] Sent: Monday, April 29, 2013 11:16 AM To: lvanzandt@nomagic.com Cc: Lonnie VanZandt; Juergen Boldt; issues@omg.org; updm-2-0-rtf@omg.org Subject: RE: issue 18688 -- UPDM 2.2 RTF issue Lonnie, Points taken. I concur this issue is in scope for UPDM/UAFP Version 3.0. FYI: My favorite SOA citation is the one that I read in depth but is somewhat dated and predates the SOA standard: Thomas Erl, Service-Oriented Architecture: Concepts, Technology, and Design, 2005, Chapters 6.6, .Orchestration., and 6.7, .Choreography., as well as Erl , SOA Principles of Service Design, 2007, Chapter 13 (13.6) on Composition and Orchestration. The book isn.t at hand but I remember it does have some handy, dandy high-level graphics. Len From: Lonnie VanZandt [mailto:lvanzandt@nomagic.com] Sent: Monday, April 29, 2013 1:41 PM To: Levine, Leonard Frederick (Len Levine @ DISA) CIV DISA EE (US) Cc: Lonnie VanZandt; Juergen Boldt; issues@omg.org; updm-2-0-rtf@omg.org Subject: Re: issue 18688 -- UPDM 2.2 RTF issue BPMN process orchestration is related but separate. This issue addresses the difficulty in modeling SOA Service Architectures within UPDM, or any collection of collaborating externally-acquired services. Regarding the roadmap, Slide 17, the SOA capabilities are shown as appearing in 2007 in DoDAF v1.5. Therefore, this issue is addresses existing capabilities within DoDAF and UPDM and not future ones. Furthermore, we are soliciting issues against the current implementations of UPDM and the UDPM team will then triage those and schedule the votes on their resolutions as appropriate to honor the roadmap. (It is not the responsibility of the individual raising the issue to withhold issues until the implementation reaches applicable roadmap milestones.) I went looking for some supporting material to illustrate to what I am referring when I am speaking about "Service Architectures". I found some material and these two come from an Intergraph powerpoint. My area of concern is "Big SOA" as the second graphic illustrates. Lonnie VanZandt Chief Architect No Magic, Inc. Mailstop: 700 Central Expressway S, Suite 110, Allen, TX 75013 Office: 637 Witter Gulch Rd, Suite 425, Evergreen, CO 80439 Direct: 303-900-3048 Fax: 303-482-2943 Email: lvanzandt@nomagic.com Skype: lonnie.vanzandt On 4/29/2013 7:12 AM, Levine, Leonard Frederick (Len Levine @ DISA) CIV DISA EE (US) wrote: Wouldn't this issue be ripe only "when" UPDM (or successor UAFP) addresses orchestration under BPMN? In UPDM 4.0 requirements? Under UPDM 5 Year plan, BPMN Profile may not come until "UPDM 4.0 (UAEP) RFP issued [around] Mar 2015". See " c4i/12-12-05: UPDM 3.0 roadmap slides", December 2012, Slide 21, OMG Member Only site http://www.omg.org/members/cgi-bin/doc?c4i/12-12-05.pdf Len Levine Defense Information Systems Agency (DISA) ATTN: Leonard F. Levine /Code EE31 P.O. Box 549 Ft. Meade, MD 20755-0549 Room A4B57D Telephone: 301-225-7497 Mobile: 703-861-4822 NEW E-MAIL (June 2012): Leonard.F.Levine.civ@mail.mil -----Original Message----- From: Juergen Boldt [mailto:juergen@omg.org] Sent: Friday, April 26, 2013 11:38 AM To: issues@omg.org; updm-2-0-rtf@omg.org Subject: issue 18688 -- UPDM 2.2 RTF issue From: webmaster@omg.org Date: 25 Apr 2013 13:47:44 -0400 To: Subject: Issue/Bug Report X-Brightmail-Tracker: AAAAAA== X-Brightmail-Tracker: AAAAAA== ******************************************************************************* Name: Lonnie VanZandt Employer: No Magic, Inc mailFrom: lvanzandt@nomagic.com Terms_Agreement: I agree Specification: UPDM Section: 8.2.1.2.4 FormalNumber: dtc/2012-12-17 Version: 2.1 Doc_Year: 2012 Doc_Month: December Doc_Day: 17 Page: 207 Title: UPDM DoDAF lacks a concept for Service Orchestration Nature: Enhancement Severity: Significant CODE: 3TMw8 B1: Report Issue Description: Of the available DoDAF Service concepts, neither ServiceAccess nor ServiceDescription is an adequate concept for expressing collaborations of multiple Services such as one does in a SOA ServiceArchitecture. The lack of a concept like HighLevelOperationalConcept, say "ServicesOrchestration" or "ServicesCollaboration", for the SvcV-1 makes it difficult in UPDM DoDAF to model SOA Service Architectures. One has to borrow an instance of concept called "ServiceAccess"--which is poorly named and which suggests the means of accessing a single entity--and then claim that the borrowed ServiceAccess instance is really only an abstraction for representing a particular instance of an orchestration of multiple Services. One names it with its type as, say, "Service Orchestration for Situation X : ServiceAccess", and then uses its StructuredClassifier and its BehavioredClassifier natures in order to draw the orchestration of multiple ServiceAccess properties just as one uses UML's composite structures metamodel to model similar collaborations for Highlevel Operational Concepts, Systems Internal Interface Descriptions for systems collaboration in CapabilityConfigurations, SysML IBDs, and etc. ServiceDescription is a derivation of ArchitectureDescription that is, itself, an extension of Package. The intended purpose of ServiceDescription is for the documentation of the purpose and of the elements of a Service. Because of this documentary intention and because Package is not intended to be a suitable metaclass for the modeling of composition hierarchies, ServiceDescription, too, is not appropriate for the concept here called "ServicesCollaboration". Recommendation: either add <> directly into UPDM or add <> to UPDM so that one can model Services in Composite hierarchies like they can model conceptually similar collections of parts in contexts in other notations. Juergen Boldt Director, Member Services 109 Highland Ave Needham, MA 02494 USA Tel: 781 444 0404 x 132 fax: 781 444 0320 www.omg.org [] ServiceTracingProblem.jpg smime2.p7s smime2.p7s