Organizational Relationships Chart (OV-4)
February 25, 2008
Product Definition. The Organizational Relationships Chart illustrates the command structure or relationships (as opposed to relationships with respect to a business process flow) among human roles, organizations, or organization types that are the key pla yers in an architecture.
Product Purpose. This product clarifies the various relationships that can exist between organizations and sub-organizations within the architecture and between internal and external organizations.
Product Detailed Description. OV-4 illustrates the relationships among organizations or resources in an architecture. These relationships can include supervisory reporting, command and control relationships, and command-subordinate relationships. Another type of relationship is a coordination relationship between equals, where two organizations coordinate or collaborate without one having a supervisory or command relationship over the other. Others may be defined depending on the purpose of the architecture. Architects should feel free to define any kinds of relationships necessary and important within their architecture to support the goals of the architecture. For example, dynamic teams or task forces (i.e., new operational nodes) may be created in real time with only limited lifespans and assigned missions, and could have needlines assigned to them. The creating node and the created node have a unique relationship that should be documented. This relationship may not be one of lines of command or organizational hierarchies, as these do not necessarily map to the needlines of OV-2. In this product, the dynamic organizations represented by operational nodes in OV-2 have a limited lifespan and a temporary collaboration relationship.
The product illustrates the relationships among organizations or organization types that are the key players in an architecture. These key players correspond to the operational nodes of an OV-2, which contains added detail on how the key players interact together in order to conduct their corresponding operational activities of OV-5.
Human roles whose skills are needed to perform the operational activities or business processes described in the architecture may also be defined in OV-4. The corresponding operational activities should be decomposed to a degree that allows them to be correlated to specific human roles within organizations. In addition, and specifically in the case of target architectures, human roles that do not reflect a specific supervisory reporting, command and control, or coordination organizational structure may be used in OV-4. In this case, OV-4 may be developed using strictly human roles that are the key players in an architecture.
Organizational relationships are important to depict in an OV (for a current architecture), because they can illustrate fundamental human roles (e.g., who or what type of skill is needed to conduct operational activities) as well as management relationships (e.g., command structure or relationship to other key players). Also, organizational relationships may influence how the operational nodes in an OV-2 are connected.
Popularity: 2% [?]
Operational Node Connectivity Description (OV-2)
February 25, 2008
OV-2 Example
Product Definition. The Operational Node Connectivity Description graphically depicts the operational nodes (or organizations) with needlines between those nodes that indicate a need to exchange information. The graphic includes internal operational nodes (internal to the architecture) as well as external nodes.
Product Purpose. OV-2 is intended to track the need to exchange information from specific operational nodes (that play a key role in the architecture) to others. OV-2 does not depict the connectivity between the nodes.
Product Detailed Description. The main features of this product are the operational nodes and the needlines between them that indicate a need to exchange information. The product indicates the key players and the interactions necessary to conduct the corresponding operational activities of OV-5.
Operational Nodes. An operational node is an element of the operational architecture that produces, consumes, or processes information. What constitutes an operational node can vary among architectures, including, but not limited to, representing an operational/human role (e.g., Air Operations Commander), an organization (e.g., Office of the Secretary of Defense) or organization type, i.e., a logical or functional grouping (e.g., Logistics Node, Intelligence Node), and so on. The notion of operational node will also vary depending on the level of detail addressed by the architecture effort.
Needlines and Information Exchanges. A needline documents the requirement to exchange information between nodes. The needline does not indicate how the information transfer is implemented. For example, if information is produced at node A, is simply routed through node B, and is used at node C, then node B would not be shown on the OV-2 diagram - the needline would go from node A to node C. OV-2 is not a communications link or communications network diagram. The system implementation (or what systems nodes or systems are used to execute the transfer) is shown in the Systems Interface Description (SV-1). Furthermore, the needline systems equivalent is the interface line depicted in SV-1. The actual implementation of an interface may take more than one form and is documented in a Systems Communications Description (SV-2). Therefore, a single needline shown in the OV may translate into multiple interfaces in SV-1 and multiple physical links in SV-2.
Needlines are represented by arrows (indicating the direction of information flow) and are annotated with a diagram- unique identifier and a phrase that is descriptive of the principal types of information exchanged. It is important to note that the arrows on the diagram represent needlines only. This means that each arrow indicates only that there is a need for some kind of information transfer between the two connected nodes.
There is a one-to- many relationship from needlines to information exchanges (e.g., a single needline on OV-2 represents multiple individual information exchanges). The mapping of the information exchanges to the needlines of OV-2 occurs in the Operational Information Exchange Matrix (OV-3). For example, OV-2 may list Situational Awareness as a descriptive name for a needline between two operational nodes. In this example, the needline represents a number of information exchanges, consisting of various types of reports (information elements), and their attributes (such as periodicity and timeliness) that are associated with the Situational Awareness needline. The identity of the individual information elements and their attributes are documented in OV-3.
OV-2 should also illustrate needs to exchange information between operational nodes and external nodes (i.e., operational nodes that are not strictly within the scope of the subject architecture but that act as important sources of information required by nodes within the architecture or important destinations for information provided by nodes within the architecture). Operational Activities. The operational activities (from the OV-5 Operational Activity Model) performed by a given node may be listed on the graphic, if space permits. OV-2, in effect, turns OV-5 inside out, focusing first-order on the operational nodes and second-order on the activities. OV-5, on the other hand, places first-order attention on operational activities and only second-order attention on nodes, which can be shown as annotations on the activities.
Representation of the product. For complex architectures, OV-2 may consist of multiple graphics. There are at least two different ways to decompose OV-2. One method involves using multiple levels of abstraction and decomposing the nodes. Another method involves restricting the nodes and needlines on any given graphic to those associated with a subset of operational activities. Both of these methods are valid and can be used together.
OVs usually avoid representing real physical facilities as operational nodes and focus on virtual or logical nodes that can be based on operational (human) roles or missions. Operational nodes are independent of materiel considerations; indeed, they exist to fulfill the missions of the enterprise and to perform its tasks and activities (business processes, procedures, and operational functions). Use of operational nodes supports analysis and design by separating business process modeling and information requirements from the materiel solutions that support them. Similarly, tasks and activities are organized, and communities of interest are defined to suit the mission and process requirements; the materiel is flexibly and automatically configurable to support the operational processes. However, an OV often has materiel constraints and requirements that must be addressed. Where appropriate, system or physical nodes that constitute the location of an operational node may augment the description of an operational node. These are often taken as recommendations or boundaries for further SV details.
Popularity: 3% [?]
OV-1
February 12, 2008
Product Definition. The High Level Operational Concept Graphic describes a mission and highlights main operational nodes (see OV-2 definition) and interesting or unique aspects of operations. It provides a description of the interactions between the subject architecture and its environment, and between the architecture and external systems. A textual description accompanying the graphic is crucial. Graphics alone are not sufficient for capturing the necessary architecture data.
Product Purpose. The purpose of OV-1 is to provide a quick, high- level description of what the architecture is supposed to do, and how it is supposed to do it. This product can be used to orient and focus detailed discussions. Its main utility is as a facilitator of human communication, and it is intended for presentation to high-level decision makers.
Product Detailed Description. OV-1 consists of a graphical executive summary for a given architecture with accompanying text. The product identifies the mission/domain covered in the architecture and the viewpoint reflected in the architecture. OV-1 should convey, in simple terms, what the architecture is about and an idea of the players and operations involved.
The content of OV-1 depends on the scope and intent of the architecture, but in general it describes the business processes or missions, high- level operatio ns, organizations, and geographical distribution of assets. The product should frame the operational concept (what happens, who does what, in what order, to accomplish what goal) and highlight interactions to the environment and other external systems.
During the course of developing an architecture, several versions of this product may be produced. An initial version may be produced to focus the effort and illustrate its scope. After other products within the architecture’s scope have been developed and verified, another version of this product may be produced to reflect adjustments to the scope and other architecture details that may have been identified as a result of the architecture development. After the architecture has been used for its intended purpose and the appropriate analysis has been completed, yet another version may be produced to summarize these findings to present them to high- level decision makers.
OV-1 is the most general of the architecture products and the most flexible in format. Because the format is freeform and variable, no template is shown for this product. However, the product usually consists of one or more graphics (or possibly a movie), as needed, as well as explanatory text.
Popularity: 2% [?]
Overview and Summary Information (AV-1)
February 6, 2008
- Architecture Project Identification
- Name
- Architect
- Organization Developing the Architecture
- Assumptions and Constraints
- Approval Authority
- Date Completed
- Level of Effort and Projected and Actual Costs to Develop the Architecture
- Scope: Architecture View(s) and Products Identification
- Views and Products Developed
- Time Frames Addressed
- Organizations Involved
- Purpose and Viewpoint
- Purpose, Analysis, Questions to be Answered by Analysis of the Architecture
- From Whose Viewpoint the Architecture is Developed
- Context
- Mission
- Doctrine, Goals, and Vision
- Rules, Criteria, and Conventions Followed
- Tasking for Architecture Project and Linkages to Other Architectures
- Tools and File Formats Used
- Findings
- Analysis Results
- Recommendations
AV-1 Example
Product Definition. The Overview and Summary Information provides executive- level summary information in a consistent form that allows quick reference and comparison among architectures. AV-1 includes assumptions, constraints, and limitations that may affect high-level decision processes involving the architecture.
Product Purpose. AV-1 contains sufficient textual information to enable a reader to select one architecture from among many to read in more detail. AV-1 serves two additional purposes. In the initial phases of architecture development, it serves as a planning guide. Upon completion of an architecture, AV-1 provides summary textual information concerning the architecture.
Product Detailed Description. The AV-1 product comprises a textual executive summary of a given architecture and documents the following descriptions.
Architecture Project Identification identifies the architecture project name, the architect, and the organization developing the architecture. It also includes assumptions and constraints, identifies the approving authority and the completion date, and records the level of effort and costs (projected and actual) required to develop the architecture.
Scope identifies the views and products that have been developed and the temporal nature of the architecture, such as the time frame covered, whether by specific years or by designations such as current, target, transitional, and so forth. Scope also identifies the organizations that fall within the scope of the architecture.
Purpose and Viewpoint explains the need for the architecture, what it should demonstrate, the types of analyses (e.g., Activity-Based Costing) that will be applied to it, who is expected to perform the analyses, what decisions are expected to be made on the basis of an analysis, who is expected to make those decisions, and what actions are expected to result. The viewpoint from which the architecture is developed is identified (e.g., planner or decision maker).
Context describes the setting in which the architecture exists. It includes such things as mission, doctrine, relevant goals and vision statements, concepts of operation, scenarios, information assurance context (e.g., types of system data to be protected, such as classified or sensitive but unclassified, and expected information threat environment), other threats and environmental conditions, and geographical areas addressed, where applicable. Context also identifies authoritative sources for the rules, criteria, and conventions that were followed. (See Universal Reference Resources [URR] section in the Deskbook for examples of authoritative sources.) The tasking for the architecture project and known or anticipated linkages to other architectures are identified.
Tools and File Formats Used identifies the tool suite used to develop the architecture and file names and formats for the architecture and each product.
Findings states the findings and recommendations that have been developed based on the architecture effort. Examples of findings include identification of shortfalls, recommended system implementations, and opportunities for technology insertion.
During the course of developing an architecture, several versions of this product may be produced. An initial version may focus the effort and document its scope, the organizations involved, and so forth. After other products within the architecture’s scope have been developed and verified, another version may be produced to document adjustments to the scope and to other architecture aspects that may have been identified as a result of the architecture development. After the architecture has been used for its intended purpose, and the appropriate analysis has been completed, yet another version may be produced to summarize these findings for the highlevel decision makers. In this version, the AV-1 product, along with a corresponding graphic in the form of an OV-1 product, serve as the executive summary for the architecture.
Popularity: 2% [?]
Architectural Framework Views
February 5, 2008
The documents provided on this site are detailed instructions of how to create a blueprint of a given enterprise/Information/Weapons system. There are no specifics on any Department of Defense or Ministry of Defense systems given here Architecture views are based on the de facto Zackman Framework *
This post series is here to help System/System Security Engineers put together documents such as SSAA’s, DIACAP, and Information Support Plans (ISP) formerly known as Command, Control, Communications, Computers, and Intelligence Support Plan (C4ISP). Complex, critical enterprise, information and Weapon systems are documents that require Architecture Frameworks which are based on the Zachman Framework standard. Many of these documents are guided by policies that are in steady flux.
Coming Soon: OV-1, OV-2, OV-3, OV-4, SV-1, SV-2, SV-4, TV-1
Resources:
Documenst such as CJCSI 3170, CJCSM 3170 and CJCSI 6212 Can be found here:Resources and here Archives
Great links:
Popularity: 2% [?]
