Open Group Architecture Framework TOGAF™ Version 9 (eBook)
782 Seiten
van Haren Publishing (Verlag)
978-90-8753-599-5 (ISBN)
The Open Group Architecture Framework (TOGAF) is a framework – a detailed method and a set of supporting tools – for developing an enterprise architecture, developed by members of The Open Group Architecture Forum (www.opengroup.org/architecture). As a comprehensive, open method for enterprise architecture, TOGAF Version 9 complements, and can be used in conjunction with, other frameworks that are more focused on specific aspects of architecture or for vertical sectors such as Government, Defense, and Finance. TOGAF may be used freely by any organization wishing to develop an enterprise architecture for use within that organization (subject to the Conditions of Use). This book is divided into seven main parts :PART I (Introduction) This part provides a high-level introduction to the key concepts of enterprise architecture and in particular the TOGAF approach. It contains the definitions of terms used throughout TOGAF and release notes detailing the changes between this version and the previous version of TOGAF. PART II (Architecture Development Method) This is the core of TOGAF. It describes the TOGAF Architecture Development Method (ADM) – a step-by-step approach to developing an enterprise architecture. PART III (ADM Guidelines & Techniques) This part contains a collection of guidelines and techniques available for use in applying TOGAF and the TOGAF ADM. PART IV (Architecture Content Framework) This part describes the TOGAF content framework, including a structured metamodel for architectural artifacts, the use of re-usable architecture building blocks, and an overview of typical architecture deliverables. PART V (Enterprise Continuum & Tools) This part discusses appropriate taxonomies and tools to categorize and store the outputs of architecture activity within an enterprise. PART VI (TOGAF Reference Models) This part provides a selection of architectural reference models, which includes the TOGAF Foundation Architecture, and the Integrated Information Infrastructure Reference Model (III-RM). PART VII (Architecture Capability Framework) This part discusses the organization, processes, skills, roles, and responsibilities required to establish and operate an architecture function within an enterprise.
Part I: Introduction 38
Chapter 1: Introduction 40
1.1 Structure of the TOGAF Document 40
1.2 Executive Overview 42
Chapter 2: Core Concepts 46
2.1 What is TOGAF? 46
2.2 What is Architecture in the Context of TOGAF? 46
2.3 What Kind of Architecture Does TOGAF Deal With? 47
2.4 Architecture Development Method 47
2.5 Deliverables, Artifacts, and Building Blocks 48
2.6 Enterprise Continuum 50
2.7 Architecture Repository 51
2.8 Establishing and Maintaining an Enterprise Architecture Capability 53
2.9 Establishing the Architecture Capability as an Operational Entity 54
2.10 Using TOGAF with Other Frameworks 55
2.11 TOGAF Document Categorization Model 55
Chapter 3: Definitions 60
Chapter 4: Release Notes 78
4.1 What’s New in TOGAF 9? 78
4.2 The Benefits of TOGAF 9 80
4.3 Mapping of the TOGAF 8.1.1 Structure to TOGAF 9 81
4.4 Mapping of TOGAF 9 Structure to TOGAF 8.1.1 82
4.5 Using TOGAF 84
4.6 Why Join The Open Group? 85
Part II: Architecture Development Method (ADM) 86
Chapter 5: Introduction 88
5.1 ADM Overview 88
5.2 Architecture Development Cycle 90
5.3 Adapting the ADM 93
5.4 Architecture Governance 94
5.5 Scoping the Architecture 95
5.6 Architecture Integration 100
5.7 Summary 102
Chapter 6: Preliminary Phase 104
6.1 Objectives 105
6.2 Approach 105
6.3 Inputs 112
6.4 Steps 113
6.5 Outputs 116
Chapter 7: Phase A: Architecture Vision 118
7.1 Objectives 119
7.2 Approach 119
7.3 Inputs 121
7.4 Steps 122
7.5 Outputs 127
Chapter 8: Phase B: Business Architecture 130
8.1 Objectives 131
8.2 Approach 131
8.3 Inputs 135
8.4 Steps 137
8.5 Outputs 143
Chapter 9: Phase C: Information Systems Architectures 146
9.1 Objectives 147
9.2 Approach 147
9.3 Inputs 148
9.4 Steps 149
9.5 Outputs 149
Chapter 10: Phase C: Information Systems Architectures — Data Architecture 152
10.1 Objectives 152
10.2 Approach 152
10.3 Inputs 154
10.4 Steps 155
10.5 Outputs 162
Chapter 11: Phase C: Information Systems Architectures — Application Architecture 164
11.1 Objectives 164
11.2 Approach 164
11.3 Inputs 165
11.4 Steps 166
11.5 Outputs 173
Chapter 12: Phase D: Technology Architecture 174
12.1 Objectives 175
12.2 Approach 175
12.3 Inputs 176
12.4 Steps 177
12.5 Outputs 185
12.6 Postscript 185
Chapter 13: Phase E: Opportunities & Solutions
13.1 Objectives 187
13.2 Approach 187
13.3 Inputs 189
13.4 Steps 190
13.5 Outputs 203
Chapter 14: Phase F: Migration Planning 204
14.1 Objectives 205
14.2 Approach 205
14.3 Inputs 206
14.4 Steps 208
14.5 Outputs 220
Chapter 15: Phase G: Implementation Governance 222
15.1 Objectives 223
15.2 Approach 223
15.3 Inputs 224
15.4 Steps 225
15.5 Outputs 228
Chapter 16: Phase H: Architecture Change Management 230
16.1 Objectives 231
16.2 Approach 231
16.3 Inputs 235
16.4 Steps 237
16.5 Outputs 239
Chapter 17: ADM Architecture Requirements Management 240
17.1 Objectives 241
17.2 Approach 241
17.3 Inputs 242
17.4 Steps 243
17.5 Outputs 246
Part III: ADM Guidelines and Techniques 248
Chapter 18: Introduction 250
18.1 Guidelines for Adapting the ADM Process 250
18.2 Techniques for Architecture Development 250
Chapter 19: Applying Iteration to the ADM 252
19.1 Overview 252
19.2 Iteration Cycles 253
19.3 Two Styles of Architecture Definition 254
19.4 Mapping TOGAF Phases to Iteration Cycles 255
Chapter 20: Applying the ADM at Different Enterprise Levels 260
20.1 Overview 260
20.2 Classes of Architecture Engagement 261
20.3 Developing Architectures at Different Levels 264
20.4 ADM Cycle Approaches 264
Chapter 21: Security Architecture and the ADM 268
21.1 Overview 268
21.2 Introduction 268
21.3 Guidance on Security for the Architecture Domains 269
21.4 ADM Architecture Requirements Management 270
21.5 Preliminary Phase 271
21.6 Phase A: Architecture Vision 272
21.7 Phase B: Business Architecture 274
21.8 Phase C: Information Systems Architectures 277
21.9 Phase D: Technology Architecture 280
21.10 Phase E: Opportunities & Solutions
21.11 Phase F: Migration Planning 283
21.12 Phase G: Implementation Governance 283
21.13 Phase H: Architecture Change Management 284
21.14 References 285
Chapter 22: Using TOGAF to Define & Govern SOAs
22.1 Overview 286
22.2 Introduction 286
22.3 Business-Led SOA Community 287
22.4 Business- & Developer-Led SOA Communities
22.5 Complexities Arising from SOA 289
22.6 How Enterprise Architecture Supports SOA 290
22.7 SOA and TOGAF 291
22.8 Guidelines for Service Contract Definition 295
22.9 Content and Structure of a Service Contract 298
22.10 Service Contract Template 299
Chapter 23: Architecture Principles 302
23.1 Introduction 302
23.2 Characteristics of Architecture Principles 303
23.3 Components of Architecture Principles 303
23.4 Developing Architecture Principles 304
23.5 Applying Architecture Principles 305
23.6 Example Set of Architecture Principles 306
Chapter 24: Stakeholder Management 318
24.1 Introduction 318
24.2 Approach to Stakeholder Management 319
24.3 Steps in the Stakeholder Management Process 319
24.4 Template Stakeholder Map 323
Chapter 25: Architecture Patterns 330
25.1 Introduction 330
25.2 US Treasury Architecture Development Guidance (TADG) 334
25.3 IBM Patterns for e-Business 335
25.4 Some Pattern Resources 337
Chapter 26: Business Scenarios 338
26.1 Introduction 338
26.2 Benefits of Business Scenarios 339
26.3 Creating the Business Scenario 339
26.4 Contents of a Business Scenario 343
26.5 Contributions to the Business Scenario 345
26.6 Business Scenarios and the TOGAF ADM 345
26.7 Guidelines on Developing Business Scenarios 347
26.8 Guidelines on Business Scenario Documentation 349
26.9 Guidelines on Goals and Objectives 350
26.10 Summary 356
Chapter 27: Gap Analysis 358
27.1 Introduction 358
27.2 Suggested Steps 359
27.3 Example 359
Chapter 28: Migration Planning Techniques 362
28.1 Implementation Factor Assessment and Deduction Matrix 362
28.2 Consolidated Gaps, Solutions, and Dependencies Matrix 363
28.3 Architecture Definition Increments Table 363
28.4 Enterprise Architecture State Evolution Table 364
28.5 Business Value Assessment Technique 365
Chapter 29: Interoperability Requirements 366
29.1 Overview 366
29.2 Defining Interoperability 367
29.3 Enterprise Operating Model 368
29.4 Refining Interoperability 369
29.5 Determining Interoperability Requirements 370
29.6 Reconciling Interoperability Requirements with Potential Solutions 371
29.7 Summary 372
Chapter 30: Business Transformation Readiness Assessment 374
30.1 Introduction 374
30.2 Determine Readiness Factors 375
30.3 Present Readiness Factors 377
30.4 Assess Readiness Factors 378
30.5 Readiness and Migration Planning 381
30.6 Marketing the Implementation Plan 381
30.7 Conclusion 382
Chapter 31: Risk Management 384
31.1 Introduction 384
31.2 Risk Classification 385
31.3 Risk Identification 385
31.4 Initial Risk Assessment 386
31.5 Risk Mitigation and Residual Risk Assessment 387
31.6 Conduct Residual Risk Assessment 387
31.7 Risk Monitoring and Governance (Phase G) 388
31.8 Summary 388
Chapter 32: Capability-Based Planning 390
32.1 Overview 390
32.2 Capability-Based Planning Paradigm 391
32.3 Concept of Capability-Based Planning 391
32.4 Capabilities in an Enterprise Architecture Context 394
32.5 Summary 395
Part IV: Architecture Content Framework 396
Chapter 33: Introduction 398
Chapter 34: Content Metamodel 404
34.1 Overview 404
34.2 Content Metamodel Vision and Concepts 404
34.3 Content Metamodel in Detail 412
34.4 Content Metamodel Extensions 417
34.5 Content Metamodel Objects 430
34.6 Content Metamodel Attributes 433
34.7 Metamodel Relationships 443
Chapter 35: Architectural Artifacts 448
35.1 Basic Concepts 448
35.2 Developing Views in the ADM 451
35.3 Views, Tools, and Languages 453
35.4 Views and Viewpoints 453
35.5 Conclusions 455
35.6 Taxonomy of Architecture Viewpoints 456
35.7 Viewpoints in the Preliminary Phase 457
35.8 Viewpoints in Phase A 458
35.9 Viewpoints in Phase B 459
35.10 Viewpoints in the Phase C Data Architecture 465
35.11 Viewpoints in the Phase C Application Architecture 468
35.12 Viewpoints in Phase D 474
35.13 Viewpoints in Phase E 478
35.14 Viewpoints for Requirements Management 479
35.15 Developing a Business Architecture View 480
35.16 Developing an Enterprise Security View 482
35.17 Developing a Software Engineering View 486
35.18 Developing a System Engineering View 496
35.19 Developing a Communications Engineering View 502
35.20 Developing a Data Flow View 507
35.21 Developing an Enterprise Manageability View 512
35.22 Developing an Acquirer View 515
Chapter 36: Architecture Deliverables 518
36.1 Introduction 518
36.2 Deliverable Descriptions 519
Chapter 37: Building Blocks 536
37.1 Overview 536
37.2 Introduction to Building Blocks 536
37.3 Building Blocks and the ADM 539
37.4 Building Blocks Example 541
Part V: Enterprise Continuum and Tools 564
Chapter 38: Introduction 566
38.1 Introduction 566
38.2 Structure of Par t V 566
Chapter 39: Enterprise Continuum 568
39.1 Overview 568
39.2 Enterprise Continuum and Architecture Re-Use 568
39.3 Constituents of the Enterprise Continuum 569
39.4 Enterprise Continuum in Detail 570
39.5 Relationship between the Enterprise Continuum and TOGAF ADM 576
39.6 Enterprise Continuum and Your Organization 576
Chapter 40: Architecture Partitioning 580
40.1 Overview 580
40.2 Characteristics of Solutions 581
40.3 Characteristics of Architectures 581
40.4 Applying Classification to Create Partitioned Architectures 582
Chapter 41: Architecture Repository 596
41.1 Overview 596
41.2 Architecture Landscape 598
41.3 Reference Library 598
41.4 Standards Information Base 599
41.5 Governance Log 601
Chapter 42: Tools for Architecture Development 604
42.1 Overview 604
42.2 Issues in Tool Standardization 604
42.3 Evaluation Criteria and Guidelines 605
Part VI: TOGAF Reference Models 610
Chapter 43: Foundation Architecture: Technical Reference Model 612
43.1 Concepts 612
43.2 High-Level Breakdown 613
43.3 TRM in Detail 615
43.4 Application Platform — Taxonomy 621
43.5 Detailed Platform Taxonomy 627
Chapter 44: Integrated Information Infrastructure Reference Model 644
44.1 Basic Concepts 644
44.2 High-Level View 648
44.3 Detailed Taxonomy 652
Part VII: Architecture Capability Framework 664
Chapter 45: Introduction 666
45.1 Overview 666
45.2 Structure of Part VII 667
Chapter 46: Establishing an Architecture Capability 668
46.1 Overview 668
46.2 Phase A: Architecture Vision 669
46.3 Phase B: Business Architecture 670
46.4 Phase C: Information Systems Architecture — Data 671
46.5 Phase C: Information Systems Architecture — Application 671
46.6 Phase D: Technology Architecture 671
46.7 Phase E: Opportunities & Solutions
46.8 Phase F: Migration Planning 671
46.9 Phase G: Implementation Governance 672
46.10 Phase H: Architecture Change Management 672
46.11 Requirements Management 672
Chapter 47: Architecture Board 674
47.1 Role 674
47.2 Responsibilities 675
47.3 Setting Up the Architecture Board 676
47.4 Operation of the Architecture Board 677
Chapter 48: Architecture Compliance 682
48.1 Introduction 682
48.2 Terminology: The Meaning of Architecture Compliance 682
48.3 Architecture Compliance Reviews 684
48.4 Architecture Compliance Review Process 686
48.5 Architecture Compliance Review Checklists 690
48.6 Architecture Compliance Review Guidelines 702
Chapter 49: Architecture Contracts 704
49.1 Role 704
49.2 Contents 705
49.3 Relationship to Architecture Governance 707
Chapter 50: Architecture Governance 708
50.1 Introduction 708
50.2 Architecture Governance Framework 712
50.3 Architecture Governance in Practice 717
Chapter 51: Architecture Maturity Models 720
51.1 Overview 720
51.2 Background 721
51.3 US DoC ACMM Framework 722
51.4 Capability Maturity Models Integration (CMMI) 726
51.5 Conclusions 727
Chapter 52: Architecture Skills Framework 728
52.1 Introduction 728
52.2 Need for an Enterprise Architecture Skills Framework 728
52.3 Goals/Rationale 730
52.4 Enterprise Architecture Role and Skill Categories 731
52.5 Enterprise Architecture Role and Skill Definitions 733
52.6 Generic Role and Skills of the Enterprise Architect 737
52.7 Conclusions 741
Part VIII: Appendices 742
Appendix A: Glossary of Supplementary Definitions 744
Appendix B: Abbreviations 760
Index 766
Chapter 1: Introduction
The Open Group Architecture Framework (TOGAF) is a framework — a detailed method and a set of supporting tools — for developing an enterprise architecture. It may be used freely by any organization wishing to develop an enterprise architecture for use within that organization (see Section 4.5.1).
TOGAF is developed and maintained by members of The Open Group, working within the Architecture Forum (refer to www.opengroup.org/architecture). The original development of TOGAF Version 1 in 1995 was based on the Technical Architecture Framework for Information Management (TAFIM), developed by the US Department of Defense (DoD). The DoD gave The Open Group explicit permission and encouragement to create TOGAF by building on the TAFIM, which itself was the result of many years of development effort and many millions of dollars of US Government investment.
Starting from this sound foundation, the members of The Open Group Architecture Forum have developed successive versions of TOGAF and published each one on The Open Group public web site.
If you are new to the field of enterprise architecture and/or TOGAF, you are recommended to read the Executive Overview (refer to Section 1.2), where you will find answers to questions such as:
What is enterprise architecture?
Why do I need an enterprise architecture?
Why do I need TOGAF as a framework for enterprise architecture?
1.1 Structure of the TOGAF Document
The structure of the TOGAF documentation reflects the structure and content of an architecture capability within an enterprise, as shown in Figure 1-1.
Figure 1-1 Structure of the TOGAF Document
There are seven main parts to the TOGAF document:
| (Introduction) This part provides a high-level introduction to the key concepts of enterprise architecture and in particular the TOGAF approach. It contains the definitions of terms used throughout TOGAF and release notes detailing the changes between this version and the previous version of TOGAF. |
| (Architecture Development Method) This part is the core of TOGAF. It describes the TOGAF Architecture Development Method (ADM) — a step-by-step approach to developing an enterprise architecture. |
| (ADM Guidelines and Techniques) This part contains a collection of guidelines and techniques available for use in applying TOGAF and the TOGAF ADM. |
| (Architecture Content Framework) This part describes the TOGAF content framework, including a structured metamodel for architectural artifacts, the use of re-usable architecture building blocks, and an overview of typical architecture deliverables. |
| (Enterprise Continuum & Tools) This part discusses appropriate taxonomies and tools to categorize and store the outputs of architecture activity within an enterprise. |
| (TOGAF Reference Models) This part provides a selection of architectural reference models, which includes the TOGAF Foundation Architecture, and the Integrated Information Infrastructure Reference Model (III-RM). |
| (Architecture Capability Framework) This part discusses the organization, processes, skills, roles, and responsibilities required to establish and operate an architecture function within an enterprise. |
The intention of dividing the TOGAF specification into these independent parts is to allow for different areas of specialization to be considered in detail and potentially addressed in isolation. Although all parts work together as a whole, it is also feasible to select particular parts for adoption whilst excluding others. For example, an organization may wish to adopt the ADM process, but elect not to use any of the materials relating to architecture capability.
As an open framework, such use is encouraged, particularly in the following situations:
Organizations that are new to TOGAF and wish to incrementally adopt TOGAF concepts are expected to focus on particular parts of the specification for initial adoption, with other areas tabled for later consideration.
Organizations that have already deployed architecture frameworks may choose to merge these frameworks with aspects of the TOGAF specification.
1.2 Executive Overview
According to The Open Group Business Executive’s Guide to IT Architecture:1
“An effective enterprise architecture is critical to business survival and success and is the indispensable means to achieving competitive advantage through IT.”
This section provides an executive overview of enterprise architecture, the basic concepts of what it is (not just another name for IT Architecture), and why it is needed. It provides a summary of the benefits of establishing an enterprise architecture and adopting TOGAF to achieve that.
What is an enterprise? What is enterprise architecture?
TOGAF defines “enterprise” as any collection of organizations that has a common set of goals. For example, an enterprise could be a government agency, a whole corporation, a division of a corporation, a single department, or a chain of geographically distant organizations linked together by common ownership.
The term “enterprise” in the context of “enterprise architecture” can be used to denote both an entire enterprise — encompassing all of its information and technology services, processes, and infrastructure — and a specific domain within the enterprise. In both cases, the architecture crosses multiple systems, and multiple functional groups within the enterprise.
Confusion often arises from the evolving nature of the term “enterprise”. An extended enterprise nowadays frequently includes partners, suppliers, and customers. If the goal is to integrate an extended enterprise, then the enterprise comprises the partners, suppliers, and customers, as well as internal business units.
The business operating model concept is useful to determine the nature and scope of the enterprise architecture within an organization. Large corporations and government agencies may comprise multiple enterprises, and may develop and maintain a number of independent enterprise architectures to address each one. However, there is often much in common about the information systems in each enterprise, and there is usually great potential for gain in the use of a common architecture framework. For example, a common framework can provide a basis for the development of an Architecture Repository for the integration and re-use of models, designs, and baseline data.
Why do I need an enterprise architecture?
The purpose of enterprise architecture is to optimize across the enterprise the often fragmented legacy of processes (both manual and automated) into an integrated environment that is responsive to change and supportive of the delivery of the business strategy.
Today’s CEOs know that the effective management and exploitation of information through IT is a key factor to business success, and an indispensable means to achieving competitive advantage. An enterprise architecture addresses this need, by providing a strategic context for the evolution of the IT system in response to the constantly changing needs of the business environment.
Furthermore, a good enterprise architecture enables you to achieve the right balance between IT efficiency and business innovation. It allows individual business units to innovate safely in their pursuit of competitive advantage. At the same time, it ensures the needs of the organization for an integrated IT strategy are met, permitting the closest possible synergy across the extended enterprise.
The advantages that result from a good enterprise architecture bring important business benefits, which are clearly visible in the net profit or loss of a company or organization:
A more efficient IT operation:
— Lower software development, support, and maintenance costs
— Increased portability of applications
— Improved interoperability and easier system and network management
— Improved ability to address critical enterprise-wide issues like security
— Easier upgrade and exchange of system components
Better return on existing investment, reduced risk for future investment:
— Reduced complexity in IT infrastructure
— Maximum return on investment in existing IT infrastructure
— The flexibility to make, buy, or out-source IT solutions
— Reduced risk overall in new investment, and the costs of IT ownership
Faster, simpler, and cheaper procurement:
— Buying decisions are simpler, because the information governing procurement is readily available in a coherent plan.
— The procurement process is faster — maximizing procurement speed and flexibility without sacrificing architectural coherence.
— The ability to procure heterogeneous, multi-vendor open systems.
What specifically would prompt me to develop an enterprise architecture?
Typically, an enterprise...
| Erscheint lt. Verlag | 1.1.2015 |
|---|---|
| Reihe/Serie | TOGAF Series |
| Verlagsort | Hertogenbosch |
| Sprache | englisch |
| Themenwelt | Schulbuch / Wörterbuch ► Schulbuch / Allgemeinbildende Schulen |
| Mathematik / Informatik ► Informatik ► Programmiersprachen / -werkzeuge | |
| Mathematik / Informatik ► Informatik ► Software Entwicklung | |
| Mathematik / Informatik ► Informatik ► Theorie / Studium | |
| Sozialwissenschaften ► Pädagogik | |
| Technik ► Architektur | |
| Wirtschaft ► Betriebswirtschaft / Management ► Finanzierung | |
| Wirtschaft ► Betriebswirtschaft / Management ► Marketing / Vertrieb | |
| Wirtschaft ► Betriebswirtschaft / Management ► Personalwesen | |
| Wirtschaft ► Betriebswirtschaft / Management ► Planung / Organisation | |
| Wirtschaft ► Betriebswirtschaft / Management ► Projektmanagement | |
| Wirtschaft ► Betriebswirtschaft / Management ► Unternehmensführung / Management | |
| Schlagworte | Enterprise Architecture |
| ISBN-10 | 90-8753-599-6 / 9087535996 |
| ISBN-13 | 978-90-8753-599-5 / 9789087535995 |
| Haben Sie eine Frage zum Produkt? |
PDF (Adobe DRM)Größe: 11,7 MB
Kopierschutz: Adobe-DRM
Adobe-DRM ist ein Kopierschutz, der das eBook vor Mißbrauch schützen soll. Dabei wird das eBook bereits beim Download auf Ihre persönliche Adobe-ID autorisiert. Lesen können Sie das eBook dann nur auf den Geräten, welche ebenfalls auf Ihre Adobe-ID registriert sind.
Details zum Adobe-DRM
Dateiformat: PDF (Portable Document Format)
Mit einem festen Seitenlayout eignet sich die PDF besonders für Fachbücher mit Spalten, Tabellen und Abbildungen. Eine PDF kann auf fast allen Geräten angezeigt werden, ist aber für kleine Displays (Smartphone, eReader) nur eingeschränkt geeignet.
Systemvoraussetzungen:
PC/Mac: Mit einem PC oder Mac können Sie dieses eBook lesen. Sie benötigen eine
eReader: Dieses eBook kann mit (fast) allen eBook-Readern gelesen werden. Mit dem amazon-Kindle ist es aber nicht kompatibel.
Smartphone/Tablet: Egal ob Apple oder Android, dieses eBook können Sie lesen. Sie benötigen eine
Geräteliste und zusätzliche Hinweise
Buying eBooks from abroad
For tax law reasons we can sell eBooks just within Germany and Switzerland. Regrettably we cannot fulfill eBook-orders from other countries.
aus dem Bereich
