1. The Open Group Architecture Framework (TOGAF) 한국전산원 정보화 표준부 이헌중3

2. 차례 OpenGroup 개요 TOGAF 배경 TOGAF 구조 Architecture Development Method
Foundation Architecture
Resource Base 요약

3. The Open Group (TOG) 설립 1996년 X/Open과 OSF가 합병으로 탄생
Industry Standard Test & Certification
Global & Regional Conference
9 Forums for Members 활동
본사 : Woburn (MA,美)
지역사무소 : Reading (英)
Menlo Park (CA,美) / Washington DC (美)
동경 (日)
서울 (UNYSIS)
한국전산원은 Full Member로 가입 예정 조직

4. TOG의 목적과 주요활동
상호운용성과 전사적 통합을 위한 소비자 요구사항에 적합한 COTS 제품의 open markets을 촉진함
multi-vendor IT 솔루션 적용을 통한 시간, 비용, 위험성을 줄임
Interoperability, Potability, Scalability, Usability
주요활동
고객 요구사항 정의 및 업체 표준의 개발 및 적용
제품표준을 통한 산업표준의 통합 (예: UNIX, CORBA, LDAP)
제품의 적합성 시험 및 인증 (상표부여권)
Conference (연 4회의 Global Conference)
The Open Group is active in many fields of the IT industry
Theme of current conference is Security – also active in Management, Directory, IT Architecture, Platforms, Mobile Computing
Open Group의 목표는 다음의 3단계를 통하여 달성된다.
- 토론(a forum for discussion), 기반구축(building the infrastructure), 기반보급(populating the infrastructure)
목표 및 임무
개방형 시스템에 관련된 업체들의 정보시스템 제품들에 대해 표준화된 규격을 정의함으로써 소비자에게 선택의 폭을 넓게 해주는 것을 목표로 한다. 또한 현재의 개방 환경에 대한 기본형태를 일치시키기 위하여 standard Specification을 마련하고, 미래의 생산발전에 영향을 미치는 업체들의 요구를 어디에서든지 들을 수 있는 활동 무대를 제공한다.
Test & Certification
Industry 표준화와 바이어 Requirement에 의거
테스트 및 인증 프로그램 제작/배포
상표 사용권 부여: 예) UNIX, xOpen, WAP (The Open Group은 WAP Forum의 공식 인증 기관임)
Conference – Global & Regional
The Open Group Conference는 바이어, 공급자, 정부기관 및 연구소 /학술기관 등 Global IT Industry Leader들이 한 자리에 모여 시장 동향, 기술/상업적 주요 이슈, 솔루션의 상호호환성 및 표준화에 대해 함께 논의하고, 더 나아가 이를 Project by Project Base의 전략적 제휴로 발전시켜 나가는 등 멤버사들에게 Business Opportunity를 제공하는 Global Conference입니다. 年 4회 개최되는 Global Conference를 보완하기 위해서 年 25회 가량 Regional Conference를 개최합니다.

5. TOG Member & Program Group
Membership (220여개사)
Platinum(8개 Sponsorship), Gold, Silver
미주 50%, 유럽 25%, 기타 25%
바이어 그룹 및 공급자 그룹 구성
프로그램 그룹
Customer Council
Supplier Council
Architecture Forum
Mobile Management Forum
Real Time & Embedded Systems Forum
Server Platform Forum
Electronic Messaging Association Forum
Security & eCommerce Forum
Enterprise Management Forum
Directory Interoperability Forum
Quality of Service Task Force
Membership의 종류
Platinum Membership (Sponsorship) : The Open Group내의 Governing Board 멤버자격이 주어지며, 전반적인 의사결정에 참여할 수 있습니다. 현재 Compaq Computer, Hewlett-Packard, Hitachi, IBM, Motorola, Sun Microsystems, Fujitsu, Fujitsu Siemens Computers 等 8개 업체가 참여중입니다.
Gold Membership : Governing Board에는 참여할 수 없으나, Conference內의 각종 Program에서 Director로서 활동할 수 있습니다. 전반적인 의사결정에 참여할 수 있습니다
Silver Membership : 멤버쉽 종류에 따라 Program에서 멤버로서 활동할 수 있습니다
현재 8개의 Sponsorship 이외에도 Apple Computer, AT&T, Intel, Microsoft, Oracle, 美 Dept. of Defense, 英 Ministry of Defense, 英 Post Office, 스웨덴 Post Office, 日 철도기술연구소 等 세계적인 기업, 연구소 및 정부기관들이 회원사로 활동 중입니다. (현재 220여 업체 및 기관)
바이어 그룹 :
다양한 공급자 그룹을 직접 만나 공급자의 차세대 제품 개발에 직접 영향을 줌으로써 보다 Customized된 제품 구매 가능
IT 시장 동향을 빨리 파악하여 시장상황에 맞는 마케팅전략 수립가능
시너지 효과를 극대화시킬 수 있는 전략적 제휴 파트너쉽 구축 가능
IT 시장의 흐름을 주도하여 기업의 내재 가치 증대
신속한 신기술 관련정보를 입수하여 신규사업/투자의 중장기 전략 수립 기초 마련
공급자 그룹
다양한 바이어그룹과 주기적으로 만남으로써 비즈니스 기회, 전략적 제휴 파트너쉽 구축의 기회 마련
미래시장의 수요를 미리 파악함으로써 신제품 개발 기획단계부터 바이어와의 Feedback이 가능
시장의 주요 변화를 먼저 감지하여 기존제품을 바이어의 요구에 부합하는 방향으로 Update 가능
신기술 기반의 미래 상품군에 대한 정보를 미리 입수함으로써, 바이어의 Needs를 만족시킬 수 있는 차세대 제품 기획/생산 가능
The Open Group의 Member(120여 업체)는 미주지역 50%, 유럽지역 25%, 기타지역 25%로 나뉘어집니다.
The Open Group의 Member는 정부기관, 각종 연구소 및 IT 관련 세계 유수업체들이 참여중입니다. The Open Group Conference에 참여중인 바이어/공급자그룹의 총 IT Budget은 年間 500억불 규모 입니다.

6. Architecture Program The Open Group Architecture Framework (TOGAF)
정보기술 아키텍처(IT architecture)에 대한 공통된 프레임워크 및 개발방법
기술 및 도구에 중립적
Architecture 도구
Architecture Description Markup Language (ADML)
상호운용성(Interoperability)
“Building Blocks”의 제공

7. TOGAF의 시작 공식 요구사항 개발 1994 주요 사항 IT 산업계의 단일 통합된 Architectural Framework
a framework, not an architecture
The Open Group의 역할과 기술적 활동을 조직화하고 전달하기 위함
사용자의 동기로 시작됨
A framework - there was dialog prior to agreement on the requirement - ultimate need was architecture, but recognition that consensus architecture not feasible - so requirement was for a framework within which individual architectures could be developed to suit specific business needs.
More than any other program, customers feel ownership
Driver was requirement developed 2H94 by X/Open User Council, subsequently endorsed by OSF customers post merger (1H96)
Problem: Building real (=multi-vendor, heterogeneous) open systems too complex and costly - need help, else alternative is single-vendor solutions (=> standards conformance irrelevant, market leader dominates)
Two main aspects to solution:
A single, unifying framework - gives help in designing open systems architectures and procuring products that meet the open design
Need to understand The Open Group's role in large picture - how individual product standards, technologies, projects, etc.. relate to / help solve the overall problem

8. TOGAF 연혁
1994: Requirement
Proof of Need
1995: X/Open Architectural Framework - Version 1
Proof of Concept
1996: The Open Group Architectural Framework – TOGAF Version 2
Proof of Application
1997: TOGAF Version 3
Relevance to practical architectures (Building Blocks)
1998: TOGAF Version 4
TOGAF in Context - the Enterprise Continuum
Web-ification / ease of use
1999: TOGAF Version 5
Business Scenarios - architecture requirements
ADML
2000: TOGAF Version 6
Architecture views
IEEE architecture standards ( , 1471)
US DoD work (C4ISR Framework, C2STA)
Brief review of development to date:
2H94 requirement - demonstrated real need
hand-picked group of customer & vendor experts (Architecture Task Force)
first version of Framework published Dec 95, as X/Open A/F
deficiencies, but demonstrated proof of concept
many had doubted feasibility of a consensus arch f/w
Arch Task Force continued, embraced work of OSF community
second version published as TOGAF, builds on XAF, integrates arch. work of OSF community => stable, robust f/w
case studies of TOGAF used in significant projects for design and procurement of open system solution
vendor commitments to develop mappings to TOGAF from own product architectures
NCR / OCCA there already, IBM / Open Blueprint committed, discussions ongoing with other vendors
Next logical progression - build critical mass
greater relevance to specific architectural implementations
address key deficiencies

9. TOGAF 현황 영국 사회안전부등 주요 프로젝트 및 조달에서 사용 1994년 부터 TOGAF를 개발, 수정, 보완
현재 TOGAF Ver. 6.0, ADML Ver2.0
TOGAF (The OpenGroup Architecture Framework)
정보기술 아키텍처를 정의하기 위한 도구
TAFIM에 기반
아키텍처 개발 방법 지침, 기술참조모델, 표준 저장소
ADML (Architecture Description Markup Language)
MCC의 SSEP 프로젝트의 일부분으로 개발
ACME에 기반하며 XML을 이용하여 표현
총 4레벨로 구성되며 XML/XMI와 상호보완적인 관계
업계 공통 프레임워크로서 사용자/공급자의 성공적 collaboration이 이루어 지고 있음
Micro-electronics and Computing technology Consortium 의 Software and Systems Engineering Productivity
Consensus framework: many had doubted feasibility of consensus arch f/w
Fit for purpose : - as a framework -stable, robust - case studies of TOGAF used in significant projects / procurements
Demonstrating response : - a major success for the open systems process, - a real requirement, - properly stated, -responded to promptly(신속한) and effectively 사례
Department of Social Security (UK) : The UK Department of Social Security (DSS) is responsible for the development, maintenance and delivery of the United Kingdom's social security programme. It utilises the largest civilian computer operation in Europe. The DSS case study illustrates the use of TOGAF, both as the basis of a new architectural framework, and as a key tool in managing the outsourcing of service delivery, in that vendors and integrators were required to use TOGAF as the basis for their tenders, and to use it subsequently in the on-going management of the IT architecture. The use of TOGAF is explained in the DSS case study.
Litton PRC (US) : Litton PRC chose the TOGAF Architecture Development Method as a basis for its revamped internal Architecture Design Process. The Litton PRC case study (PDF) reviews the use of TOGAF within Litton PRC, and explains why TOGAF was chosen. Also, the JEDMICS case study illustrates the early stages of the Architecture Development Method in use on a specific project.
Ministry of Defence (UK) : The UK Ministry of Defence in its case study shows how the Architecture Development Methodology can be used to develop an organization-specific architectural framework, allowing independent operating divisions to develop their own architectures while ensuring that they share a common core operating environment.
National Health Service (UK) : The UK National Health Service is testing TOGAF for use as a standard framework for IT architectures. It is hoped to provide a formal case study in the near future, explaining the use of TOGAF in the NHS. In the interim, contact information can be found on the NHS IM&T web site.
NATO (Belgium) : NATO's ACEACCIS example illustrates the use of architecture views in architecture development.
Police IT Organization (UK) : The UK Police IT Organization (PITO) used TOGAF as the basis for the Technical Architecture for its National Strategy for Police Information Systems (NSPIS). The NSPIS case study includes a comprehensive approach to architecture views, and a methodology for ensuring interoperability between the building blocks of the final architecture.
Statskonsult (Norway) : Statskonsult is the Department of IT Planning & Co-ordination, in the Directorate for Public Management, within the Norwegian Government. It used parts of the TOGAF.

10. TOGAF 구조 아키텍처 개발방법 기본아키텍처 자원기반 Architecture Development Method
Foundation Architecture
자원기반
Resource Base
Target Architectures
Architecture Development Method
Technical Reference Model
(services taxonomy)
Standards Information Base
(standards)
Building Blocks Information Base
(architecture building blocks - future)
- Part 1 Introduction : 일반적인 ITA의 주요 사항과 TOGAF의 특별사항을 간략히 소개
- Part 2 Architecture Development Method : TOGAF의 핵심으로서 ITA 개발단계에 따라서 TOGAF Architecture Development Method를 설명
- Part 3 Foundation Architecture : TOGAF Foundation Architecture, Technical Reference Model, Standard Information Base
- Part 4 Resources : Tool & Techniques
TOGAF Foundation Architecture
Resource Base

11. TOGAF FAQ 1. What is an architecture? And what is a framework?
2. Why do I need an IT architecture...?
3. ...And why a “Framework” for IT Architecture?
4. What is TOGAF?
5. What kind of "architecture" does TOGAF specifically deal with?
6. Who would benefit from using TOGAF?
7. What specifically does TOGAF contain?
8. Just how do you use TOGAF?
9. How much does TOGAF cost?
10. Since TOGAF is freely available, why join The Open Group?
- Preface(7) : Welcome, Structure, Navigation, Download
1. 다양한 Analogy(유추, 공통점)에 대한 기본적 개념(9)
- Another definition is that an architecture is the technical foundation for an effective IT strategy, which in turn is the core of any successful modern business strategy.
- An architectural framework is a tool which can be used for developing a broad range of different IT architectures. It should describe a method for designing an information system in terms of a set of building blocks, and for showing how the building blocks fit together. It should contain a set of tools and provide a common vocabulary. It should also include a list of recommended standards and compliant products which can be used to implement the building blocks.
2. 10-Minute Guide (16)

12. ITA 업무실무자 Guide What is an IT Architecture? Why do I need it?
Have you thought about your need for an IT Architecture? This Guide explains:
What is an IT Architecture?
Why do I need it?
What are the specific business benefits?
What is TOGAF?
How does TOGAF help deliver an effective IT Architecture?
What Specifically Does TOGAF Contain...?
How do I use TOGAF?
What Do I Get From Participating in The Open Group's Architecture Program?
What Are the Specific Business Benefits of Participation?
What action do I take now?
Have you thought about your need for an IT Architecture? This Guide explains:
What is an IT Architecture?
Why do I need it?
What are the specific business benefits?
What is TOGAF?
How does TOGAF help deliver an effective IT Architecture?
What Specifically Does TOGAF Contain...?
How do I use TOGAF?
What Do I Get From Participating in The Open Group's Architecture Program?
What Are the Specific Business Benefits of Participation?
What action do I take now?

13. 아키텍처 개발방법 : Architecture Development Method (ADM)
정보기술 아키텍처 개발 방법
실제 경험에 근거한 지침
빠른 기초작업이 가능
요구사항에 대한 지속적인 변화
A Initiation and Framework
G Architecture Maintenance
B Baseline Description
Requirements
C Target Architecture
F Implement-ation
- Design, Design Principle, Development Cycle
Introduction: 설계 원칙, 개발 주기
Phase A: Initiation and Framework: 요구사항 분석, 개발 개시
Phase B(28): Baseline Description: 관련 환경 분석
Phase C(30): Target Architecture: 목표 아키텍처 정의
(Index to) detailed steps of Phase C
Phase D(53): Opportunities and Solutions: 주 작업단위의 선택과 견적
Phase E(55): Migration Planning: 우선순위 결정, 대략적인 계획 수립
Phase F(57): Implementation: 전체 계획 수립과 실행
Phase G(59): Architecture Maintenance : 새로운 환경에 대한 유지보수
ADM Input and Output Descriptions(61): ADM의 모든 입출력물
- introduction, I/O per phase, I/O per step of phase C, I/O List & Description
Building Blocks and the ADM - Summary(69): 구축 단위와 연계
- Principles, Specification Process, Level of Modeling
D Opportunities and Solutions
E Migration Planning

14. Phases A through C Phase - Objective - Approach - Inputs - Steps
A – Initiation and Framework:
관련 업무 요구사항을 정의한 업무 시나리오를 사용
관련 사항 및 관련자를 확인
파트너와 합의 구축
B – Baseline Description
현재 시스템의 설명
문제점 분석
재사용 가능한 building blocks의 목록 정리
C –Target Architecture:
모든 요구 서비스 확인
관련자 및 관련사항에 대한 다양한 관점
(Relevant to all architecture developments)
A Initiation and Framework
G Architecture Maintenance
B Baseline Description
Requirements
C Target Architecture
F Implementation
시작 및 프레임워크 – 기준설정 – 목표 아키텍처 – 기회 및 해법 – 이전(전환)계획 – 시행 – 아키텍처 유지보수
Phase
- Objective
- Approach
- Inputs
- Steps
- Outputs
E Migration Planning
D Opportunities and Solutions

15. Phase C – Target Architecture (Steps)B
1 Create baseline
2 Consider views
3 Create arch. model
6 Determine criteria
4 Select services
5 Confirm bus. Objs.
7a Define architecture
7b Identify Arch. Building Blocks
8 Conduct gap analysis D

16. Phases D through G
D - Opportunities and Solutions:
주요 작업의 견적 및 선택
E - Migration Planning
작업 및 개략적개발계획의 우선순위 설정
F – Implementation
완전화 계획 수립 및 실행
G - Architecture Maintenance
새로운 Baseline의 유지보수를 위한 절차 수립
(Relevant when taking architecture through to implementation)
A Initiation and Framework
G Architecture Maintenance
B Baseline Description
Requirements
C Target Architecture
F Implementation
E Migration Planning
D Opportunities and Solutions

17. 기본 아키텍처 : Foundation Architecture
기본 아키텍처의 전후관계
Foundation Architecture in context
기술참조모델
Technical Reference Model
표준정보기반
Standards Information Base
PART III: Foundation Architecture (75)
Overview, Constituents, Future
- Introduction: 기본원칙, 구성요소
- Enterprise Continuum(84): Foundation Architecture 내용
- Technical Reference Model(86) : 분류 및 도해
- Standards Information Base(127): 산업 표준의 데이터베이스

18. 기본아키텍처의 전후관계 The “Enterprise Continuum”
Common
Systems
Architectures
Foundation
Architectures
Industry
Architectures
Organization
Architectures
Business Applications
Qualities
Architecture Continuum
guides & supports
guides & supports
guides & supports
guides & supports
- 아키텍처와 솔루션의 관계
Foundation Architecture - TOGAF
Common Systems Architecture – Security, Manageability, etc.
Industry Architecture - ARTS
Organization Architecture - Dairy Farm Group
- Target Architecture 설계 과정
Green : Target Architecture개발 과정으로의 입력, 사전에 적용
Yellow : TOGAF에서 프로세스로의 입력
White : Target Architecture개발 과정 내부의 입출력
Blue : Architecture 개발 주기의 다음 단계에 대한 출력
Gray : Target Architecture 개발 프로세스의 현 상태
Solutions Continuum
Products & Services
Systems
Solutions
Industry
Solutions
Organization Solutions

19. TOGAF : 개발 Flow Target Architecture 설계 과정 Green : 입력, 사전에 적용
Yellow : TOGAF에서 프로세스로의 입력
White : 개발 과정 내부의 입출력
Blue : Architecture 개발 주기의 다음 단계에 대한 출력
Gray : 개발 프로세스의 현 상태
- Target Architecture 설계 과정
Green : Target Architecture개발 과정으로의 입력, 사전에 적용
Yellow : TOGAF에서 프로세스로의 입력
White : Target Architecture개발 과정 내부의 입출력
Blue : Architecture 개발 주기의 다음 단계에 대한 출력
Gray : Target Architecture 개발 프로세스의 현 상태

20. 기본아키텍처 : 기술참조모델 (TRM) 서비스의 상세한 분류 시스템 차원의 능력을 판단 객체지향 프로비젼 서비스 품질
Qualities
Network Services
Operating System Services
Data Management
Location & Directory
Infrastructure
Applications
Business
Data Interchange
International Operations
User Interface
Transaction Processing
System & Network Management
Security
Software Engineering
Graphics & Image
Communication Infrastructure
Application Programming Interface
Communications Infrastructure Interface
서비스의 상세한 분류
각 서비스의 범위를 정의
시스템 차원의 능력을 판단
국 제화, 보안, 관리 등 12개
객체지향 프로비젼 서비스
ORB, Common object 품질
가용도, 확실성, 가용성, 적용성
The detailed Technical Reference Model presents the TRM entities and interfaces, including the service categories of the Platform and the sub-entities of the External Environment. The diagram neither implies nor inhibits relationships among the service categories.
The detailed TRM shows two different kinds of Platform Service category:
Categories on the front face have functionality that is self-contained, in that its proper implementation system-wide depends only on proper implementation of the services in that category. Functionality in these service categories delivers services for use by applications through an API.
Categories on the right hand face, orthogonal to the front face, relate to cross-category services. Services in these categories have functionality that requires consistent implementation in software from all other relevant service categories. Functionality in these service categories not only provides applications with services (through an API ), but gives the system some attributes which affect its behavior without necessarily being under direct application control.
TOGAF identifies a generic set of platform services. In a specific target architecture not all these services may be present, since the platform contains only the services needed to support the required functions. Also, a particular organization may need to augment these with services or service categories that are considered to be generic in its vertical market segment (e.g., “trouble-ticketing” services in a Telco-specific platform).
The set of services provided by the platform will change over time. As technology develops, the model will need to be extended to include new types of service and as application needs change.
As well as supporting application software through the API, services will support each other, either by architected interfaces which may or may not be the same as the API, or by private, unexposed interfaces. Such service modules should be capable of replacement by modules providing the same service functionality via the same service API. Use of private, unexposed interfaces among service modules may compromise this substitutability. These private interfaces represent a risk that should be highlighted to facilitate future transition.

21. 기본아키텍처: Standards Information Base (SIB)
개방형 산업 표준(open industry standards)의 DB
Open Group이 승인한 표준 집합
Open Group 합의절차에 의하여 내용을 결정
TOGAF TRM 분류에 의함
정기적 갱신
웹 access 제공
관련 resources와의 Link
The SIB lists all the standards and specifications recommended by The Open Group for use in open systems architectures.These comprise the current X/Open CAE Specifications, and relevant International standards adopted by The Open Group as having the same status as CAE Specifications. It also lists all the current X/Open branding definitions.
The tables are structured according to the service areas in the TRM and its taxonomy:
Data Interchange Services, Data Management Services, Distributed Computing Services, Graphics Services, Network Services, Object Management Services, Operating System Services, Software Engineering Services, Transaction Processing Services, User Interface Services, Internationalization Services, Security Services, System Management Services
There are hyperlinks from most entries in the SIB to details of the referenced specification or standard, held either on The Open Group web server (in the case of CAE Specs and branding definitions) or the web sites of other standards organizations (ISO, IETF, IEEE).

22. 표준제정현황 SIB는 2종류의 표준을 제공 OpenGroup Standard
Technical standard(77건), Product Standard(44건)
Adopted(320), Pending(5), Withdrawn(40)
Data Interchange Services (25-1-1), Data Management Services (10-0-0), Graphics and Imaging Services (8-1-0), International Operation Services (5-0-0), Location and Directory Services (22-0-6), Network Services ( ), Object-Oriented Provision (6-0-0), Operating System (32-1-1), Security (13-1-0), Software Engineering (24-1-1), System and Network Management (29-0-3), Transaction Processing (9-0-3), User Interface (20-0-1), Quality of Service (0)
OpenGroup Reference Standard

23. 자원기반 : Resource Base ADML Architecture Views Business Scenarios
(Architecture Description Markup-Language)
Architecture Views
Business Scenarios
(requirements method)
Case Studies
Building Block Example
IT Governance Strategies
PART IV: Resource Base (135)
- Architecture Description Markup Language (ADML): XML기반의 representation Language
- (Index to) Architecture Views(245): 아키텍처의 각 관점
- (Index to) Case Studies(276): 실 사례 Dairy Farm Group(홍콩), Department of Social Security(UK), Litton PRC(US), Ministry of Defence(UK), National Health Service(UK), NATO(Belgium), Police IT Organization(UK), Staskonsult(Norway)
- (Index to) Building Block Example(279): 가상의 구축 사례
- (Index to) Relating IT Architecture to the Organization(313):s
요구사항에 맞는 전략과 실행, 요구사항 도출방법 제시(조직 등)
- (Index to) Other Architectures / Frameworks(330):
다른 아키텍처 및 TOGAF와의 관계
(C4ISR, CORBA, DCE, ISO/IEC TR 14252, ISO RM-ODP, NCR EAF, SPRIT, TAFIM)
- Tools for Architecture Development(368): TOGAF 사용 도구 및 기술
- Setting Goals for Architecture Evolution(377)
- Glossary(381)

24. Architecture View
개발방법도 포함하고 있음

25. Building Block 종류 Building Block과 ADM
Architecture Building Block (ABB)
Solution Building Block (ABB)
Building Block과 ADM
Building Block Specification Process
Phase A, B, C(Step3-7), D
모델링 단계
Business Process (Phase A)
Technical functionality and constraints (Phase B)
Architectural Model (Phase C)
Solution Model
Example은 Opportunity Identification(PhaseD)와 Building Block Reuse(Phase E to F)가 있음
Building Blocks have generic characteristics as follows:
A Building Block is a package of functionality defined to meet the business needs across an organization A Building Block has published interfaces to access the functionality A Building Block may interoperate with other, interdependent, Building Blocks. A good Building Block has the following characteristics: It considers implementation and usage, and evolves to exploit technology and standards It may be assembled from other Building Blocks It may be a subassembly of other Building Blocks Ideally a Building Block is reusable and replaceable, and well specified A Building Block may have multiple implementations but with different interdependent Building Blocks
BBSP : 각 Phase간 순차적 순환이 가능하고 비즈니스 요구사항은 모든 단계에 적용됨
Modeling : 워터풀 모델처럼 되어 있음, 순차적으로 진행하되 피드백은 어느 단계로도 가능함

26. TOGAF Version 6의 새로운 점 The C4ISR / DoD Architecture Framework
IEEE Std 1471, Recommended Practice for Architectural Description
IEEE Std 1471의 개념과 용어에 맞춰 TOGAF Architecture Views를 확대개정
TOGAF Architecture Development Method에 통합
IEEE Std , Guide for Developing User Organization Open System Environment (OSE) Profiles
통합작업 시작
The C4ISR / DoD Architecture Framework
TOGAF와 비교 시작
소프트웨어 공학 관점
Component-based 개발의 지원을 목적
US Air Force Command & Control System Technical Architecture (C2STA) 작업에 기반
ADML (Architecture Description Mark-up Language) Version 1
새로운 ADML 웹사이트를 TOGAF와 연계

27. TOGAF Version 7의 계획 타 아키텍처/프레임워크와의 관계를 정리 TOGAF ADM 수정 아키텍처 평가
Zachmann Framework, Spewak (EAP),…
현재 아키텍처 시작의 로드맵
TOGAF ADM 수정
아키텍처와 설계간의 요구수준(desired line) 확인
총괄적인 조직 특성의 ADM 개발
아키텍처 평가
분석 및 평가 관점의 방법론
IEEE Stds , 1471 통합 완료
DoD/DISA recommendations
ADM : 의사전달 중심의 서술작업
TOGAF의 아키텍처들과 다른 Open Group 프로그램과의 통합
Security, Management, Mobile, Directory

28. 2001 프로젝트 계획 TOGAF Executive Overview - 3rd Edition
TABB (Technical Architecture Builder/Browser)
ADML 적용
Open-source development program
TOGAF 인증
Architects, Training / Consultancy services
TOGAF, SIB를 E.C.에 제시/촉진
Europe-wide framework for enterprise architecture
TOGAF, SIB를 U.S government에 제시/촉진
U.S. government departments affected by Clinger-Cohen (Public Law )

29. 결론 국내 활용 방안 The Open Group Architecture Program: TOGAF의 개발 및 전개
아키텍처 도구 및 서비스의 형상화
A worldwide forum
다양한 관련자의 참여 및 정보공유
공동작업 참여
국내 활용 방안
표준화된 아키텍처
국내 아키텍처 활성화의 도구로 활용
지속적인 자료 검토 및 활용방안 토의
The Open Group Architecture Program:
TOGAF의 개발 및 전개
A worldwide forum
for customers, tools vendors, solution vendors, integrators, and academic & research organizations involved with architecture
Exchanging information, experience, and requirements
Access to current work in progress
Shaping the market for architecture tools and services
표준화된 아키텍처
국제적 논의기구, 국제 표준의 수용, 표준화된 COTS의 활용

30. 참고 SITE Architecture 포털 사이트: TOGAF 문서: TOGAF 관련 정보:
TOGAF 문서:
TOGAF 관련 정보:
Standards Information Base (SIB):