DOCSLIB.ORG

The Open Group Architecture Framework (TOGAF)

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
The Open Group Architecture Framework (TOGAF) The Open Group Architecture Framework (TOGAF) John Spencer, Director – Architecture Forum Boston, July 24th 2002 Agenda q The Architecture Forum q TOGAF background q TOGAF components q Plans for the Future q Summary Architecture Forum - Stakeholders q Customer Architects: reduced time, cost, risk § procuring effective IT architecture tools § developing an IT architecture § procuring products to implement an IT architecture q Tools Vendors: bigger market, bigger market share § supporting open methods for architecture q IT Solution Vendors: greater cost-efficiency § reduced cost of bidding, greater share of procurements q Integrators: greater cost-efficiency, better service § better service delivery to clients § more effective use / re-use of own architecture assets q Academic / Research Organizations: funding support § demonstrated relevance to market, route to standardization § “technology transfer” important in bids for funding Membership – 1st July 2002 48 members: § Arthur Andersen Business Consulting (US) § Mitre Corporation (US) § BMC Software Inc. (US) § Monash University (Australia) § Boeing Corporation (US) § NASA Goddard Space Flight Center (US) § CC and C Solutions (Australia) § National Computerization Agency (Korea) § Centre For Open Systems (Australia) § NATO C3 Agency (Belgium) § ChiSurf (Hong Kong) § NEC (Japan) § Compaq (US) § NeTraverse, Inc. (US) § Computacentre (UK) § Nexor, Inc. (US) § Computas (Norway) § Open GIS Consortium, Inc. (US) § Computer Associates (US) § PASS Network Consulting (Germany) § Conclusive Logic (US) § POSC (US) § Department of Defense / DISA (US) § Predictive Systems AG (Germany) § Department of Works and Pensions (UK) § ReGIS (Japan) § Desktop Management Task Force (US) § QA Consulting (UK) § Frietuna Consultants (UK) § SCO (US) § Fujitsu (Japan) § Sun Microsystems (US) § Hewlett-Packard (US) § Teamcall (Belgium) § Hitachi (Japan) § The Terasoft Group (US) § IBM (US) § Tivoli (US) § Innenministerium NordRhein-Westfalen (Ger) § Toyota InfoTechnology Center (Japan) § Jet Propulsion Labs (US) § TRON Association (Japan) § Lockheed Martin (US) § Veriserve Corporation (US) § Ministry of Defence (UK) § Visa International (US) § Motorola (US) § Westpac Banking Corporation (Australia) Architecture Forum - Vision Target q An effective, open framework ADM and method TRM SIB BBIB Resource Base TOGAF q Knowledgeable and professional practitioners q Adequate “Commercial Off- The-Shelf” tools TOGAF Origins q A customer initiative q A framework, not an architecture § Main themes: § A single, unifying architectural framework for the IT industry § A framework for developing architectures to meet different business needs • not a “one-size-fits-all” architecture q Originally based on TAFIM (U.S. DoD) TOGAF Development q 1994: Requirement Proof of need q 1995: TOGAF Version 1 Proof of concept q 1996: TOGAF Version 2 Proof of application q 1997: TOGAF Version 3 Relevance to practical architectures (building blocks) q 1998: TOGAF Version 4 Enterprise Continuum (TOGAF in context) Business Scenarios (architecture q 1999: TOGAF Version 5 requirements) q 2000: TOGAF Version 6 Architecture views - IEEE 1471 US DoD work (C4ISR A/F, C2STA) q 2001: TOGAF Version 7 Architecture Principles; Compliance Reviews; TOGAF & enterprise frameworks TOGAF Today q An industry consensus framework and method § Successful customer / vendor collaboration q Technology and tool neutral q Proven in practice § 8 years continuous development & evolution § Used successfully in major projects / procurements around the world q Publicly available § http://www.opengroup.org/public/arch (view on-line) § http://www.opengroup.org /architecture/togaf (download) TOGAF Structure and Components q Architecture Target Development Architectures Method Architecture Development Method q Foundation Architecture Technical Standards Building q Resource Reference Information Blocks Model Base Information Base Base TOGAF (services (standards) (architecture taxonomy) building blocks Foundation - future) Architecture Resource Base TOGAF Architecture Development Method (ADM) q Open, industry consensus method for IT architecture q Quick-start foundation q Practical, experience based guidance q Emphasizes continual validation against requirements Phases A through C (Relevant to all architecture developments) A – Initiation and Framework: A Initiation q Use Business Scenarios to define and relevant business requirements Framework G B q Identify stakeholders / concerns Architecture Baseline Maintenance q Build consensus with partners Description B – Baseline Description q Build description of current Requirements system F C Implementation Target q Identify “what’s wrong” Architecture q Inventory of re-usable building blocks C –Target Architecture: E D Migration Opportunities q Identify all needed services Planning and Solutions q Multiple views to address stakeholder concerns Phases A through C (Relevant to all architecture developments) A – Initiation and Framework: A Initiation q Use Business Scenarios to define andAA relevant business requirements Framework G InitiationInitiation && B q Identify stakeholders / concerns Architecture Baseline MaintenanceFrameworkFramework q Build consensus with partners Description B – Baseline Description q Build description of current Requirements system F C Implementation Target q Identify “what’s wrong” Architecture q Inventory of re-usable building blocks C –Target Architecture: E D Migration Opportunities q Identify all needed services Planning and Solutions q Multiple views to address stakeholder concerns Identifying Requirements: Business Scenarios 1 - problem 2 - environment 3 - objectives 4 - human actors 5 - computer actors 6 - roles & responsibilities 7 - refine Phases A through C (Relevant to all architecture developments) A – Initiation and Framework: A Initiation q Use Business Scenarios to define and relevant business requirements Framework G BB B q Identify stakeholders / concerns Architecture Baseline Maintenance Baseline q Build consensus with partners BaselineDescription B – Baseline Description DescriptionDescription q Build description of current Requirements system F C Implementation Target q Identify “what’s wrong” Architecture q Inventory of re-usable building blocks C –Target Architecture: E D Migration Opportunities q Identify all needed services Planning and Solutions q Multiple views to address stakeholder concerns Phases A through C (Relevant to all architecture developments) A – Initiation and Framework: A Initiation q Use Business Scenarios to define and relevant business requirements Framework G B q Identify stakeholders / concerns Architecture Baseline Maintenance q Build consensus with partners Description B – Baseline Description q Build description of current Requirements CC system F C Implementation TargetTargetTarget q Identify “what’s wrong” Architecture ArchitectureArchitecture q Inventory of re-usable building blocks C –Target Architecture: E D Migration Opportunities q Identify all needed services Planning and Solutions q Multiple views to address stakeholder concerns Phase C – Target Architecture (Steps) B 11 CreateCreate baselinebaseline 22 ConsiderConsider viewsviews 33 CreateCreate arch.arch. modelmodel 66 DetermineDetermine criteriacriteria 44 SelectSelect servicesservices 55 ConfirmConfirm bus.bus. ObjsObjs.. 7a7a DefineDefine architecturearchitecture 7b7b IdentifyIdentify Arch.Arch. BuildingBuilding BlocksBlocks 88 ConductConduct gapgap analysisanalysis D Phases D through G (Relevant when taking architecture through to A implementation) Initiation and Framework q D - Opportunities and G B Solutions: evaluate and select Architecture Baseline Maintenance Description major work packages q E - Migration Planning: prioritize work, develop outline Requirements plan F C Implementation Target q F - Implementation: develop Architecture full plan and execute q G - Architecture Maintenance: establish E D procedure for maintenance of Migration Opportunities new baseline Planning and Solutions TOGAF Components q Architecture Development Method q Foundation Architecture § Technical Reference Model § Standards Information Base § Enterprise Continuum (Foundation Architecture in context) q Resource Base Foundation Architecture: Technical Reference Model (TRM) Qualities Infrastructure Business q Associated with Applications Applications System & Network Management detailed taxonomy of Application Programming Interface International Operations Transaction Processing services Software Engineering Location & Directory Data Management Graphics & Image Data Interchange § defines scope of User Interface Security each service Qualities category q Identifies system-wide capabilities Qualities (“qualities”), e.g.: Operating System Services § Internationalization Network Services § Security Communications Infrastructure Interface § Management Communication Infrastructure Qualities Foundation Architecture: Standards Information Base (SIB) q A database of open industry standards § The complete set of Open Group endorsed standards § Content determined by Open Group consensus process q Structured according to TOGAF Technical Reference Model taxonomy q Regularly updated q Available for public web access § http://www.db.opengroup.org/sib.htm q Gateway to many linked resources The Foundation Architecture in Context: The “Enterprise Continuum” Common Foundation Systems Industry Organization Architectures Architectures Architectures Architectures Business Applications Architecture Qualities Continuum guides
Load more

Recommended publications
  • The History of Enterprise Architecture: an Evidence-Based Review
    Article The History of Enterprise Architecture: An Evidence-Based Review Svyatoslav Kotusev Abstract The conventional wisdom says that the concept of Enterprise Architecture (EA) originated from the pioneering work of John Zachman. He is frequently referred to as the “father” of EA and many consider the Zachman Framework to be the breakthrough that created the discipline of EA and provided the foundation for all subsequent EA frameworks and methodologies. Is Zachman’s “A Framework for Information Systems Architecture” really the seminal publication of the EA discipline? Is it really the first EA framework? Did it really profoundly influence modern EA methodologies? In order to answer these questions, in this article I describe an evidence-based history of EA and trace the origins of all essential ideas constituting the basis of the modern concept of EA. Keywords Enterprise Architecture, history, frameworks, Zachman Framework, Business Systems Planning divided into three distinct periods: Business Systems INTRODUCTION Planning, early EA, and modern EA. Almost every publication on Enterprise Architecture (EA) BUSINESS SYSTEMS PLANNING cites the Zachman Framework (Zachman 1987) as a seminal EA publication that fundamentally shaped the The idea of deliberate information systems planning is discipline of EA. Authors routinely call John Zachman far from new. Early planning approaches proposed the “father” of EA and consider his framework paper to various considerations on how to design corporate be the initial breakthrough publication that created the information systems based on an organizational strategy very concept of EA and significantly influenced its (King 1978), data flows between departments modern understanding. Moreover, many authors argue (Blumenthal 1969), suppliers and orders (Carlson 1979; that the Zachman Framework inspired all other Kerner 1979), critical success factors (Rockart 1979), subsequent EA frameworks and methodologies.
    [Show full text]
  • On the State-Of-The-Art in Enterprise Architecture Management Literature
    FAKULTAT¨ FUR¨ INFORMATIK DER TECHNISCHEN UNIVERSITAT¨ MUNCHEN¨ Technical Report On the State-of-the-Art in Enterprise Architecture Management Literature Sabine Buckl and Christian M. Schweda II Abstract The enterprise architecture (EA) and its management are topics receiving ongoing interest from academia, practitioners, standardization bodies, and tool vendors. Over the last decade and especially in the last five years, much has been said and written on these topics that nevertheless have a much longer history dating back to the nineties of the last century. In these days, John Zachman was one of the first to understand the ‘bigger whole’ in which IS architecting and IS development is embedded. Ever since these days, the canonic knowledge on this topic, which would later become known as “EA management”, has been furthered by many contributors originating from different philosophical, educational, and theoretical backgrounds, leading to numerous presentations and publications in this area. But while each article, paper or book extends the body of knowledge, it also ‘raises the stakes’ for anyone willing to enter this field of engagement. Especially, young researchers novel to this area that is not covered that much in university education than it perhaps should, find themselves confronted with a vast amount of ‘hits’, when they enter “EA management” as keyword in their favorite (scientific) search engine. This report aims at charting the landscape of EA management research and practice. Applying a generic framework for structuring the body of knowledge in the field into the two core areas of “method” and “language”, the work provides an overview on the state-of-the-art in the field, delineates interesting questions for future research, and shows how different approaches taken may be worthwhile subjects for researching how they may complement each other.
    [Show full text]
  • Comprehensive Measurement Framework for Enterprise Architectures
    International Journal of Computer Science & Information Technology (IJCSIT) Vol 3, No 4, August 2011 COMPREHENSIVE MEASUREMENT FRAMEWORK FOR ENTERPRISE ARCHITECTURES Mahesh R. Dube 1 and Shantanu K. Dixit 2 1Department of Computer Engineering, VIT, Pune, India mrdube@rediffmail.com 2Department of Electronics and Telecommunications, WIT, Solapur, India dixitsk1@yahoo.com ABSTRACT Enterprise Architecture defines the overall form and function of systems across an enterprise involving the stakeholders and providing a framework, standards and guidelines for project-specific architectures. Project-specific Architecture defines the form and function of the systems in a project or program, within the context of the enterprise as a whole with broad scope and business alignments. Application-specific Architecture defines the form and function of the applications that will be developed to realize functionality of the system with narrow scope and technical alignments. Because of the magnitude and complexity of any enterprise integration project, a major engineering and operations planning effort must be accomplished prior to any actual integration work. As the needs and the requirements vary depending on their volume, the entire enterprise problem can be broken into chunks of manageable pieces. These pieces can be implemented and tested individually with high integration effort. Therefore it becomes essential to analyze the economic and technical feasibility of realizable enterprise solution. It is difficult to migrate from one technological and business aspect to other as the enterprise evolves. The existing process models in system engineering emphasize on life-cycle management and low-level activity coordination with milestone verification. Many organizations are developing enterprise architecture to provide a clear vision of how systems will support and enable their business.
    [Show full text]
  • Enterprise Architecture Analysis and Designing T Support the Filtering O Process Consumer at Real Estate Company
    International Journal of Civil Engineering and Technology (IJCIET) Volume 10, Issue 09, September 2019, pp. 1-15, Article ID: IJCIET_10_09_001 Available online at http://iaeme.com/Home/issue/IJCIET?Volume=10&Issue=9 ISSN Print: 0976-6308 and ISSN Online: 0976-6316 © IAEME Publication ENTERPRISE ARCHITECTURE ANALYSIS AND DESIGNING TO SUPPORT THE FILTERING PROCESS CONSUMER AT REAL ESTATE COMPANY Nilo Legowo, Wandi Aprianto Information System Department, BINUS Graduate Program-Master in Information System Management, Bina Nusantara University Jakarta Indonesia 11480 Email : nlegowo@binus.edu, wandi.aprianto@binus.ac.id ABSTRACT PT Gerbang Duabelas is a real estate company engaged in the field of developer domiciled in Pontianak, West Kalimantan. Today, there are often problems with consumers, such as high sales cancellation rates, consumers who are in arrears in payment of DP receivables, consumers who are in arrears in housing installments to banks as lenders, consumers who are in trouble, constrained mortgage documents and uncooperative consumers. PT Gerbang Duabelas needs to design an Enterprise Architecture that can filter prospective customers who have good and healthy prospects. Enterprise Architecture is an activity of organizing data that is used and produced by an organization that covers the business processes of the organization. The framework is used as a reference in designing enterprise architecture in this study is TOGAF ADM, with a focus on design in the information system architecture phase, namely the data architecture and application architecture. Key words: Enterprise Architecture, TOGAF ADM, System Information Architecture, Architecture Data, Architecture Technology. Cite this Article: Nilo Legowo, Wandi Aprianto, Enterprise Architecture Analysis and Designing to Support the Filtering Process Consumer at Real Estate Company.
    [Show full text]
  • TOGAF: Just the Next Fad That Turned Into a New Religion
    TOGAF: Just the Next Fad That Turned into a New Religion Svyatoslav Kotusev (kotusev@kotusev.com) This article appeared as a book chapter in: Smith, K. L. (ed.) (2018) TOGAF Is Not an EA Framework: The Inconvenient Pragmatic Truth, Great Notley, UK: Pragmatic EA Ltd. (Disclaimer: This article is merely a personal opinion of the author, which can be freely agreed or disagreed with, and should not be associated with any other individuals or organizations) Introduction Currently the discourse in the enterprise architecture (EA) discipline largely revolves around The Open Group Architecture Framework (TOGAF). TOGAF is actively promoted by many consultancies and gurus as a leading EA framework. For example, The Open Group claims that TOGAF is “a proven Enterprise Architecture methodology and framework” as well as “the most prominent and reliable Enterprise Architecture standard in the world”. TOGAF describes an EA practice as an iterative step-wise process consisting of eight consecutive phases where each of these phases produces a specified set of architectural deliverables. This iterative process is titled as TOGAF architecture development method (ADM) and implies describing the current state, defining the desired future state, analyzing the gaps between these states, developing a transition plan, executing the plan and then repeating the same process all over again. But what is the true origin of TOGAF ADM? Where did TOGAF really come from? What is TOGAF? 27 TOGAF: Just the Next Fad That Turned into a New Religion By Svyatoslav Kotusev (RMIT University) Introduction Currently the discourse in the enterprise architecture (EA) discipline largely revolves around The Open Group Architecture Framework (TOGAF).
    [Show full text]
  • IA-4 MGT-Part2.Pdf
    1 44.48 2 7.22 3 5.12 4 4.64 5 3.55 6 3.29 7 3.17 8 2.48 9 2.09 10 2.01 11 1.97 12 1.92 13 1.72 14 0.99 15 0.89 16 0.86 17 0.73 18 0.70 19 0.67 20 0.61 (Schekkerman, J., 2004 , p. 5), (www.enterprise-architecture.info) (Allega, P., 2004, p. 3) Lockheed Martin (Schekkerman, J., 2004 , p. 19) DuPont Bank Of America Fidelity Dow Chemical Motorola W.W. Grainger Procter & Gamble Cigna Toyota Motor USA Dow Jones T-Mobile Verizon (Allega, P., 2004, p. 2) (Koch, C., 2005 , p.2) Allega, P., 2004, p. 2) (Koch, C., 2005 , p. 5) Meta Group Gartner Group IBM TOGAF (FEAF) TEAF TAFIM (Schekkerman, J., 2004 , p. 25) Microsoft Ofice/Visio MDA RUP UML BPML (Schekkerman, J., 2004 , p. 5) Entity Relationship Information Process Reengineering Terminal Technology Driver Business Driver Gap Analysis Organizational Perspective Command, Control, Communications, Computers, Inteligence, C4ISR Surveillance and Reconnaissance(C4ISR) Architecture Framework Architecture Framework Technical Architecture Framework for Information Management TAFIM (TAFIM) Treasury Enterprise Architecture Framework(TEAF) TEAF The Open Group Architecture Framework(TOGAF) TOGAF Zachman Architecture Framework Federal Enterprise Architecture Framework(FEAF) Department of Defense Architecture Framework(DoDAF) DoDAF Domain Architecture Output, Architecture Deliverable Organizational View Strategy Event Business Process Modeling Language(BPML) Enterprise Organization Procedure Migration Plan Process Business Process Mainframe Business Strategic Layer Information Technology(IT) Layer Business
    [Show full text]
  • Enterprise Architecture Survey 2005 IFEAD
    Report of the Third Measurement Trends in Enterprise Architecture 2005 How are Organizations Progressing? Web-form Based Survey 2005 Report of the Third Measurement December 2005 Edition 1.0 J. Schekkerman 1 Trends in Enterprise Architecture 2005: How are Organizations Progressing? © Copyright Institute For Enterprise Architecture Developments, 2005 – All Rights Reserved Report of the Third Measurement © Copyright, Institute For Enterprise Architecture Developments (IFEAD), 2005 – All Rights Reserved. No part of this report may be reproduced or transmitted in any form or by any means, electronic, mechanical, including photocopying, recording, or by any information storage and retrieval system, without the express written permission of the copyright holder. For more information or questions about this survey, please contact: Institute For Enterprise Architecture Developments Att. J. Schekkerman President & Thought Leader Suikerpeergaarde 4 3824BC Amersfoort The Netherlands jschekkerman@enterprise-architecture.info http://www.enterprise-architecture.info 2 Trends in Enterprise Architecture 2005: How are Organizations Progressing? © Copyright Institute For Enterprise Architecture Developments, 2005 – All Rights Reserved Report of the Third Measurement Content 1 Introduction ................................................................................................... 4 2 The Enterprise Architecture Survey 2005 - Study ........................................... 5 2.1 Enterprise Architecture Activity Ranking..........................................................
    [Show full text]
  • Edward S. Ageno School of Business Operations and Information Technology Management Department ITM342-Enterprise Architecture Pl
    GOLDEN GATE UNIVERSITY Edward S. Ageno School of Business Operations and Information Technology Management Department ITM342-Enterprise Architecture Planning (3 units) SPRING/2009 - Sections SF1, C1 Instructor: Dr. Miro Costa, Ph.D. Office: Room 4325 Phone: (415) 442-6500 (Department) Fax: (415) 442-6579 E-mail: mcosta@ggu.edu Web Page: http://courses.ggu.edu/~mcosta / Surface Address: Golden Gate University Operations and Information Technology Management Department School of Business 536 Mission Street, Office# 4325 San Francisco, CA 94105-2968 Room: TBA (San Francisco), and in Cybercampus Days: Wednesday 4:00pm-6:40pm Starts: Spring/2009 – January/07/2009 Ends: Spring/2009 – April/28/2009 Time: TBA + (8 to 12 hours of work per week outside class). Office hours: TBA in my SF office or by appointment. Take advantage of phone, fax and email. 1. Catalog Description: ITM342-Enterprise Architecture Planning (3 units) This course will examine the elements of enterprise architecture and how the IT leader links the business mission, strategy, and processes of an organization to its IT strategy . You will examine the different EA methodologies and approaches, and understand where the y fit into the IT function. Key linkages between business strategy, IT project portfolio management, and EA will be explored. Using case studies, you will learn how to apply the tenets of the EA discipline to define and chart the course of IT strategy to solve strategic business problems. Co-requisite: ITM 340- Managing Information Technology in the Business Enterprise 1 Updated in September/01/2008 GOLDEN GATE UNIVERSITY 2. Course Methodology: This course is a graduate (MS.
    [Show full text]
  • The Role of Architecting in Systems of Systems
    The Role of Architecting in Systems of Systems Peter Brook Dashwood Consulting Dashwood House, Manby Rd Malvern, Worcs WR14 3BB UK dashwoodbrook@aol.com ABSTRACT Architecture and architecting jointly lie at the heart of all activity to develop and operate Systems of Systems (SoS). This paper reviews this growing field in relation to complex systems generally, and then discusses those aspects which are specific to SoS, including the use of architectural frameworks. The aim is to lay some foundations for the talks which follow. 1.0 INTRODUCTION 1.1 Architecture and Architecting From the earliest times, mankind has used the practice of architecture to describe how it has designed and built its most important creations. For the last few millennia and until recent times, the subject was associated exclusively with large physical constructions – for example pyramids, public monuments, and religious, civic and private buildings. That meaning continues today, but as we have extended our capability to build more and more complex entities, the nature and scope of architecture has had to expand accordingly. The mid-20th Century saw the emergence of systems engineering as the all-embracing discipline, with architecting at its centre, for the design and building of a new class of more complex products and systems (e.g. cars, ships and aeroplanes) which incorporated software and digital control. In parallel, a range of similar tools and methods emerged for designing information systems, i.e. those comprising ‘just’ software running on computing platforms over networks. The growth in how architecting is understood and applied continues today and is accelerating rapidly as the technical, commercial, military and security communities learn how to grapple with the new 21st Century systems challenges characterised by ubiquitous computing and near-global connectivity.
    [Show full text]
  • Standards for Enterprise Architectures
    Journal of Communication and Computer 12 (2015) 49-56 doi: 10.17265/1548-7709/2015.02.002 D DAVID PUBLISHING Standards for Enterprise Architectures Alicia Valdez Menchaca1 , Griselda Cortes2, Sergio Castaneda2 and Alejandro Luna2 1. Research Center, Faculty of Engineering Mechanical and Electrical, University Autonomous of Coahuila 2. Academic Unit Computer Systems, Faculty of Engineering Mechanical and Electrical, University Autonomous of Coahuila Abstract: The manufacturing industry in Mexico has great potential for growth, especially small and medium enterprises (smes), with an area of opportunity for the integration of its key processes to information technology, through which you can provide information quickly and effectively to support strategic decision making. A methodology for the development of schemes that provide the foundation for the use of information in support of business strategy enterprise architecture is composed of partial architectures and data architecture / applications, business architecture and technology architecture. This paper presents an analysis of standards known in the scientific literature on enterprise architecture to develop a proposal for midsize companies. It also discusses open source tools for managing enterprise architecture. The results offer great expectations for sme’s to implement enterprise architectures in their processes this analysis is part of a research project that seeks to design and implement enterprise architectures in sme’s, the project is currently in analysis. Key words: Enterprise architecture, SME’s, key processes. 1. Introduction competitiveness of enterprises. This paper presents an analysis of the first three EA (enterprise architecture) is a methodology that mentioned frameworks for enterprise architectures, aims to provide companies a framework for the use of tools, and a design model for medium manufacturing information in business processes in ways that support enterprises.
    [Show full text]
  • Syen #019: News in the Field of Systems Engineering | Project Performance International 30/04/10 8:49 AM
    SyEN #019: News in the Field of Systems Engineering | Project Performance International 30/04/10 8:49 AM Project Performance International Systems Engineering Newsletter (SyEN) SyEN #019 - April 29, 2010 Brought to you by Project Performance International http://www.ppi-int.com/newsletter/SyEN-019.php Dear Colleague, SyEN is an independent free newsletter containing informative reading for the technical project professional, with scores of news and other items summarizing developments in the field, including related industry, month by month. This newsletter and a newsletter archive are also available at www.ppi-int.com. Systems engineering can be thought of as the problem-independent, and solution/technology-independent, principles and methods related to the successful engineering of systems, to meet stakeholder requirements and maximize value delivered to stakeholders in accordance with their values. If you are presently receiving this newsletter from an associate, you may receive the newsletter directly in future by signing up for this free service of PPI, using the form at www.ppi-int.com. If you do not wish to receive future SE eNewsletters, please reply to this e-mail with "Remove" in the subject line, from the same email address. Your removal will be confirmed, by email. We hope that you find this newsletter to be informative and useful. Please tell us what you think. Email to: contact@ppi-int.com. What's Inside: READ ALL A Quotation to Open On Featured Article A Method for the Determination of an Optimum Set of Verification Requirements ... READ MORE Systems Engineering News NASA Conducts Systems Engineering Student Competition Annual Systems Engineering Conference 2010 (ASEC10) - “Systems Engineering: Adding Value in Challenging Times” New! Online Library Exclusively for IIBA Members The StaMina Competition IT Systems Engineer Named Best U.S.
    [Show full text]
  • Dodaf Architecture Framework Version 2.02
    DoDAF Architecture Framework Version 2.02 Department of Defense Home DoDAF-DM2 WG DoDAF Journal DoD Meta Data Registry IDEAS Links Background The DoDAF Architecture Framework Version 2.02 Architecture Development Welcome to DoDAF Version 2.02! This is the official and current version for the Department of Defense Architecture Framework. Meta Model Version 2.02 Viewpoints & Models This is the current release of DoDAF as of August Presentation Techniques 2010. A PDF version of this website is produced Configuration Management periodically and can be downloaded here: DoDAF Overview 2.02.pdf Acronyms List and Glossary For a description of changes made to DoDAF/DM2 of Terms 2.01 to create DoDAF/DM2 2.02, download the Version Description Document here. Site Map DoDAF Conformance Archives DoD Components are expected to conform to DoDAF to the maximum extent possible in development of architectures within the Department. Conformance ensures that reuse of information, architecture artifacts, models, and viewpoints can be shared with common understanding. Conformance is expected in both the classified and unclassified communities, and further guidance will be forthcoming on specific processes and procedures for the classified architecture development efforts in the Department. DoDAF conformance is achieved when: The data in a described architecture is defined according to the DM2 concepts, associations, and attributes. The architectural data is capable of transfer in accordance with the PES. DoDAF Journal The DoDAF Journal is a community of interest based discussion board. The Journal includes descriptions of best practices, lessons learned, example views and DM2 datasets, DoDAF model templates, DoDAF meeting presentations, and tutorial materials, and reference documents.
    [Show full text]