Defining a VOCABULARY, & Other Related Terms

A fundamental component of any Enterprise Architecture is the set of key terms and concepts that are a part of the enterprise domain.  These terms and their associated definitions serve to falilitate understanding, foster consensus, and minimize confusion within and outside the enterprise.  The collections of terms and definitions may be called by different names, depending on how they are organized and presented.  Here is a quick and dirty overview of some of these collections of terms.

VOCABULARY = The list of terms and concepts used within a domain, with their associated definitions.  Ideally, there should be only one definition per term and only one term per definition, though there may exist situations where a single term has more than one definition.  In these instances, it becomes necessary either to designate one definition as the "authoritative" one and annotate all others as alternatives, or to define the specific conditions under which the alternative definitions apply.

THESAURUS = A list of synonyms (i.e., terms with the same or very similar meanings) within a domain.  A thesaurus also may contain antonyms--terms with opposite meanings.

TAXONOMY = A listing of the terms and concepts within a domain showing the hierarchical relationships among them.  These hierarchical relationships usually can be expressed as "is a child of", “is a parent of", “is a part of", "is composed of", or similar parent-child or whole-part expressions.  Ideally, a term should be the child of only one parent within a single taxonomy, though it can be included in multiple taxonomies.  A taxonomy has to include some attribute (or set of attributes) that are used to organize the instance terms and concepts.  It is possible; however, to apply different attributes to the same set of things and get totally different taxonomies.  For example, starting with the set of all people in the world, a different taxonomy would be produced by applying the attribute GENDER than would result from the attribute NATIONALITY, or LANGUAGE, or EDUCATION LEVEL, or OCCUPATION, or MARITAL STATUS, etc.

ONTOLOGY = A listing of the "things" that exist within a domain, and the relationships among those things.  The types of relationships possible go beyond the parent-child or whole-part relationships shown in a taxonomy.  However, they must be clearly defined, and can be thought of as "methods" that relate one thing to another (e.g., an OBJECT occupies a LOCATION).

LEXICON = A listing of equivalent terms and concepts in two or more languages or domains.

DICTIONARY = An alphabetical listing of words from a particular language with their definitions, origins, pronunciations, synonyms, antonyms, and other information. Dictionaries may come on two “flavors”: Generalized (i.e., containing all words) or Directed (i.e., limited to those words within a specific knowledge, subject, or functional area).  A Directed Dictionary is also called a Specialized Dictionary.

 
DATA ELEMENT DICTIONARY = A listing of the data elements, their definitions, associations/relationships, and associated business rules extracted from a data model or schema.

A Proposed "Services Reference Architecture"

The proposed Services Reference Architecture (SRA) describes how an operational or functional community plans to implement web services and service-oriented architecture to support the performance of its joint functional mission.  It is called a reference architecture because it is meant to serve as a roadmap and reference to community stakeholders on how to incorporate web services and associated considerations into their respective acquisition, engineering, development, and implementation efforts.  The standards in the document may or may not be prescriptive.

The SRA should include a description of

·         the services to be implemented (SvcV-1, SvcV-2, SvcV4*), based on the required capabilities defined in an Operational Architecture

·         by whom and where they will be implemented, notionally (SvcV-3a)

·         functionality and information exchanges facilitated or performed via the services (SvcV-5). 

·         data elements used in the services (SvcV-2, SvcV-6).  Ideally, these data elements are from existing data models, schemas, ontologies, or other approved data artifacts.

·         service relationships and dependencies (SvcV-3b, SvcV-10c)

·         service standards to be applied by service developers (SvcV-7, SvcV-9).  This may include mandated standards (e.g., from higher level external agencies and activities), recommended standards (where multiple standards are acceptable), and emerging standards that are being considered for adoption.

·         services terms of reference, which is simply a list of key terms and concepts used in the document, along with their definitions.

·         guiding principles for service development and implementation, to include criteria for assessing the suitability and acceptability of services being considered for adoption, being developed, being operationally evaluated, or being used.

The SRA may include, as optional elements,

·         Identification of enterprise (i.e., non-community specific) services to be adopted by the community (SvcV-3b).

·         Existing, planned, and developmental services that meet interim or objective community service requirements (SvcV-3b).

·         Service development and implementation priorities (SvcV-8).  [NOTE: This product may be considered a mandatory component of a prescriptive SRA, but is optional for an SRA that is only descriptive.]

·         A high level operational concept graphic and description to place the referenced services in an operational context (OV-1).

·         A description of the operational benefits to be gained from each service, service “string” and the set of services as a whole.

·         A discussion of possible trade-offs among services with similar or overlapping capabilities.

·         Standard verbiage to be inserted into solicitations and RFPs.

The SRA should not include

·         The assignment of specific service development responsibilities to individual programs of record (May be included in a follow-on Services Implementation Plan)

·         Any discussion of service development costs (May be included in a follow-on Services Implementation Plan, or may be deferred to individual implementing agents.) 

*The DODAF architecture view annotations are for reference, only. The Services Reference Architecture may actually be formatted as a standard textual artifact with appropriate graphics, and need not include DODAF view designations.

Ten Rules for Naming Operational Activities & System Functions

Operational Activities and System Functions (and the activity models, process models, function models, functional or process flows, sequence diagrams, or activity/function “threads” of which they are a part) are essential components of any Enterprise Architecture.  They effectively identify what the enterprise is all about—what the enterprise does; who or what does it; how it does it; with what it is done; and for or to whom or what it is done.  Naming these activities and functions provides a reader with a critical understanding of the purpose, scope, and point of view of not just the model of which they are a part, but also of the parent architecture as a whole.  Enterprise Architects must carefully consider the names assigned to enterprise operational activities and systems functions, taking into account their importance in facilitating understanding of the enterprise as a whole.  With this in mind, the following ten rules for naming operational activities and system functions are presented for consideration and use by modelers and architects.

1. Be concise: The name chosen for an activity or function should be long enough to give one a good understanding of what the activity or function is about, but not so long as to read as a description instead of a title.  As a general rule, if the name has more than about six words, you probably should consider shortening it.  Save the details for inclusion in the activity or function description.

 

2. Be singular: An activity or function, and its name, should describe a single action, process, or behavior.  Though it may sometimes be necessary to combine two activities or functions into one in order to meet some modeling rules, the resulting composite activity or function should be assigned a singular name.     One method for doing this is to select a generic term phrase that encompasses the original two terms or phrases.  For example, replace “Bake a Cake and Roast a Turkey” with “Cook Food”; replace “Wash and Wax Car” with “Detail Car”, etc.

3. Use approved terminology or terminology familiar to the community: If the activity or functional model is being developed for an enterprise, system, organization, or functional area for which an approved, standardized vocabulary exists, then the activity or function name should be selected from that standardized vocabulary if possible.  Even if no approved community vocabulary exists, the name chosen for an activity or function should use terminology that is familiar to and understandable by personnel within the community.

 

4. Avoid using abbreviations and acronyms: Abbreviations and acronyms can significantly shorten an activity or function name, but they can also make them less understandable. For abbreviations, especially, they can have more than one meaning.  For example, the abbreviation “C.A.P.” can stand for either “Civil Air Patrol” or “Combat Air Patrol”.  This can lead to confusion over the correct meaning, or misinterpretation when the wrong meaning is assumed.  So unless the meaning is so universally recognized, or so clear from the context as to preclude misinterpretation, abbreviations and acronyms should be fully expanded or replaced with equivalent terms.

 

5. Follow existing naming conventions and standards: For communities that have adopted activity and/or function naming conventions, activity and function names should be selected in accordance with those conventions.  There may even exist communities that have adopted both a standard vocabulary (see rule 3 above) and a set of activity and function naming conventions.  Within these communities, activity and function names should be selected to be consistent with both.

6. Be descriptive of the process covered, or of the output of the process:  Even though the activity or process should have a detailed definition that fully describes it, the name should present to the reader an indication of what the activity or function is about.  [See rules 7, 8, and 9 below for further details on writing descriptive titles.]

7. Use a verb phrase to identify the action, process, or behavior addressed: Probably the most important part of selecting a name for an activity or function is determining the right verb or verb phrase to capture the nature of the action, process, or behavior encompassed by the activity or function.  Ideally, the verb should be active and in the present tense.

 

8. Use a noun to identify the object of the action, process, or behavior:  After selecting the proper verb or verb phrase to define the behavior, probably the next most important aspect of naming the activity or function is choosing an appropriate noun or set of nouns to identify the object of the action, process or behavior.  Without a noun to define what is being affected, the true nature of an activity or function nearly impossible to determine.  For example, an activity with the name “Generate” could mean almost anything—Generate Electricity, Generate Profits, even Generate Thought.  But the correct noun or set of nouns eliminates the ambiguity, making the meaning of the activity or function crystal clear (e.g., Generate Simulated Speech).

 

9. Use adverbs and adjectives to distinguish similar processes:  Having chosen the perfect verb and noun pair is often all that is needed to create an effective name for an activity or function.  Sometimes; however, is may be necessary to use adverbs or adjectives to modify the verbs or nouns to make the activity or function name more specific or more accurate.  For example, it may require a slightly different process and set of resources to wash a large vehicle than it does to wash a small one.  So adjectives may be used to create separate activities named “Wash Large Cars” and “Wash Small Cars”.  Likewise, there may be alternative ways to perform the same process that need to be accounted for in the activity or function name.  So adverbs may be used to produce separate activities such as “Manually Process Insurance Claims” and “Automatically Process Insurance Claims”.

 

10. Be consistent throughout the model:  The final recommendation for naming activities and functions is to be consistent throughout the model.  This means not only using consistent naming conventions, but also presenting a consistent level of detail in activity or function names.  Names in one part of the model should not be short and concise while those in other parts are long and verbose.  Consistent naming conventions, consistent levels of detail, and consistent use of modifiers in activity and function names makes the model much easier for a reader to understand.