GEM description regarding EA falling short in SOA

In my view, there are 1) physical services (e.g., mow the lawn, build the system, staff the office) involving combinations of space/time/matter/energy that provide a capability to produce intended output, and 2) informational services (e.g., provide intelligence such as data and information, including virtual services (e.g., provide voice and data communication capability with a given capacity)) to produce intended output. 

Informational services can exist without physical services, but all physical services always include some informational service components (e.g., the skill, knowledge, and abilities to mow the lawn, build the system, staff the office).  I use the term "information product" as descriptive name for the non-physical inputs, controls, outputs, and mechanisms of an "information service". 

The "services" of a SOA are types of information products, while the mechanisms to provide the information products are "processes".  A key factor in "service orientation" and in the architecture of capabilities that provide information products is whether the process that generates the information product is "built-in" to the production capability (i.e., tightly coupled) or is a "module" that can be added-in or replaced with minimal efforts (i.e., loosely coupled).

I have described and used the following model for Information Products (as inputs, controls, outputs, and mechanisms of a process).  This also puts "process modeling" in the position of supporting broader "resource" modeling (i.e., physical and informatonal resources), not just the data modeling that is typical of most process modeling approaches I've seen.  It also enables what I call "intelligence inventory" and "intelligence management (see my site http://www.one-world-is.org).  Information Products (e.g., process-outputs, as informational services, to be interchanged in a Service-Oriented-Architecture) are can be built in seven layers: concept, content, context, container, connector, carrier, communication.

1. An Information Product's Concept is a word or term (i.e., a noun, a name for some thing, a subject, a topic) that has the equivalent meaning, per definition and intent, for two or more persons or machine-processors within and around a process. Ref:  http://www.thefreedictionary.com/concept, n. 1. A general idea derived or inferred from specific instances or occurrences. 2. Something formed in the mind; a thought or notion. See Synonyms at idea. 3. A scheme; a plan.  To me, a concept is the same thing as a "theory" about some part of the world.

2. The Concept's Content is a collection of Concepts connected together using verbs or verb phrases.  Examples would be assertions, propositions, questions, declarations, statements, exclamations, specifications, etc., grammaticaly represented as "object + predicate verb + predicateobject",  structurally represented as a noun_verb_noun "triple" combination (i.e., basic metadata), graphically represented as a directed_labeled_graph (DLG) (e.g., as in labeled node_link_node diagrams, flow diagrams, entity-relationship diagrams, swimlane or BPMN diagrams).

3. The Content's Context is the arrangement of the various Content triples that directly and indirectly, to at least a couple of levels of inference (i.e., levels or degree of separation from direct connection), connect to a central concept (subject).  The Context is consistently structured in terms of the relationships (i.e., verbs or verb phrases) between concepts.  The context of a concept's content is also referred to as its "semantics" or "usage". 

3.1. The seven types of relationships I use are: A) equivalence, B) categorization, C) containment, D) sequence, E) version, F) variance, and G) description. 

3.1.2. The Categorization relation type provides a structured hierarchical "reference catalog" of concepts (also called a "reference model", subject catalog, subject-tree, taxonomy) conveying concepts (subjects) arranged from broader hypernym to narrower hyponym definitions. 

3.1.2.1. The subject catalogs I use are built to organize, operate, integrate, and unify specific "endeavors" (i.e., enterprises) and includes sub-catalogs for: 1) locations, 2) organizations, 3) organization-units, 4) functions, 5) processes, 6) resources, and 7) requirements.  Other names for a catalog are type, class, taxonomy, subject-tree, entity, and inventory.  Each of the endeavor's subject catalogs has its own specified and inherited attributes to describe the catalog's content.

3.1.2.1.1.  The location catalog contains classes and subclasses of concepts about physical, virtual, and conceptual locations.

3.1.2.1.2.  The organization catalog

3.1.2.1.3.  The organization-unit catalog

3.1.2.1.4.  The function catalog

3.1.2.1.5.  The process catalog

3.1.2.1.6.  The resource catalog

3.1.2.1.7.  The requirement catalog

3.1.3.  The  Containment relation type provides a physical or informational assemblage of "things within things".

3.1.4.  The Sequence relation type

3.1.4.1.  The Capability Life Cycle sequence

3.1.4.1.1.  Conception

3.1.4.1.2.  Request

3.1.4.1.3.  Authorize

3.1.4.1.4.  Acquire (Build or Buy)

3.1.4.1.5.  Deploy

3.1.4.1.6.  Operate and Maintain

3.1.4.1.7.  Assess and Dispose

3.1.4.2.  The Capability Value-Chain role

3.1.4.2.1.  Customer

3.1.4.2.2.  Performer

3.1.4.2.3.  Supplier

3.1.4.2.4.  Authority

3.1.4.2.5.  Partner

3.1.4.2.6.  Subordinate

3.1.4.2.7.  Public

3.1.5.  The Version relation type

3.1.6.  The Variance relation type

3.1.7.  The Description relation type

4. The Context's Container

5. The Container's Connector

6. The Connector's Carrier

7. The Carrier's Communication

Semantic Analysis

Intelligence Inventory