The Truth about Hedge Funds

The following article has been edited by me. My comments are in italic and in bold.

Recently had occasion to look at Hedge Funds For Dummies by Ann C. Logue (2007). A couple of things struck me.

• Would I get more dirty looks reading a book about Hedge Funds in a public place than I would by reading   the current equivalent to Playboy ? 
• Would I be able to read the book without getting into a series of arguments with it?

Yes, hedge funds can provide a valuable service in the economy – but the managers that manage them give

them a bad rap and theregulators that ‘supposedly’ regulate them are clueless on how to do their job.

 

Aside: The regulators are fighting a losing battle as the financial industry – for better or worse – is constantly

modifying, expanding\ and  changing, so a rule based system is always fighting yesterday’s wars.

 

So let’s peel away some of the jargon and battle some of the ignorance so that you can make an informed decision as

to whether hedge funds can be good (as opposed to inherently evil) and whether you can use them to help you

 

or your family

 

Thus the definition of a hedge fund an aggressively managed portfolio of investments that uses

 

advanced investment strategies such as leveraged, long, short and derivative positions in both

 

domestic and  international markets with the goal of generating high returns (either in an

 

absolute sense or over a specified market benchmark)

 

Legally, hedge funds are most often set up as private investment partnerships that are open to a

 

limited  number of investors and require a very large initial minimum investment. Investments in

 

hedgefunds ar   illiquid as they often require investors keep their money in the fund for at least

 

of the year

http://www.investopedia.com/terms/h/hedgefund.asp

So let’s review the comment made by Ms Logue: “Not all hedge fund managers are performing financial alchemy. Many

of  the techniques they use are available to any investor who wants to increase  return relative to the amount o

 

 

f risk taken.”

 

We agree with her so much. Many of the techniques are available to financial literate people. The ‘alchemy’ part throws people off.

The definition of alchemy: “the pseudoscientific predecessor of chemistry that sought a method of

transmuting   base metals into gold.”

 

 

It conjures up images of a quaint or quasi mad medieval philosopher on a fool’s quest. After


all who would believe?

• That you could speak to someone over hundreds of miles by using strings

• That you could heat up sand, draw pictures on it and it would allow me the power to write
  
  
  
  
  this article
  
  
   
• That you could use a ‘special’ card to buy your provisions for the week
   
• That you could use the same card to transport yourself 1200 miles in a couple of hour
  

 

Nonsense, right?

As we have seen in this Information Age that the power of invention and discovery is still amongst us and it only seems ridiculous until you find a way to do it.

Some very smart people have devoted their lives and in some cases fortunes, to an activity that was unheard for most a hundred years ago. Financial alchemy exists. Let’s follow Giovanni as he discovers how to use it for his and your advantage.

alchemy  (lk-m)

A medieval philosophy and early form of chemistry whose aims were the transmutation of base metals into gold, the

discovery of a cure for all diseases, and the preparation of a potion that gives eternal youth. The imagined substance

capable of turning other metals into gold was called the philosophers' stone.

A Closer Look Because their goals were so unrealistic, and because they had so little success in achieving them, the

practitioners of alchemy in the Middle Ages got a reputation as fakers and con artists. But this reputation is not fully

deserved. While they never succeeded in turning lead into gold (one of their main goals), they did make discoveries that

helped to shape modern chemistry. Alchemists invented early forms of some of the laboratory equipment used today,

including beakers, crucibles, filters, and stirring rods. They also discovered and purified a number of chemical

elements, including mercury, sulfur, and arsenic. And the methods they developed  to separate mixtures and purify

compounds by distillation and extraction are still important.

 

Unlimited Wealthby Paul Zane Pilzer

I began my studies at Wharton Graduate Business School in 1975 with this belief: that human suffering and social injustice reflected nothing more than our failure to use the tools that God had given us.”

 

See Preface from Unlimited Wealth

Excerpt from Unlimited Wealth — Introduction

For the past four hundred years, virtually all practitioners of the dismal science we call economics have agreed on one basic premise: namely that a society’s wealth is determined by its supply of physical resources–its land, labor, minerals, water, and so on.  And underlying this premise has been another, even more profound, assumption–one supposedly so obvious that it is rarely mentioned: namely, that the entire world contains a limited amount of these physical resources.

This means, from an economic point of view, that life is what the mathematicians call a zero-sum game.  After all, if there are only limited resources, one person’s gain must be another person’s loss; the richer one person is, the poorer his neighbors must be.

Over the centuries, this view of the world has been responsible for innumerable wars, revolutions, political movements, government policies, business strategies, and possibly a religion or two.

Once upon a time, it may even have been true.  But not anymore.

Whether or not we ever did, today we do not live in a resource-scarce environment.  That may seem hard to believe, but the businessperson and the politician–as well as the butcher, the baker, and the candlestick maker–who
continue to behave as if they were operating in the old zero-sum world will soon find themselves eclipsed by those who recognize the new realities and react accordingly.

What are these new realities?  To put it simply, we live today in a world ofeffectively unlimited resources–a world of unlimited wealth.  In short, we live in what one might call a new Alchemic world.

The ancient alchemists sought to discover the secret of turning base metals into gold; they tried to create great value where little existed before.  But an analysis of their writings shows that they were on a spiritual as well as a monetary quest.  They believed that by discovering how to make gold they could offer unlimited prosperity to all of God’s children.  And, although in our era the term alchemy is often equated with “false science” and fraud, the ancient alchemists were successful in their quest in a manner that they could not have anticipated.

Consider this: if the ancient alchemists had succeeded in fabricating gold, gold would have become worthless and their efforts would have been for naught. Yet, through their attempts to make gold, they laid the foundation for modern science, which today has accomplished exactly what the alchemists hoped to achieve: the ability to create great value where little existed before.  We have achieved this ability through the most common, the most powerful, and the most consistently underestimated force in our lives today–technology.

In the alchemic world in which we now live, a society’s wealth is still a function of its physical resources, as traditional economics has long maintained.  But unlike the outdated economist, the alchemist of today recognizes that technology controls both the definition and the supply of physical resources.  In fact, for the past few decades, it has been the backlog of unimplemented technological advances, rather than unused physical resources, that has been the determinant of real growth.

 

There is no such thing as unlimited growth. We live on globe. Resources are finite. The problem with

 

hedgefunds is if you have to aggressive market them they are probably bad investment. There is a

 

funny guy named Matt, he loves aggresive marketing strategies and 9/10 times he gets balls busted

 

because he  loves hedge funds.

The problem with books like the above and its authors are they so smart they would be rich. The reason

 

it is  a truism , people know a good thing when they see it. The ancient alchemists did produce gold. I

 

have an  uncle who is top surgeon and medical researcher. I asked him about the Triumphant Chariot of

 

Antimony  and asked it it was feasible to produce the medicine. He told me it was, but it be very costly

 

Alchemy is high energy chemistry.

 

Net-Ops :Another Supposedly leaked document

This is another docment from  http://thedocs.hostzi.com    The document is faithfully produced  expept for graphic  files. 
Have fun with it :)

 

1

Purpose

The purpose of the NetOps Strategic Vision is  to communicate the DoD CIO’s vision and goals for migrating to new NetOps capabilities which will enable the Department’s Net-Centric vision. It builds on the DoD Information Management/Information Technology (IM/IT) Strategic Plan, the GIG Architectural Vision, and supporting Net-Centric strategies. This document is intended to do the following: guide the Department’s NetOps activities, initiatives, and investments; foster unity of   effort throughout DoD  and its mission partners; serve as a framework for governing the evolution of NetOps capabilities; and provide the foundation for planning the coherent implementation of NetOps across the DoD.

The NetOps Strategic Vision is written for Department leadership including the Office of the Secretary of Defense, the Military Departments, the Chairman of the Joint Chiefs of Staff, the Combatant Commands, and Agencies. It provides insight for the Department’s mission partners and other organizations engaged inthe operation and defense of the GIG. Commanders, warfighters, system and service developers, and acquisition personnel must understand the vision for NetOps. Areas of responsibility for this new construct have been defined in Departmental policy and guidance such as the Defense Information Enterprise Architecture version 1.0 and will be fomalized in the DoD Instruction, NetOps for the GIG

.

2

Introduction

2.1

NetOps Overview

As the globally interconnected set of DoD information capabilities, the GIG is truly a set of Joint capabilities that are used throughout DoD. The information and functional capabilities it provides impact every aspect of DoD operations. The GIG includes all owned and leased communications and computing systems and services, software (including applications), data, security services, and other associated services necessary to achieve Information Superiority. It also includes National Security Systems as defined in section 5142 of the Clinger-Cohen Act of 1996. The GIG supports all Department of Defense, National Security, and related Intelligence Community missions and functions (strategic, operational, tactical, and business), in war and in peace.

The GIG provides capabilities from all operating locations (bases, posts, camps, stations, facilities, mobile platforms, and deployed sites). The GIG provides interfaces to coalition, allied, and non-DoD users and systems.

1

NetOps is defined as the DoD-wide operational,organizational, and technical capabilities for operating and defending the GIG. NetOps includes, but is not limited to, enterprise management, net assurance

2

, and content management. NetOps provides commanders with GIG situational awareness to make informed command and control decisions. GIG situational awareness is gained through the operational and technical integration of enterprise

1

DoD Directive 8100.1, September 19, 2002

2

This term formerly referred to as “Net Defense” DoD NetOps Strategic Vision

2

management and defense actions and activities across all levels of command (strategic, operational, and tactical).

3

•

Enterprise Management is the set of functional capabilities and operational processes necessary to monitor, manage, and control the availability, allocation, and performance within and across the GIG. It includes Enterprise Services Management, Applications Management, Computing Infrastructure Management, Network Management, Satellite Communications Management, and Electromagnetic Spectrum Management.

•

Net Assurance is the set of functional capabilities and operational processes necessary to protect and defend the GIG. This includes the operational responsibilities for

information assurance, computer network defense (to include Computer Network Defense Response Actions), and critical infrastructure protection in defense of the GIG.

•

Content Management is the set of functional capabilities and operational processes necessary to manage, and facilitate the visibility and accessibility of information within

and across the GIG. NetOps influences all core segments of the GIG and associated capabilities in the Net-Centric capability portfolio

4

which encompasses Net Management as well as those associated with Information Transport, Enterprise Services and Information Assurance. By linking these operational, technical and programmatic perspectives to achie ve integrated capabilities, NetOps assures the availability, protection and integrity of DoD networks, systems, services, and information. In support of NetOps, the United States Strategic Command (USSTRATCOM) is responsible for planning, integrating, and coordinating DoD’s global network operations by directing GIG operations and defense and by advocating the respective desired characteristics and capabilities. USSTRATCOM executes this mission through the Joint Task Force–Global Network Operations (JTF-GNO) with the full and active participation by the entire joint community. Every DoD Component and partner organization that develops, deploys, operates, or uses any portion of the GIG plays a role in the accomplishment of this mission from the Combatant Commands and Services through acquisition executivesand materiel developers who must ensure capabilities destined for use as part of the GIG are supportive of NetOps and USSTRATCOM’s role.

2.2

The Role of NetOps in Net-Centric Operations The role of NetOps in Net-Centric Operations is to enable the GIG to provide users at all levels and in all operational environments access to and use of the information they need. As depicted in Figure 1, NetOps is a critical operational enabler, and forms the core of GIG operations in a Net-Centric framework. NetOps enables the operations and defense within and across GIG information transport, enterprise services, and information assurance capabilities.

3

DoD Instruction, NetOps for the GIG, Draft Final, July 2008

4

Net-Centric Joint Capability Area (JCA) Tier 2 DoD NetOps Strategic Vision

3

It does so in a way that creates a trusted environment capable of protecting and maintaining the integrity, quality, and availability of information. This trusted environment enables users to  post, access, and share relevant information and to collaborate on the development and/or use of such information. This environment also enables forces to conduct Net-Centric Operations and superior decision making through shared understanding, and agile force synchronization.

Figure 1.

NetOps Enabled Net-Centric Operations

2.3

NetOps Today

NetOps has yet to transcend the organizational and functional stovepipes of individual GIG networks in terms of interoperability and information access. While each of these stovepipes has its own management capability, DoD does not yet share information to manage across domains. The result is relatively static configurations that  limit NetOps and GIG agility in the face of rapidly changing and Providing a robust, DoD-wide NetOps capability would significantly enhance the ability of the operators/defenders of the GIG to fully support warfighting and non-warfighting missions in an increasingly joint and multi-partner environment.

DoD NetOps Strategic Vision

4

unanticipated mission needs. The Joint NetOps Concept of Operations

5

has enabled the DoD to begin significantly improving how the GIG is operated and defended. Also the Net-Centric Functional Capability Board within the Joint Capabilities Integration and Development System (JCIDS) process and the related Net-Centric Capability Portfolio Manager (NC CPM) initiative

6

have begun to address many of the key deficiencies that have been reported from operation Iraqi Freedom and day-to-day operations. Continued organizational, technological

and process changes will enable a significantly more unified, timely and responsive GIG NetOps that can fully enable net-centric operations by providing:

•

Timely and complete GIG Situational Awareness information to Commanders

•

GIG Command and Control capabilities that enable rapid decision making

•

Clear, well integrated and enforceable NetOps operational policies

•

More effective, coordinated operational use of the electromagnetic spectrum

•

Standardized metrics that enable the measurement of the health and mission readiness across the GIG

•

Automated, federated NetOps capabilities that enable the rapid adaption of GIG capabilities to rapidly changing mission needs and unanticipated threats.

•

Increased coordination, alignment and synchronization of NetOps acquisition and fielding activities currently under way.Addressing these capabilities will significantly improve the ability of the operators and defenders of the GIG to fully support ongoing warfighting and peacekeeping missions in an increasingly joint and multi-partner environment.However, there is a need for overarching operationally based guidance to ensure unity of effort in transforming NetOps to this end

 

3

NetOps in the Future

3.1

The NetOps Challenge To provide the capabilities outlined in the previous section, NetOps will transform along with the GIG, to dynamically support new warfighting, intelligence,and business processes and enable users to access and share trusted information in a timely manner. The future GIG will result in a richer Net-Centric information environment comprised of shared services and capabilities based on advanced technologies. It will be heavily reliant on end-to-end virtual networks to interconnect anyone, anywhere, at

5

Joint Concept of Operations for GIG NetOps, Version3, 4 August 2006

6

Network Management & Spectrum Management Functional Solutions Analysis (NM & SP FSA); Final Draft,

16 May 2008

The overarching NetOps challenge is to be able to operate and defend the GIG as a single, unified, agile and adaptive enterprise capable of providing

responsive and resilient support to multiple simultaneous mission areas under uncertain and changing conditions. DoD NetOps Strategic Vision

5

any time with any type of information through voice,video, images, or text. It will also be faced with even greater security threats that NetOps must help address.

In a Net-Centric environment, the core GIG capabilities (e.g. Information transport, Enterprise Services, and Information Assurance) and the applications they support will become increasingly dynamic with new capabilities being deployed, configured, re-configured, and removed as needed to meet the needs of anagile force and dynamic mission requirements. This new and dynamic environment will require that NetOps be executed in an equally dynamic way. As the current Base Realignment and Closure progresses, Commanders and staff elements will find themselves increasingly operating in an environment that they do not directly control. For example, an Air Force or Army unit may be Joint-based on each other’sinstallation, which will require them to use the host organization’s networked infrastructure and conform to the host’s policies. Another example would be if a user at a Navy or Marine Corps installation had to access Army services, information, or data to do operational planning. While there are some notable exceptions, this is in sharp contrast to today’s environment, in which most services and capabilities are Service stovepipes

owned and controlled by individual units or organizations. In a shared environment, warfighters will have to trust that services and capabilities will be available when and where they are needed. NetOps requires dynamic, flexible, integrated management capabilities that enable rapid synchronization of decisions at appropriate levels across different areas of responsibility or domains within the GIG. This will facilitate the decision-making necessary to quickly identify problems, shift resources, change configurations and coordinate management of the GIG infrastructure and capabilities. Finally, the future NetOps must provide Commanders with the ability to effectively control, manage, defend, and operate in and through the cyberspace domain. The National Military Strategy for Cyberspace Operations lays the initial groundwork for this effort and NetOps must continue to evolve and support this integral component of future warfighting.

3.2

The Vision for Net-Centric NetOps

To meet the NetOps challenge, a fundamentally improved approach for performing NetOps is necessary – one that involves major improvements in the ability to achieve GIG shared situational awareness and significant changes in the overarching approach to C2 of the GIG as well as the enabling capabilities; the way these capabilities are provided across DoD, and most importantly the way they are viewed and employed by the GIG’s users. The vision is to transform existing and new NetOps capabilities into a force multiplier that enables the warfighters, business, and intelligence users and decision makers to fully employ the The NetOps Vision is to transform existing and new NetOps capabilities into a force multiplier that enables warfighter, business, intelligence, and enterprise information environment users and decision makers to fully employ the power of the GIG. DoD NetOps Strategic Vision

6

power of the GIG. This vision will be attained by establishing NetOps capabilities that are: Mission Oriented: All information dependent processes necessary for a mission can be effectively supported; User Focused: Users can access and obtain needed information from anywhere in the GIG in a timely manner; even when their needs are unanticipated;

Globally Agile: Rapidly changing and unanticipated mission priorities and requirements can be met by dynamically maneuvering GIG resources; and Institutionally Transformed: NetOps capabilities evolve smoothly in concert with GIG capabilities and emerging Net-Centric operational concepts.

This vision will require developing and implementing agile and responsive planning, engineering and provisioning capabilities. In this vision, GIG situational awareness information will be shared with GIG authorized users so they can collaborate on meeting mission needs or assessing the impact of GIG changes on mission accomplishment. NetOps personnel will use shared situational awareness to proactively manage the GIG to meet commander’s intent and to rapidly respond to unexpected changes in threats and mission needs. Shared situational awareness will facilitate central oversight of critical GIG assets and rapid integrated management and execution of decisions. This will be accomplished through

decentralized policy-based management with a high degree of automated support and by employing consistent tactics, techniques, and procedures that enable the conduct of coherent operations in a federated GIG environment. In the future, NetOps will be able to routinely, rapidly, and accurately reallocate or reconfigure GIG resources, including elements such asinformation assurance devices, computing processing and storage capacities, and network throughputs tomeet changing mission needs and threats. All NetOps tasks necessary to enable data access, information flow, and user collaboration across management boundaries or domains will be synchronized and executed at an appropriate level of detail. Commanders will beable to understand the state of the GIG as it relates to their missions and the associated tradeoffs in performance, security, and agility that could impact the mission. Warfighters and other users will be confident that the GIG can be tailored to meet their needs and can be leveraged to enhance the agility and effectiveness of their forces. NetOps capabilities will be developed, implemented, and matured as time-phased capability  increments. These defined capability incrementswill be consistent with and supportive of the DoD’s evolving Net-Centric operational concepts. Transforming and maturing NetOps will involve work in many non-technical areas that span Doctrine, Organization, Training, Material, Leadership and Education, Personnel and Facilities (DOTMLPF). A critical aspect of NetOps transformation will be the creation of policy, governance structures, implementation plans, and metrics that will be necessary to guide NetOps evolution.

DoD NetOps Strategic Vision

7

4

The Net-Centric NetOps Strategic Vision Goals and

Objectives

The following sections describe a set of goals and objectives that are intended to serve as actionable guidance for achieving the NetOps Vision. The goals described in Table 1 are focused on achieving operational outcomes, not on developing and deploying specific technical implementations. This recognizes  that the major hurdles associated with transforming NetOps are organizational, procedural, or cultural in nature. While there are also technical challenges, the Department must first and foremost fundamentally re-think how it conducts NetOps in order for the GIG to be truly responsive to mission needs and to effectively support operations in cyberspace. Each goal identifies high-priority objectives for meeting that goal.

Table 1. Goals for Net-Centric NetOps

 

Goals	Description
Share GIG Situational Awareness	Provide GIG users, operators, and commanders at all levels with accurate and timely information that enables a shared understanding of the health and mission readiness of the GIG
Unify  GIG CIC	Adopt a unified C2 approach for agile proactive management of the GIG.
Institutionalize NetOps	Institutionalize NetOps across DOTMLPF to ensure DoD requirements, acquisition, budgeting, and management processes can be influenced to achieve the NetOps vision

 

 

 

.

4.1

Goal 1: Share GIG Situational Awareness

Provide GIG users, operators, and commanders at all levels with accurate and timely information that enables a shared understanding

of the health and mission readiness of the GIG.

4.1.1

Objective: Make NetOps data visible, accessible, and understandable to all authorized users Effective and efficient management of the GIG requires accurate, timely, and relevant situational awareness. Authorized users must be able to quickly find, access, retrieve, and analyze information related to the operational health, performance, security, and mission readiness of the GIG. Achieving this objective will require the adoption of Department-wide, industry based standards for posting and sharing NetOps information. This will ensure that authorized users, to include mission partners, will have access to the NetOps information they need to support operational missions. NetOps must move from a point-to-point information sharing model to one that exposes NetOps data and information to any authorized user (person or machine) using agreed-upon data models and mechanisms.

DoD NetOps Strategic Vision

8

Owners and managers of NetOps capabilities must comply with the DoD Net-Centric Data Strategy by making all NetOps datvisible, accessible, and unders tandable to all authorized users. This is necessary to support critical processes among NetOps centers; such as processes for fault identification, isolation, and correction, as well as those for information assurance and computer network defense activities. Adopting industry based standards will also improve the Department’s ability to share NetOps information with mission partners and commercial entities that support and provide information technology services and capabilities to the DoD. NetOps personnel and the users they support must be able to access NetOps data commensurate with its operational and security sensitivity and their assigned and authorized permissions. This means that it will be necessary to develop rules to govern access to NetOps data. NetOps data must also be made available in ways that support users equipped with different access mechanisms, (e.g. desktop or laptop versus personal digital assistants, etc.).

Finally it is no longer possible to predict inadvance all who might need access to NetOps information; therefore NetOps information sharing approaches must be able to accommodate the unanticipated or ad hoc user. For instance, a Combatant Command J4, who traditionally might not be considered a user of NetOps information, may want to know the reliability of a service that was not specifically developed for his mission. He might want to understand whether a Defense Logistics Agency service that provides order confirmation and availability status to wholesale logistics centers is reliable (i.e., operational all the time, endorsed by the people who rely on it, etc.).

4.1.2

Objective: Provide GIG Situational Awareness information in a mission context Commanders at all levels mustbe provided with the understanding of how events happening across the GIG impact their operations. NetOps personnel must make information related to the health and mission readiness of the GIG available to Commanders in a form that can be easily adapted to their mission context. Rather than simply informing a Commander that a network router is “down” or that a critical battlefield application service that operates over a satellite link is experiencing excessive delay, NetOpsmust have the ability to report an event

Leaked D.O.D document

The following come from http://thedocs.hostzi.com  According to my source,Anonymous got them. I gather they can't be THAT  secret.  Have fun with them.

Department of Defense

Office of the Assistant Secretary of Defense (OASD) for Network Infrastructure and Integration (NII)

Configuration Management Plan

For

The DoD Architecture Framework (DoDAF)
And
DoDAF Meta Model (DM2)

Version 1.0

3 October 201

THIS PAGE INTENTIONALLY LEFT BLANK

Revision History

This document is under the control of the Department of Defense Chief Information Officer (DoD CIO). Any changes to this document will be reflected by a document change record or by a complete revision.

Document DateRevision LevelChange DescriptionAffected Section(s)April 20101.0 DRAFTFirst DRAFT submitted to FAC for reviewALLMarch 20111.0 DRAFTResponse to FAC commentsALLOctober 20111.0 DRAFTRevision for change in FAC voting process, formal tasker process, baseline scheduling, and additional FAC commentsALL

 

THIS PAGE INTENTIONALLY LEFT BLANK

Table of Content

List of Figures and Tables

1. Introduction

   1. Purpose

      1. Purposes of the DoD Architecture Framework (DoDAF)

The purpose of the DoD Architecture Framework (DoDAF) is to support process improvement for the six core processes of DoD:

1. Joint Capabilities Integration and Development (JCIDS)
   
2. Planning, Programming, Budgeting, and Execution (PPBE)
   
3. Acquisition System (DAS)
   
4. Systems Engineering (SE)
   
5. Operations Planning
   
6. Capabilities Portfolio Management (CPM)

1. Purposes of the DoDAF Meta Model (DM2)

The DoDAF Meta Model (DM2) is the core of DoDAF. The purposes of DM2 are:

1. Provide the vocabulary for description and discourse about DoDAF models (formerly “products”) and core process usage.
   
2. Provide the basis for generation of the “physical” exchange specification for exchange of data between architecture tools and databases.
   
3. Provide a basis for semantic precision in architectural descriptions to support heterogeneous architectural description integration and analysis in support of core process decision making.
   
4. Support discovery and understandability of architecture data assets within the DoD Enterprise Architecture (EA) Community of Interest (COI) and with cross-COIs, discovery using DM2 categories of information, and understandability thru precise semantics augmented with linguistic traceability.
   
5. Support information sharing across the DoD Enterprise Architecture COI with precise, universally understood, and commonly interpretable semantics.

1. Purposes of DoDAF-DM2 Configuration Management (CM)

The purposes of DoDAF-DM2 Configuration Management (CM) are:

1. Governance. Provide a visible and clearly understood process for DoDAF-DM2 issue resolution and model improvement. Establish change activity that is controlled through a known, organized process so that there is a known basis for making change to architecture model, and a means for evaluating the effectiveness of that change. Establish procedures for interaction with related communities including related COIs, EA tool vendors, and semantic interoperability groups.
   
2. Product Improvement. Improve the ability to produce desired models and analyses that reflect customer need through common understanding of the definition and usage of the data. Provide a process for evaluation of present and future impact of proposed changes.
   
3. Baselines. Maintain stable DoDAF-DM2 baselines and clearly establish and provide community-wide awareness of DoDAF-DM2 developmental, operational, deprecated, and retired baselines. Ensure that all changes to any baseline can be traced to an approved change proposal and that the implementation status of changes can be verified.
   
4. COI. Provide a means to continuously re-assess and improve information sharing within the DoD EA COI and with related COIs, to determine requirements for information sharing, and to monitor and measure progress within the DoD EA COI.

A configuration management program provides an orderly way to facilitate change, based on need, and utilizes best practices and performances standards to ensure that expectations are realized, efficiency is increased, reliability and maintainability is assured, and stability achieved.

1. Scope

This plan applies to the Office of the Secretary of Defense, the Joint Staff, the Military Services, the Combatant Commands and Defense Agencies at all levels involved in the development, employment, and maintenance of enterprise architecture models and data. The scope of this DoDAF-DM2 Configuration Management Plan (CMP) is:

1. Configuration Identification (CI)
2. Configuration Management Organizational Roles and Interactions
   
3. DoDAF-DM2 CM Processes and Procedures
   
4. DoDAF-DM2 CM Business Rules
   
5. Configuration Status Accounting

1. Definitions

Reference (Military Handbook Configuration Management Guidance), “Military Handbook Configuration Management Guidance”, states, “DoD has adopted ANSI/EIA-649, “National Consensus Standard for Configuration Management,” as the guiding document providing the basic principles of Configuration Management. Consequently, this CMP adopts terminology and processes from Reference (National Consensus Standard for Configuration Management), “National Consensus Standard for Configuration Management”. . As stated in Reference (National Consensus Standard for Configuration Management),

The configuration management process facilitates orderly management of product information and product changes for such beneficial purposes as to revise capability; improve performance, reliability, or maintainability; extend life; reduce cost; reduce risk and liability; or correct defects. The relatively minimal cost of implementing configuration management is returned many fold in cost avoidance. The lack of configuration management, or its ineffectual implementation, can be very expensive and sometimes can have such catastrophic consequences as failure of equipment or loss of life.

It prescribes processes and procedures for:

The orderly establishment, documentation, and maintenance of a product's functional, performance and physical attributes

Management of changes to the attributes

Access to accurate information essential to the product's development, fabrication, production, use, maintenance, procurement, and eventual disposal..

Reference (National Consensus Standard for Configuration Management) defines a flexible, but well-defined standard employed most often at the ‘enterprise’ level. Its flexibility lies in the ability to provide CM practices that can be selectively applied to the degree necessary for each of the areas to be covered under this plan. Thus, while the standard will be the guide for development of the plan, its principles should not stifle necessary change without undue complexity. Rather, changes that are complex will require more stringent application of technical review, especially on the impact of potential change, than less complex proposals that may be expedited as administrative or logistical changes that do not require the same treatment.
Key terms are defined below. A complete glossary of terms, acronyms, and abbreviations is included at the end of this document.

1. Configuration Management (CM): a management discipline that applies technical and administrative direction over the life cycle of an item to:
   
2. Identify and document the functional and physical characteristics of configuration items (CIs) (configuration identification)
   
3. Control changes to configuration items and their associated documentation (configuration control)
   
4. Record and report information needed to manage configuration items effectively, including the status of proposed changes and the implementation status of approved changes (status accounting)
   
5. Audit CIs to verify conformance to requirements (configuration audit)
   
6. Configuration Item (CI): an aggregation of metadata, and occasionally data on architecture components, processes, or data that is designated for configuration management and treated as a single entity in the configuration management process. (E.g., NetViz net file, Core Systems and Quantities List, etc.) [Adapted from ISO 10007:1995(E)]
   
7. Baseline: the configuration of a model formally established at a specific point in time, which serves as a reference for further activities. [ISO 10007:1995(E)]
   
8. Release: the formal notification and distribution of an approved baseline version of a configuration item.
   
9. Change Request (CR): A formal request for a major and/or specific change to a CI.
10. Change Request Tracker (CRT): A database used to track submitted CRs to any configuration item and to document all actions that add, delete, or change a configuration item.
    
11. Configuration Status Accounting Report (CSAR). A formal document prepared monthly that summarizes all DoDAF-DM2 Working Group (WG) activities during the monthly period, WG membership participation over the period, and all WG recommendations prioritization and adjudication of CRs.
    
12. Version Description Document (VDD). A formal document issued with each DoDAF-DM2 baseline that describes all changes from the prior baseline in summary and detailed form.

1. Applicable Documents

1. Reference Number and TitleDocument Control NumberAuthorDateNational Consensus Standard for Configuration ManagementANSI/GEIA Standard EIA 649-AAmerican National Standards InstituteArchitecture and Standards Review Group (ASRG) CONOPS DoD CIOFeb 2010Systems and software engineering — Architecture descriptionISO/IEC WD4 42010

1. IEEE P42010/D5Jan 2009Military Handbook Configuration Management GuidanceMIL-HDBK-61A(SE)DUSD (AT&L)Feb 2001

1. Configuration Identification

The DoDAF-DM2 Configuration Items and their associated data items are:

1. DoDAF Viewpoint Definitions. Conventions for the construction, interpretation and use of architecture views and associated architecture models.
   
2. DoDAF Model Specifications. Specifications from which architecture views representing a architecture are composed.
   
3. Data Dictionary. Defines all non-demotic terms used in DoDAF and the DoDAF Meta Model.
   
4. DM2. Consists of a Conceptual Data Model (CDM) diagram and narrative description, a Logical Data Model (LDM) in an UML file adapted to IDEAS and a narrative description, and Physical Exchange Specification (PES) XML Schema Descriptions.

NOTE that introductory, tutorial, document outlining, and web navigation documentation is considered under control of the DoDAF Journal editorial team and not subject to formal CM in scope of this plan.
DoDAF-DM2 baselines are statused as “DoDAF Version 2.xx” and “DM2 Version 2.xx” where xx is a sequential number assigned to each baseline. The status of DoDAF-DM2 baselines follows the nomenclature established by the DoD MDR as follows:

1. Operational: This is the current baseline approved for use throughout the DoD EA COI. In addition, this status indicates the Namespace Manager has deemed the baseline of sufficient quality to be used by other COI’s. This baseline is frozen and cannot change.
   
2. Developmental: This is the future operational baseline and the baseline the FAC directs the DoDAF-DM2 WG to work with. DoDAF-DM2 CRs are applied against this baseline.
   
3. Deprecated: These baselines are still valid for use but will be retired in the near future.
   
4. Retired: These baselines are no longer valid to use.

Deprecated and retired baselines will be kept in an archive.

1. Organizational Roles, Responsibilities, and Interactions

As per Reference (Architecture and Standards Review Group (ASRG) CONOPS), “Architecture and Standards Review Group (ASRG) CONOPS”, there are three organizations involved in CM of the DoDAF-DM2 CI’s. They are shown outlined with the yellow background in Error: Reference source not found and described in the following subparagraphs.

Figure 3 . DoDAF-DM2 CM Organizational Relationships

1. Architecture and Standards Review Group (ASRG)

For purposes of DoDAF-DM2 CM, the ASRG has the assigned authority and responsibility to approve configuration baselines and make decisions on configuration and its management.

1. The mission of the ASRG is to review and provide architecture policy and guidance, identify IT technical standards, oversee IT standards management, review and approve architectures as fit for federation, assess compliance with architecture policy, and oversee DOD EA Federation. [Adapted from ASRG CONOPS and ISO 10007:1995(E)] The ASRG serves within the DoD CIO Enterprise Governance framework. The ASRG is subordinate to the DOD CIO Enterprise Governance Board (EGB). It is chartered to: review architecture policy and guidance; identify DoD Information technology (IT) technical standards; oversee IT standards management; review architectures and enforce architecture policy; oversee DoD EA Federation; and enforce DoD Information Enterprise Architecture (IEA) compliance. The ASRG receives its authority to perform these duties from the DoD CIO Governance Board Restructure Implementation and EGB Charter, as authorized in DoD Directive 5144.1, Assistant Secretary of Defense for Networks and Information Integration/DoD Chief Information Officer (ASD(NII)/DoD CIO).
   
2. The ASRG is co-chaired by the DoD CIO’s Director of Enterprise Architecture and Standards, and the Defense Information Systems Agency (DISA) Chief Systems Engineer. The ASRG meets quarterly or as requirements dictate. Chief Architects and Chief Engineers from the military services, selected Combatant Commands and Defense Agencies, USD (AT&L), Joint Staff J6, and the Director of National Intelligence (DNI) CIO comprise this group. the ASRG works through a dedicated secretariat, standing groups, and ad hoc working groups to execute its responsibilities. The standing groups that report directly to the ASRG include the Information Technology Standards Committee (ITSC), Global Information Grid (GIG) Technical Guidance Configuration Management Board (GTG CMB), and FAC. Each has subordinate working groups. Ad hoc groups will also be constituted as needed to work specific issues related to policy, compliance criteria, reference models, and related issues in the EA and standards domains. Support will be provided by member organizations, and existing groups will re-align under the ASRG as applicable. The Enterprise Reference Architecture Cell, an element of the Enterprise Architecture and Infrastructure Directorate, will also provide support to the ASRG. ASRG membership is at the FO/GO/SES level and has representatives from
   
3. DoD CIO (Director
   
4. EA and Infrastructure Directorate
   
5. Co-Chair)
   
6. DISA (Chief Systems Engineer
   
7. Co-Chair)
   
8. DNI CIO (Chief Architect )
   
9. USD (AT&L) (Deputy Director
   
10. Systems Engineering )
    
11. USD (Intelligence) (Chief Architect )
    
12. USD (P&R) (Director of Information Management )
    
13. Army (Chief Architect )
    
14. Department of Navy (Chief Architect )
    
15. USMC (Chief Architect )
    
16. Air Force (Chief Architect )
    
17. DCMO (Chief Architect )
    
18. Joint Staff J6 (Vice Director for C4 Systems )
    
19. STRATCOM (Chief Architect )
    
20. JFCOM (Chief Architect )
    
21. NSA (Chief Architect )
    
22. DNI CIO (Chief Engineer )
    
23. Army (Chief Engineer )
    
24. Department of Navy (Chief Engineer )
    
25. Air Force (Chief Engineer )
    
26. Joint Staff J6 (Chief Engineer )
    
27. JFCOM (Chief Engineer )
    
28. NSA (Chief Engineer )

1. Federated Architecture Committee (FAC)

1. The mission of the FAC is to serve as the Architecture Community of Interest (COI) for the formulation and exchange of DoD architecture concepts, guidance, and policy and to review and recommend to the ASRG that Capability Segment, Reference, Component, and Enterprise-wide Solution architectures are fit for federation into the DoD EA. FAC membership consists of O6-level or civilian equivalent Enterprise Architects and associated managerial and technical professionals, responsible for overseeing architecture programs and activities within their organizations. The FAC is chaired by the DoD CIO EA and Infrastructure Directorate on behalf of the DoD Chief Architect. The Chair reports to the ASRG. The FAC will meet monthly or as required by the Chair. [Adapted from ASRG CONOPS and ISO 10007:1995(E)]
   
2. For purposes of DoDAF-DM2 CM, the FAC is a board composed of technical and administrative representatives with the assigned authority and responsibility to review configuration baselines and to recommend approval to the ASRG. The FAC reviews CR adjudication recommendations from the DoDAF-DM2 WG and votes to accept, reject, or defer these recommendations. The FAC shall consider changes to DoDAF-DM2 for reasons that can be traced to:
   
3. changes needed to eliminate newly discovered internal inconsistencies in the model, or regular model maintenance and clean up,
   
4. changes needed to make the model implementable in tools,
   
5. new (or so far unmet) user community requirements, for example changes needed as a result of changing DoD processes, such as definitions in JCIDS or acquisition processes, new directives, etc.),
   
6. changes in definition, or application of architecture modeling principles and tool application (e.g. release of a new related industry standard such as OASIS Reference Architecture).

2. DoDAF-DM2 WG

The DoDAF-DM2 WG is an advisory group to the FAC. Whereas the FAC is relatively small formal voting body, the WG is a large collaborative body. The DoDAF-DM2 WG has hundreds of members from Government, military, industry, academia, and vendor communities. The DoDAF-DM2 WG oversees, reviews, and makes recommendations to the FAC on matters related to the DoDAF-DM2. The DoDAF-DM2 WG provides the subject-matter expertise necessary to provide informed and broad-based recommendations to the FAC. An overview of the relationship between the FAC and the WG is shown in Error: Reference source not found; details of the interaction are provided in section DoDAF-DM2 CM Processes and Procedures of this CM Plan.

1. DoDAF-DM2 WG Roles

The DoDAF-DM2 WG is internally organized into a Functional Configuration Manager (FCM), CI Custodians (one per DoDAF-DM2 CI), and the WG members.

1. The FCM conducts the WG meetings, performs the day-to-day duties of organizing the WG, maintains the DoDAF-DM2 Action Item system, reports to the FAC, including regular submission of DoDAF-DM2 Configuration Status Accounting Reports (CSAR), maintains the ARCH Namespace on the DoD MDR, represents the DoDAF-DM2 WG at related COI, DoD MDR, and other forums, and establishes DoDAF-DM2 baselines.
2. Designated CI Custodians maintain the CI baselines. DoDAF-DM2 CI Custodians are agents who are appointed to maintain specific DoDAF-DM2 CI’s. CI Custodians will research, analyze, and make recommendations on DoDAF-DM2 CRs and implement approved changes to designated CI’s as directed by the FCM.
3. DoDAF-DM2 WG members. Membership is voluntary and there are no pre-requisites for membership. Members are from Government, military, industry, academia, and vendor communities. No restrictions were made because they tend to stifle input and alienate organizations. However, the DoDAF-DM2 WG follows business rules that channel diverse member views and inputs productively. Members representing DoD components are expected to ensure their components are aware of ongoing work and inform the FAC accordingly.
4. The DoDAF-DM2 WG interacts with the following organizations as shown in Error: Reference source not found. Roles of these organizations with respect to DoDAF-DM2 CM are as follows:
5. The International Defense Enterprise Architecture Specification (IDEAS) Group is developing a formal ontology to facilitate interoperability of Enterprise Architecture (EA) models. Members are the United States, United Kingdom, Canada, Australia, and Sweden with observation by NATO.
   
6. Industry Advisory and Standards Groups to include OMG and OASIS.
   
7. Related COI’s to include UCORE and C2 Core
   
8. Controlled Vocabulary groups
   
9. Pilots and Early Adopters
   
10. DoD Architecture Registry System (DARS) WG
    
11. DoD Metadata Working Group (DoD MWG).
    
12. DoD COI Forum.
    
13. EA Tool Vendors

Figure 3 . FAC - DoDAF-DM2 WG Organizational Relationships Overview

1. DoDAF-DM2 CM Processes and Procedures

DoDAF-DM2 CM is accomplished by the following major process types:

1. CR Processing and Configuration Status Reporting
   
2. Preparation of Draft Baseline, Baseline Review, Resolution, and Release

Each of these is described in the following subparagraphs.

1. CR Processing and Configuration Status Reporting

A typical monthly DoDAF-DM2 CM process is shown in Figure 4-2. Each of the tasks is described in detail in the following subparagraphs.

1. Maintain Membership

The FCM will record attendance at scheduled WG meetings and update the membership information as needed with the following:

1. Name: The name of the individual attending the Work Group.
2. Employer: The company which employs the individual
3. Organization/Project Supported: Project supported by individual.
4. Principal ASRG/FAC Association: Organization represented by member.
5. Email: Contact Email for the attendee.
6. 2nd Email: Secondary Email for contacting the attendee: (optional)
7. 3rd Email: Tertiary Email for contacting the attendee: (optional)

1. Enter New CRs

DoDAF-DM2 CRs can be submitted via the DoDAF-DM2 Working Group website or provided to the FCM by email or at meetings. New CRs are entered into the CRT with:

1. Number: A sequential number assigned to a specific CR.
2. Title: A descriptive name assigned to a specific CR.
3. Description: A detailed description of the CR, including any and all suggested resolutions
4. Date Submitted: Date the CR was added to the CR/DB tracking database.
5. Source: Name of individual submitting the CR.
6. Source Organization: Organization of the individual submitting the CR.
7. Configuration Item (CI): The CI which the CR is about from Table 1.
8. Data Group/ Model/ Other: Part of the CI which the CR specifically requests to be changed.
9. Level of Effort (LOE): Estimate of the resources needed to adjudicate the request as High (H), Medium (M), or Low (L). The default value for new CRs is M.
10. Priority: Importance to submitter and overall usability of the CI as High (H), Medium (M), or Low (L). The default value for new CRs is M.
11. Core Process Category: One of six Core Process listed in paragraph 1.1, if reference by submission.
12. Description of Core Process Requirement: A description extracted from the CR if provided.
13. Status. New CRs are statused as Unassigned.

Figure 4 . CR Processing and Configuration Status Reporting

1. Prepare Agenda and Readaheads

The FCM prepares an agenda of significant events since the last WG meeting, proposed actions based upon requests from last DoDAF-DM2 WG, prioritization from the FAC, inputs from other DoDAF venues, and periodic needs, e.g., to status “in progress” CRs. The typical agenda contains announcements and reports of significant events, status update for “in progress” CRs, presentations by submitters and/or Actionee(s) of new or in progress CRs, starting point in the excel spread sheet for next CRs for consideration and discussion, and time to suggest topics for the next meeting.
The FCM also includes in the Email agenda notification a link with a read-ahead for the upcoming WG from Reference and Research and other material and statuses a numeric summary of DoDAF-DM2 CRs by Status, Priority, and LOE. The FCM also notifies members of any new or updated Research and Reference material on the DoDAF-DM2 Collaboration Site. When a new CR is ready for consideration to the WG, it is proposed as a regular WG meeting agenda item.

1. Conduct WG Meeting

The FCM moderates the conduct of the meeting according to the agenda including:

1. Assisting members and quest with achieving proper access to the collaboration environment, taking attendance and recording contact information for new members.
   
2. Introducing and regulating the sharing of status and any special briefings on agenda topics.
   
3. When an agenda item for a new CR is queued, the FCM aids CR originator: (Note if the CR Originator does not present at scheduled the bi-weekly WG meeting, the unassigned CR is “Moved” to the bottom of queue and it is now in CR trackers rotation discussion queue)
   
4. in the briefing the WG,
   
5. presenting additional materials to the WG, including ones submitted in real-time by WG members,
   
6. advising WG members of DoDAF-DM2 Business Rules as established and described in paragraph DoDAF-DM2 CM Business Rules, herein,
   
7. and facilitating orderly, time-limited, and productive discussion.
   
8. If the working group decides to accept the CR, then the next decision is to determine how it will be implemented. This could include discussion to determine:
   
9. If the CR requires long term research and/or determination of some Course of Action (CoA) and associated Actionee(s) or
   
10. If the CR can be resolved without further research.
    
11. If it can be handled through a simple fix or change (e.g. short textual rewrite with in document), it will be resolved during the current WG discussion and:
    
12. The change is made to the appropriate CI working copy, and
    
13. Documented in the CR Tracking system with the status of “In Version 2.XX” and recording of what was done and the date the action was taken.
    
14. If, after discussion, the WG decided there is need for establishing an CoA, they can choice one of the following actions after following the Originator/Actionee research process outlined in paragraph 4.1.3 below. They do so via mutual consent of the WG attendees (no formal voting process is used): The Action decision shall be recorded with rational in the Action field of the CRT. The date of decision is recorded in the Action Updated Date, Action is recorded in the Action column, and Actionee(s) assigned Actionee(s) may be updated. The following are possible Status:
    
15. In general, if the new CR will require significant time and resources for accomplishment, it will be added to a prioritized list of items that will be addressed through major revisions or formal updates. The significance of the CR will be considered for prioritizing its placement within scheduled revisions or updates as decided by the working group. Once the CI has been included in a formal revision, this information will be passed to the ASRG Secretariat who will inform the submitter of the CIs disposition (See paragraph 4.1.6).
    
16. Just like new CRs, When the agenda calls for review of existing DoDAF-DM2 CRs (CR tracking system) or CI Custodian actions , they are queued for consideration by the WG on a rotating basis. After Actionee(s) provide research findings and subsequent WG discussion, the WG decisions are entry into the CR tracking system again based on mutual consent of the WG attendees (no formal voting process is used). If after Actionee(s) presentation the CR now is considered completed or involves change beyond the requirements baseline of DoDAF-DM2 (core process modeling), or is technically incorrect, inconsistent, or suboptimal, it will be Status appropriately using one of the codes listed in f above. A rationale is recorded in the Action field in the CRT.
    
17. All Completed CRs are reported to the FAC via the WG activity Summary CSAR. Minority member non-concurrence can be report to the FAC through the members FAC representative. Details in reporting to FAC are in paragraph 4.1.6 below.
    
18. The FAC can vote to redirect CR priorities recommended by the WG and/or request further consideration of statused and/or non-concurred CRs.
    
19. When the FCM receives instructions on redirections from the FAC, the topics will be added to the agenda for the next Bi-weekly WG meeting.
    
20. The redirection will be discussed with the CR originator/CR actionee(s) for possible Action impact and the WG again discuss options.
    
21. If the Action impacts business rules or Program vendors, these impacts along with new recommendation from the WG will be reported to the FAC at the same time as the CSAR is sent for FAC consideration as per Paragraph 4.1.6 below.

1. Update CR Status

When the WG Actionee(s) present findings to the WG for review, The Status, Action, Action Update Date, Actionee(s), CI Change Date and/or WG Approve Date will be change to reflect the consensus of the WG.

1. Research Topic

Originator/Actionee recommendation process: Actionee(s) perform preliminary research and prepares a brief for the WG. Research materials are provided to the FCM for posting on the DoDAF-DM2 URL collaboration site.

1. Maintain Working Group Collaboration Site

Material prepared for briefing initial new CRs by originator(s) or Action Item research discussions will be added to content which can be found on the work group collaboration tab on to the http://cio-nii.defense.gov/sites/dodaf20/ web site.

1. Implement Directed Solution.

The CI Custodian implements the solution as directed by the DoDAF-DM2 WG (paragraph 4.1.2.3.h.3), taking care to maintain consistency with all other CI’s and data items, particularly the Data Dictionary.

1. Conduct Ad Hoc WG Sessions

The Actionee(s) may require addition discussion to complete Research topics. Meetings with selected WG membership will be conducted as required.

1. Report to FAC

The FCM reports to the FAC at each monthly FAC meeting. At the meeting, the FCM also receives direction on WG priorities and technical courses of actions and solutions. The FAC specifically reviews priorities recommended by the WG, resolves problems and issues that cannot be resolved within the WG, provides additional guidance from the Community of Interest perspective, and approves or redirects the priorities. This information, guidance and approved priorities are given to the FCM for conduct of future WG activities. An overview of the data exchange is shown in Figure 4-.

1. WG Activity summary information briefing
2. Other information briefings of significant recommendations being considered
3. Configuration Status Accounting Report (CSAR) document for information
4. Process CR Redirects

Figure 4 . Monthly Reporting Cycle

1. DoDAF Specific Processing

Processing specific to DoDAF CRs (as indicated by the CI field in the CRT) is shown in Figure 4-. Note that if the analysis leads to a need for new or changed term or relationship, the process then leads into the DM2 specific processing described in paragraph DoDAF Specific Processing,

1. View request process: If the CR requests deletion of a view or artifact within a view, perform paragraph Artifact deletion request:, below; otherwise perform paragraph New or changed view request: below.
   
2. New or changed view request:
   
3. Determine if the CR requires new views or new or changed artifacts and, if so, determine if the view or artifact is required by core process governance. If the new view or artifact or change is required by a Core Process, continue CR processing; otherwise reject.
   
4. If a new artifact is being requested, determine if the artifact is included in an existing view. If the artifact is already in an existing view but a specific subset is required by Core Process governance, then proceed with CR processing; otherwise reject.
   
5. If nether a new view or artifact nor a changed artifact is being requested, determine if the CR is for improved consistency, description quality, or other view description style guide issues. If so, continue CR processing; otherwise reject.
   
6. Determine if CR requires a new of changed term. If the answer is Yes, perform DM2 Data Dictionary CR processing as described in paragraph DoDAF Specific Processing.
   
7. Determine if the CR requires a new relationship. . If the answer is Yes, perform DM2 Data Dictionary CR processing as described in paragraph DoDAF Specific Processing.
   
8. Construct the CR view requested IAW the view description style guide: Determine the name for the new relationship, create a “one-liner” of the new relationship, construct a description of the relationship, suggest Core Process usage of the new relationship, and provide a DM2 mapping of the new relationship. When these are completed, propose that the CR is done and request schedule for WG review.
   
9. Artifact deletion request:
   
10. Determine is artifact is required by core process governance. If the answer is No, perform paragraph Deleted artifact from View. If as a result of the deletion of this artifact, the view no longer has any artifacts, propose that below, else
    
11. Determine if artifacts are included in some other suitable existing view. If the answer is Yes, continue CR processing; otherwise reject CR.
    
12. Determine if the manner in which the artifact is contained in the view proposed for deletion is required by Core Process governance for a particular reason. It the answer is No, continue CR processing; otherwise reject CR.
    
13. Deleted artifact from View. If as a result of the deletion of this artifact, the view no longer has any artifacts, propose that the entire view be deleted; otherwise, create modified view with artifacts deleted.
    
14. Notify Core Process governance owners of any changes proposed to cited views.

Figure 4  Detailed DoDAF CR Processing

1. DM2 Specific Processing

Processing specific to DM2 CRs (as indicated by the CI field in the CRT) is shown in Figure 4-.

1. The CR is reviewed to determine if it requires a new term or definition change/DM2 relationship change
   
2. A determination is made to evaluate if a new term is requested. If the answer is yes follow procedures in b below, else follow procedures in c below
   
3. Data Dictionary Process:
   
4. Collect source definitions and enter in the Data Dictionary. Particularly important when considering new independent classes is researching multiple source definitions and aliases.
   
5. Review and pick or formulate definition
   
6. Make determination of definition status. If the definition can be aliased follow procedures in 4 step below, else follow new definition process in step 5 below
   
7. Map Alias into appropriate location in the Data Dictionary and prepare for WG presentation (END).
   
8. Determine the supertype of the new definition using the BORO analysis technique.
   
9. Determine relationship in the DM2 by going to paragraph d below
   
10. A determination is made to evaluate the nature of the relationship change. If an new relationship is required follow procedures in d below and consider alternatives in f below
    
11. New Relationship: If a new relationship is not required go to step e below, else perform the following:
    
12. Relationship Process: Determine supertype using the BORO analysis process.
    
13. If a super type can be determined, make change to DM2 and to Data Dictionary (paragraph b above) else
    
14. Determine if the relationship should be aliased. If alias is selected add the alias to the Data Dictionary, else propose that the CR be rejected and request schedule for WG review (END).
    
15. Evaluate relationship integration impact:
    
16. What definitions and other requirements are effected by changed relationships
    
17. If the changed relationship has no impact on the model make change to DM2 and request schedule for WG review (END), else consider alternatives
    
18. Alternatives:
    
19. Consider possible alternatives and if there are none
    
20. Propose that the CR be rejected and request schedule for WG review (END).

Figure 4 . DM2 CR Processing

1. Baseline Process

This process happens in two phases. The first phase is preparation of baseline for FAC approval for component review and the second phase is the adjudication of component comments and publishing the new baseline. Figure 4- shows the first phase required to prepare DM2 and DoDAF inputs for FAC approval. Figure 4- shows the review, resolution, and release process. A notional timeline for a DoDAF-DM2 version development and release is shown in Figure 4-.

Figure 4 . Notional DoDAF-DM2 Version Timeline

1. Announce to WG technical cutoff meeting

The FCM prepares an agenda of significant events since the last WG meeting, proposed actions based upon requests from last DoDAF-DM2 WG, prioritization from the FAC, inputs from other DoDAF venues, and order for “done” and “in progress” CRs to be presented. The cutoff meeting agenda contains announcements and reports of significant events, the actionee(s) briefing the “done” and “in progress” CRs , and time to suggest topics for the next meeting.
The FCM also includes in the Email agenda notification a link with a read-ahead for the upcoming WG from Reference and Research. The FCM also notifies members of specific material to be presented and its location in the Research and Reference material section on the DoDAF-DM2 Collaboration Site.

1. The FCM will notify WG membership of intentions to prepare a new baseline.
2. Announcing a technical cutoff from CR solutions and implementations.
3. The FCM will ask WG membership, who are CR actionee(s), to identify completed and ready for review “done” CR requests.
4. The WG membership will also review “in progress” CRs for consideration.
5. The FCM will announce a proposed date for the Technical Cutoff meeting.

Figure 4  Baseline preparation

1. Conduct technical cutoff meeting

The FCM moderates the cutoff meeting according to the agenda including:

1. Assisting members and quest with achieving proper access to the collaboration environment, taking attendance and recording contact information for new members.
2. Introducing and regulating the sharing of status and any special briefings on agenda topics.
3. When an agenda item for a “done” or CR is queued, the FCM aids actionee(s) in :
4. briefing the WG,
5. presenting additional materials to the WG, including improvements submitted in real-time by WG members,
6. advising WG members of DoDAF-DM2 Business Rules as established and described in paragraph DoDAF-DM2 CM Business Rules , herein,
7. and facilitating orderly, time-limited, and productive discussion of baseline inclusion.
8. When the agenda calls for review of “done” CRs (CR tracking system), they are presented to the WG membership. After Actionee(s) provide research findings and subsequent WG discussion, The WG decides if the CR is ready for baseline release. Approved CR are statused in the CR tracking system as “in version 2.xx” and others are re-status using codes from paragraph 4.1.2.3 and return to queue. All WG decisions are entry into the CR tracking system again based on mutual consent of the WG attendees (no formal voting process is used). The vetting process is similar to that listed for papa 4.1.2.3 but specifically include:
9. Approved for baseline release CRs are given a WG approved date of the meeting.
10. All other CRs will be given Updated status (e.g. defer, in progress for 2.XX+01., etc.) and given an Action Update Date of the meeting.
11. When an agenda item for a “in progress” CR is queued, the FCM aids actionee(s) in:
    
12. briefing the WG,
    
13. presenting additional materials to the WG, including improvements submitted in real-time by WG members,
    
14. advising WG members of DoDAF-DM2 Business Rules as established and described in paragraph DoDAF-DM2 CM Business Rules , herein,
    
15. and facilitating orderly, time-limited, and productive discussion of baseline inclusion.
    
16. When the agenda calls for review of “in progress” CRs (CR tracking system), they are presented to the WG membership. After Actionee(s) provide research findings and subsequent WG discussion, The WG decides if the CR is ready for baseline release. Approved CR are statused in the CR tracking system as “in version 2.xx” and others are re-status using codes from paragraph 4.1.2.3 and return to queue. All WG decisions are entry into the CR tracking system again based on mutual consent of the WG attendees (no formal voting process is used). The vetting process is similar to that listed for papa 4.1.2.3 but specifically include:
    
17. Approved for baseline release CRs are given a WG approved date of the meeting
18. All other CRs will be given Updated status (e.g. “in progress” for next version) and given an Action Update Date of the meeting.
19. Minority member non-concurrence for any CRs approved for baseline can be report to the FAC through the members FAC representative.

1. Reporting to FAC During Baseline Cutoff

The FCM reports to the FAC at each monthly FAC meeting. At the meeting, the FCM will report on CRs to be included in the baseline release, CRs plan for version, and the version release timeline and any issues. The FCM also receives direction on WG priorities and technical courses of actions and solutions. The FAC specifically reviews priorities recommended by the WG, resolves problems and issues that cannot be resolved within the WG, provides additional guidance from the Community of Interest perspective, and approves or redirects the priorities. This information, guidance and approved priorities are given to the FCM for conduct of future WG activities.

1. Prepare baseline review documentation

The FCM will direct the CI and CR Custodians to prepare documentation for Component review to include:

1. Finalize implementations
2. Perform QA using various IDEAS Group and DoDAF-DM2 Custodian tools
3. Update definitions in EA file from Data Dictionary
4. Generate XSDs from Data Dictionary and Mappings Excel and EA UML files
5. Update all description documents
6. Prepare a Version Description Document (VDD) that describes changes to the DoDAF-DM2 in the new version. The VDD will be uploaded to all the DoDAF-DM2 distribution points. This will be prepared from CRT by changing Action field to describe the change actually made.
7. Rename all new baseline files from ISO date stamps to version stamping
8. On MDR, deprecate v2.xx and post v2.xx+01 to Operational status. All ARCH namespace and DoD EA COI subscribers notified of the update.
9. Provide all data items to DoD CIO webmasters for posting and HTML regeneration
10. Archive v2.xx on DoDAF-DM2 Collaboration Site, post new baseline, and create working copy for v2.xx+.02 with ISO date file stamping

When the draft documentation is complete, the FCM will request its entry into the SACP and prepare a “tasker” for FAC to request Component review of proposed “draft” baseline.

1. Adjudication of Component Comments

The FAC will collect component comments and forward them to the FCM for adjudication:

1. The FCM will direct the CI Custodian to re-status the CRs with component comments.
   
2. The FCM will include the comments in the agenda for the next WG meeting.
   
3. The FCM will use the normal WG meeting processes (paragraph 4.1.2) to resolve comments.
   
4. The FCM will relay WG decisions to the FAC in monthly CSAR report (paragraph 4.1.6)
   
5. When all comments have been resolved and the FAC has not redirects the FCM based on the CSAR report and FCM briefing. The FCM will begin Baseline production.

1. Perform Baseline Production and QA

The FCM will direct the CI and CR Custodians to prepare final documentation for baseline release to include:

1. Finalize implementations
2. Perform QA using various IDEAS Group and DoDAF-DM2 Custodian tools
3. Update definitions in EA file from Data Dictionary
4. Generate XSDs from Data Dictionary and Mappings Excel and EA UML files
5. Update all description documents
6. Prepare a Version Description Document (VDD) that describes changes to the DoDAF-DM2 in the new version. The VDD will be uploaded to all the DoDAF-DM2 distribution points. This will be prepared from CRT by changing Action field to describe the change actually made.
7. Rename all new baseline files from ISO date stamps to version stamping
8. On MDR, deprecate v2.xx and post v2.xx+01 to Operational status. All ARCH namespace and DoD EA COI subscribers notified of the update.
9. Provide all data items to DoD CIO webmasters for posting and HTML regeneration
10. Archive v2.xx on DoDAF-DM2 Collaboration Site, post new baseline, and create working copy for v2.xx+.02 with ISO date file stamping

1. Provide Recommendation to ASRG

The FCM will prepare promulgation notice for the FAC to present to the ASRG. Upon ASRG approval, the ASRG approval recommendation will be provided to the DoDAF community distribution and a news article will be posted in the DoDAF Journal.

1. Publish New Baseline

The FCM and Custodians will update the CI locations deprecating the prior version, and archiving older versions. The FAC, WG, and DoDAF community via community events such as the DoD EA Conference and DoDAF Plenaries will be notified of the publication.

Figure 4  Release Baseline Process

1. DoDAF-DM2 CM Business Rules

Business rule govern the conduct of the DoDAF-DM2 WG CM processes. The business rules that apply to the DoDAF-DM2 WG are of two types, one pertaining to the CIs and the the other pertaining to the conduct of the WG. The former are shown in Table 5- and the latter in Table 5-.

Table 5 . DoDAF-DM2 Model Specification RulesRule NameDescriptionTerms and DefinitionsAll model and alias terms proposed for inclusion in the data dictionary shall be researched for multiple source definitions. DoD definitions shall be included. Other Federal Government, industry and academic and common definitions should also be included. The WG shall formulate a baseline definition based on the multiple sources, core process requirements, and model structural meaning. The source definitions and the rationale for the baseline definition shall be maintained in the data dictionary as well.AliasesTerms representing concepts that are represented in a semantically equivalent way by other terms and concepts in the model shall be maintained as aliases and shall not be introduced into the model. Multiple source definitions shall be maintained as with other model terms and a consensus definition shall be derived from the sources. Core Process RequirementAll concepts included in the DM2 shall be necessary to support the information requirements of one or more core processes (PPBE, DAS, JCIDS, CPM, SE, OPS). All DoDAF models shall be applicable to one or more core processes. Core process information requirements shall be as explicitly or implicitly specified in current or planned DoD governance. All model terms and concepts not necessary for core process support with architectures shall be removed. All core process information requirements for architectural descriptions shall be modeled and contained in one or more DoDAF models.Aggregation RuleIf a term representing a concept differs structurally from some other term representing some concept only in level of aggregation, it shall not be included in the model. Whole-part relationships cover the need without different names for different types of wholes and parts. The term may be included as an alias.Subtype RuleIf a term representing a subtype concept has no structural difference from its supertype, it shall not be included in the model. Super-subtype relationships cover the need without different names for different types of supertypes and subtypes. The term may be included as an alias.Typed RelationshipsAll relationships shall be typed, ultimately up to IDEAS foundation. The typing shall be determined using BORO analysis of spatio-temporal examples.Attributes and PropertiesAll attribute and property relationships shall be explicit, that is, by an association class that is typed according to the Typed Relationships rule. The only exceptions are for representational exemplars.DoDAF model specificationAll DoDAF models shall be specified using terms from the data dictionary. Aliases may be used. If new terms are required, they shall undergo the process for new term inclusion in the data dictionary as described by the Terms and Definitions and Aliases rules. All DoDAF models shall be mapped to the DM2 classes (base and associative) that represent the information contained in the view the model specifies.Information PedigreeThere shall be a provision to provide pedigree (and provenance) for every piece of data IAW NCDSSecurity classification markingThere shall be a provision to provide a classification marking for every piece of data and for DM2 PES XML documents overall IAW NCDS

1. Table 5 . DoDAF-DM2 Working Group Process RulesRule NameDescriptionDecision ProcessDecisions on CM processes, CRs, etc., are reached via mutual consent of the WG attendees (no formal voting process is used). Attendance is taken at each meeting, notes are logged and AIs/CRs are statused.DoDAF-DM2 work share siteMaintains reference and research materials for WG.Maintain DoDAF-DM2 descriptionsPart of CDM and LDM CI’s. Formerly, DoDAF Volume I, Section 9, and Volume II, Section 2WG CR cross-referencing and report-outFor CRs coordinated with DoDAF and/or DARS WG, maintain CR cross-referencing and ensure report-out at CR closure.Modification to DDMS DoD EA COI Extensions and other DoDAF-DM2 architectural description metadataCoordination with DARS WG.Organizational IntroductionConsideration of impact of change on existing and/or on-going architecture and engineering efforts. Timing, degree of impact, “grandfathering’, and backwards compatibility will be considered.Quality AssuranceQuality and clarity of proposed changeWG CR cross-referencing and report-outMonthly CR status reports generated from the CRT.XSD ContentVia LDM CI data item that maps DM2 LDM to DoDAF models.ExtensionsA core that can be extended by user communities, so as not to try to cover all user detail. Extenders should be careful to not create redundant representations. Extensions (subtypes (e.g., Unified Modeling Language (UML) specializations), additional attribution, and concepts beyond scope of DoDAF-DM2) to the DoDAF-DM2 are expected and can be done by architecture development efforts. If an extension becomes widespread, it may be appropriate to submit a change request to the DoDAF so that it can be considered by the DoDAF Change Control Board and the Data Working Group for inclusion in the baseline DoDAF-DM2Configuration Status Accounting

   1. CR Tracker (CRT)

CRs are tracked via system that records all actions, plans, status, and dispositions for CRs. The CR tracker has the following fields:

Table 6 . CRT FieldsFieldDefinitionValuesNo.Sequential number for DoDAF / DM2 action items and change requests assigned by the DoDAF / DM2 WG secretariat.Natural numbersTitleShort title of action item or change request for convenient reference by WG.TextDescriptionAction item or change request as submitted by submitter.TextDate SubmittedDate submitted.dd mmm yyyySourceSubmitter individual, group, venue, etc.TextSource OrganizationSubmitter organization.TextCIThe Configuration Item to which the CR pertains.DoDAF Viewpoint, DoDAF Model, and / or DM2Data Group / Model / ViewpointThe DoDAF Viewpoint(s), Model(s) and / or DM2 Data Group(s) to which this CR pertains.Operational, Capability, System, Service, Project, Standard, Data and Information, All

AV-x, OV-x, CV-x, SV-x, SvcV-x, StdV-x, PV-x, DIV-x

Performer, Resource Flow, Services, Capabilities

Measures, Locations, Rules, Foundation (IDEAS), Pedigree, Metadata, Reification, Information and Data

LOEEstimated Level of Effort to resolveHigh, Medium, LowPriorityFAC and Working Group priority for resolution of CRHigh, Medium, Low.Core Process CategoryCore process(es) that requires the requested change or that is potentially impacted by the CR.CPM, DAS, JCIDS, OPS, PPBE, SE.Description of Core Process RequirementThe description of need or impact on the core process(es) cited in the Core Process field.TextStatusState of the CR in the CM processConsult IDEAS Group: If the CR involves the IDEAS Foundation, it is statused as “Consult IDEAS Group”. The Actionee(s) are set to the IDEAS Group US representative(s) and the Priority, LOE, and Action are updated with notes from the WG discussion as to what the Actionee(s) should address with the IDEAS Group. This CR now becomes a CR that will not be re-statused until the IDEAS Group has been consulted and the CR issue has been addressed by the IDEAS Group.

Defer: The CR can become a “defer” CR if the solution is too difficult, costly, time consuming. This could include decision to defer action until after next baseline release. The CR can also be deferred because it is not high priority, is not resourceable, or schedule is inadequate to solve, its Status also becomes “Defer”. Notes as to rationale may be added to the Action field in the CRT. Priority and LOE may also be updated.

In Progress for 2.xx+.01: If the CR is deemed desirable for the next baseline release, the Status becomes “In Progress for 2.xx+.01”, a preliminary Action is recorded in the CR database (DB), Actionee(s) are assigned, Priority is assigned, and an LOE is estimated. The CR will be re-statused at a future DoDAF-DM2 WG when the Actionee(s) have had time to research the CR and devise possible solutions and when In-Progress statusing becomes an agenda item.

Rejected: If the requested CR is not accepted or deemed “unactionable” by DoDAF /DM2 WG, its Status becomes “Rejected”. This includes any CR found to be incorrect, out of scope, or suboptimal. In addition the CI change date and WG Approved Date will be updated with the same date as the Action Update Date.

No Change Required: If the CR is determined to require no changes to the DoDAF or DM2, its Status becomes “No Change Required.” In addition the CI change date and WG Approved Date will be updated with the same date as the Action Update Date.

OBE: Although very unlikely for new CR, Previous CRs and/or CI from the CR and/or another CR has eliminated the need for this CR. In addition the CI change date and WG Approved Date will be updated with the same date as the Action Update Date.

In Ver 2.xx: If the CR is considered completed, its Status becomes “in Ver 2.xx”. A rationale is recorded in the Action field in the CRT and the WG Approve Date is also updated.

1. Unassigned: New ones that are pending WG initial review and determination of course of action and actionee.ActionDuring resolution, this is the action(s) the WG determines need to be taken, the Course of Action (CoA) to be taken. Upon satisfactory completion, this is the record of what was changed.TextAction Update DateThe date of the latest action update.dd mmm yyyyActionee(s)Who is assigned the action.CI Change DateDate(s) changes were made by the actionee(s) and reviewed by the WG.dd mmm yyyyApplicable CI Business RulesCI business rule(s) that need to be adhered to in the resolution of the CR..From the Rule Name column of Table 5-.Business Rule AdherenceThe CRs relationship with the adherence of a business rule.No, YesWG Approve DateThe date the Working Group approves a CR.dd mmm yyyyCSAR

A CSAR is provided to the FAC by the WG every month. The contents are:

1. Purpose - This document summarizes the DoDAF-DM2 Working Group activities and status of DoDAF-DM2 Change Requests (CR).
2. Summary of the DoDAF-DM2 Working Group activity for the reporting period - To keep the FAC apprised of the Working Group meetings, agendas are listed as well as the attendance sheet and a complete list of the Working Group members.
3. DoDAF-DM2 Change Request (CR) Status - This section shows the CR status summary for the current and prior reporting period. The CR tracker fields and field codes are defined in Table 6-.

1. VDD

The Version Description Document is published along with the new release. The purpose of this document is to describe changes made in the new version. It includes a summary of the DoDAF - DM2 change requests and their status. Of those, the ones that have been resolved are listed in a summary of improvements.

1. Glossary and Terms

1. AccreditationAn official determination by management that an M&S is acceptable for a specific purpose. [PAM 5-11]Activity ModelProvides a framework for identifying, defining, and organizing the functional strategies, functional rules, and processes needed to manage and support the way an organization does or wants to do business--provides a graphical and textual framework for organizing the data and processes into manageable groups to facilitate their shared use and control throughout the organization. [DOD 5000.11-M]Application The system or problem to which a computer is applied. Reference is often made to an application as being of the computational type, wherein arithmetic computations predominate, or of the data processing type, wherein data handling operations predominate. [DoD Dictionary of Military and Associated Terms]ArchitectingThe process of developing architecture.ArchitectureThe structure of components, their interrelationships, and the principles and guidelines governing their design and evolution over time. [TOGAF]ASRG DoDAF-DM2 Change Request (CR)The formal mechanism to be used to configuration manage the architecture CI’s. The CR will be the document used to, (1) initiate a major change to a CI, and (2) request specific changes to CIs. Approved CRs are the main products of the ASRG.Archived informationInformation that has been retained for historical purposes that can be retrieved and is usable over the time designated for retention. [ANSI/EIA 649, 12/3/2001 Draft]AuditAn independent examination of a work product or set of work products to assess compliance with specifications, standards, contractual agreements, or criteria. [CMU/SEI-93-TR-25, IEEE-STD-610]BaselineA configuration identification document or set of such documents formally designated and fixed at a specific time during the configuration item’s (CI’s) life cycle. Baselines, plus approved changes from those baselines, constitute the current configuration identification.Configuration(1) The product attributes of an existing or planned product, or a combination of products; (2) one of a series of sequentially created variations of a product. [ANSI/EIA 649, 12/3/2001 draft]Configuration auditThe CM Function that reviews processes and products to validate compliance with requirements, and to verify that products have achieved their required attributes and conform to released product definition information. (I.e., (1) The review of procedures, processes, and systems for compliance and consistency. (2) Examination to determine if a product conforms to its product definition information. (3) Assessment of performance requirements to observed and measured information.) Note: These audits are sometimes divided into separate functional and physical configuration audits. [ANSI/EIA 649, 12/3/2001 draft]Configuration baseline Identifies and declares the attributes of a product at a point in time, which serves as reference for activities throughout its life cycle. [ANSI/EIA 649, 12/3/2001 draft]Configuration changeAn alteration to a product and its product configuration information [ANSI/EIA 649, 12/3/2001 draft]Configuration change managementThe CM function that ensures changes to a configuration baseline are properly identified, recorded, evaluated, approved, incorporated, and verified. (2) The CM process concerning the systematic proposal, justification, evaluation, coordination, and disposition of proposed configuration changes; and the implementation of all approved and released configuration changes into (a) the applicable configurations of a product, (b) associated product configuration information, and (c) supporting and interfacing products and their associated product information. [ANSI/EIA 649, 12/3/2001 draft]Configuration ControlThe systematic proposal, justification, evaluation, coordination, and approval or disapproval of proposed changes, and the implementation of all approved changes in the configuration of a CI after establishment of the baseline(s) for the CI. [MIL-STD-973]Configuration IdentificationThe selection of CI's; the determination of the types of configuration documentation required for each CI; the issuance of numbers and other identifiers affixed to the CI's and to the technical documentation that defines the CI's configuration, including internal and external interfaces; the release of CI's and associated configuration documentation; the functional and physical characteristics, and the establishment of configuration baselines for CI's. [MIL-STD-973]Configuration ItemAn aggregation of important information or data on a component that Is designated for configuration management and treated as a single entity in the configuration management process. This definition includes all information of importance to the management of the design process and development of the CI. CIs include intermediate in-work/draft products and not just final products and, as such, change according to the specific work in progress.Configuration management (CM)A process that establishes and maintains consistency of a product with its requirements and configuration information throughout its life cycle. [ANSI/EIA 649, 12/3/2001 draft]Configuration status accounting (CSA)The CM function managing the capture, storage, retrieval, and access of product configuration information necessary to account for the configuration of a product. [ANSI/EIA 649, 12/3/2001 draft]Configuration verificationThe CM function verifying that a product has achieved consistency and accuracy of its product requirements, and product configuration information/data. The representation of facts, numbers, or datum of any nature that can be communicated/stored, and processed to form information. See Information. [ANSI/EIA 649, 12/3/2001 draft]EffectivityA designation defining the product range (e.g., serial, lot numbers, model, dates) or event at which a change to a specific product is to be (or has been) effected, or to which a variance applies. [ANSI/EIA 649, 12/3/2001 draft]Engineering Change Proposal (ECP)A proposed engineering change and the documentation by which the change is described, justified, and submitted to the Government for approval or disapproval. [MIL-STD-973] Appendix D of MIL-STD-973 provides the format and preparation instructions for an ECP.Group identifierAn alphanumeric identifier that (1) uniquely identifies a group of like units of the same product which are manufactured or assembled under uniform conditions, and are expected to function in a consistent manner (e.g. lot). (2) Is used to uniquely designate a specific volumetric quantity (batch) of a material (usually a chemical mixture) created at the same time and expected to have properties similar to, but not necessarily the same as other batches created at other times. [ANSI/EIA 649, 12/3/2001 draft]InterchangeableA product that is capable of being exchanged with another product, which has equivalent or similar product, attributes without alteration of the products themselves, or of adjoining products, except for adjustment. [ANSI/EIA 649, 12/3/2001 draft]InterfaceThe product attributes that exist at a common boundary of two or more products. [ANSI/EIA 649, 12/3/2001 draft]Interface controlThe process of identifying, recording, and managing product attributes to the common boundary interfacing of two or more products provided by one or more organizations. Interface information is recorded information (e.g. interface control drawing) that depicts product attributes of an interface between related or co-functioning products. [ANSI/EIA 649, 12/3/2001 draft]Life cycleA generic term for the entire life of a product from concept to disposal. [ANSI/EIA 649, 12/3/2001 draft]Nomenclature(1) Names assigned to kinds and groups of products, (2) formal designations assigned to products by customer or supplier (e.g., model number or model type, design differentiation, specific design series or configuration). [ANSI/EIA 649, 12/3/2001 draft]Operational configurationThe ‘state’ (i.e., on/off, open/closed, operating / not operating) of products, systems, or components at a particular point in time. The actual operational configuration will vary depending on overall product status and condition. [ANSI/EIA 649, 12/3/2001 draft]Operational informationInformation that supports the use of a product (e.g., operation, maintenance, and user’s manuals/instructions, procedures, and diagrams). [ANSI/EIA 649, 12/3/2001 draft]Planning, Programming, Budgeting, and Execution (PPBE)The process for justifying, acquiring, allocating, and tracking resources in support of DoD missions. [http://acc.dau.mil]Product attribute(s)Performance, functional, and physical characteristic(s) of a product--product configuration information. Information about a product in support of its life cycle phases. This includes product definition and supplementary types of information e.g., operating procedures, maintenance procedures, disposal methods) necessary to support all phases of the product’s life cycle. However, it does not consist of project or administrative types of information (e.g. cost, schedule, and planning etc. Update alias table [ANSI/EIA 649, 12/3/2001 draft]Product definition informationTechnical design definition information that defines product attributes and is the authoritative source for configuration definition. (E.g., specifications, drawings, source code) Other types of information are derived from the product definition information to develop the product configuration information (e.g., operating procedures, maintenance procedures, disposal methods) necessary to support the product. Update alias table [ANSI/EIA 649, 12/3/2001 draft]Product identifierA name or alphanumeric identifier, unique to the issuing organization, used to designate parts, assemblies, or products of the same configuration, and to differentiate them from other products. Note: These identifiers may include a supplementary identifier used to distinguish one of several sequentially created configurations of a product from the previous configuration of the same product (i.e. revision or version). [ANSI/EIA 649, 12/3/2001 draft]ReleaseDissemination or distribution of information and/or products after approval and is subject to configuration change management. [ANSI/EIA 649, 12/3/2001 draft]RetrofitThe incorporation of new design parts, or software code, resulting from an approved configuration change, into products already delivered. [ANSI/EIA 649, 12/3/2001 Draft]SpecificationInformation that explicitly states the essential technical attributes for a product/unit:)One of a quantity of items (e.g., products, parts); identifier of measure [ANSI/EIA 649, 12/3/2001 draft]ValidationConfirmation that the requirements for a specific intended use or application have been fulfilled [ANSI/EIA 649, 12/3/2001 draft]VarianceAn approved departure from a specified requirement(s). Note: A variance does not require a corresponding revision to current approved product definition information. It may be temporary, permanent, or for a specific use. [ANSI/EIA 649, 12/3/2001 draft]VerificationConfirmation that the produce has fulfilled specific requirements. [ANSI/EIA 649, 12/3/2001 Draft]VersionA particular form of product that varies from other forms of the product. [ANSI/EIA 649, 12/3/2001 draft]Acronyms

ACPArchitecture Certification PackageCRAction ItemANSIAmerican National Standards InstituteARCHArchitectureASDAssistant Secretary of DefenseASRGArchitecture Standards and Review GroupAT&LAcquisition, Technology and LogisticsCDMConceptual Data ModelC2Command and ControlC4Command, Control, Communications and ComputersCIConfiguration ItemCIOChief Information OfficerCMConfiguration ManagementCMBConfiguration Management BoardCMPConfiguration Management PlanActionCourse of ActionCOICommunity of InterestCPMCapabilities Portfolio ManagementCRChange RequestCSARConfiguration Status Accounting ReportDARSDoD Architecture Registry SystemDASDefense Acquisition SystemDBDatabaseDDMSDoD Discovery Metadata SpecificationDISADefense Information Systems AgencyDM2DoDAF Meta ModelDNIDirector of National IntelligenceDoDDepartment of DefenseDoD CIODepartment of Defense Chief Information OfficerDoD MWGDoD Metadata Working GroupDoDAFDoD Architecture FrameworkDODDDepartment of Defense DirectiveDODIDepartment of Defense InstructionEAEnterprise ArchitectureEGBEnterprise Governance BoardEIAElectronic Industries AllianceFACFederated Architecture CommitteeFCMFunctional Configuration ManagerGEIAGovernment Electronics and Information AssociationGIGGlobal Information GridGTG CBMGIG Technical Guidance Configuration Management BoardIAWIn Accordance WithIDEASInternational Defense Enterprise Architecture SpecificationIEAInformation Enterprise ArchitectureIEEEInstitute of Electrical and Electronics EngineersISOInternational Organization for StandardsITInformation TechnologyITSCInformation Technology Standards CommitteeJCIDSJoint Capabilities Integration and DevelopmentLDMLogical Data ModelLOELevel of EffortMDRMeta Data RegistryMILMilitaryNGONon-Governmental Organization NIINetworks and Information IntegrationOASDOffice of the Assistant Secretary of DefenseOASISOrganization for the Advancement of Structured Information Standards OMGObject Management GroupOWLWeb Ontology LanguagePESPhysical Exchange SpecificationPOA&MPlan of Action and MilestonesPPBEPlanning, Programming, Budgeting, and ExecutionQAQuality AssuranceRDBMSRelational Data Base Management SystemSESystems EngineeringTWGTechnical Working GroupUCOREUniversal COREUSDUnder Secretary of DefenseVDDVersion Description DocumentWGWorking Group