Historical Evolution Of Dodaf

Published Date: 02 Nov 2017

Introduction

All organizations have business goals that are realized by the system they build. Often these goals are abstract and difficult to understand. Software Architecture acts as the path that helps in the development of a system from the clearly defined goals.

An architecture of a system is typical of the framework that supports it and conveys to the stakeholders the elements of the system. Architecture can thus be said to be a combination of software elements that are tied together by means of some property. These properties must be of importance to some stakeholder interested in the system. Architecture cannot be composed of just one combination of software elements as architectural decisions are based on a number of factors which are of concern to the various stakeholders. These factors are called non-functional requirements or Quality attributes

Types of Architecture

There are mainly two types of architecture that are associated with the software architecture discipline

System Architecture and Enterprise architecture. Both these disciplines have a set of conditions or constraints that must be adhered to for a software system to function successfully.

System Architecture

System Architecture is a clear representation of a system where the functionality is mapped both onto hardware and software components and there is a relation between software architecture and hardware architecture.

Enterprise Architecture

Enterprise Architecture is a representation of the structural and organizational behaviour of a company, how it is associated with the company’s vision, goals etc. Typical enterprise architectures did not require an information system but in today’s world it’s impossible to think of an enterprise architecture without one. Modern enterprise architecture would have an information system and conditions on how it would affect the business goals and requirements.

There are mainly 3 things that enterprise architecture would deal with

how the systems deal with external factors and systems

human computer interaction to carry out business processes

required computational environment standards

Defense communities throughout the world have developed frameworks to standardize architecture and facilitate easy communication among different branches. It also leads to easy interoperability. Architectures can also be classified as defense based frameworks and non-defense frameworks. In this paper we survey the defense frameworks: DoDAF, andMODAF and the non-defense framework TOGAF and how it compares to Attribute Driven Design.

Enterprise Architecture Frameworks standards are impulsively emerging. With respect to Defense industry frameworks, DoDAF and MODAF are extensively used, and UPDM is emerging. With respect to commercial Information Technology frameworks, TOGAF seems to be the most popular. Zachman framework is another non-defense framework that is very famous.

Architecture Framework "View"

A View is a extension of the system architecture model of an enterprise that is significant to one or more system stakeholders. For instance, a Business Analysis View might exhibit business requirements and business process workflows that are vital to Business Analysts and Clients, but less significant to other system stakeholders (e.g., Hardware engineers, Embedded programmers,etc.,). In Contrary, a System Design View might exhibit software design particulars that are crucial to Software Engineers, Hardware Engineers, and Network Architects, but less significant to Business Analysts and Clients.

The association between an enterprise Architecture Framework and its Views is comparable to the association between an apartment's blueprint and its respective site plans.

ADD

Overview

Carnegie Mellon Software Engineering Institute developed ADD methodology which is called as Attribute Driven Design.The ADD process is an means to define a software architecture where in the design process is based on the software ’s quality attribute requirements. ADD is in accordance with a recursive design method that breaks down a system or system component by applying architectural tactics and patterns that content its driving requirements. ADD essentially follows a "Plan, Do, and Check" cycle:

Plan:

Quality attributes and design deterrents are examined to select which types of elements will be employed in the architecture.

Do:

Elements are instantiated to content quality attribute requirements as well as functional requirements.

Check:

The concluding design is analyzed to determine if the requirements are satisfied.This process is repeated until all architecturally important requirements are satisfied.

DODAF

DoDAF , Department of Defense Architecture Framework is an industrial standard.

The US Department of Defense – DoD, defines DoDAF as The Department of Defense Architecture Framework which is the industry standard of Enterprise Architecture Framework that is used by DoD for defense and aerospace applications. DoDAF explains how to systematize the specifications of enterprise architectures for U.S Department of Defense (DoD). all DoD weapons and Information technology systems should document their enterprise architecture with respect to the viewpoints prescribed by DoDAF architecture.

DoDAF is a model based engineering process. In traditional systems, the system is document based and code based; whereas model based engineering process is requirement driven and architecture centric.DoDAF elucidates a flock of views that operate as apparatus for imagery, understanding, and grasping the wide scope and complexities of an architecture depiction through tabular, structural, behavioral, ontological, pictorial, temporal or graphical methods. DoDAF is best fit to huge systems and systems-of-systems (SoSs) with complex integration and interoperability problems. Despite the fact that DoDAF primarily focuses on defense applications, it can also be enforced to commercial systems. DoDAF has wide pertinence over the private, public and voluntary sectors worldwide, and symbolize one of a large number of system architecture frameworks.

Three related views of DoDAF architecture:

All- View : Explains the scope and context of the architecture.

Operational View : Finds what needs to be accomplished and who does it.

Technical standards view : elucidates standards and conventions

System and services view : amalgamates systems, services and characteristics to operational needs.

DODAF OVERVIEW

The Department of Defense Architecture Framework - (DoDAF)Version 2.0, aid as the synthesized, overarching, comprehensive framework and conceptual model permitting the growth of architectures to allow the capability of Department of Defense managers at all levels to perform key decisions more capable through structured information distribution across the Department, Joint Capability Areas , Mission, Component, and Program boundaries. DoDAF is the structure for organising architecture concepts, principles, assumptions, and terminology about operations and solutions into meaningful patterns to satisfy specific DoD purposes. DoDAF provides directions,instructions on communicating business, mission wants and abilities to managers, architects, analysts, and developers who are authoritative for developing and constructing the important assistances, applications and infrastructure to satisfy the stakeholder wants and to satisfy their expectations. DoDAF compliments mutations in organizations through building and utilization of architectures which will :

• Improve decision making procedure by influencing knowledge and opportunities for reusing already present information properties.

• Reply back to stakeholder, customer, and client wants for efficient and impacting processes, systems, services, and resource allocation.

• Offer procedures to manage configuration of the existing state of the enterprise and manage validity of the conventional performance.

• Assist the design of future states of the enterprise.

• Establish baseline architecture for solutions under development.

Historical Evolution of DoDAF

The Command, Control, Communications, Computers, and Intelligence, Surveillance, and Reconnaissance - C4ISR Architecture Framework version 1.0 was designed on 7th June 1996 and this was developed in counter to the passage of the Clinger-Cohen Act. It reinstated the Technical Architecture for Information Management - TAFIM. Version 2.0 of C4ISR Framework was published on 18th December 1997. The DoDAF Version 1.0 that was published on 30th August 2003 reconstructed the C4ISR Framework Version 2.0 and expanded the employability of architecture principles and practices to all JCA - Java Connector Architecture rather than just the C4ISR group. DoDAF Version 1.0 was complemented by a CADM - Core architecture data model, which aided for data systematizing and sharing. DoDAF Version 1.5 was developed on 23rd April 2007 and this accommodated extra supervision on how to reflect net-centric concepts within Architectural Descriptions also this added information on architectural data management and federating architectures through the Department, and included the pre-release CADM Version 1.5 which is a simplified model of former CADM. DoDAF Version 2.0 broadens previous framework development exertions to catch architecture information about net-centricity, compliment Departmental net-centric strategies, and elaborate service oriented solutions that facilitate the creation and maintenance of a net-centric environment - NCE

ARCHITECTURE VIEWPOINTS OF DODAF Version 2.0

Architecture viewpoints are chosen sets of architectural data which are arranged to provide visualization in an understandable way. An Architectural Description could be visualized in so many formats like dashboard, textual, composite and graphics that represent data and extracted information gathered in the course of the development of an Architectural Description. A view is only a presentation of a division of the architectural data where in the feel that a photograph can show only one view of the object within the picture and not the whole representation of that object.

[DIAGRAM]

All Viewpoint - The All Viewpoint (AV) models provide information pertinent to the entire Architectural Description.

The Capability Viewpoint - The Capability Viewpoint (CV) gets the enterprise goals related with the entire vision for executing a specified course of action

The Data and Information Viewpoint - The Data and Information Viewpoint (DIV) captures the business information requirements and structural business process rules for the Architectural Description.

The Operational Viewpoint - The Operational Viewpoint (OV) encapsulates the organizations, tasks and information that must be communicated between them to accomplish DoD goal.

The Project Viewpoint - The Project Viewpoint (PV) explains the way by which programs are grouped in organizational terms as a articulated portfolio .

The Services Viewpoint - The Services Viewpoint (SvcV) captures system, service, and interconnection functionality providing for, or supporting, operational activities.

The Standards Viewpoint The Standards Viewpoint (StdV) is the minimal set of rules governing the arrangement, interaction, and interdependence of system parts or elements.

The Systems Viewpoint Systems Viewpoint (SV) captures the information on supporting automated systems, interconnectivity, and other systems functionality in support of operating activities.

Representation of DoDAF

DoDAF can be represented using various techniques like Tables, Entity-Relationship diagrams, Unified Modelling Language and Systems Modelling Language. DoDAF should also provide metadata to Defense Information Technology Portfolio Repository (DITPR) or other architectural repositories.

MODAF (Ministry of Defense Framework)

MODAF is an Architecture framework developed by the British Department of Defense mainly to handle Enterprise Architecture issues.

MODAF was developed primarily to carry out two main tasks.

· To provide a concrete structure that will support equipment functionality for a Network Enabled Capability model

· To effectively utilize the effect of Enterprise Architecture and to realize the goals and vision of the business in the form of processes and resultant system.

Overview

MODAF Enterprise architecture framework is recognized throughout the world today and is used by a number of organizations for improving their business model, process and controlling change management activities. Important and complex information is carefully scrutinized, arranged and presented in a way so that organizational heads can weigh the pros and cons before considering the key factors that affect their business decisions. It’s use is widely found in areas such as the NEC, which deals with combining sensors, weapon control systems and decision makers.

The staff of the MOD’s Chief Information Officer maintain MODAF and provide information .Other groups within the MOD also provide necessary support and help in developing the (SOSA)System of Systems approach which help in attaining interoperability between various systems. MOD also works in close collaboration with other international groups to achieve a similarity in the architecture frameworks and help in ease of interoperability.

MODAF was developed using the DoDAF version 1.0 but with the addition of a few viewpoints namely Strategic viewpoint, Acquisition and Service oriented viewpoints.

The first version of MODAF was released in the year 2005 and after further work by MODAF team members it has undergone continuous change and improvement. The latest version MODAF 1.2.004 came out in 2010.

Framework

There are different views for the MODAF architecture model. They provide us guidelines on how to improve the business process. Each view deals with factors and attributes that are of interest to various stakeholders. It helps us to understand the operations of a business.

Views of MODAF

The different set of rules and structures that provide us with a roadmap on how to convert the business goals and requirements to a concrete system based on different stakeholder interests can be called a view. MODAF consists of 38 views and each constitute the viewpoint of varios stakeholders. The different views available for the MOD framework are categorised into viewpoints and listed below.

· Strategic Views : explain the business goal and the strategies to be followed to achieve it..

· Operational Views : explain abstractly the elements, processes and data that is required to satisfy the functional requirements.It helps in defining the processes to be used in satisfying customer requirements.

· Service Oriented Views: define the services and external services to be used in developing the processes described by the operational view. It will provide us with all the information required to produce artifacts

Systems Views: describe the system level details that help in the implementation of the system. It will describe the detailed implementation associated with Operational and Service oriented views.

Acquisition Views : help us to understand the basis on which the project deliverables are dependent on other units and when they may be delivered.It will help us in setting milestones for various deliverables.

· Technical Views :explain the various standards that can be followed to develop standard and high quality deliverable work products to the user.

All Views : contain a comprehensive repository of all the details of the architecture

MODAF Meta Model M3

MODAF has a data model that can be called similar to the data model in DoDAF. .The MODAF data model is called M3. This data model is created using UML techniques; UML 2.0 and it ensures consistency between the different sets if views available and helps in ease of transition between tools that enable development of MODAF artifacts. M3 defines and depicts the various architectural artifacts available for creating different MODAF based views. It also helps us to understand the relationship and interaction between these objects.