DOCSLIB.ORG

Nato Architecture Framework (Naf)

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Nato Architecture Framework (Naf) NATO ARCHITECTURE FRAMEWORK Version 4 Architecture Capability Team Consultation, Command & Control Board January 2018 Acknowledgments for NAFv4 Publication Throughout the development of version 4 of this publication numerous individual experts of NATO Nations participated, resulting in this significant achievement: The realization of the NATO Architecture Framework. This work would not have been possible without the continuous support of the Ministries of Defence of United Kingdom and France, and the NATO Science and Technology Organization. Also special thanks goes to Partner Nations and Industry Partners for their unwavering support in assigning and providing their best professional resources in the architecture domain. The NATO Architecture Framework is a substantial achievement for the Architecture Capability Team under the Consultation, Command and Control Board. Each member of the Architecture Capability Team worked determinedly over the last four years to provide extensive professional guidance and personal effort in the development of this product. The Architecture Capability Team is grateful to all for their contributions to this effort. 4 NAFv4 NAFv4 5 CONTENTS Chapter 1 - Introduction 1 GENERAL ....................................................................................................................................................................... 11 1.1 Purpose ......................................................................................................................................................................... 11 1.2 Aim ................................................................................................................................................................................. 11 1.3 Objectives ..................................................................................................................................................................... 11 1.4 Scope of NAF Documentation ................................................................................................................................ 11 1.5 Reason for Change ...................................................................................................................................................... 11 2 WHAT IS ARCHITECTURE? ....................................................................................................................................... 13 2.1 Description .................................................................................................................................................................... 13 2.2 Why Develop Architectures? .................................................................................................................................... 13 3 WHAT IS AN ENTERPRISE ARCHITECTURE? ........................................................................................................ 14 3.1 Description .................................................................................................................................................................... 14 4 WHAT IS AN ARCHITECTURE FRAMEWORK? ..................................................................................................... 15 4.1 Description .................................................................................................................................................................... 15 5 THE STRUCTURE OF THE NATO ARCHITECTURE FRAMEWORK (NAF) ....................................................... 16 5.1 Introduction .................................................................................................................................................................. 16 6 PURPOSE AND SCOPE OF ARCHITECTURES AND ARCHITECTURE FRAMEWORKS ................................. 17 6.1 Introduction .................................................................................................................................................................. 17 6.2 What is the Value of an Architecture? ................................................................................................................... 18 6.3 Interoperability between Architectures ................................................................................................................. 19 7 NEW FEATURES AND IMPORTANT CHANGES IN NAFv4 ............................................................................... 20 7.1 New Features ............................................................................................................................................................... 20 7.2 Architecture Methodology ........................................................................................................................................ 20 7.3 Grid Representation .................................................................................................................................................... 20 7.4 Adoption of Industry Meta-Models ........................................................................................................................ 21 7.5 Architecture Body of Knowledge ............................................................................................................................. 21 Chapter 2 - Methodology 1 FOREWORD ................................................................................................................................................................. 22 2 SCOPE ............................................................................................................................................................................ 22 3 WHY DO WE NEED THIS ARCHITECTING METHODOLOGY? ....................................................................... 23 4 MAIN CONCEPTS FOR ARCHITECTURE AND ARCHITECTING ....................................................................... 23 4.1 Introduction for Architecting and Architecture.................................................................................................... 23 5 ARCHITECTING SCOPE ............................................................................................................................................. 25 5.1 Introduction .................................................................................................................................................................. 25 5.2 Stakeholder Concerns, Viewpoints and Perspectives .......................................................................................... 25 5.3 Architecture Dimensions ........................................................................................................................................... 25 5.4 Kinds of Architectures ................................................................................................................................................ 25 5.5 Architecting Styles ...................................................................................................................................................... 26 5.6 Main Architecture Processes ..................................................................................................................................... 27 5.7 Architecture Governance........................................................................................................................................... 27 5.8 Architecture Management ........................................................................................................................................ 27 5.9 Architecture Description ........................................................................................................................................... 28 5.10 Architecture Evaluation ............................................................................................................................................. 28 5.11 Architecture Enablers ................................................................................................................................................. 28 5.12 Architecture Life Cycle ............................................................................................................................................... 29 5.13 Architectures and Architecting Activities in the Enterprise............................................................................... 29 5.14 Architecture Framework ............................................................................................................................................ 30 5.15 Architecture Repositories .......................................................................................................................................... 34 5.16 Architecture Motivation Data .................................................................................................................................. 35 5.17 Manage Architecture Motivation Data .................................................................................................................. 36 5.18 Architecture Policy ...................................................................................................................................................... 37 6 NAFv4 5.19 Architecture Management Plan ............................................................................................................................... 37 5.20 Migration Plan .............................................................................................................................................................
Load more

Recommended publications
  • ASP.NET MVC with Entity Framework and CSS
    ASP.NET MVC with Entity Framework and CSS Lee Naylor ASP.NET MVC with Entity Framework and CSS Lee Naylor Newton-le-Willows, Merseyside United Kingdom ISBN-13 (pbk): 978-1-4842-2136-5 ISBN-13 (electronic): 978-1-4842-2137-2 DOI 10.1007/978-1-4842-2137-2 Library of Congress Control Number: 2016952810 Copyright © 2016 by Lee Naylor This work is subject to copyright. All rights are reserved by the Publisher, whether the whole or part of the material is concerned, specifically the rights of translation, reprinting, reuse of illustrations, recitation, broadcasting, reproduction on microfilms or in any other physical way, and transmission or information storage and retrieval, electronic adaptation, computer software, or by similar or dissimilar methodology now known or hereafter developed. Trademarked names, logos, and images may appear in this book. Rather than use a trademark symbol with every occurrence of a trademarked name, logo, or image we use the names, logos, and images only in an editorial fashion and to the benefit of the trademark owner, with no intention of infringement of the trademark. The use in this publication of trade names, trademarks, service marks, and similar terms, even if they are not identified as such, is not to be taken as an expression of opinion as to whether or not they are subject to proprietary rights. While the advice and information in this book are believed to be true and accurate at the date of publication, neither the authors nor the editors nor the publisher can accept any legal responsibility for any errors or omissions that may be made.
    [Show full text]
  • Configuring Metadata Manager Privileges and Permissions
    Configuring Metadata Manager Privileges and Permissions © Copyright Informatica LLC 1993, 2021. Informatica LLC. No part of this document may be reproduced or transmitted in any form, by any means (electronic, photocopying, recording or otherwise) without prior consent of Informatica LLC. All other company and product names may be trade names or trademarks of their respective owners and/or copyrighted materials of such owners. Abstract You can configure privileges to allow users access to the features in Metadata Manager. You can configure permissions to allow access to resources or objects in Metadata Manager. This article describes the privileges and permissions that you can configure in Metadata Manager. Supported Versions • Metadata Manager 9.6.1 Table of Contents Introduction................................................................ 2 Users, Groups, Privileges, and Roles................................................ 3 Privileges ................................................................. 4 Catalog Privilege Group...................................................... 4 Load Privilege Group........................................................ 6 Model Privilege Group....................................................... 7 Security Privilege Group...................................................... 7 Permissions................................................................ 8 Types of Permissions........................................................ 9 Rules and Guidelines.......................................................
    [Show full text]
  • Technology Update on the Unified Architecture Framework (UAF)
    View metadata, citation and similar papers at core.ac.uk brought to you by CORE provided by KTUePubl (Repository of Kaunas University of Technology) Technology Update on the Unified Architecture Framework (UAF) Matthew Hause Graham Bleakley Engineering Fellow Solution Architect PTC IBM Analytics [email protected] [email protected] Aurelijus Morkevicius Senior Solution Architect No Magic [email protected] Copyright © 2016 by Matthew Hause, Graham Bleakley, Aurelijus Morkevicius. Abstract. Architecture frameworks continue to evolve. The Unified Profile for the Department of Defense (DoD) Architecture Framework (DoDAF) and the UK’s Ministry of Defence Architecture Framework (MODAF) (UPDM) provides a standard means of representing DoDAF, MODAF, and NATO Architecture Framework (NAF) conformant architectures using the Unified Modeling Language (UML), and Systems Modeling Language (SysML). Since the UPDM V2.0 publication, further information has emerged such as the June 2011 NATO study entitled: “Development of The AMN (Afghanistan Mission Network) Architecture In 2010 – Lessons Learned,” by Torsten Graeber of the NATO C3 Agency. This report identified the following in section 4.1-ARCHITECTURE FRAMEWORKS, sub-section 4.1.2 Observations (Need for a Unified Architecture Framework) and stated that: • differences in DoDAF, MODAF, and NAF make it difficult to match the metamodel one to one. • some of the concepts in the frameworks have the same name but different definitions, i.e. different semantics. • difficult to cross-walk the concepts between the different frameworks leads to miscommunication between architects using different frameworks. Based on the above, the NATO Architecture Capability Team (Architecture CaT) meeting on Sept. 10-11, 2012 committed to move to a single world-wide Architecture Framework.
    [Show full text]
  • Software Architecture and Agility
    Agility and Architecture May 18 2010 Agility and Architecture: An Oxymoron? Philippe Kruchten Saturn May 18, 2010 Philippe Kruchten, Ph.D., P.Eng., CSDP Professor of So)ware Engineering NSERC Chair in Design Engineering Department of Electrical and Computer Engineering University of BriIsh Columbia Vancouver, BC Canada [email protected] Founder and president Kruchten Engineering Services Ltd Vancouver, BC Canada [email protected] Philippe Kruchten 1 Agility and Architecture May 18 2010 Agile & Architecture? Oil & Water? • Paradox • Oxymoron • Conflict • IncompaIbility Outline • Agility?? • SoSware architecture? • A story • Seven viewpoints on a single problem • The zipper model • A clash of two cultures • Summary Philippe Kruchten 2 Agility and Architecture May 18 2010 Agility • A definiIon – Agility is the ability to both create and respond to change in order to profit in a turbulent business environment. Jim Highsmith (2002) • CharacterisIcs – IteraIve and incremental – Small release – Collocaon – Release plan/ feature backlog – IteraIon plan/task backlog Sanjiv AugusIne (2004) Agile Values: the Agile Manifesto We have come to value: • Individuals and interacIons over process and tools, • Working soSware over comprehensive documents, • Customer collaboraIon over contract negoIaIon, • Responding to change over following a plan. That is, while there is value in the items on the right, we value the items on the leS more Source: hp://www.agilemanifesto.org/ Philippe Kruchten 3 Agility and Architecture May 18 2010 Geng at the Essence of Agility • SoSware development is a knowledge acIvity – Not producIon, manufacturing, administraIon… • The “machines” are humans • Dealing with uncertainty, unknowns, fear, distrust • Feedback loop -> – reflect on business, requirements, risks, process, people, technology • CommunicaIon and collaboraIon -> – Building trust Named Agile Methods • XP = eXtreme Programming (K.
    [Show full text]
  • Architectural Improvement of Display Viewer 5 Software
    Teemu Vähä-Impola Architectural Improvement of Display Viewer 5 Software Master’s Thesis in Information Technology November 6, 2020 University of Jyväskylä Faculty of Information Technology Author: Teemu Vähä-Impola Contact information: [email protected] Supervisors: PhD Raino Mäkinen, MSc Tommy Rikberg, and MSc Lauri Saurus Title: Architectural Improvement of Display Viewer 5 Software Työn nimi: Display Viewer 5 -ohjelmiston arkkitehtuurin parantaminen Project: Master’s Thesis Study line: Software Technology Page count: 76+1 Abstract: In this thesis, an improved architecture for Display Viewer 5 (DV5) software was studied. The new architecture would enforce MVVM architecture more strongly, make clearer divisions of the software’s parts and enhance maintainability and reusability of the software, thus making the software more customizable for new projects and suitable for the customers’ needs. As a result, the existing MVVM architecture was strengthened by enforcing division into models, views and viewmodels. In addition, redundant duplications were removed and certain code was divided into their own separate entities. Keywords: architecture, software engineering Suomenkielinen tiivistelmä: Tässä tutkielmassa Display Viewer 5 (DV5) -ohjelmistolle pyrittiin löytämään parempi arkkitehtuuri, jonka seurauksena huollettavuus ja uudelleenkäytet- tävyys kasvavat ja ohjelmiston kustomointi uusille asiakkaille helpottuu. Tuloksena päädyt- tiin vahvistamaan jo nykyistä MVVM-arkkitehtuuria tekemällä jokaiselle luokalle tarvitta- van arkkitehtuurin
    [Show full text]
  • Air Force Human Systems Integration Handbook
    Air Force Human Systems Integration Handbook: Planning and Execution of Human Systems Integration Distribution A: Unlimited Distribution Prepared by: Directorate of Human Performance Integration Human Performance Optimization Division 711 HPW/HPO 2485 Gillingham Drive Brooks City-Base, TX 78235-5105 This page intentionally left blank. 2 TABLE OF CONTENTS EXECUTIVE SUMMARY...........................................................................................................................................7 1. INTRODUCTION TO AIR FORCE HUMAN SYSTEMS INTEGRATION ......................................................8 1.1 HANDBOOK PURPOSE........................................................................................................................................8 1.2 HISTORY .............................................................................................................................................................8 1.3 KEY CONCEPTS................................................................................................................................................10 1.4 DOMAINS ..........................................................................................................................................................10 2. IMPLEMENTING AIR FORCE HUMAN SYSTEMS INTEGRATION...........................................................12 2.1 PRIMARY AFHSI ORGANIZATIONS..................................................................................................................12 2.1.1 Air Force
    [Show full text]
  • Model and Tool Integration in High Level Design of Embedded Systems
    Model and Tool Integration in High Level Design of Embedded Systems JIANLIN SHI Licentiate thesis TRITA – MMK 2007:10 Department of Machine Design ISSN 1400-1179 Royal Institute of Technology ISRN/KTH/MMK/R-07/10-SE SE-100 44 Stockholm TRITA – MMK 2007:10 ISSN 1400-1179 ISRN/KTH/MMK/R-07/10-SE Model and Tool Integration in High Level Design of Embedded Systems Jianlin Shi Licentiate thesis Academic thesis, which with the approval of Kungliga Tekniska Högskolan, will be presented for public review in fulfilment of the requirements for a Licentiate of Engineering in Machine Design. The public review is held at Kungliga Tekniska Högskolan, Brinellvägen 83, A425 at 2007-12-20. Mechatronics Lab TRITA - MMK 2007:10 Department of Machine Design ISSN 1400 -1179 Royal Institute of Technology ISRN/KTH/MMK/R-07/10-SE S-100 44 Stockholm Document type Date SWEDEN Licentiate Thesis 2007-12-20 Author(s) Supervisor(s) Jianlin Shi Martin Törngren, Dejiu Chen ([email protected]) Sponsor(s) Title SSF (through the SAVE and SAVE++ projects), VINNOVA (through the Model and Tool Integration in High Level Design of Modcomp project), and the European Embedded Systems Commission (through the ATESST project) Abstract The development of advanced embedded systems requires a systematic approach as well as advanced tool support in dealing with their increasing complexity. This complexity is due to the increasing functionality that is implemented in embedded systems and stringent (and conflicting) requirements placed upon such systems from various stakeholders. The corresponding system development involves several specialists employing different modeling languages and tools.
    [Show full text]
  • Reflections on Software Architecture Linda Northrop SEI Fellow
    Reflections on Software Architecture Linda Northrop SEI Fellow Software Engineering Institute Carnegie Mellon University Pittsburgh, PA 15213 © 2016 Carnegie Mellon University Distribution Statement A: Approved for Public Release; Distribution is Unlimited Notices Copyright 2016 Carnegie Mellon University This material is based upon work funded and supported by the Department of Defense under Contract No. FA8721-05-C-0003 with Carnegie Mellon University for the operation of the Software Engineering Institute, a federally funded research and development center. Any opinions, findings and conclusions or recommendations expressed in this material are those of the author(s) and do not necessarily reflect the views of the United States Department of Defense. NO WARRANTY. THIS CARNEGIE MELLON UNIVERSITY AND SOFTWARE ENGINEERING INSTITUTE MATERIAL IS FURNISHED ON AN “AS-IS” BASIS. CARNEGIE MELLON UNIVERSITY MAKES NO WARRANTIES OF ANY KIND, EITHER EXPRESSED OR IMPLIED, AS TO ANY MATTER INCLUDING, BUT NOT LIMITED TO, WARRANTY OF FITNESS FOR PURPOSE OR MERCHANTABILITY, EXCLUSIVITY, OR RESULTS OBTAINED FROM USE OF THE MATERIAL. CARNEGIE MELLON UNIVERSITY DOES NOT MAKE ANY WARRANTY OF ANY KIND WITH RESPECT TO FREEDOM FROM PATENT, TRADEMARK, OR COPYRIGHT INFRINGEMENT. [Distribution Statement A] This material has been approved for public release and unlimited distribution. Please see Copyright notice for non-US Government use and distribution. This material may be reproduced in its entirety, without modification, and freely distributed in written or electronic form without requesting formal permission. Permission is required for any other use. Requests for permission should be directed to the Software Engineering Institute at [email protected]. Carnegie Mellon® and CERT® are registered marks of Carnegie Mellon University.
    [Show full text]
  • From Requirements to Design Specifications- a Formal Approach
    INTERNATIONAL DESIGN CONFERENCE - DESIGN 2010 Dubrovnik - Croatia, May 17 - 20, 2010. FROM REQUIREMENTS TO DESIGN SPECIFICATIONS- A FORMAL APPROACH W. Brace and K. Thramboulidis Keywords: requirements, requirements checklist, design specification, requirements formalization, model-centric requirements engineering 1. Introduction The traditional development process for mechatronic systems is criticized as inappropriate for the development of systems characterized by complexity, dynamics and uncertainty as is the case with today’s products. Software is playing an always increasing role in the development of these systems and it has become the evolving driver for innovations. It does not only implement a significant part of the functionality of today’s mechatronic systems, but it is also used to realize many of their competitive advantages [Thramboulidis 2009]. However, the current process is traditionally divided into software, electronics and mechanics, with every discipline to emphasize on its own approaches, methodologies and tools. Moreover, vocabularies used in processes and methodologies are different making the collaboration between the disciplines a great challenge. System development activities such as requirements and design specification, implementation and verification are well defined in software engineering. In terms of software engineering the term “design specification” is used to refer to the various models that are produced during the design process and describe the various models of the proposed solutions. Therefore, “design specifications” are descriptions of solution space while “analysis specifications” are descriptions of problem space. Analysis specifications include both requirements specifications but also the problem space structuring that is represented by analysis models such as class diagrams that capture the key concepts of the problem domain and in this sense they provide a specific structuring of the problem space.
    [Show full text]
  • System-Of-Systems Viewpoint for System Architecture Documentation
    System-of-Systems Viewpoint for System Architecture Documentation John Klein∗ and Hans van Vliet† VU University, Amsterdam, Netherlands Revised 11 Nov 2017 Abstract Context: The systems comprising a system of systems (SoS) are inde- pendently acquired, operated, and managed. Frequently, the architecture documentation of these existing systems addresses only a stand-alone perspective, and must be augmented to address concerns that arise in the integrated SoS. Objective: We evaluated an architecture documentation viewpoint to address the concerns of a SoS architect about a constituent system, to support SoS design and analysis involving that constituent system. Method: We performed an expert review of documentation produced by applying the viewpoint to a system, using the active review method. Results: The expert panel was able to used a view constructed using the baseline version of the viewpoint to answer questions related to all SoS architect concerns about a constituent system, except for questions concerning the interaction of the constituent system with the platform and network infrastructure. Conclusions: We found that the expert panel was unable to answer certain questions because the baseline version of the viewpoint had a gap in coverage related to relationship of software units of execution (e.g., processes or services) to computers and networks. The viewpoint was revised to add a Deployment Model to address these concerns, and is included in an appendix. arXiv:1801.06837v1 [cs.SE] 21 Jan 2018 Keywords: architecture documentation; system of systems; viewpoint defi- nition; active review; expert panel; design cycle 1 Introduction A system of systems (SoS) is created by composing constituent systems.
    [Show full text]
  • Kruchten Frog Octopus JSS V6
    Paper submitted to the Journal of Software and Systems, July 2011, resubmitted November 2011. The frog and the octopus: a conceptual model of software development Philippe Kruchten University of British Columbia 2332 Main Mall Vancouver BC V6N2T9 Canada email: [email protected] phone: +1 (604) 827-5654 fax: +1 (604) 822-5949 Abstract We propose a conceptual model of software development that encompasses all approaches: traditional or agile, light and heavy, for large and small development efforts. The model identifies both the common aspects in all software development, i.e., elements found in some form or another in each and every software development project (Intent, Product, People, Work, Time, Quality, Risk, Cost, Value), as well as the variable part, i.e., the main factors that cause the very wide variations we can find in the software development world (Size, Age, Criticality, Architecture stability, Business model, Governance, Rate of change, Geographic distribution). We show how the model can be used as an explanatory theory of software development, as a tool for analysis of practices, techniques, processes, as the basis for curriculum design or for software process adoption and improvement, and to support empirical research on software development methods. This model is also proposed as a way to depolarize the debate on agile methods versus the rest-of-the-world: a unified model. Keywords: software development, conceptual model, ontology, method, software development process, software engineering, theory Visual abstract for JSS: !"#$%& !"#$%& '()*& '()*& Alternate visual abstract for JSS: Authorʼs bio: Philippe Kruchten is professor of software engineering at the University of British Columbia, Vancouver, Canada.
    [Show full text]
  • (2008). Exploring the Impact of Systems Architecture
    Exploring the Impact of Systems Architecture and Systems Requirements on Systems Integration Complexity Dr. Rashmi Jaini, Anithashree Chandrasekaran, George Elias, Dr. Robert Cloutier Stevens Institute of Technology [email protected], [email protected], [email protected], [email protected] Abstract development projects in the government The need to perform faster systems sector. integration of complex systems require the Keywords: System Architecture, System architect and design team understand how Integration, Integration Complexity, System the selected architecture and design Requirements components will impact the system Introduction integration processes complexity. System It is necessary to determine if integration process complexity is an integration of the defined physical elements outcome of the interaction between degree and interfaces in system architecture of feasibility and level of effort required to contributes to system integration process understand, describe, implement, manage complexity. Today’s systems are usually and document the system integration process expected to function independently and in for a given system development and cooperation with the existing systems operational environment. This paper (system of systems). The cooperating analyzes the cause and effect relationships systems undergo frequent changes and between the system requirements, interoperability becomes a key factor and a architecture and the system integration major contributor to system integration processes complexity. In order to address process complexity. Interoperability is based systems integration issues upfront in the on the existence of the conceptual view design phase it is necessary to determine if [Carney and Oberndoff, 2004]. The the architecture and design of components, conceptual view can be embodied in sub-systems, processes and interfaces requirements and architecture/design and the impacts (and to what extent) system system architecture determines the level of integration process complexity.
    [Show full text]