Ten Reasons To Decompose An Activity Or Function

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 is done; with what it is done; and for or to whom or what it is done. One of the key skills associated with modeling activities (and functions), is called “activity decomposition”, which is the process of breaking down large or complex activities or functions into small, more discrete parts. The following ten rules for naming operational activities and system functions are presented for consideration and use by modelers and architects.

1. The Activity Includes Three Or More Steps. Activities or functions that are performed in three or more well-defined steps may be decomposed such that each step is a separate sub-activity or sub-function.  Sub-activities/functions that are derived from steps that must be performed in a specific order may be sequenced accordingly within the activity or function model.  (NOTE: Those activities or functions with only two steps need not be decomposed.)

2. The Activity Generates Multiple Partial Outputs That Are Combined to Create the Final Output. For these types of activities or functions, you can create separate subordinate activities or functions to generate each of the partial outputs, and another to combine them into the ultimate output. An example of this is the activity of building a car.  Interim partial inputs created prior to the final construction of the car would include the engine, the transmission, the fuel system, the chassis, and others.  So the “Build A Car” activity could be decomposed into “Build Car Engine”, “Build Automatic Transmission”, “Construct Car Fuel System”, “Construct Vehicle Chassis”, etc.

3. The Activity Produces Multiple, Distinct Outputs.  A separate sub-activity or sub-function may be created for each of the distinct outputs.  This should only be done, however, if there are at least three unique outputs.  An example of this is the activity “Make Desserts”.  Decomposed sub-activities might include “Bake A Cake”, “Bake A Pie”, “Make Pudding”, and “Make Frozen Dessert”.

4. The Same Input(s) Used to Produce Three or More Outputs.  This is a special case of #3, above. The primary distinction is that, in this case, the different outputs are generated from the same set of inputs.  For example, the parent activity might be “Bake Pastries”, and the inputs to this activity would be flour, sugar, butter, and eggs.  Distinct outputs of this parent activity that might be created using these same inputs include cakes, cookies, cupcakes, donuts, and muffins.  Subordinate activities, therefore, might be “Bake A Cake”, “Bake Cookies”, “Bake Cupcakes”, “Bake Muffins”, and “Make Donuts”.

5. The Activity Is Performed By Different Entities.  When multiple entities (e.g., organizations) perform the same activity or function, there may be a need or desire to describe the activities/functions from an organizational perspective.  To do so, create a version of the activity or function for each of the entities or organizations that perform it.  Be sure to include the name or designation of the entity or organization in the name of the activity or function.  An example is the activity “Manage Budget” if performed by governmental agencies at the municipal (i.e., city), state, or national levels.  So decomposed subordinate activities might be “Manage El Paso City Budget”, “Manage Texas State Budget” and “Manage US National Budget”.

6. The Activity Is Performed to Varying Levels of Detail.  Sometimes, the same activity or function may be performed to different levels of detail based on varying requirements, different event triggers, the available inputs or resources, the experience of the performer(s) or the prevailing conditions. An example of this involving different requirements and event triggers is the activity “Perform Item Inventory”.  Subordinate activities might include “Perform Daily Inventory”, “Perform Weekly Inventory”, “Perform Monthly Inventory”, “Perform Quarterly Inventory”, “Perform Annual Inventory”, and “Perform On-Demand Inventory”.

7. The Activity Is Performed Using Different Inputs.  There are situations in which essentially the same output is generated using different sets of inputs.  This is the opposite of the situation described in #4, above. This situation can be illustrated by the activity “Create A Sculpture”, as a sculptor can use many different media to create a finished product.  Appropriate subordinate activities of “Create A Sculpture” might, therefore, include “Sculpt In Bronze”, “Sculpt In Stone”, “Sculpt In Clay”, “Sculpt In Ice”, “Sculpt In Glass”, “Sculpt In Wood”, and “Sculpt In Mixed Media”.

8.  The Activity Is Performed Differently Under Different Conditions. In this situation, the output(s) of an activity are the same, but the process used to generate the output(s), and possibly the inputs used in the process, differ based on some definable factor.  The value of this definable factor determines which of the subordinate activities is to be executed.  An example of this is the activity “Deliver Merchandise to Purchaser”.  Subordinate activities would include “Provide Standard Delivery”, “Provide Expedited Delivery”, and Provide Emergency Delivery”.  The factor determining exactly how the activity is performed would be purchaser’s preference.

9.   Alternate Methods Are Available to Generate the Same Output. This is very similar to the situation described in #8, above, with one major difference.  There is no specific factor to define which of the subordinate activities has to be executed: all subordinate activities are equally valid under all conditions.  The activity “Advertise Goods and Services” is a great example of this situation – there are a number of advertising methods available and with minor exceptions, each of them is equally valid and equally effective.  Subordinate activities include “Advertise Via Newspaper”, “Advertise Via Radio”, “Advertise Via Magazine”, “Advertise Via Internet”, “Advertise Via Direct Mail”, “Advertise Via Billboard”, and “Advertise Via Broadcast Television.  In this particular instance, an individual or organization wishing to advertise might not just choose to implement one method, but might even multiple methods (and their associated subordinate activities) simultaneously.

10.  Activity Outputs Are Tailored for Different Consumers. This one addresses the situation wherein there are multiple consumers of the outputs of an activity, each with unique requirements.  The subordinate activities would exist to modify the output as appropriate to meet the needs of each consumer.  For example, the activity “Publish Books” might be decomposed to create different versions of a book to cater to different audiences: “Publish English Books”, “Publish Spanish Books”, “Publish French Books”, “Publish German Books”, “Publish Children’s Books”, “Publish Adolescent Books”, etc.

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.