• DODAF Home 
• Background 
• Architectural Development 
• Meta Model 
  • Conceptual 
  • Logical 
  • PES 
  • IDEAS Foundation Ontology 
• Viewpoints & Models
  • All Viewpoint 
  • Capability Viewpoint 
  • Data and Information Viewpoint 
  • Operational Viewpoint 
  • Project Viewpoint 
  • Services Viewpoint 
  • Standards Viewpoint 
  • Systems Viewpoint 
  • Models 
  • Model Categories
  • Levels of Architecture
  • Architecture Interrogatives 
  • Architecture Modeling Primitives
  • Mapping to DM2 
• Presentation Techniques
  • Composite Views 
  • Fusion Views 
  • Reference Models 
• DODAF-DM2 Configuration Management
• IDEAS 
• Related Links 
• Acronyms List and Glossary of Terms 
• Site Map 
• Archives

Rules

Rules are prescriptive sets of procedures regarding the execution of activities within an enterprise. Rules exist within the enterprise whether or not they are ever written down, talked about, or even part of an organization's consciousness. However, it is fairly common practice for organizations to gather rules in a formal manner for specific purposes.

Business rules are a type of Rule that govern actions and are initially discovered as part of a formal requirement-gathering process during the initial stages of a Project or during activity analysis, or event analysis. In this case, the collecting of the business rules is coincidental to the larger discovery process of determining the workflow of a process. Projects such as the launching of a new system or service that supports a new or changed business operation might lead to a new body of business rules for an organization that would require employees to conceptualize the purpose of the organization in a new way. This practice of coincidental business rule gathering is vulnerable to the creation of inconsistent or even conflicting business rules within different organizational units, or within the same organizational unit over time.

The DoDAF Meta Model provides a set of clear, concise data about rules that facilitates the creation of rules and enables the sharing of those rules with others requiring similar information.

A rule is not a process - the two, while related, are very different. A process is a transformation that produces new things (outputs) from existing things (inputs), while a rule prescribes the exact procedures to be used to ensure that the output is as to be expected in each instance that the process is executed. 

Data Group Description

The DoDAF Meta Model for the data comprising Rules is shown in the figure below.

DoDAF Meta Model for Rules
(Click image to enlarge)

The following should be noted about the Rules Data Group:

1. A Rule constrains Activities. For example, a speed limit rule constrains driving activity. Some seemingly static rules have the effect of limiting possible activities. For example, a rule that security fences must be 10 feet high constrains the activity of building security fences. This constraint may apply or vary under certain conditions. For example, speed limits can be lower in poor weather conditions. 
2. Security classification, security marking, releasability, etc. are types of Guidance. Similarly; a Rule is a stronger form of Guidance.
3. An important Constraint type is a Service Policy that constrains access to capability Performers.
4. Doctrine, by definition, constrains military action.

Usage in Core Processes

Rules data are used to create, document, and share rules of all types that support operational activities and/or the execution of capabilities in operational processes (composite activities). These data can include:

1. Processes that define transactions where data must be exchanged or passed to execute a specified activity, such as PPBE, CPM, JCIDS, or DAS.
2. Rules that define methods of accessing information or services within the net-centric environment, such as Ops, PPBE, CPM, or JCIDS.
3. The order of steps that occur in a series of actions that must be performed in a specific order, such as DAS, SE, PPBE, or CPM.
4. Rules defining analysis of options or future actions, such as Ops Planning, JCIDS, PPBE or CPM.

Data for Rules are used in the six core processes in the following ways:

1. JCIDS:
   1) For Materiel Facility, Installation, and Site trade-offs as part of DOTMLPF analyses
   2) For detailing Interoperability requirements.
   3) In constraining requirements dealing with material and non-material solutions.
   4) In relating Doctrine and TT&P to material and non-material solutions.
2. PPBE:
   1) In the Planning and Programming process many rules are applied to cost-benefit tradeoffs, cost estimation, program structure, and program constraints.
3. DAS:
   1) In both technical and programmatic aspects of the DAS.
   2) In specification, standards, directives and guidelines.
4. SE:
   1) In the architectural descriptions of systems describing both structure and behavior.
   2) In standards applied throughout the design and development process.
5. Ops Planning:
   1) Rules are the basic elements contained in Doctrine, TT&P and training publications. Rules are used throughout the development and architectural descriptions of Operational processes.
6. CPM:
   1) In describing and governing both the programmatic and technical aspects of the portfolio.
   2) In describing the standards and constraints applicable to the portfolio.

Rules can be represented in many ways. Typically behavioral and tree structures as well as various logic mapping techniques can be used to depict rules, their relationships and interactions. Conflicting rules can be identified using many well know logic analysis instruments and techniques.