Architecture Frameworks. Version 3
|
|
- Ezra Stone
- 5 years ago
- Views:
Transcription
1 NATO Architecture Framework Version 3 ANNEX A Architecture Frameworks NATO Architecture Framework v3, ANNEX A Page i
2 This page is left blank intentionally. NATO Architecture Framework v3, ANNEX A Page ii
3 Conditions of Release With reference to NATO Documents C-M(2002)49 and AC/322-D/1, this document is released to all parties concerned at the direction of the NATO Consultation, Command and Control Board (NC3B) subject to the following conditions: 1. The recipient party agrees to use its best endeavours to ensure that the information herein disclosed, whether or not it bears a security classification, is not dealt with in any manner (a) contrary to the intent of the provisions of the Charter of the NATO C3 Organisation, or (b) prejudicial to the rights of the owner thereof to obtain patent, copyright or other likely statutory protection thereof. 2. If the technical information was originally released to NATO by a NATO or Partner Government subject to restrictions clearly marked on this document, the recipient party agrees to abide by the terms of the restrictions so imposed by the releasing Government. 3. This material may be reproduced free of charge in any format or medium provided it is reproduced accurately and not used in a misleading context. Where this material is being republished or copied to others, the source of the material must be identified and the copyright status acknowledged. For further information, contact NATO at NATO Architecture Framework v3, ANNEX A Page iii
4 This page is left blank intentionally. NATO Architecture Framework v3, ANNEX A Page iv
5 Reader s Guide Background An architecture is the fundamental organisation of a system embodied in its components, their relationships to each other and to the environment and the principles guiding its design and evolution. An Architecture can be captured in a formal description of an instance, or configuration of people, processes, systems and organisations, connected by their inter-relationships. An architecture description includes views showing various aspects of the architecture. The views include architectural elements and the relations between elements as governed by a Metamodel. Architectures can be represented by models. These support operational processes by providing an explicit representation of the operational domain that can be used in analysis, for articulation of issues and requirements, as support to planning, and as a means of solution design and validation, amongst other things. Architectures can be developed for the smallest subsystem up to and culminating in an architecture that covers the whole enterprise. The role of an enterprise architecture is to provide decision support, in the context of the enterprise strategy, for the use of resources (including processes and procedures) in the enterprise. In other words, the architecture is responsible for defining how resources will be used to support enterprise strategy and benefit the NATO goals and objectives. Enterprise architecture touches every part of the organisation. Architectures are to be used as analysis tools to develop new capabilities, structure organisations and to optimize processes and spending. There is an increase in the need for international coalition operations (NATO Response Force) and a growing need to deliver end-to-end capability, whilst delivering more for less and ensuring interoperability. NATO Network Enabled Capability (NNEC) is a key part of meeting this changing need, and enables us to federate systems, sensors, effectors and hence improve military effectiveness. There is a need for a more structured approach to manage the complexity whilst balancing all appropriate user perspectives. Architectural frameworks support this goal, and the most mature and widely adopted architectural frameworks in the defence sector are the US DoD Architecture Framework (DoDAF), and the UK MOD Architecture Framework (MODAF). NATO is using its own NATO Architecture Framework (NAF) to support this goal. The previous version of NAF was tightly coupled to DoDAF. The current version has been updated in several areas, and has incorporated not only US and UK experiences, but also views and experiences from other nations, from industry and from academia. NATO Architecture Framework v3, ANNEX A Page v
6 New features include: initial support for NNEC architectures support to the NATO capability development process; support to programme management; integration of Service-Oriented Architecture (SOA) concepts; support to spectrum and bandwidth planning; provision and integration of the NATO Architecture Framework Metamodel (NMM) and the NATO Architecture Repository (NAR); a running example. The NAF is not an architecture itself, but it provides the rules, guidance, and product descriptions for developing, presenting and communicating architectures. The NAF is also the common denominator for understanding, comparing, and integrating architectures. The application of the framework will enable architectures to contribute most effectively to the acquisition and fielding of cost-effective and interoperable military capabilities. The framework ensures that the architectures developed by NATO and the Nations can be compared and related across NATO and National boundaries. NATO common funded programmes are to comply with the NAF to promote systems interoperability. NAF Document Suite Structure The NATO Architecture Framework is composed of ten volumes, covering NAFchapters 1 through 7, and NAF-annexes A through C (see Figure A-1). Each NAFchapter and each NAF-annex is contained within a separate volume, and each volume is published as one electronic file. Each electronic file is intended to be readable as a stand-alone document. For that purpose, each volume contains common introductory sections that provide enough context to understand the contents of the NAF as a whole, as well as that particular volume. This approach enables us to disseminate concise portions of information to the intended audience. The NAF will also be published in HTML format. Executive Summary In addition to the ten volumes, an executive summary exists. This is a concise summary of NAF version 3. The document is intended to give the reader a quick but nonetheless comprehensive understanding of NAF, its use and benefits. The summary is sufficient to understand why the NAF is relevant and where and how the NAF can be used. The details can then be found in the NAF-volumes themselves. NATO Architecture Framework v3, ANNEX A Page vi
7 Figure A-1, NAF v3 Document Suite Structure CHAPTER 1 Introduction to NATO Architecture Framework NAF-chapter 1 is the introduction to the NAF. This chapter essentially presents the business case for NATO architectures. Chapter 1 defines what an architecture is, what the benefits are, and why architectures are relevant to NATO in the light of current and future developments, such as NNEC, NRF and Comprehensive Approach. This chapter contains the following paragraphs: 1.1 Introduction to Chapter What is an Enterprise Architecture? 1.3 Purpose and Scope of the NAF 1.4 Imperative Documents 1.5 Why use NAF? 1.6 The NATO Architecture Framework (NAF) 1.7 New Features and Important Changes in NAF 1.8 Architecture Tools 1.9 Types of NATO Architectures 1.10 NATO Architecture Views 1.11 Management of NAF and architectures 1.12 Guidelines for Architects NATO Architecture Framework v3, ANNEX A Page vii
8 CHAPTER 2 Architecture Stakeholders NAF-chapter 2 addresses the stakeholders and communities of interest that may benefit from the use of the NAF. It is one of the principles of this version of the NAF to align the architecture framework with the objectives and interests of those who use it, providing for as much added value as possible, without being sidetracked by issues that do not directly contribute to the stakeholder s cause. This chapter contains the following paragraphs: 2.1 Introduction to Chapter Identification and Description of Stakeholders and Communities of Interest (CoIs) 2.3 Requirements Analysis of Communities of Interest (CoIs) CHAPTER 3 NNEC Architecture Concepts and Elements NAF-chapter 3 provides a description of the NNEC architecture concepts and elements that are essential for developing a complete and coherent architecture, capable of specifying seamlessly interoperable network enabled systems. This chapter contains the following paragraphs: 3.1 Introduction to Chapter NNEC Architecture Concepts 3.3 NNEC Architecture Elements and Descriptions CHAPTER 4 Architecture Views and Subviews Chapter 4 defines a toolbox of architecture views and subviews, where each subview comprises of specific diagrams and specifications, intended to support a specific purpose, and intended to be communicated to specific stakeholders and specific Communities of Interest. This chapter contains the following paragraphs: 4.1 Introduction to Chapter NATO Architecture Views 4.3 NAV, NATO All View 4.4 NCV, NATO Capability View 4.5 NOV, NATO Operational View 4.6 NSOV, NATO Service-Oriented View 4.7 NSV, NATO Systems View 4.8 NTV, NATO Technical View 4.9 NPV, NATO Programme View 4.A Mapping Subviews to Communities of Interest 4.B Running Example 4.C Mapping Subviews to NNEC Elements NATO Architecture Framework v3, ANNEX A Page viii
9 CHAPTER 5 NATO Architecture Framework Metamodel (NMM) and Architecture Data Exchange Specification (ADES) NAF-chapter 5 contains the NAF Metamodel (NMM). In essence, an architecture is delivered as a set of design models, specifications and guidelines, which are indispensable for subsequent system development within NATO s highly complex, dispersed and heterogeneous automated information system. In practice, the result of an architecture effort is an architecture core data repository. The NAF Metamodel is the engine of this repository. The NAF Metamodel is also intended to facilitate exchange of architecture design information. This chapter contains the following paragraphs: 5.1 Introduction to Chapter NATO Architecture Framework Metamodel (NMM) 5.3 NATO Architecture Data Exchange Specification (ADES) CHAPTER 6 Management of Architectures in NATO NAF-chapter 6 provides guidelines on how to manage NATO-architectures. Merely developing an architecture does not provide or ensure the full benefits. Architectures must also be maintained, communicated, and enforced. These aspects of the architecture life-cycle are the subject of NAF-chapter 6. This chapter contains the following paragraphs: 6.1 Introduction to Chapter The Management and Use of NAF v3 6.A General Guidelines for the Management of NAF v3 Architectures in Nations 6.B NAF v3 Request For Change Proposal (RFCP) Procedure 6.C Standardization of the NATO Architecture Framework Metamodel (NMM) and the Architecture Information Exchange Mechanism (ADEM) CHAPTER 7 Architecture Definitions, Terminology and Ontology NAF-chapter 7 contains a comprehensive glossary of terms. All essential terms used in the NAF are defined in a precise and unambiguous way to optimize consistency, and increase readability of each NAF-volume, and the entire framework, across the different volumes. This chapter contains the following paragraphs: 7.1 Introduction to Chapter Definitions 7.3 Acronyms and Abbreviations 7.4 Taxonomy (not yet included in NAF version 3) 7.5 Ontology (not yet included in NAF version 3) NATO Architecture Framework v3, ANNEX A Page ix
10 ANNEX A Architecture Frameworks NAF-annex A presents an overview of some architecture frameworks. This chapter presents brief introductions to other architecture frameworks for ease of reference and for comparison. This chapter contains the following paragraphs: A.1 Introduction to Annex A A.2 The Open Group Architecture Framework (TOGAF) A.3 Gartner s Enterprise Architecture Framework A.4 Zachman Framework A.5 Department of Defense Architecture Framework (DoDAF) A.6 Ministry of Defence Architecture Framework (MODAF) A.7 AGATE v3 A.8 Defence Architecture Framework (DAF) A.9 Model-based Architecture for Command and Control Information Systems (MACCIS) ANNEX B Architecture Methodologies NAF-annex B contains an overview of some architecture methodologies. This chapter presents brief introductions to other architecture methodologies for ease of reference and for comparison. NC3A s Architecture Engineering Methodology (AEM) is included in full. This particular methodology serves as information for those Partnerand NATO-Nations that want to know more about NATO architecture projects where NC3A is host Nation or provider, and where the AEM is used. This chapter contains the following paragraphs: B.1 Introduction to Annex B B.2 TOGAF ADM B.3 Boeing/Openwings B.4 META Group and Gartner process model B.5 DoDAF s 6 step model B.6 NC3A/AEM ANNEX C Transition Guidance NAF v2 to NAF v3 NAF-annex C provides for guidance on how to migrate existing architectures, based upon NAF version 2, to architectures that are compliant with NAF version 3. This chapter contains the following paragraphs: C.1 Introduction to Annex C C.2 Considering Transition Feasibility C.3 Implementation of Transition C.4 View, Subview and Metamodel Transition NATO Architecture Framework v3, ANNEX A Page x
11 Intended Audience This document is intended for all people who want to have a brief oversight of architecture frameworks. Structure of sections in this chapter Section A.1 contains an introduction to this annex followed by separate sections describing some well known frameworks as follows: Section A.2 Section A.3 Section A.4 Section A.5 Section A.6 Section A.7 Section A.8 The Open Group Architecture Framework (TOGAF) Gartner s Enterprise Architecture Framework The Zachman Framework The Department of Defense Architecture Framework (DoDAF) The Ministry of Defence Architecture Framework (MODAF) AGATE v3 The Defence Architecture Framework (DAF) Section A.9 Model-based Architecture for Command and Control Information Systems (MACCIS) NATO Architecture Framework v3, ANNEX A Page xi
12 This page is left blank intentionally. NATO Architecture Framework v3, ANNEX A Page xii
13 Table of Contents ANNEX A Architecture Frameworks... i Conditions of Release... iii Reader s Guide... v Background... v NAF Document Suite Structure... vi Intended Audience... xi Structure of sections in this chapter... xi Table of Contents...xiii A.1 Introduction to ANNEX A... 1 A.1.1 Objectives... 1 A.1.2 Scope... 1 A.1.3 Approach... 1 A.2 The Open Group Architecture Framework (TOGAF)... 3 A.3 Gartner s Enterprise Architecture Framework... 5 A.4 Zachman Framework... 9 A.5 Department of Defense Architecture Framework (DoDAF) A.6 Ministry of Defence Architecture Framework (MODAF) A.7 AGATE v A.8 Defence Architecture Framework (DAF) A.8.1 The Defence Architecture Framework explained A Framework Elements A The Influences on the Architecture A.9 Model-based Architecture for Command and Control Information Systems (MACCIS) NATO Architecture Framework v3, ANNEX A Page xiii
14 This page is left blank intentionally. NATO Architecture Framework v3, ANNEX A Page xiv
15 A.1 Introduction to ANNEX A What is an Architecture Framework? An Architecture Framework (AF) defines the standard set of key business and technical information that provides for the development of architectures. An architecture developed in line with that set of information is then compliant to that architecture framework. It is also then interoperable with other architectures developed in line with the same architecture framework, ensuring that the overall Enterprise Architecture (EA) is coherent. An architecture framework specifies an organising structure for architecture information and provides a common tool for describing enterprises through complex models. To manage this complexity, an AF defines a standard set of model categories which each have a specific purpose and are often categorized in aspects or view groups. An AF defines a standard set of business and technical information about an enterprise. The purpose of the AF may be to identify elements of this information that will be mandatory to produce within the enterprise or to act as a guide to which types of information may be of most value in analyzing aspects of the enterprise. An AF usually describes a standard set of representations on the enterprise. A.1.1 Objectives The objective is to give oversight over the most known and used architecture frameworks, which have been used by organisations, industry and governments to describe their enterprises. A.1.2 Scope The most known and used architecture frameworks will be described in a condensed form in order to give an insight and background into architecting concepts and usage. A.1.3 Approach The information in this annex is captured from original documents or web-based information and reflects the respective copyright owners view of characteristics or capabilities of their frameworks. NATO Architecture Framework v3, ANNEX A Page 1
16 This page is left blank intentionally. NATO Architecture Framework v3, ANNEX A Page 2
17 A.2 The Open Group Architecture Framework (TOGAF) TOGAF recognizes four kinds of architecture that are commonly accepted as subsets of an overall Enterprise Architecture (EA): Business Architecture; Data Architecture; Application Architecture; and Technology Architecture. The combination of Data Architecture and Application Architecture is also referred to as the Information System Architecture. TOGAF was originally designed to support the last of these - the Technology Architecture. Over its years of evolution, however, it has acquired many of the facets of a framework and method for Enterprise Architecture. As of TOGAF Version 8, these different facets have been integrated, and TOGAF has undergone a major redevelopment, with the result that it is now a fully-fledged enterprise architecture framework. Two of the key elements of any enterprise architecture framework are: a definition of the deliverables that the architecting activity should produce; and a description of the method by which this should be done. With some exceptions, the majority of enterprise architecture frameworks focus on the first of these - the specific set of deliverables - and are relatively silent about the methods to be used to generate them (intentionally so, in some cases.) Because TOGAF is a generic framework, as mentioned above, and intended to be used in a wide variety of environments, it does not prescribe a specific set of deliverables; rather it talks in general terms about the types of deliverable that need to be produced, and focuses instead on the methods by which these should be developed. As a result, TOGAF may be used either in its own right, with the generic deliverables that it describes; or else these deliverables may be replaced by a more specific set, defined in any other framework that the user architect considers relevant. In the latter case, the user architect will adapt and build on the TOGAF Architecture Development Method (ADM) in order to define a tailored method and process for developing these more specific deliverables. Refer to Annex B for more information on TOGAF ADM. As a generic framework and method for Enterprise Architecture, TOGAF also complements other frameworks that are aimed at specific vertical business domains, NATO Architecture Framework v3, ANNEX A Page 3
18 specific horizontal technology areas such as Security or Manageability, or specific application areas such as e-commerce. The concept of leveraging other relevant architectural assets in this way is known within TOGAF as the Enterprise Architecture Continuum. The Role of TOGAF TOGAF in its Enterprise edition remains what it has always been, namely an architectural framework - a set of methods and tools for developing a broad range of different IT architectures. The key to TOGAF remains a reliable, practical method - the TOGAF ADM)- for defining business needs and developing an architecture that meets those needs, utilizing the elements of TOGAF and other architectural assets available to the organisation. The TOGAF ADM therefore does not prescribe any specific set of enterprise architecture deliverables - although it does describe a set, by way of example. Rather, TOGAF is designed to be used with whatever set of deliverables the TOGAF user feels is most appropriate. That may be the set of deliverables described in TOGAF itself; or it may be the set associated with another framework, such as Zachman Framework, FEAF, etc. TOGAF describes an example taxonomy of the kinds of views that an architect might consider developing, and why; and it provides guidelines for making the choice, and for developing particular views, if chosen. With the migration of TOGAF to an enterprise architecture framework, this flexibility becomes even more important. TOGAF is not intended to compete with these other frameworks: rather, it is intended to perform a unique role, in distilling what these other frameworks have to offer, and providing a generic Architecture Development Method that can be adapted for use with any of these other frameworks. NATO Architecture Framework v3, ANNEX A Page 4
19 A.3 Gartner s Enterprise Architecture Framework Enterprise architecture is an iterative process that produces four major deliverables: a future-state architecture that supports the requirements of the business strategy and external environmental factors; documentation of the current-state architecture (to the minimal level of detail required); a gap analysis that identifies the shortfalls of the current state in terms of its ability to support the strategies of the enterprise; a road map defining the steps that should be taken to transform the current state into the future state. Control of the execution of the road map, decisions with respect to the allocation of funds and resources, are not made within the architecture itself, but are the function of other management disciplines that are related to, but not part of, the architecture. The development of the business context begins during the initial organise the architecture effort step, since business strategy analysis is a key component of the Enterprise Architecture (EA) value proposition, which should be articulated as early as possible. Further analysis and the expression of the business strategy in terms of foundational enterprise architecture principles are done as the business context is developed. The future-state vision is usually expressed in three types of artefacts: the requirements, which define what the architecture is trying to achieve; the principles, which guide decision making; and finally the models, which illustrate what the future vision of the architecture looks like. The business context is a critical component of the architecture that is required before the future-state architecture vision can be developed. It provides the necessary insight into the business strategy that architecture requires in order to be relevant to and supportive of the needs of the business. In addition, the business context provides the foundation for subsequent architectural work, so it is helpful if the business context can be expressed in the same type of artefacts - requirements, principles and models. Another way to look at this is by levels of abstraction. Enterprise architecture (EA) is a process of progressive decomposition. You start with a very generalized vision and develop increasing levels of detail as you get further into the process. Typically, EA efforts encompass at least three levels of abstraction: a conceptual level, where the general concepts of the architecture are laid out; a logical level, where more specific architectural components are identified; an implementation level, where the specific tools, products and implementation standards are determined. NATO Architecture Framework v3, ANNEX A Page 5
20 The business context can be thought of as a contextual level of abstraction, where the highest-level requirements and business drivers are articulated to provide a foundation for a business-aligned architecture. As we indicated previously, the enterprise architecture is overlaid by the business context, which is derived from the business strategy and the external factors that affect the enterprise. Within the EA, Gartner has adopted an aspect-oriented approach, similar to the approach espoused in the IEEE's Recommended Practice for Architectural Description of Software-Intensive Systems (IEEE ), which proposes that the architecture is a collection of viewpoints - architectural descriptions that satisfy the perspectives of each individual stakeholder. In Gartner's approach, an EA has a minimum of three viewpoints: a business viewpoint, which is concerned with functional, process and organisational views of the enterprise; an information viewpoint, which is concerned with the information required to run the enterprise, the logic that manipulates the information and the mechanisms that allow for integration of that information across diverse processes; a technology viewpoint, which is concerned with the infrastructural components, both hardware and software, that support the enterprise. These viewpoints are derived from the business context and should demonstrate clear traceability of architectural decisions to the elements of the business strategy. The crux of the framework is the solution architecture, which represents the intersection of the business, information and technology viewpoints. It is here that we find the architectural guidance required to build solutions, where the relationships between components in different viewpoints are needed (for example, application partition model, which shows how the business functions of the enterprise are supported by the application portfolio). This is another view of Gartner's EA framework, showing the different levels of abstraction. The business context is a foundation for the work in each of the architectural viewpoints; business, information and technology - as well as at the intersection of those three viewpoints, where the solution architecture is developed. Following the development of the business context, conceptual, logical and implementation levels of detail can be developed in any or all of the viewpoints as required. NATO Architecture Framework v3, ANNEX A Page 6
21 Figure A-2, Gartner's Enterprise Architecture Framework In a business-driven architecture, the business context provides the foundational assumptions for the entire future-state architecture. The strategic requirements of the enterprise are analyzed, and a set of architecture principles is articulated. These principles are derived from the elements of the business strategy and analysis of environmental trends so that there is a direct linkage between the architectural decisions and the business imperatives they support. These architecture principles will be further decomposed into the conceptual, logical and implementation-level principles that guide architectural and design decisions as the architecture moves farther away from strategy and closer to implementation. An additional element of the business context is an analysis of the business functions that the enterprise requires in order to fulfil the business strategy. This analysis includes an articulation of the high-level requirements of each business function. As these requirements are articulated, it is possible to identify the information and technology services that support the business functions and the business processes that discharge the business strategy. NATO Architecture Framework v3, ANNEX A Page 7
22 This page is left blank intentionally. NATO Architecture Framework v3, ANNEX A Page 8
23 A.4 Zachman Framework The Zachman framework is a logical structure intended to provide a comprehensive representation of an information technology enterprise. It allows for multiple perspectives and categorization of business artefacts. The brainchild of John Zachman who conceived the idea in 1987, the full technical name is Zachman Framework for Enterprise Architecture and Information Systems Architecture. The Zachman framework gathers and refines principles from older methods. It has a structure (or framework) independent of the tools and methods used in any particular IT business. The framework defines how perspectives are related according to certain rules or abstractions. A framework takes the form of a 36-cell table with six rows (scope, business model, system model, technology model, components, and working system) and six columns (who, what, when, where, why, and how). The Zachman framework is seen by some business managers as an ideal set of rules for the management of complex and evolving IT enterprises. Figure A-3, Zachman framework NATO Architecture Framework v3, ANNEX A Page 9
24 This page is left blank intentionally. NATO Architecture Framework v3, ANNEX A Page 10
25 A.5 Department of Defense Architecture Framework (DoDAF) Architectures within the Department of Defense (DoD) are created for a number of reasons. From a compliance perspective, the DoD s development of architectures is compelled by law and policy (i.e., Clinger-Cohen Act, Office of Management and Budget (OMB) Circular A-130). The DoD Architecture Framework (DoDAF) was established as a guide for the development of architectures. DoDAF explained The DoDAF provides the guidance and rules for developing, representing, and understanding architectures based on a common denominator across DoD, Joint, and multi-national boundaries. It provides insight for external stakeholders into how the DoD develops architectures. The DoDAF is intended to ensure that architecture descriptions can be compared and related across programmes, mission areas, and, ultimately, the enterprise, thus, establishing the foundation for analyses that supports decision-making processes throughout the DoD. DoDAF v1.5 is a transitional version that responds to the DoD s migration towards Netcentric Warfare (NCW). It applies essential net-centric concepts1 in transforming the DoDAF and acknowledges that the advances in enabling technologies such as services within a Service-Oriented Architecture (SOA) are fundamental to realizing the Department s Net-Centric Vision. Version 1.5 addresses the immediate netcentric architecture development needs of the Department while maintaining backward compatibility with DoDAF v1.0. In addition to net-centric guidance, DoDAF v1.5 places more emphasis on architecture data rather than the products, introduces the concept of federated architectures, and incorporates the Core Architecture Data Model (CADM) as an integral component of the DoDAF. Figure A-4, Evolution of the DoDAF NATO Architecture Framework v3, ANNEX A Page 11
26 The DoDAF is a three-volume set that inclusively covers the concept of the architecture framework, development of architecture descriptions, and management of architecture data. Volume I introduces the DoDAF framework and address the development, use, governance, and maintenance of architecture data. Volume II outlines the essential aspects of architecture development and applies the net-centric concepts to the DoDAF products. Volume III introduces the architecture data management strategy and describes the pre-release CADM v1.5, which includes the data elements and business rules for the relationships that enable consistent data representation across architectures. NATO Architecture Framework v3, ANNEX A Page 12
27 A.6 Ministry of Defence Architecture Framework (MODAF) The UK Ministry of Defense Architectural Framework (MODAF) defines a standardized way of conducting Enterprise Architecture and provides a means to model, understand, analyze and specify Capabilities, Systems, Systems of Systems, and Business Processes. The purpose of MODAF is to provide a rigorous system of systems definition when procuring and integrating defense systems. As of 10th April 2007, MODAF version 1.1 was released. MODAF explained MODAF is methodology independent, but has been developed to provide an Enterprise Architecture approach in support of a wide number of communities across MOD and assist them in conducting their day-to-day business. Although there is strong support for operational processes and acquisition of capability to support these, MODAF is equally applicable to the business space, operational analysis, planning and all other aspects of the MOD enterprise and other organisations that interface with it, such as coalition partners and its supply chain. MODAF architectures are an essential source for processes to deliver benefits from: Structured analysis and articulation of business issues Enhanced requirements specifications Improved efficiency, effectiveness and standardization of MOD-wide processes and ways of working Improved validation and assurance of solutions A coherent portfolio of military capability and better integrated systems Avoidance of unnecessary costs in the overall investment programme In addition, MODAF has Through Life relevance, addressing; Capability deployment and delivery through operational and system views Business transformation and capability planning through strategic views Programme synchronization through acquisition views Defense Lines of Development (DLODs), which are inherent across all of the views. NATO Architecture Framework v3, ANNEX A Page 13
28 This page is left blank intentionally. NATO Architecture Framework v3, ANNEX A Page 14
29 A.7 AGATE v3 AGATE (Atelier de Gestion de l'architecture des systèmes d'information et de communication) is a framework for modelling computer or communication systems architecture. It is promoted by the Délégation Générale pour l'armement (DGA), the French government agency which conducts development and evaluation programmes for weapon systems for the French military. All major DGA weapons and information technology system procurements are required to document their proposed system architecture using the set of views prescribed in AGATE. AGATE is similar to DoDAF, promoted by U.S. Department of Defense (DoD) or MODAF, promoted by UK Ministry of Defence (MOD). Figure A-5, Agate v3 logo AGATE v3 explained AGATE, CIS Architecture Management Framework, is a methodology intended to improve: the accessibility of systems and their architectures; the management of architecture data; the sharing of knowledge; the control and the coherence; the efficiency of the parties contributing to the definition, the realisation and the implementation of CIS. AGATE provides the means to describe Communication and Information Systems in a synthetic and homogeneous way thanks to a formalism and a set of federating rules. NATO Architecture Framework v3, ANNEX A Page 15
30 AGATE provides an environment for valorisation of information and sharing between the different parties of the Ministry of Defence. AGATE covers the following architecture aspects: system goals and objectives; description of organizations; operational procedures, information exchange; security requirements and management, conform with the Ministry s methods; system services and the link to the operational requirements; logical organization of the system; typical assembly of technical components, fielded products; system life-cycle and its architecture element life-cycle follow-up. AGATE can be used to describe systems of any size as well as systems of systems. Process modelling has to be in conformance with MADIOS (Méthode d ADministration de l Interopérabilité Opérationnelle des Systèmes d Information et de Communication) and made with the tools recommended by the CIADIOS (Centre Interarmées d ADministration de l Interopérabilité Opérationnelle des SIC). The AGATE V3 reference manual is composed of HTML 1 pages gathered inside S- CAT n guide. It consists of the following parts: architecture views and their selection; the modelling objects and options; the objects modelling baselines; the glossary; interoperability with other methodologies and tools; the AGATE charter for use; standard contractual clauses; changes from the previous version the AGATE metamodel; downloadable documents (additional application user guide for VISIO, MADIOS V2, etc.). 1 see 40 MB files only available in French NATO Architecture Framework v3, ANNEX A Page 16
31 Figure A-6, Principles of AGATE Views NATO Architecture Framework v3, ANNEX A Page 17
32 This page is left blank intentionally. NATO Architecture Framework v3, ANNEX A Page 18
33 A.8 Defence Architecture Framework (DAF) In the context of the Australian Defence Information Environment (DIE), architecture is a disciplined approach to the planning and implementation of information capability for the Australian Defence Organisation. As in the building industry context of architecture, the DIE architecture is a high levelplanning tool providing a top-down visualisation of the DIE structure and activity. The architectural approach produces a design that enables the optimisation of the DIE as a system of systems. The purpose of architecture is to inform investment decision-makers how individual capabilities relate and interact with each other and provide an integrated development path. Architecture allows capabilities to interact across the enterprise. That is the DIE interacts with all of the other capabilities in the Enterprise to produce the effects based outcomes sought by government. The Defence architecture methodology that has been adopted by the ADO for the development of the DIE architecture is the Defence Architecture Framework (DAF). The DAF has been developed from the United States Department of Defence Architecture Framework (DoDAF) and the METAGroup Enterprise Architecture Strategies. A.8.1 The Defence Architecture Framework explained The DAF is an integrated framework that has been developed as a means to improve the design and coherency of the DIE. Drawing on the US DoD Architecture Framework and the META Group Enterprise structure, the DAF has been developed as shown below in Figure A-7. A key concept to understanding the DAF is that there are five ways of viewing a capability. There are four Common to All views (CV) providing an overview, controlled language and architecture governance mechanisms for the capability. There are nine operational views (OV) which together describe the components of the capability, the relationship between those components and the information needs. There are 13 systems views (SV) which relate the capabilities and characteristics to the system requirements, There are two technical standards views (TV) which document the current and emerging technologies required to build the capability and There are seven Data Views (DV). The relationship between these sets of views is depicted in the following diagram. NATO Architecture Framework v3, ANNEX A Page 19
34 Operational and Business Context Security Standards Common View Data View Fundamental Inputs to Capability Defence Architecture Framework (v9.0) 1 2 Governance, Compliance and Co-ordination 3 5 Enterprise Architecture Business 6 Specific Architecture Descriptions Defines Operational View Information Represented by Systems View Influences Technical View Systems Determines Infrastructure Supported by 7 Defence Enterprise Architecture Library Defence Architecture Information Model Enterprise Architecture Repository Library Populated by Tools 4 Research and Technology Influences Figure A-7, Major components of the Australian Defence Architecture Framework The Outside boxes, marked as are the external influences upon the Architecture. These encompass the Directions from Government, the internal directions within the department and the external governance regimes in place that direct, guide and constrain the department, the fundamental inputs to the development and maintenance of capability within the Department, and the research and technology base that supports all aspects of the work the department does. The Enterprise Architecture component is also an essential component providing the organisation with the methods, processes, discipline, and organisational structure to create, manage, organise, and use models for managing the impact of change. The Specific Operational & Business Architecture Descriptions component of the DAF provides a mechanism for standardising the documents that define the architecture of an enterprise. By using the architecture descriptions lodged in the enterprise repository and the tools contained within the Defence Enterprise Architecture Library, the Enterprise Architecture framework can be accurately defined. NATO Architecture Framework v3, ANNEX A Page 20
35 A Framework Elements The Australian Defence Architecture Framework (DAF) is made up of four major elements. These are: The Influences on the Architecture The Enterprise Architecture The specific instances of the Architecture, and The Repository A The Influences on the Architecture The Influences on the architecture are the four boxes on the outside of the Framework. The information contained in these boxes is the influences and environmental considerations, which shape and inform the actual Enterprise Architecture. Information held in this area is not doing information, that is operational or information required to drive and action or event, and should not included specific information, which is pivotal or essential to the operation of any part of the Enterprise Architecture. However, the information is granular and when moving between the various layers of an architecture, issues and influences will move or disappear. NATO Architecture Framework v3, ANNEX A Page 21
36 This page is left blank intentionally. NATO Architecture Framework v3, ANNEX A Page 22
37 Modelling Language Component Technology UML 1.4 Asset description Standards Software Component Reference Archutecture A.9 Model-based Architecture for Command and Control Information Systems (MACCIS) MACCIS is an architecture framework based on elements from C4ISR-AF (now DoDAF) and Reference Model for Open Distributed Computing (RM-ODP). The framework was developed by Sintef for the Norwegian and Swedish material commands. It has greatly influenced the architecture work in the Norwegian Defence, and has also been used as a basis for the architectural work in Multilateral Interoperability Programme (MIP), which is an international programme where the agenda is to achieve interoperability between different Nations land tactical C2IS. MACCIS is an architectural description framework targeted towards software systems. In addition to identifying architectural artefacts, MACCIS also contains guidelines for how to produce the architectural artefacts. MACCIS defines a generic framework for system architecture that can be applied in any domain. Figure A-8 shows both the generic and a specific C2IS version of the framework. MACCIS Generic Framework System Scope Model Assets System Architecture Model Baseline Development Process MACCIS Specific Framework C2IS Dictionary Patterns Context Model Requirements Model Component Core Models Model Distribution Model Realisation Model Asset usage MACCIS Development Process Figure A-8, MACCIS Framework The generic framework focuses on system architecture models. The system architecture models are specified in a modelling language following a baseline development process. The system has a domain as specified in its scope and a set of target deployment technologies. In order to support system architecture modelling, a number of model assets are available, adapted to the language, process, scope and technologies. The specific architecture shows the refined framework for the C2IS scope. MACCIS defines system architecture in terms of five architecture model views: NATO Architecture Framework v3, ANNEX A Page 23
38 Context Model: The purpose of the context model is to describe the operation of the target system within a given context. This model also defines the dependencies of the specified elements of the target system to the specified elements of the context system. Requirements Model: The purpose of this model is to capture the requirements of the target system. Component Model: The purpose of this model is to describe the services, information, components and interactions of the target system. Distribution Model: The purpose of this model is to describe the distribution concerns of the target system. Realisation Model: The purpose of the realisation model is to describe the realisation of the target system in terms of technology and realised subsystems. NATO Architecture Framework v3, ANNEX A Page 24
Vendor: The Open Group. Exam Code: OG Exam Name: TOGAF 9 Part 1. Version: Demo
Vendor: The Open Group Exam Code: OG0-091 Exam Name: TOGAF 9 Part 1 Version: Demo QUESTION 1 According to TOGAF, Which of the following are the architecture domains that are commonly accepted subsets of
More informationModule 3. Overview of TOGAF 9.1 Architecture Development Method (ADM)
Module 3 Overview of TOGAF 9.1 Architecture Development Method (ADM) TOGAF 9.1 Structure The Architecture Development Method (ADM) Needs of the business shape non-architectural aspects of business operation
More informationOG0-091 Q&As TOGAF 9 Part 1
CertBus.com OG0-091 Q&As TOGAF 9 Part 1 Pass The Open Group OG0-091 Exam with 100% Guarantee Free Download Real Questions & Answers PDF and VCE file from: 100% Passing Guarantee 100% Money Back Assurance
More informationAn Overview of TOGAF Version 9.1
An Overview of TOGAF Version 9.1 Robert Weisman MSc, PEng, PMP, CD CEO / Chief Enterprise Architect robert.weisman@buildthevision.ca 44 Montgomery Street 1168 Ste Therese Ottawa, Ontario Canada K1C2A6
More informationKillTest *KIJGT 3WCNKV[ $GVVGT 5GTXKEG Q&A NZZV ]]] QORRZKYZ IUS =K ULLKX LXKK [VJGZK YKX\OIK LUX UTK _KGX
KillTest Q&A Exam : OG0-091 Title : TOGAF 9 Part 1 Version : Demo 1 / 5 1.According to TOGAF, Which of the following are the architecture domains that are commonly accepted subsets of an overall enterprise
More informationA Comparative Analysis of Architecture Frameworks
A Comparative Analysis of Architecture Frameworks Antony Tang Jun Han Pin Chen School of Information Technology DSTO C3 Research Centre Swinburne University of Technology Department of Defence Melbourne,
More informationVocabulary-Driven Enterprise Architecture Development Guidelines for DoDAF AV-2: Design and Development of the Integrated Dictionary
Vocabulary-Driven Enterprise Architecture Development Guidelines for DoDAF AV-2: Design and Development of the Integrated Dictionary December 17, 2009 Version History Version Publication Date Author Description
More informationPASS4TEST. IT Certification Guaranteed, The Easy Way! We offer free update service for one year
PASS4TEST IT Certification Guaranteed, The Easy Way! \ http://www.pass4test.com We offer free update service for one year Exam : OG0-091 Title : TOGAF 9 Part 1 Vendors : The Open Group Version : DEMO Get
More informationRich Hilliard 20 February 2011
Metamodels in 42010 Executive summary: The purpose of this note is to investigate the use of metamodels in IEEE 1471 ISO/IEC 42010. In the present draft, metamodels serve two roles: (1) to describe the
More information10 Steps to Building an Architecture for Space Surveillance Projects. Eric A. Barnhart, M.S.
10 Steps to Building an Architecture for Space Surveillance Projects Eric A. Barnhart, M.S. Eric.Barnhart@harris.com Howard D. Gans, Ph.D. Howard.Gans@harris.com Harris Corporation, Space and Intelligence
More informationModule 1 Management Overview
Module 1 Management Overview V9.1 Edition Copyright 2009-2011 Slide 1 of 67 All rights reserved Published by The Open Group, 2011 Management Overview Slide 2 of 67 TOGAF is a registered trademark of The
More informationOG The Open Group OG TOGAF 9 Combined Part 1 and Part 2
The Open Group OG0-093 TOGAF 9 Combined Part 1 and Part 2 1 Set1, Part 1 QUESTION: 1 Which of the following TOGAF components was created to enable architects to design architectures addressing Boundaryless
More informationDoD Architecture Framework Version 2.0
wreath stars Text DoD Architecture Framework Version 2.0 Volume 2: Architectural Data and Models Architect s Guide 28 May 2009 This page left intentionally blank TABLE OF CONTENTS SECTION PAGE 1. INTRODUCTION...
More informationCliayter s. Vsing the ~usiness-it 5Ztfignment :Mode{
Cliayter s. Vsing the ~usiness-it 5Ztfignment :Mode{ 5.1 INTRODUCTION The purpose of the previous chapter was to recognize the knowledge embedded in current alignment approaches by inductively creating
More informationMINISTRY OF DEFENCE. MOD Architectural Framework Technical Handbook
MODAF-M07-022 MINISTRY OF DEFENCE MOD Architectural Framework Technical Handbook Version 1.0 31 August 2005 Prepared by:- Approved by:- MODAF Project Review Board CROWN COPYRIGHT 2005. THIS DOCUMENT IS
More informationThe Great TOGAF Scavenger Hunt. Enterprise Architecture Using TOGAF 9 Course Preparation Guide
Enterprise Architecture Using TOGAF 9 Course Preparation Guide 2011 Metaplexity Associates LLC All Rights Reserved Version 2.0 January 2, 2011 The Open Group Certification Mark logo and TOGAF are trademarks,
More informationUPDM PLUGIN. version user guide
UPDM PLUGIN version 17.0 user guide No Magic, Inc. 2011 All material contained herein is considered proprietary information owned by No Magic, Inc. and is not to be shared, copied, or reproduced by any
More informationCopyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see
TOGAF 9 Certified Study Guide 4th Edition The Open Group Publications available from Van Haren Publishing The TOGAF Series: The TOGAF Standard, Version 9.2 The TOGAF Standard Version 9.2 A Pocket Guide
More informationFundamentals to Creating Architectures using ISO/IEC/IEEE Standards
Fundamentals to Creating Architectures using ISO/IEC/IEEE Standards What to Architect? How to Architect? IEEE Goals and Objectives Chartered by IEEE Software Engineering Standards Committee to: Define
More informationIntegrating TOGAF, Zachman and DoDAF Into A Common Process
Integrating TOGAF, Zachman and DoDAF Into A Common Process Rolf Siegers Senior Principal Software Systems Engineer The Open Group Architecture Practitioner s Conference October 2003 Customer Success Is
More informationThe-Open-Group 0G TOGAF 8 Certification for Practitioners. Download Full Version :
The-Open-Group 0G0-081 TOGAF 8 Certification for Practitioners Download Full Version : http://killexams.com/pass4sure/exam-detail/0g0-081 What guides and supports the evolution of the Solutions Continuum?
More informationNATO Architecture Framework. Version 3. CHAPTER 5 NATO Architecture Framework Metamodel (NMM) and Architecture Data Exchange Specification (ADES)
AC/322(SC/-WG/)N(2007)0004 NATO Architecture Framework Version 3 CHAPTER 5 NATO Architecture Framework Metamodel (NMM) and Architecture Data Exchange Specification (ADES) NATO Architecture Framework v3,
More informationcameo Enterprise Architecture UPDM / DoDAF / MODAF / SysML / BPMN / SoaML USER GUIDE version 17.0
cameo Enterprise Architecture UPDM / DoDAF / MODAF / SysML / BPMN / SoaML USER GUIDE version 17.0 No Magic, Inc. 2010 All material contained herein is considered proprietary information owned by No Magic,
More informationModule B1 An Introduction to TOGAF 9.1 for those familiar with TOGAF 8
Informs the capability Ensures Realization of Business Vision Business needs feed into method Refines Understanding Informs the Business of the current state Sets targets, KPIs, budgets for architecture
More informationModule 3 Introduction to the Architecture Development Method
TOGAF Standard Courseware V9.2 Edi:on 01/06/18 Module 3 Introduction to the Architecture Development Method V9.2 Edi:on Copyright 2009-2018 All rights reserved Published by The Open Group, 2018 1 Introduc:on
More informationA Comparative Analysis of Architecture Frameworks
School of Information Technology Centre for Component Software and Enterprise Systems A Comparative Analysis of Architecture Frameworks Technical Report: CeCSES Centre Report: SUTIT-TR2004.01 SUT.CeCSES-TR001
More informationUPDM 2 PLUGIN. version user guide
UPDM 2 PLUGIN version 17.0.1 user guide No Magic, Inc. 2011 All material contained herein is considered proprietary information owned by No Magic, Inc. and is not to be shared, copied, or reproduced by
More informationDoD Architecture Framework Version 2.0
wreath stars Text DoD Architecture Framework Version 2.0 Volume 3: DoDAF Meta-model Physical Exchange Specification Developer s Guide 18 May 2009 This page left intentionally blank TABLE OF CONTENTS SECTION
More informationISO/IEC/ IEEE INTERNATIONAL STANDARD. Systems and software engineering Architecture description
INTERNATIONAL STANDARD ISO/IEC/ IEEE 42010 First edition 2011-12-01 Systems and software engineering Architecture description Ingénierie des systèmes et des logiciels Description de l'architecture Reference
More informationModule 7 TOGAF Content Metamodel
Module 7 TOGAF Content Metamodel V9 Edition Copyright January 2009 All Slide rights reserved 1 of 45 Published by The Open Group, January 2009 TOGAF Content Metamodel TOGAF is a trademark of The Open Group
More informationDesigning a System Engineering Environment in a structured way
Designing a System Engineering Environment in a structured way Anna Todino Ivo Viglietti Bruno Tranchero Leonardo-Finmeccanica Aircraft Division Torino, Italy Copyright held by the authors. Rubén de Juan
More informationfor TOGAF Practitioners Hands-on training to deliver an Architecture Project using the TOGAF Architecture Development Method
Course Syllabus for 3 days Expert led Enterprise Architect hands-on training "An Architect, in the subtlest application of the word, describes one able to engage and arrange all elements of an environment
More informationModule 3 Introduction to the. Architecture Development Method. Introduction to the. Architecture Development Method (ADM)
Module 3 Introduction to the Development Method 8.1.1 Edition Copyright November 2006 All Slide rights reserved 1 Published by The Open Group, November 2006 Development Method Introduction to the Development
More informationWhy do architects need more than TOGAF?
Why do architects need more than TOGAF? To bridge the gap between a high-level management framework for EA and solution/implementation projects You need something like BCS professional certificates in
More informationBenefits and Challenges of Architecture Frameworks
Benefits and Challenges of Architecture Frameworks Daniel Ota Michael Gerz {daniel.ota michael.gerz}@fkie.fraunhofer.de Fraunhofer Institute for Communication, Information Processing and Ergonomics FKIE
More informationPREPARE FOR TAKE OFF. Accelerate your organisation s journey to the Cloud.
PREPARE FOR TAKE OFF Accelerate your organisation s journey to the Cloud. cloud. Contents Introduction Program & Governance BJSS Cloud Readiness Assessment: Intro Platforms & Development BJSS Cloud Readiness
More informationOMG Specifications for Enterprise Interoperability
OMG Specifications for Enterprise Interoperability Brian Elvesæter* Arne-Jørgen Berre* *SINTEF ICT, P. O. Box 124 Blindern, N-0314 Oslo, Norway brian.elvesater@sintef.no arne.j.berre@sintef.no ABSTRACT:
More informationSummary of Contents LIST OF FIGURES LIST OF TABLES
Summary of Contents LIST OF FIGURES LIST OF TABLES PREFACE xvii xix xxi PART 1 BACKGROUND Chapter 1. Introduction 3 Chapter 2. Standards-Makers 21 Chapter 3. Principles of the S2ESC Collection 45 Chapter
More informationForensics and Biometrics Enterprise Reference Architecture (FBEA)
Forensics and Biometrics Enterprise Reference (FBEA) Overview and Summary Information (AV-1) Final Draft Version 2.6 Aug 2016 Version History Version# Date Page(s) Changed Change Description 1.0 Feb 2016
More informationContents. viii. List of figures. List of tables. OGC s foreword. 3 The ITIL Service Management Lifecycle core of practice 17
iii Contents List of figures List of tables OGC s foreword Chief Architect s foreword Preface vi viii ix x xi 2.7 ITIL conformance or compliance practice adaptation 13 2.8 Getting started Service Lifecycle
More informationTOGAF Enterprise Edition Version 8.1
TOGAF Enterprise Edition Version 8.1 A Presentation to the The Open Group Architecture Briefing San Diego 4 th February 2004 Graham John Spencer Bird Vice Director, President Architecture Forum Mobile
More informationContents. List of figures. List of tables. 5 Managing people through service transitions 197. Preface. Acknowledgements.
Contents List of figures List of tables Foreword Preface Acknowledgements v vii viii 1 Introduction 1 1.1 Overview 3 1.2 Context 6 1.3 ITIL in relation to other publications in the Best Management Practice
More informationIntroduction in the Dragon1 open EA Method
Introduction in the Dragon1 open EA Method Dragon1 starts the third wave in Enterprise Architecture: Entering the era of Visual EA Management Overview Revision date: 28 November 2013 Management Overview
More informationIntegration With the Business Modeler
Decision Framework, J. Duggan Research Note 11 September 2003 Evaluating OOA&D Functionality Criteria Looking at nine criteria will help you evaluate the functionality of object-oriented analysis and design
More informationService Vs. System. Why do we need Services and a Services Viewpoint in DM2 and DoDAF? Fatma Dandashi, PhD March 4, 2011
Service Vs. System Why do we need Services and a Services Viewpoint in DM2 and DoDAF? Fatma Dandashi, PhD March 4, 2011 1. Does DoD Need To Model a Service? Bottom Line Up front (BLUF) DoD has a requirement
More informationEnterprise Architecture Method
OIO Enterprise Introduction to the OIO Enterprise Method (OIO ) Version 1.0 and X1. X2. A1. -related challenges A3. Method Foundation A5. Vision, Goals and Strategies B1. Objects B3. Services B5. UseCases
More informationMULTILATERAL INTEROPERABILITY PROGRAMME MIP OPERATIONAL LEVEL TEST PLAN (MOLTP)
MOLTP - TEWG MULTILATERAL INTEROPERABILITY PROGRAMME MIP OPERATIONAL LEVEL TEST PLAN (MOLTP) 14 May 2009, Greding Germany This Multilateral Interoperability Programme (MIP) Operational Level Test Plan
More informationUNCLASSIFIED. ADF Tactical Data Link Authority Ground Network Capability Assurance Services UNCLASSIFIED
UNCLASSIFIED MilCIS 2013 TDL Stream, Session 2.5a ADF Tactical Data Link Authority Ground Network Capability Assurance Services Mr. Josh Roth Ground Networks Manager joshua.roth1@defence.gov.au 02 626
More informationEnterprise Architecture Layers
Enterprise Architecture Layers Monica Scannapieco ESTP Training Course Enterprise Architecture and the different EA layers, application to the ESS context Advanced course Rome, 11 14 October 2016 THE CONTRACTOR
More informationAccelerate Your Enterprise Private Cloud Initiative
Cisco Cloud Comprehensive, enterprise cloud enablement services help you realize a secure, agile, and highly automated infrastructure-as-a-service (IaaS) environment for cost-effective, rapid IT service
More informationBraindumpStudy. BraindumpStudy Exam Dumps, High Pass Rate!
BraindumpStudy http://www.braindumpstudy.com BraindumpStudy Exam Dumps, High Pass Rate! Exam : OG0-093 Title : TOGAF 9 Combined Part 1 and Part 2 Vendor : The Open Group Version : DEMO Get Latest & Valid
More informationRaytheon Mission Architecture Program (RayMAP) Topic 1: C2 Concepts, Theory, and Policy Paper #40
Raytheon Mission Architecture Program (RayMAP) Topic 1: C2 Concepts, Theory, and Policy Paper #40 Dale Anglin Erik Baumgarten John Dinh Mark Hall Bert Schneider May 13, 2008 Cleared for public release
More informationDATA Act Information Model Schema (DAIMS) Architecture. U.S. Department of the Treasury
DATA Act Information Model Schema (DAIMS) Architecture U.S. Department of the Treasury September 22, 2017 Table of Contents 1. Introduction... 1 2. Conceptual Information Model... 2 3. Metadata... 4 4.
More informationthe steps that IS Services should take to ensure that this document is aligned with the SNH s KIMS and SNH s Change Requirement;
Shaping the Future of IS and ICT in SNH: 2014-2019 SNH s IS/ICT Vision We will develop the ICT infrastructure to support the business needs of our customers. Our ICT infrastructure and IS/GIS solutions
More informationEnterprise Architecture Frameworks
Enterprise Architecture Frameworks Learning Objective of Chapter 2 Topic: Enterprise Architecture Framework Content and structure of enterprise architecture descriptions This is necessary because Enterprises
More informationThe Process of Software Architecting
IBM Software Group The Process of Software Architecting Peter Eeles Executive IT Architect IBM UK peter.eeles@uk.ibm.com 2009 IBM Corporation Agenda IBM Software Group Rational software Introduction Architecture,
More informationModule E1 TOGAF 9.1 Changes Overview
Personal PDF. For non-commercial use only Module E1 TOGAF 9.1 Changes Overview V9.1 Copyright 2009-2011 Slide 1 All rights reserved Published by The Open Group, 2011 TOGAF 9.1 Changes Overview Slide 2
More informationThe Zackman Framework
The Zackman Framework 1987 - John Zachman published the Zachman Framework for Enterprise Architecture. He wrote "To keep the business from disintegrating, the concept of information systems architecture
More informationThe Open Group SOA Ontology Technical Standard. Clive Hatton
The Open Group SOA Ontology Technical Standard Clive Hatton The Open Group Releases SOA Ontology Standard To Increase SOA Adoption and Success Rates Ontology Fosters Common Understanding of SOA Concepts
More informationTOGAF Transforming Business
TOGAF 9.2 - Transforming Business The Open Group EA Forum ArchiMate, DirecNet, Making Standards Work, OpenPegasus, Platform 3.0, The Open Group, TOGAF, UNIX, and The Open Brand X logo are registered trademarks
More informationUNCLASSIFIED. Representing Information Exchange Requirements. Version November Ian Bailey
UNCLASSIFIED Representing Information Exchange Requirements using the MOD Architecture Framework (MODAF) Version 1.1 12 November 2007 Ian Bailey This document outlines the preferred approach to developing
More informationSolution Architecture Template (SAT) Design Guidelines
Solution Architecture Template (SAT) Design Guidelines Change control Modification Details Version 2.0.0 Alignment with EIRA v2.0.0 Version 1.0.0 Initial version ISA² Action - European Interoperability
More informationFederated Mission Networking
Federated Mission Networking Learning & Applying the Lessons John Palfreyman, IBM V4; 20 Mar 14 Agenda Future Mission Networking - Context Effective Coalitions through OPEN Integration Save money through
More informationTOGAF 9 Foundation v9.1 Level 1 Level 1: An Introduction to TOGAF
TOGAF 9 Foundation v9.1 Level 1 Level 1: An Introduction to TOGAF full course details This is an accredited online training course, designed by TOGAF experts to prepare you with everything you need to
More informationImplementing a Modular Open Systems Approach (MOSA) to Achieve Acquisition Agility in Defense Acquisition Programs
Implementing a Modular Open Systems Approach (MOSA) to Achieve Acquisition Agility in Defense Acquisition Programs Philomena Zimmerman Office of the Deputy Assistant Secretary of Defense for Systems Engineering
More informationMemorandum of Understanding
Memorandum of Understanding between the European Commission, the European Union Agency for Railways and the European rail sector associations (CER, EIM, EPTTOLA, ERFA, the ERTMS Users Group, GSM-R Industry
More informationBSIF. A Freeware Framework for. Integrated Business Solutions Modeling. Using. Sparx Systems. Enterprise Architect
33 Chester Rd Tawa 5028 Wellington New Zealand P: (+64) 4 232-2092 m: (+64) 21 322 091 e: info@parkconsulting.co.nz BSIF A Freeware Framework for Integrated Business Solutions Modeling Using Sparx Systems
More informationBeyond Technical Interoperability Introducing a Reference Model for Measures of Merit for Coalition Interoperability
Beyond Technical Interoperability Introducing a Reference Model for Measures of Merit for Coalition Interoperability Andreas Tolk, Ph.D. Virginia Modeling Analysis and Simulation Center Old Dominion University
More informationGUIDELINE NUMBER E-NAVIGATION TECHNICAL SERVICES DOCUMENTATION GUIDELINE
ENAV20-9.23 IALA GUIDELINE GUIDELINE NUMBER E-NAVIGATION TECHNICAL SERVICES DOCUMENTATION GUIDELINE Edition x.x Date (of approval by Council) Revokes Guideline [number] DOCUMENT REVISION Revisions to this
More informationTOGAF Certified (Level 1 and 2) 9.1. Lesson Plan. This course covers all learning materials for TOGAF v9.1. Mock Exam: Duration: Language:
TOGAF Certified (Level 1 and 2) 9.1 Lesson Plan This course covers all learning materials for TOGAF v9.1 Delivery: e-learning Certificate: Examination (vouchers included) Accredited By: The Open Group
More informationStandard SOA Reference Models and Architectures
Standard SOA Reference Models and Architectures The Open Group Perspective 4 February 2009 Dr Christopher J Harding Forum Director Tel +44 774 063 1520 (mobile) c.harding@opengroup.org Thames Tower 37-45
More informationEnterprise Architecture Frameworks
Master of Science Business Information Systems Enterprise Architecture Frameworks Chapter 2: Enterprise Architecture Frameworks Enterprise Architecture Frameworks Zachman Enterprise Ontology TOGAF ArchiMate
More informationPolicy Based Security
BSTTech Consulting Pty Ltd Policy Based Security The implementation of ABAC Security through trusted business processes (policy) and enforced metadata for people, systems and information. Bruce Talbot
More informationTOGAF days. Course description
TOGAF 9.1 5 days Course description TOGAF stands for The Open Group Architecture Framework It is the industry-standard methodology and framework for performing EA work and is used by thousands of Enterprise
More informationBreakout Session. James Martin Kevin Kreitman Jeff Diehl Scott Bernard
Breakout Session Exploring the Differences between Enterprise and System s A Look at the Different Methods, Tools, and Techniques James Martin Kevin Kreitman Jeff Diehl Scott Bernard Slide 1 Abstract Point:
More informationNational Data Sharing and Accessibility Policy-2012 (NDSAP-2012)
National Data Sharing and Accessibility Policy-2012 (NDSAP-2012) Department of Science & Technology Ministry of science & Technology Government of India Government of India Ministry of Science & Technology
More informationArchitecture of Business Systems Architecture and the Role of the Architect
Sandro Schwedler Wolfram Richter Architecture of Business Systems Architecture and the Role of the Architect Lecture Outline Introduction (W) Lecture Overview Architecture & role of the Architect Views
More informationEUROPEAN ICT PROFESSIONAL ROLE PROFILES VERSION 2 CWA 16458:2018 LOGFILE
EUROPEAN ICT PROFESSIONAL ROLE PROFILES VERSION 2 CWA 16458:2018 LOGFILE Overview all ICT Profile changes in title, summary, mission and from version 1 to version 2 Versions Version 1 Version 2 Role Profile
More informationRESPONSE TO 2016 DEFENCE WHITE PAPER APRIL 2016
RESPONSE TO 2016 DEFENCE WHITE PAPER APRIL 2016 HunterNet Co-Operative Limited T: 02 4908 7380 1 P a g e RESPONSE TO 2016 DEFENCE WHITE PAPER APRIL 2016 Project Manager Marq Saunders, HunterNet Defence
More informationScience and Technology Directorate
Science and Technology Directorate SAFECOM Background on Public Safety and Wireless Communications Inadequate and unreliable wireless communications have been issues plaguing public safety organizations
More informationNCOIC Interoperability Framework (NIF ) and NCOIC Patterns Overview
Network Centric Operations Industry Consortium NCOIC Interoperability Framework (NIF ) NCOIC Interoperability Framework (NIF ) and NCOIC Patterns Overview and NCOIC Patterns Overview August 2008 Approved
More informationInformation Security and Service Management. Security and Risk Management ISSM and ITIL/ITSM Interrelationship
Information Security and Service Management for Management better business for State outcomes & Local Governments Security and Risk Management ISSM and ITIL/ITSM Interrelationship Introduction Over the
More informationDLV02.01 Business processes. Study on functional, technical and semantic interoperability requirements for the Single Digital Gateway implementation
Study on functional, technical and semantic interoperability requirements for the Single Digital Gateway implementation 18/06/2018 Table of Contents 1. INTRODUCTION... 7 2. METHODOLOGY... 8 2.1. DOCUMENT
More informationOOI CyberInfrastructure Architecture & Design
OOI CI Architecture & Design Integrated Dictionary (AV-2) OOI CyberInfrastructure Architecture & Design Operational Node Connectivity Description OV-2 PDR CANDIDATE November 2007 Last revised: 11/13/2007
More informationSystems and Capability Relation Management in Defence SoS Context
Systems and Capability Relation Management in Defence SoS Context Authors: Pin Chen and Ronnie Gori Integrated Capabilities Branch DSAD, DSTO. Presenter: Thea Clark Outline Introduction Classification
More informationDoDAF 2.0 Viewpoint Definitions. DoDAF v2.0 Viewpoint Definitions
DoDAF v2.0 Viewpoint Definitions i Copyright 2011-2016 Vitech Corporation. All rights reserved. No part of this document may be reproduced in any form, including, but not limited to, photocopying, translating
More informationBusiness Architecture Implementation Workshop
Delivering a Business Architecture Transformation Project using the Business Architecture Guild BIZBOK Hands-on Workshop In this turbulent and competitive global economy, and the rapid pace of change in
More informationNick Rozanski Andy Longshaw Eoin Woods. Sold! How to Describe, Explain and Justify your Architecture
Nick Rozanski Andy Longshaw Eoin Woods Sold! How to Describe, Explain and Justify your Architecture Objectives of Today If you are an architect who has to produce an Architectural Description, then this
More informationIntroduction... 1 Part I: How ITIL Can Help You... 7
Contents at a Glance Introduction... 1 Part I: How ITIL Can Help You... 7 Chapter 1: Managing IT Services: Welcome to the World of ITIL...9 Chapter 2: Using the Building Blocks of ITIL...19 Chapter 3:
More information"Charting the Course... ITIL 2011 Managing Across the Lifecycle ( MALC ) Course Summary
Course Summary Description ITIL is a set of best practices guidance that has become a worldwide-adopted framework for IT Service Management by many Public & Private Organizations. Since early 1990, ITIL
More informationInformation Security Continuous Monitoring (ISCM) Program Evaluation
Information Security Continuous Monitoring (ISCM) Program Evaluation Cybersecurity Assurance Branch Federal Network Resilience Division Chad J. Baer FNR Program Manager Chief Operational Assurance Agenda
More informationBPS Suite and the OCEG Capability Model. Mapping the OCEG Capability Model to the BPS Suite s product capability.
BPS Suite and the OCEG Capability Model Mapping the OCEG Capability Model to the BPS Suite s product capability. BPS Contents Introduction... 2 GRC activities... 2 BPS and the Capability Model for GRC...
More informationINFORMATION ASSURANCE DIRECTORATE
National Security Agency/Central Security Service INFORMATION ASSURANCE DIRECTORATE CGS Network Mapping The Network Mapping helps visualize the network and understand relationships and connectivity between
More informationSubmission to the International Integrated Reporting Council regarding the Consultation Draft of the International Integrated Reporting Framework
Submission to the International Integrated Reporting Council regarding the Consultation Draft of the International Integrated Reporting Framework JULY 2013 Business Council of Australia July 2013 1 About
More informationIntroduction to the DoDAF 2.0
Introduction to the DoDAF 2.0 The introduction to the DoDAF 2.0 provides students with a foundational understanding of DoDAF 2.0 s history and purpose. During the DoDAF 2.0 introduction, items should not
More informationSoftware Architecture
Software Architecture L T JayPrakash jtl@iiitb.ac.in Software Architecture (recap) Other Influences on SA Therefore, SA is important and look into its constituents! Every software system has an architecture!
More informationRobin Wilson Director. Digital Identifiers Metadata Services
Robin Wilson Director Digital Identifiers Metadata Services Report Digital Object Identifiers for Publishing and the e-learning Community CONTEXT elearning the the Publishing Challenge elearning the the
More informationImplementing the Army Net Centric Data Strategy in a Service Oriented Environment
Implementing the Army Net Centric Strategy in a Service Oriented Environment Michelle Dirner Army Net Centric Strategy (ANCDS) Center of Excellence (CoE) Service Team Lead RDECOM CERDEC SED in support
More informationMetadata Framework for Resource Discovery
Submitted by: Metadata Strategy Catalytic Initiative 2006-05-01 Page 1 Section 1 Metadata Framework for Resource Discovery Overview We must find new ways to organize and describe our extraordinary information
More informationMaking Information Perform: Evolving the MIP from databases to services
Making Information Perform: Evolving the MIP from databases to services Doug Sim, Dstl, GBR Pawel Jasinski, RUAG Defence, CHE Crown Copyright 2012. Published with the permission of the Defence Science
More information