Enterprise Architecture

An overview
Contents

1 Introduction 1
1.1 Enterprise architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.1.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.1.2 Topics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.1.3 Benets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1.4 Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1.5 Relationship to other disciplines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1.6 Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1.7 Criticism . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1.8 See also . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1.9 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1.10 External links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2 Enterprise Architect 7
2.1 Enterprise architect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1.1 Role . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1.2 Responsibilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1.3 Skills and knowledge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1.4 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.1.5 External links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

3 Enterprise Architecture 9
3.1 Enterprise Architecture Assessment Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.1.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.1.2 Performance Improvement Lifecycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.1.3 See also . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.1.4 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.1.5 External links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.2 Enterprise architecture planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.2.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.2.2 EAP topics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.2.3 Criticism . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.2.4 See also . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

i
ii CONTENTS

3.2.5 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.2.6 Further reading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.3 Enterprise Architecture Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.3.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.3.2 Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.3.3 See also . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.3.4 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.3.5 External links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.4 Architecture Patterns ( EA Reference Architecture) . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.4.1 Denition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.4.2 Architectural style . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.4.3 Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.4.4 See also . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.4.5 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.4.6 Bibliography . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

4 Frameworks 15
4.1 Enterprise Architecture framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.1.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.1.2 History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.1.3 EA framework topics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.1.4 Components of enterprise architecture framework . . . . . . . . . . . . . . . . . . . . . . 18
4.1.5 Types of enterprise architecture framework . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.1.6 Criticism . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.1.7 See also . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.1.8 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.1.9 External links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

5 Open Source or Consortia-developed frameworks 23

5.1 Enterprise Architecture Body of Knowledge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
5.1.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
5.1.2 Perspective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
5.1.3 See also . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
5.1.4 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
5.1.5 External links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
5.2 Generalised Enterprise Reference Architecture and Methodology . . . . . . . . . . . . . . . . . . 24
5.2.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
5.2.2 History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
5.2.3 Topics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
5.2.4 See also . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
5.2.5 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
5.2.6 Further reading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
CONTENTS iii

5.2.7 External links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

5.3 IDEAS Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
5.3.1 The Need for Architecture Interoperability . . . . . . . . . . . . . . . . . . . . . . . . . . 30
5.3.2 Military Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
5.3.3 Ontology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
5.3.4 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
5.3.5 IDEAS Publications & Presentations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
5.3.6 Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
5.3.7 External links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
5.4 RM-ODP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
5.4.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
5.4.2 History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
5.4.3 RM-ODP topics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
5.4.4 RM-ODP and UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
5.4.5 Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
5.4.6 See also . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
5.4.7 Notes and references . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
5.4.8 External links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
5.5 The Open Group Architecture Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
5.5.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
5.5.2 TOGAF pillars . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
5.5.3 TOGAF culture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
5.5.4 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
5.5.5 External links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

6 Commercial frameworks 39
6.1 Integrated Architecture Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
6.1.1 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
6.2 OBASHI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
6.2.1 Core Principle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
6.2.2 The Origins of OBASHI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
6.2.3 Characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
6.2.4 Fields of use . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
6.2.5 See also . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
6.2.6 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
6.2.7 External links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
6.3 Information Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
6.3.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
6.3.2 Industry Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
6.3.3 Banking and nancial markets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
6.3.4 Insurance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
6.3.5 Other industries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
iv CONTENTS

6.3.6 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
6.3.7 Further reading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
6.4 Zachman Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
6.4.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
6.4.2 History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
6.4.3 Zachman Framework topics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
6.4.4 Applications and inuences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
6.4.5 Criticism . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
6.4.6 See also . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
6.4.7 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
6.4.8 External links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

7 Defense industry frameworks 57

7.1 Department of Defense Architecture Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
7.1.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
7.1.2 History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
7.1.3 Capabilities and mission . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
7.1.4 Version 1.5 views . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
7.1.5 Version 2.0 viewpoints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
7.1.6 Creating an integrated architecture using DoDAF . . . . . . . . . . . . . . . . . . . . . . 64
7.1.7 Representation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
7.1.8 Meta-model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
7.1.9 Relationship to other architecture frameworks . . . . . . . . . . . . . . . . . . . . . . . . 67
7.1.10 Criticism . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
7.1.11 See also . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
7.1.12 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
7.1.13 Further reading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
7.1.14 External links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
7.2 MODAF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
7.2.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
7.2.2 History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
7.2.3 Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
7.2.4 Functionality of Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
7.2.5 Harmonisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
7.2.6 Tools and Tooling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
7.2.7 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
7.2.8 Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
7.2.9 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
7.2.10 External links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
7.3 NATO Architecture Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
7.3.1 NAF Meta-Model (NMM) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
7.3.2 Using the UK Ministry of Defences MODAF Documentation for NAF Work . . . . . . . 71
CONTENTS v

7.3.3 External links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

7.3.4 See also . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
7.4 AGATE Architecture Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
7.4.1 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
7.4.2 AGATE Views . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
7.4.3 Representation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
7.4.4 History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
7.4.5 See also . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
7.4.6 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
7.4.7 External links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

8 Government frameworks 73
8.1 Government Enterprise Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
8.1.1 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
8.1.2 History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
8.1.3 See also . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
8.1.4 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
8.1.5 External links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
8.2 FDIC Enterprise Architecture Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
8.2.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
8.2.2 History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
8.2.3 EA framework topics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
8.2.4 See also . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
8.2.5 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
8.2.6 Further reading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
8.2.7 External links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
8.3 Federal Enterprise Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
8.3.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
8.3.2 History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
8.3.3 Collaborative planning methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
8.3.4 Version 2 reference models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
8.3.5 Version 1 reference models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
8.3.6 Architecture levels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
8.3.7 Program results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
8.3.8 See also . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
8.3.9 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
8.3.10 External links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
8.4 NIST Enterprise Architecture Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
8.4.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
8.4.2 History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
8.4.3 NIST Enterprise Architecture Model topics . . . . . . . . . . . . . . . . . . . . . . . . . 85
8.4.4 Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
vi CONTENTS

8.4.5 See also . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

8.4.6 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
8.4.7 External links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
8.5 Treasury Enterprise Architecture Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
8.5.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
8.5.2 History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
8.5.3 TEAF Topics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
8.5.4 See also . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
8.5.5 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
8.5.6 External links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

9 Lifecycles 92
9.1 Enterprise life cycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
9.1.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
9.1.2 Enterprise life cycle topics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
9.1.3 See also . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
9.1.4 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
9.1.5 Further reading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
9.1.6 External links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
9.2 ISO 12207 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
9.2.1 History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
9.2.2 Primary lifecycle processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
9.2.3 Activities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
9.2.4 Deliverables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
9.2.5 Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
9.2.6 See also . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
9.2.7 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
9.3 Systems Development Life Cycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
9.3.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
9.3.2 History and details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
9.3.3 Phases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
9.3.4 Systems analysis and design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
9.3.5 Object-oriented analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
9.3.6 Life cycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
9.3.7 Strengths and weaknesses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
9.3.8 See also . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
9.3.9 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
9.3.10 Further reading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
9.3.11 External links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
9.4 Technology Life Cycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
9.4.1 The four phases of the technology life-cycle . . . . . . . . . . . . . . . . . . . . . . . . . 105
9.4.2 Technology perception dynamics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
CONTENTS vii

9.4.3 Licensing options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106

9.4.4 Technology development cycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
9.4.5 See also . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
9.4.6 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
9.5 Whole-life cost . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
9.5.1 Financial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
9.5.2 Environmental and social . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
9.5.3 Whole-life cost topics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
9.5.4 IT industry usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
9.5.5 Automobile industry, nances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
9.5.6 See also . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
9.5.7 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
9.5.8 Further reading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
9.5.9 External links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110

10 Modelling 111
10.1 Enterprise modelling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
10.1.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
10.1.2 History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
10.1.3 Enterprise modelling basics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
10.1.4 Enterprise modelling techniques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
10.1.5 Enterprise engineering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
10.1.6 Related elds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
10.1.7 See also . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
10.1.8 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
10.1.9 Further reading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
10.1.10 External links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117

11 Collaboration 118
11.1 Business analyst . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
11.1.1 Areas of business analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
11.1.2 Typical deliverables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
11.1.3 Industries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
11.1.4 See also . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
11.1.5 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
11.2 Systems analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
11.2.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
11.2.2 Information technology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
11.2.3 Policy analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
11.2.4 Practitioners . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
11.2.5 See also . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
11.2.6 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
viii CONTENTS

11.2.7 Selected publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120

11.2.8 External links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
11.3 Information architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
11.3.1 Denition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
11.3.2 Information architect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
11.3.3 Notable people in information architecture . . . . . . . . . . . . . . . . . . . . . . . . . . 121
11.3.4 See also . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
11.3.5 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
11.3.6 Bibliography . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
11.3.7 Further reading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
11.4 Solutions Architect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
11.4.1 Overview of the role . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
11.4.2 Solution architects vs. enterprise architects . . . . . . . . . . . . . . . . . . . . . . . . . . 123
11.4.3 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
11.5 Software architect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
11.5.1 History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
11.5.2 Responsibilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
11.5.3 Duties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
11.5.4 Other types of IT-related architects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
11.5.5 See also . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
11.5.6 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
11.5.7 External links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
11.6 Systems architect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
11.6.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
11.6.2 Systems architect: topics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
11.6.3 Architect metaphor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
11.6.4 See also . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
11.6.5 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
11.6.6 Further reading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
11.6.7 External links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
11.7 Project manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
11.7.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
11.7.2 Project Management Key Topics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
11.7.3 Types of Project Managers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
11.7.4 Responsibilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
11.7.5 Education and Certications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
11.7.6 See also . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
11.7.7 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
11.7.8 Further reading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
11.8 Project management oce . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
11.8.1 Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
CONTENTS ix

11.8.2 Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132

11.8.3 Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
11.8.4 See also . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
11.8.5 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
11.9 Chief information ocer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
11.9.1 The need for CIOs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
11.9.2 Roles and responsibilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
11.9.3 Risks involved . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
11.9.4 Information technology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
11.9.5 Distinction between CIO, CDO and CTO . . . . . . . . . . . . . . . . . . . . . . . . . . 134
11.9.6 See also . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
11.9.7 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
11.9.8 External links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135

12 Text and image sources, contributors, and licenses 136

12.1 Text . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
12.2 Images . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
12.3 Content license . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
Chapter 1

Introduction

1.1 Enterprise architecture enterprise architecture as a practice, which

Enterprise architecture (EA) is a well-dened prac- analyzes areas of common activity within or
tice for conducting enterprise analysis, design, planning, between organizations, where information and
and implementation, using a holistic approach at all times, other resources are exchanged to guide future
for the successful development and execution of strat- states from an integrated viewpoint of strategy,
egy. Enterprise architecture applies architecture princi- business, and technology.[5]
ples and practices to guide organizations through the busi-
ness, information, process, and technology changes nec- IT analysis rm Gartner denes the term as a discipline
essary to execute their strategies. These practices utilize where an enterprise is led through change. According to
the various aspects of an enterprise to identify, motivate, their glossary,
and achieve these changes.[1]
Practitioners of enterprise architecture, enterprise archi- Enterprise architecture (EA) is a discipline
tects, are responsible for performing the analysis of busi- for proactively and holistically leading enter-
ness structure and processes and are often called upon to prise responses to disruptive forces by identi-
draw conclusions from the information collected to ad- fying and analyzing the execution of change
dress the goals of enterprise architecture: eectiveness, toward desired business vision and outcomes.
eciency, agility, and durability.[2] EA delivers value by presenting business and
IT leaders with signature-ready recommenda-
tions for adjusting policies and projects to
1.1.1 Overview achieve target business outcomes that capital-
ize on relevant business disruptions. EA is used
In the enterprise architecture literature and community, to steer decision making toward the evolution
there are various perspectives in regards to the meaning of the future state architecture.[6]
of the term enterprise architecture. As of 2012, no ocial
denition exists; rather, various organizations (public and
Each of the denitions above underplays the historical
private) promote their understanding of the term. Conse-
reality that enterprise architecture emerged from meth-
quently, the enterprise architecture literature oers many
ods for documenting and planning information systems
denitions for the term enterprise architecture; some of
architectures, and the current reality that most enterprise
which are complementary, others are nuances, and others
architecture practitioners report to a CIO or other IT de-
yet are in opposition.[3]
partment manager. In a business organization structure
The MIT Center for Information Systems Research (MIT today, the enterprise architecture team performs an ongo-
CISR) in 2007 dened enterprise architecture as the spe- ing business function that helps business and IT managers
cic aspects of a business that are under examination: to gure out the best strategies to support and enable busi-
ness development and business change in relation to the
Enterprise architecture is the organizing logic business information systems that the business depends
for business processes and IT infrastructure re- on.
ecting the integration and standardization re-
quirements of the companys operating model.
The operating model is the desired state of busi- 1.1.2 Topics
ness process integration and business process
standardization for delivering goods and ser- The terms enterprise and architecture
vices to customers.[4]
The term enterprise can be dened as describing an
The Enterprise Architecture Body of Knowledge denes organizational unit, organization, or collection of organi-

1
2 CHAPTER 1. INTRODUCTION

zations that share a set of common goals and collaborate Architectural description of an enterprise
to provide specic products or services to customers.[7]
[9]
In that sense, the term enterprise covers various types According to the standard ISO/IEC/IEEE 42010, the
of organizations, regardless of their size, ownership product used to describe the architecture of a system is
model, operational model, or geographical distribution. called an architectural description. In practice, an archi-
It includes those organizations complete socio-technical tectural description contains a variety of lists, tables, and
systems,[8] including people, information, processes, and diagrams. These are models known as views. In the case
technologies. of Enterprise Architecture, these models describe the
logical business functions or capabilities, business pro-
The term architecture refers to fundamental concepts or cesses, human roles and actors, the physical organization
properties of a system in its environment, embodied in its structure, data ows and data stores, business applica-
elements, relationships, and in the principles of its design tions and platform applications, hardware, and commu-
and evolution.[9] nications infrastructure.
Understood as a socio-technical system, the term enter- The UK National Computing Centre EA best practice
prise denes the scope of the enterprise architecture. guidance[11] states:

Normally an EA takes the form of a com-

Scopes prehensive set of cohesive models that describe
the structure and functions of an enterprise.
Perspectives, or beliefs, held by enterprise architecture The individual models in an EA are arranged
practitioners and scholars, with regards to the meaning in a logical manner that provides an ever-
of the enterprise architecture, typically gravitate towards increasing level of detail about the enterprise.
one or a hybrid of three schools of thought:[10]
The architecture of an enterprise is described with a view
to improving the manageability, eectiveness, eciency,
1. Enterprise IT design the purpose of EA is the
or agility of the business, and ensuring that money spent
greater alignment between IT and business con-
on information technology (IT) is justied.
cerns. The main purpose of enterprise architecture
is to guide the process of planning and designing the Paramount to changing the enterprise architecture is the
IT/IS capabilities of an enterprise in order to meet identication of a sponsor. His/her mission, vision, and
desired organizational objectives. Typically, archi- strategy, and the governance framework dene all roles,
tecture proposals and decisions are limited to the responsibilities, and relationships involved in the antici-
IT/IS aspects of the enterprise; other aspects only pated transformation. Changes considered by enterprise
serve as inputs. architects typically include:

2. Enterprise integrating According to this school of
thought, the purpose of EA is to achieve greater
coherency between the various concerns of an en-
terprise (HR, IT, Operations, etc.) including the
linking between strategy formulation and execution.
Typically, architecture proposals and decisions en-
compass all the aspects of the enterprise.
innovations in the structure or processes of an orga-
nization
innovations in the use of information systems or
technologies
the integration and/or standardization of business
processes, and

3. Enterprise ecological adaptation the purpose of improving the quality and timeliness of business in-
EA is to foster and maintain the learning capabil- formation.
ities of enterprises so that they may be sustainable.
Consequently, a great deal of emphasis is put on im-
A methodology for developing and using architecture to
proving the capabilities of the enterprise to improve
guide the transformation of a business from a baseline
itself, to innovate and to coevolve with its environ-
state to a target state, sometimes through several transi-
ment. Typically, proposals and decisions encompass
tion states, is usually known as an enterprise architecture
both the enterprise and its environment.
framework. A framework provides a structured collec-
tion of processes, techniques, artifact descriptions, refer-
Ones belief with regards to the meaning of enterprise ar- ence models and guidance for the production and use of
chitecture will impact how one sees its purpose, its scope, an enterprise-specic architecture description.
the means of achieving it, the skills needed to conduct it, See also: architecture domain
and the locus of responsibility for conducting it[10]
1.1. ENTERPRISE ARCHITECTURE 3

1.1.3 Benets IT risk management - Enterprise architecture con-

The benets of enterprise architecture are achieved
through its direct and indirect contributions to organi-
zational goals. It has been found that the most notable
benets of enterprise architecture can be observed in the
following areas:[12]
tributes to the reduction of business risks from sys-
tem failures and security breaches. Enterprise archi-
tecture helps reduce risks of project delivery.[18][22]
1.1.4 Examples

Organizational design - Enterprise architecture pro- Documenting the architecture of enterprises is done
vides support in the areas related to design and re- within the U.S. Federal Government[23] in the context of
design of the organizational structures during merg- the Capital Planning and Investment Control (CPIC) pro-
ers, acquisitions or during general organizational cess.
change.[13][14][15][16] The Federal Enterprise Architecture (FEA) reference
Organizational processes and process standards - model guides [24] federal agencies in the development of their
Enterprise architecture helps enforce discipline and architectures.
standardization of business processes, and enable Companies such as Independence Blue Cross, Intel,
process consolidation, reuse, and integration.[17][18] Volkswagen AG[25] and InterContinental Hotels Group
use enterprise architecture to improve their business ar-
Project portfolio management - Enterprise architec-
chitectures as well as to improve business performance
ture supports investment decision-making and work
and productivity.
prioritization.[14][15]
For various understandable reasons, commercial organi-
Project management - Enterprise architecture en- zations rarely publish substantial enterprise architecture
hances the collaboration and communication be- descriptions. However, government agencies have begun
tween project stakeholders. Enterprise architec- to publish architectural descriptions they have developed.
ture contributes to ecient project scoping, and Examples include:
to dening more complete and consistent project
deliverables.[16][17]
US Department of the Interior
Requirements Engineering - Enterprise architec-
ture increases the speed of requirement elicita- US Department of Defense Business Enterprise
tion and the accuracy of requirement denitions, Architecture,[26] or the 2008 BEAv5.0 version
through publishing of the enterprise architecture
documentation.[19] Treasury Enterprise Architecture Framework

System development - Enterprise architecture con-

tributes to optimal system designs and ecient re- 1.1.5 Relationship to other disciplines
source allocation during system development and
testing.[14][15]
IT management and decision making - Enterprise
architecture is found to help enforce discipline and
standardization of IT planning activities and to con-
tribute to a reduction in time for technology-related
decision making.[15][18]
IT value - Enterprise architecture helps reduce the
systems implementation and operational costs, and
minimize replication of IT infrastructure services
across business units.[18][20]
IT complexity - Enterprise architecture contributes
to a reduction in IT complexity, consolidation of
data and applications, and to better interoperability
of the systems. [17][18][20]
IT openness - Enterprise architecture contributes to
more open and responsive IT as reected through in-
creased accessibility of data for regulatory compli-
ance, and increased transparency of infrastructure
changes.[18][21]
According to the Federation of EA Professional Organi-
zations (FEAPO), Enterprise Architecture interacts with
a wide array of other disciplines commonly found in busi-
ness settings. According to FEAPO:
An Enterprise Architecture practice collabo-
rates with many interconnected disciplines, in-
cluding performance engineering and manage-
ment, process engineering and management,
IT and enterprise portfolio management, gov-
ernance and compliance, IT strategic planning,
risk analysis, information management, meta-
data management, and a wide variety of tech-
nical disciplines as well as organizational dis-
ciplines such as organizational development,
transformation, innovation, and learning. In-
creasingly, many practitioners have stressed
the important relationship of Enterprise Archi-
tecture with emerging holistic design practices
such as design thinking, systems thinking, and
user experience design.[1]
4 CHAPTER 1. INTRODUCTION
As Enterprise Architecture has emerged in various or-
ganizations, the broad reach has resulted in this business
role being included in the information technology gover-
nance processes of many organizations. While this may
imply that enterprise architecture is closely tied to IT,
it should be viewed in the broader context of business
optimization in that it addresses business architecture,
performance management, and process architecture, as
well as more technical subjects.
Discussions of the intersection of Enterprise Architecture
and various IT practices have been published by various
IT analysis rms. Gartner and Forrester have stressed the
important relationship of Enterprise Architecture with
emerging holistic design practices such as Design Think-
ing and User Experience Design.[27][28][29] Analyst rm
Real Story Group suggested that Enterprise Architecture
and the emerging concept of the Digital workplace were
two sides to the same coin.[30] The Cutter Consortium
describes Enterprise Architecture as an information and
knowledge-based discipline.[31]
The enterprise architecture of an organization is too
complex and extensive to document in its entirety, so
knowledge management techniques provide a way to ex-
plore and analyze these hidden, tacit, or implicit areas.
In return, enterprise architecture provides a way of docu-
menting the components of an organization and their in-
teraction, in a systemic and holistic way that complements
knowledge management.[32]
In various venues[33] , enterprise architecture has been
discussed as having a relationship with Service Oriented
Architecture, a particular style of application integra-
tion. Research points to enterprise architecture promot-
ing the use of SOA as an enterprise-wide integration
pattern.[34][35]
1.1.6 Tools
The following table lists some enterprise architecture
tools listed by Gartner and Forrester Research in their A key concern about EA has been the diculty in arriv-
2013 and 2014 reports.[36][37][38] ing at metrics of success, because of the broad-brush and
often opaque nature of EA projects.[44]
1.1.7 Criticism
1.1.8 See also
Despite the benets that enterprise architecture claims to
provide, for more than a decade, writers and organiza-
tions raised concerns about enterprise architecture as an
eective practice. Here is a partial list of those objec-
tions:
In 2007, computer scientist Ivar Jacobson (a ma-
jor contributor to UML and pioneer in OO software
development) gave his assessment of enterprise ar-
chitecture: Around the world introducing an En-
terprise Architecture EA has been an initiative for
most nancial institutions (banks, insurance compa-
nies, government, etc.) for the last ve years or so,
and it is not over. I have been working with such
companies and helped some of them to avoid mak-
ing the worst mistakes. Most EA initiatives failed.
My guess is that more than 90% never really resulted
in anything useful.[39]
In a 2007 report, on enterprise architecture, Gartner
predicted that "... by 2012 40% of [2007s] enter-
prise architecture programs will be stopped.[40]
A 2008 study, by performed by Erasmus Univer-
sity Rotterdam and software company IDS Scheer
concluded that two-thirds of enterprise architec-
ture projects failed to improve business and IT
alignment.[41]
In a 2009 article, industry commentator Dion
Hinchclie wrote that traditional enterprise archi-
tecture might be broken": At its very best, en-
terprise architecture provides the bright lines that
articulate the full range of possibilities for a busi-
ness, even describing how to go about getting there.
... Recently theres a growing realization that tra-
ditional enterprise architecture as its often prac-
ticed today might be broken in some important way.
What might be wrong and how to x it are the ques-
tions du jour.[42]
In 2011, federal enterprise architecture consultant
Stanley Gaver released a report that examined prob-
lems within the United States federal governments
enterprise architecture program. Mr. Gaver con-
cluded that the federal enterprise architecture pro-
gram had mostly failed; this conclusion was corrob-
orated by a similar one made by the federal gov-
ernment at an October 2010 meeting that was held
to determine why the federal enterprise architecture
program was not as inuential and successful as in
the past.[43]
Architectural pattern (computer science)
Architecture of Integrated Information Systems,
Architecture of Interoperable Information Systems
Enterprise Architect
Enterprise Architecture Assessment Framework
Enterprise Architecture framework
Enterprise Architecture Planning
Enterprise Architecture Management
1.1. ENTERPRISE ARCHITECTURE
History of Enterprise Architecture
Enterprise engineering
Enterprise Life Cycle
Enterprise Unied Process
Federation of Enterprise Architecture Professional
Organizations
Global Information Network Architecture
Information Architecture
Information Framework[45]
John Zachman
Enterprise Architecture Service Life Cycle - SOMF
1.1.9 References
[1] Federation of EA Professional Organizations, Common
Perspectives on Enterprise Architecture, Architecture and
Governance Magazine, Issue 9-4, November 2013 (2013).
Retrieved on November 19, 2013.
[2] Pragmatic Enterprise Architecture Framework, PEAF
Context
[3] Mentz, J, Van der Merwe, Alta, & Kotze, Paula. (2012)
"A Comparison of Practitioner and Researcher Deni-
tions of Enterprise Architecture using an Interpretation
Method". In: Advances in Enterprise Information Systems
II, C. Mller & S. Chaudhry eds., CRC Press, p. 11-26
[4] MIT Center for Information Systems Research, Peter
Weill, Director, as presented at the Sixth e-Business Con-
ference, Barcelona Spain, March 27, 2007,
[5] Enterprise Architecture Book of Knowledge, Planning an
EA - Purpose, , retrieved on October 3, 2014.
[6] Gartner IT Glossary Enterprise Architecture (EA).
Gartner.com. Retrieved on July 29, 2013.
[7] Business Analysis Body of Knowledge, from the
International Institute of Business Analysis
[8] Giachetti, R.E., Design of Enterprise Systems, Theory,
Architecture, and Methods, CRC Press, Boca Raton, FL,
2010.
[9] ISO/IEC/IEEE 42010:2011 - Systems and software en-
gineering - Architecture description. Iso.org. November
24, 2011. Retrieved August 6, 2013.
[10] Lapalme, J., Three Schools of Thought on Enterprise Ar-
chitecture, IT Professional, vol. 14, no. 6, pp. 3743,
Nov.Dec. 2012, doi:10.1109/MITP.2011.109
[11] Jarvis, Bob (2003) Enterprise Architecture: Understand-
ing the Bigger Picture A Best Practice Guide for Deci-
sion Makers in IT, The UK National Computing Centre,
Manchester, UK. p. 9
5
[12] The Contribution of Enterprise Architecture to the
Achievement of Organizational Goals: Establishing the
Enterprise Architecture Benets Framework, Techni-
cal Report, Department of Information and Computing
Sciences Utrecht University, Utrecht, The Netherlands,
(2010 online)
[13] Bert Arnold, Martin Op 't Land and Jan Dietz. Eects of
an architectural approach to the implementation of shared
service centers, in Second International Workshop on
Enterprise, Applications and Services in the Finance In-
dustry (FinanceCom05), Regensburg, Germany, 2005.
[14] Jaap Schekkerman. Trends in enterprise architecture
2005: How are organizations progressing? [Online].
2009(10/20), pp. 33. Available: (online)
[15] T. Bucher, R. Fischer, S. Kurpjuweit and R. Winter,
Enterprise architecture analysis and application: An ex-
ploratory study, in EDOC Workshop TEAR, Hong Kong,
2006.
[16] Nilsson, Management of technochange in an interorga-
nizational E-government project, in Proceedings of the
41st Annual Hawaii International Conference on System
Sciences, 2008, pp. 209.
[17] J. Varnus and N. Panaich. TOGAF 9 enterprise archi-
tecture survey results. Presented at 23rd Enterprise Ar-
chitecture Practitioners Conference. [Online]. Avail-
able: www.opengroup.org/public/member/proceedings/
q309/q309a/Presentations/pl-varnus-panaich.pdf.
[18] Jeanne W. Ross and Peter Weill, Understanding the Ben-
ets of Enterprise Architecture, CISR Research Brief-
ings, 2005.
[19] W. Engelsman, M. E. Iacob and H. M. Franken,
Architecture-driven requirements engineering, in Pro-
ceedings of the 2009 ACM Symposium on Applied Com-
puting(SAC '09), Honolulu, Hawaii, 2009, pp. 285-286.
[20] L. Kappelman, T. McGinnis, A. Pettite and A. Sidorova,
Enterprise architecture: Charting the territory for aca-
demic research, in AMCIS 2008, 2008.
[21] M. Pulkkinen, A. Naumenko and K. Luostarinen, Man-
aging information security in a business network of ma-
chinery maintenance services business - Enterprise archi-
tecture as a coordination tool, J. Syst. Softw., vol. 80,
pp. 1607-1620, 2007.
[22] T. Obitz and M. K. Babu. (2009). Enterprise architecture
expands its role in strategic business transformation: In-
fosys enterprise architecture survey 2008/2009. (online).
[23] Federal Government agency success stories, (2010),
whitehouse.gov
[24] FEA Practice Guidance Federal Enterprise Archi-
tecture Program Management Oce OMB, (2007),
whitehouse.gov
[25] Volkswagen of America: Managing IT Priorities, Har-
vard Business Review, October 5, 2005, Robert D.
Austin, Warren Ritchie, Greggory Garrett
[26] DoD BEA
6 CHAPTER 1. INTRODUCTION

[27] Clay Richardson, Forrester Blogs Design Thinking Re- 1.1.10 External links
shapes EA For Dynamic Business, (2013)
Media related to Enterprise architecture at Wikime-
[28] Joe McKendrick, ZDNet Gartner urges more 'design dia Commons
thinking' to break enterprise architecture out of its silo,
(2010) Quotations related to Enterprise architecture at
Wikiquote
[29] Leslie Owens, Forrester Blogs Who Owns Information
Architecture? All Of Us., (2010), blogs.forrester.com The dictionary denition of enterprise architecture
at Wiktionary
[30] Tony Byrne, Real Story Group Blog Digital work-
place and enterprise architecture: two sides to same coin,
(2012),

[31] Evernden, Roger. Dealing with Too Much Data from an

Architectural Perspective, November 13, 2012 (online)

[32] Evernden, Elaine, Evernden, Roger. Information First

- Integrating Knowledge and Information Architecture
for Business Advantage, Butterworth-Heinemann, Ox-
ford, 2003 (online)

[33] SOA and Enterprise Architecture. The Open Group.

Retrieved December 18, 2014.

[34] Christopher Kistasamy, Alta van der Merwe, Andre de la

Harpe, (2012), The role of service-oriented architecture
as an enabler for Enterprise Architecture, AMCIS 2012,
Seattle Washington

[35] Rosa and Sampaio. SOA Governance Through Enter-

prise Architecture. Oracle.com. Oracle. Retrieved De-
cember 19, 2014.

[36] Gartner Magic Quadrant for Enterprise Architecture

Tools, 2013

[37] Forrester Wave EA Management Suites, Q2 2013

[38] Gartner Magic Quadrant for Enterprise Architecture

Tools, 2014

[39] EA Failed Big Way! by Ivar Jacobson. on http://blog.

ivarjacobson.com/ October 18, 2007.

[40] Gartner (2007) Gartner Enterprise Architecture Summit:

Architecting the Agile Organization, 26 27 September
2007. Overview on www.gartner.com. Accessed Novem-
ber 18, 2013.

[41] S. Roeleven, Sven and J. Broer (2010). Why Two Thirds

of Enterprise Architecture Projects Fail, ARIS Expert
Paper (online)

[42] Fixing Enterprise Architecture: Balancing the Forces of

Change in the Modern Organization Dion Hinchclie,
September 3, 2009

[43] Why Doesn't the FEA Work September 6, 2012, sum-

marized in Semantic Community

[44] Measuring Enterprise Architecture Eectiveness: A Fo-

cus on Key Performance Indicators, Gunther, W 2014

[45] Evernden, R. "The Information FrameWork", IBM Sys-

tems Journal, Volume 35 Issue 1, January 1996, Pages 37
- 68
Chapter 2

Enterprise Architect

2.1 Enterprise architect A holistic enterprise architecture (entarch) strategy has

the potential to allow both the Business and IT strategies
This article is about the job title. For the UML modeling to cohesively enable and drive each other. Therefore, en-
tool Enterprise Architect, see Enterprise Architect terprise architecture may be regarded as one of the key
(software). means to achieving competitive advantage through infor-
mation technology.

Enterprise architects are practitioners of enterprise ar-

chitecture; an enterprise strategic management discipline 2.1.2 Responsibilities
that operates within organizations.[1]
Alignment of IT strategy and planning with com-
panys business goals.
2.1.1 Role
Optimization of information management through
Enterprise architects work with stakeholders, both lead- an understanding of evolving business needs and
ership and subject matter experts, to build a holistic view technology capabilities.
of the organizations strategy, processes, information, and
information technology assets. The role of the enterprise Strategic responsibility for the companys IT sys-
architect is to take this knowledge and ensure that the tems.
business and IT are in alignment.[2] The enterprise archi-
tect links the business mission, strategy, and processes of Promotion of shared infrastructure and applications
an organization to its IT strategy, and documents this us- to reduce costs and improve information ow. En-
ing multiple architectural models or views that show how sure that projects do not duplicate functionality or
the current and future needs of an organization will be diverge from each other and business and IT strate-
met in an ecient, sustainable, agile, and adaptable man- gies.
ner.
Work with solutions architect(s) to provide a con-
Enterprise architects operate across organizational and sensus based enterprise solution that is scalable,
computing silos to drive common approaches and ex- adaptable and in synchronization with ever chang-
pose information assets and processes across the enter- ing business needs.
prise. Their goal is to deliver an architecture that supports
the most ecient and secure IT environment meeting a Risk Management of information and IT assets
companys business needs. through appropriate standards and security policies.
Enterprise architects are like city planners,[3] providing Direct or indirect involvement in the development
the roadmaps and regulations that a city uses to manage of policies, standards and guidelines that direct the
its growth and provide services to its citizens. In this anal- selection, development, implementation and use of
ogy, it is possible to dierentiate the role of the system Information Technology within the enterprise.
architect, who plans one or more buildings; software ar-
chitects, who are responsible for something analogous to Build employee knowledge and skills in specic ar-
the HVAC (Heating, Ventilation and Air Conditioning) eas of expertise.
within the building; network architects, who are respon-
sible for something like the plumbing within the building,
and the water and sewer infrastructure between buildings 2.1.3 Skills and knowledge
or parts of a city. The enterprise architect however, like a
city planner, both frames the city-wide design, and chore- Systems thinking - the ability to see how parts inter-
ographs other activities into the larger plan.[4] act with the whole (big picture thinking)

7
8 CHAPTER 2. ENTERPRISE ARCHITECT

Knowledge of the business for which the enterprise

architecture is being developed
Comprehensive knowledge of hardware, software,
application, and systems engineering
Knowledge of IT governance and operations

Knowledge of nancial modeling as it pertains to IT

investment

Interpersonal and leadership skills - servant lead-

ership, collaboration, facilitation, and negotiation
skills
Communication skills, both written and spoken

Ability to explain complex technical issues in a way

that non-technical people may understand
Project and program management planning and or-
ganizational skills
Customer service orientation

Time management and prioritization

2.1.4 References
[1] Worthen, Ben (2005-03-01). Wanted: Enterprise Archi-
tects. CIO: 4750. Retrieved 2015-09-25.

[2] Nick Rozanski, Ein Woods (2011). Software Systems

Architecture: Working with Stakeholders Using Viewpoints
and Perspectives. p. 73. ISBN 978-0321718334.

[3] Open Group Standard TOGAF Version 9.1. The Open

Group (2009-2011). p. 612.

[4] Rosen, Mike Ten Key Skills Architects Must Have to Deliver
Value, November 2008

2.1.5 External links

IBM Developer Works: Article on SOA user roles

Daljit Banger Rise of the Enterprise Architect,

British Computer Society, March 2006
Chapter 3
Enterprise Architecture
3.1 Enterprise Architecture As-
sessment Framework
EAAF Maturity levels.
The Enterprise Architecture Assessment Framework
(EAAF) is created by the US Federal government Oce
of Management and Budget (OMB) to allow federal agen-
cies to assess and report their enterprise architecture ac- While agencies have clearly demonstrated a degree of
tivity and maturity,[1] and to advance the use of enterprise maturity and competency in developing and using their
architecture in the federal government.[2]
The version 2.2 of the framework was released in October architectures, aimed at driving the kinds of government-
2007,[3] and version 3.1 in June 2009.
3.1.1 Overview
The OMB Enterprise Architecture Assessment Frame-
work (the Framework) helps OMB and the agencies as-
sess the capability of enterprise architecture programs to
guide IT investments.[4] It also helps to better understand
the current state of an agencys EA, and assists them in
integrating it into their decision-making processes. By
applying the assessment themselves, agencies can iden-
tify strengths and weaknesses within their programs and
adjust them accordingly.
Enterprise Architecture Assessment Framework
(EAAF) version 3.1 identies the measurement areas
and criteria by which agencies are expected to use the
EA to drive performance improvements that result in the
following outcomes:[1]
Closing agency performance gaps identied via co-
ordinated agency strategic planning and perfor-
mance management activities;
Saving money and avoiding cost through collabo-
ration and reuse, productivity enhancements, and
elimination of redundancy;
Strengthening the quality of agency investment port-
folios by improving security, inter-operability, relia-
bility, availability, solution development and service
delivery time, and overall end-user performance;
Improving the quality, availability and sharing of
data and information government-wide; and
Increasing the transparency of government opera-
tions by increasing the capacity for citizen partici-
pation and cross-governmental collaboration.
EAs, EAAF seeks to advance the practice of EA, particu-
larly through the development and use of agency segment
wide outcomes.[5]
3.1.2 Performance Improvement Lifecycle
Government agencies are continually assessing current
performance, identifying opportunities for improvement,
and translating them into specic actions. Enterprise
architecture is an integrated management practice that
maximizes the use of an agencys resources to achieve
their goals. Architecture describes the pathway from
strategic goals and objectives, through investments, to
measurable performance improvements for the entire en-
terprise or a portion.[5]
9
10 CHAPTER 3. ENTERPRISE ARCHITECTURE

initiatives in the Enterprise Transition Plan (ETP) and

described in the segment architectures. Program man-
agement plans are created to implement the individual
solutions.[5]

Information and IT-Enabled Performance Improvement Lifecy-

Implement
cle

Projects are executed and tracked throughout the system

Continuous performance improvement is the principal
driver connecting EA program sta with key business
stakeholders across each phase of the Performance Im-
provement Lifecycle. Agency Chief Architects and EA
program sta:[5]
development life cycle (SDLC). Achievement of the pro-
gram / project plan within acceptable variance for sched-
ule and budget is measured and reported through Earned
Value Management (EVM) process.[5]

identify and prioritize enterprise segments and op- Measure, assess and improve
portunities to improve mission performance, linked
to agency goals and objectives;

plan a course of action to close performance gaps,

using common or shared information assets and in-
formation technology assets;

allocate agency resources supporting program man-

agement and project execution;

measure and assess performance to verify and report

results; and EAAF assessment table describing how agency EAs will be as-
sessed.
assess feedback on program performance to en-
hance architecture, investment and implementation Information and information technology, as critical en-
decisions. ablers of program performance improvements, must be
assessed and evaluated in the context of agency missions
Opportunities to improve mission performance are pri- and outcome-oriented results dened in the enterprise-
oritized in terms of their relative value to the agencys wide performance architecture.[5]
strategic goals and objectives in the enterprise transition
Performance improvement plans and priorities, including
plan (ETP) and segment architecture.[5]
those previously gathered under the PART and Perfor-
mance Assessment Report (PAR) programs, are reected
Architect in the agency EA, particularly the performance architec-
ture and ETP. Performance metrics previously gathered
Enterprise architecture describes the current (baseline) are used to evaluate the results in agency performance im-
and future (target) states of the agency, and the plan to provement plans, identifying a programs strengths and
transition from the current to the future state, with a fo- weaknesses and addressing ways to improve the program
[5]
cus on agency strategy, program performance improve- performance.
ments and information technology investments. Agency
EAs are organized by segments core mission areas (e.g.,
homeland security, health), business service (e.g., nan- Agency submission data quality
cial management, human resources), and enterprise ser-
vices (e.g., Information Sharing). Segments are dened OMB collects a signicant amount of IT investment
using the Federal Enterprise Architecture (FEA) refer- data and other related data from executive agencies dur-
ence models .[5] ing each phase of Performance Improvement Lifecycle.
OMB uses the information for development of an IT in-
vestment portfolio as a part of the Presidents budget re-
Invest quest to Congress.[5]

Performance improvement opportunities identied dur-

ing the Architect process are ideally addressed through 3.1.3 See also
an agency portfolio of IT investments. This step denes
the implementation and funding strategy for individual Capability Maturity Model (CMM)
3.2. ENTERPRISE ARCHITECTURE PLANNING 11

Capability Maturity Model Integration (CMMI) that taken by DOE in that the business mission is the pri-
mary driver. That is followed by the data required to sat-
Modeling Maturity Levels isfy the mission, followed by the applications that are built
using that data, and nally by the technology to imple-
ment the applications.[1]
3.1.4 References
This hierarchy of activity is represented in the gure
[1] Enterprise Architecture Assessment Framework, Oce above, in which the layers are implemented in order, from
of Management and Budget, USA. top to bottom. Based on the Business Systems Planning
(BSP) approach developed by John Zachman, EAP takes
[2] Pallab Saha (2009) Advances in Government Enterprise a data-centric approach to architecture planning to pro-
Architecture. Idea Group Inc (IGI). p.133 vide data quality, access to data, adaptability to chang-
ing requirements, data interoperability and sharing, and
[3] OMB (july 2007) Federal Enterprise Architecture Program
cost containment. This view counters the more traditional
EA Assessment Framework 2.2. (Online copy here)
view that applications should be dened before data needs
[1]
[4] Federal Enterprise Architecture, Oce of Management are determined orx provided for.
and Budget, USA.

[5] US OBM (2009). Improving Agency Performance Using 3.2.2 EAP topics
Information and Information Technology : Enterprise Ar-
chitecture Assessment Framework v3.1 June 2009 Zachman framework

EAP denes the blueprint for subsequent design and im-

3.1.5 External links plementation and it places the planning/dening stages
into a framework. It does not explain how to dene the
E-GOV EA Assessment at whitehouse.gov top two rows of the Zachman Framework in detail but for
the sake of the planning exercise, abbreviates the analy-
sis. The Zachman Framework provides the broad context
3.2 Enterprise architecture plan- for the description of the architecture layers, while EAP
focuses on planning and managing the process of estab-
ning lishing the business alignment of the architectures.[2]
EAP is planning that focuses on the development of ma-
trixes for comparing and analyzing data, applications, and
technology. Most important, EAP produces an imple-
mentation plan. Within the Federal Enterprise Architec-
ture, EAP will be completed segment enterprise by seg-
ment enterprise. The results of these eorts may be of
Government wide value; therefore, as each segment com-
pletes EAP, the results will be published on the Architec-
turePlus web site.[2]

Levels of Enterprise Architecture Planning.[1] EAP components

Enterprise architecture planning (EAP) in enterprise Enterprise Architecture Planning model consists of four
architecture is the planning process of dening levels:
architectures for the use of information in support
of the business and the plan for implementing those Level 1 - getting started : This layer leads to produc-
architectures.[2] ing an EAP workplan and stresses the necessity of
high-level management commitment to support and
resource the subsequent six components (or steps) of
3.2.1 Overview the process. It consists of Planning Initiation, which
covers in general, decisions on which methodology
One of the earlier professional practitioners in the eld to use, who should be involved, what other support
of system architecture Steven H. Spewak in 1992 dened is required, and what toolset will be used.[2]
Enterprise Architecture Planning (EAP) as the process
of dening architectures for the use of information in sup- Level 2 - where we are today : This layer provides
port of the business and the plan for implementing those a baseline for dening the eventual architecture and
architectures.[3] Spewaks approach to EAP is similar to the long-range migration plan. It consists of:[2]
12 CHAPTER 3. ENTERPRISE ARCHITECTURE

Business process modeling, the compilation of
a knowledge base about the business functions
and the information used in conducting and
supporting the various business processes, and
Current Systems and Technology, the deni-
tion of current application systems and sup-
porting technology platforms.
Federal Enterprise Architecture (FEA) program
based on the EAP methodology has largely failed:
Enterprise Architecture within the federal govern-
ment hasnt been working, and far more often than
not hasnt delivered useful results. Moreover, sig-
nicant parts of the federal EA program have been
complete and utter failures.[8]

Level 3 - the vision of where we want to be : Even Steven Spewak and Steven Hill (1992) admit
The arrows delineate the basic denition process that the vast majority of enterprises that undertake
ow: data architecture, applications architecture, Enterprise Architecture Planning are not successful
and technology architecture. It consists of:[2] (page 19).[3]
Data Architecture - Denition of the major
kinds of data needed to support the business. 3.2.4 See also
Applications Architecture - Denition of the
major kinds of applications needed to manage Enterprise Architecture Framework
that data and support the business functions.
Technology Architecture - Denition of the Enterprise Architecture Process
technology platforms needed to support the
Enterprise Life Cycle
applications that manage the data and support
the business functions.
Level 4 - how we plan to get there : This consists 3.2.5 References
of the Implementation / Migration Plans - Deni-
tion of the sequence for implementing applications, [1] FAA (1998). Federal Information Architecture Initiatives.
a schedule for implementation, a cost/benet analy- Federal Aviation Administration, February 1998.
[2]
sis, and a clear path for migration.
[2] The Chief Information Ocers Council (1999). Federal
Enterprise Architecture Framework Version 1.1 September
EAP methodology 1999.

[3] Steven Spewak and S. C. Hill (1992) Enterprise Architec-

The Enterprise Architecture Planning (EAP) methodol-
ogy is benecial to understanding the further denition of
the Federal Enterprise Architecture Framework at level
IV. EAP is a how to approach for creating the top two
rows of the Zachman Framework, Planner and Owner.
The design of systems begins in the third row, outside the
scope of EAP.[2]
EAP focuses on dening what data, applications, and
technology architectures are appropriate for and support
the overall enterprise. Exhibit 6 shows the seven compo-
nents (or steps) of EAP for dening these architectures
and the related migration plan. The seven components
are in the shape of a wedding cake, with each layer repre-
senting a dierent focus of each major task (or step).[2]
3.2.3 Criticism
The eectiveness of the EAP methodology have been
questioned in the late 1980s and early 1990s:
ture Planning: Developing a Blueprint for Data, Applica-
tions, and Technology. Boston, QED Pub. Group. p. 1
[4] Lederer, A.L., and Sethi, V. (1988). The Implementation
of Strategic Information Systems Planning Methodologies.
In: MIS Quarterly, vol. 12, no. 3, pp. 445-461.
[5] Goodhue, D.L., Quillard, J.A., and Rockart, J.F. (1988).
Managing the Data Resource: A Contingency Perspective.
In: MIS Quarterly, vol. 12, no. 3, pp. 373-392.
[6] Lederer, A.L., and Sethi, V. (1992). Meeting the Chal-
lenges of Information Systems Planning. In: Long Range
Planning, vol. 25, no. 2, pp. 69-80.
[7] Goodhue, D.L., Kirsch, L.J., Quillard, J.A., and Wybo,
M.D. (1992). Strategic Data Planning: Lessons from the
Field. In: MIS Quarterly, vol. 16, no. 1, pp. 11-34.
[8] Why Doesnt the Federal Enterprise Architecture
Work?", Stanley B. Gaver, visited 19 May 2016.

Business Systems Planning (BSP), the concep- 3.2.6 Further reading

tual predecessor of EAP, did not work suc-
cessfully: Given their great expense and time Steven Spewak with Steven C. Hill (1995) Enter-
consumption, [...] ndings seriously challenge prise Architecture Planning: Developing a Blueprint
the utility of the [BSP and similar] planning for Data, Applications, and Technology. John Wiley
methodologies.[4][5][6][7] & Sons, New York City. 1995.
3.4. ARCHITECTURE PATTERNS ( EA REFERENCE ARCHITECTURE) 13

3.3 Enterprise Architecture Man- process. In this way EAM supports sustainable business
strategy realization.
agement
Enterprise Architecture Management (or EAM) is
a management practice that establishes, maintains and 3.3.3 See also
uses a coherent set of guidelines, architecture principles
and governance regimes that provide direction and prac- Application Architecture
tical help in the design and development of an enterprises
architecture to achieve its vision and strategy.[1] Service-Oriented Architecture

Information Technology Governance

3.3.1 Overview
The fundamental prerequisites for eective EAM are a Project Portfolio Management
current, consistent baseline of information about the as-
is landscape and an integrated planning process from Risk Management
demand to budget to reach the to-be landscape. The
enterprise architecture function also involves review-
ing and consolidating detailed architecture decisions 3.3.4 References
and migration plans to identify eciencies, advance
standardization, and align business and IT priorities. [1] F. Ahlemann et al. (eds.), Strategic Enterprise Architec-
As IT architectural layers, business support processes, ture Management: Challenges, Best Practices, and Future
and organizational structures become more sophisticated Developments, Springer-Verlag Berlin Heidelberg, 2012
and prone to constant change, EAM will only result in
haphazard business and IT alignment if the primary focus
is on delivering sets of technically based models. This ap- 3.3.5 External links
proach is only helpful insofar as it depicts the enterprise
architecture as a snapshot in time, but it oers no reitera-
tive process support to develop architecture solutions and 3.4 Architecture Patterns ( EA
test against dierent scenarios, benchmarks, and stan- Reference Architecture)
dards as dictated by the ever converging business and IT
strategy.
For the use of the word pattern in the eld of architec-
Moreover, a model-centric approach is prohibitively ture, see Pattern (architecture).
time-intensive to keep updated and leaves too much room
for error as changes to the architecture occur unchecked
and isolated in the heads of small groups of architec- An architectural pattern is a general, reusable solu-
ture specialists. Instead, the EAM eort has to bring the tion to a commonly occurring problem [1]
in software archi-
highly distributed knowledge of all experts to the table tecture within a given context. Architectural patterns
and allow every participant to provide such knowledge are similar to software design pattern but have a broader
and input in the terms that best t the experience and ex- scope. The architectural patterns address various issues
pectations of the contributing stakeholders. in software engineering, such as computer hardware per-
formance limitations, high availability and minimization
of a business risk. Some architectural patterns have been
3.3.2 Application implemented within software frameworks.

Successful Enterprise Architecture programs are ap-

proached from a management perspective as opposed to a
modeling perspective. A new generation of EA Planning
tools are emerging that support not only the modeling of
the architecture, but also the creation of roll-out and im-
plementation plans for continuous IT improvement over
time.
An important aspect of this approach is support of collab-
oration amongst a wide group of stakeholders from both
business and IT including C-level, IT strategists, plan-
ning teams, technology implementers, and business ana-
lysts, who contribute to the EA management and planning
3.4.1 Denition
Even though an architectural pattern conveys an im-
age of a system, it is not an architecture. An archi-
tectural pattern is a concept that solves and delineates
some essential cohesive elements of a software architec-
ture. Countless dierent architectures may implement
the same pattern and share the related characteristics.
Patterns are often dened as strictly described and com-
monly available.[2][3] When it is strictly described and
commonly available, it is a pattern.
14 CHAPTER 3. ENTERPRISE ARCHITECTURE

3.4.2 Architectural style 3.4.4 See also

Following traditional building architecture, a 'software
architectural style' is a specic method of construc-
tion, characterized by the features that make it notable
(Architectural style). An architectural style denes: a
family of systems in terms of a pattern of structural or-
ganization; a vocabulary of components and connectors,
with constraints on how they can be combined.[4]
An architectural style is a named collection of architec-
tural design decisions that (1) are applicable in a given 3.4.5 References
development context, (2) constrain architectural design
decisions that are specic to a particular system within [1] R. N. Taylor, N. Medvidovi and E. M. Dashofy, Software
that context, and (3) elicit benecial qualities in each re- architecture: Foundations, Theory and Practice. Wiley,
sulting system.[1]
Some treat architectural patterns and architectural styles
as the same,[5] some treat styles as specializations of pat-
terns. What they have in common is both patterns and
styles are idioms for architects to use, they provide a
common language[5] or vocabulary[4] with which to
describe classes of systems.
The main dierence is that a pattern can be seen as a so-
lution to a problem, while a style is more general and does
not require a problem to solve for its appearance.
3.4.3 Examples
Here is a list of architecture patterns, and corresponding
design patterns and solution patterns.
Some additional examples of architectural patterns:
Blackboard system
Broker pattern
List of software architecture styles and patterns
Process Driven Messaging Service
Enterprise architecture
Common layers in an information system logical ar-
chitecture
2009.
[2] Chang, Chih-Hung; Lu, Chih-Wei; Lin, Chih-Hao; Yang,
Ming-Feng; Tsai, Ching-Fu (June 2008). An Experience
of Applying Pattern-based Software Framework to Im-
prove the Quality of Software Development: 4. The De-
sign and Implementation of OS2F. Journal of Software
Engineering Studies, Vol. 2, No. 6. the Third Taiwan Con-
ference on Software Engineering (TCSE07). pp. 185
194. Retrieved 2012-05-16. Furthermore, patterns are
often dened as something strictly described and com-
monly available. For example, layered architecture is a
call-and-return style, when it denes an overall style to in-
teract.
[3] Architectural Patterns: Denition. AAHN IN-
FOTECH (INDIA) PVT. LTD. Retrieved 2012-05-16.
Even though an architectural pattern conveys an image of
a system, it is not an architecture as such. An architec-
tural pattern is rather a concept that solves and delineates
some essential cohesive elements of a software architec-
ture. Countless dierent architectures may implement the
same pattern and thereby share the related characteris-
tics. Furthermore, patterns are often dened as something
strictly described and commonly available.

Event-driven architecture [4] M. Shaw and D. Garlan, Software architecture: perspec-

tives on an emerging discipline. Prentice Hall, 1996.
Implicit invocation
[5] http://msdn.microsoft.com/en-us/library/ee658117.aspx
Layers

Microservices 3.4.6 Bibliography

Model-view-controller, Presentation-abstraction- Avgeriou, Paris; Uwe Zdun (2005). Architectural pat-

control, Model-view-presenter, and Model-view- terns revisited:a pattern language. 10th European Con-
viewmodel ference on Pattern Languages of Programs (EuroPlop
2005), Irsee, Germany, July.
Multitier architecture (often three-tier or n-tier)
Buschmann F.; Meunier R.; Rohnert H.; Sommerlad P.;
Naked objects Stal M. (1996). Pattern-Oriented Software Architecture:
A System of Patterns. John Wiley & Sons.
Operational Data Store (ODS) Bass L.; Clements P.; Kazman R. (2005). Software Ar-
Peer-to-peer chitecture in Practice: Second Edition. Addison-Wesley.

Pipe and lter architecture

Service-oriented architecture
Chapter 4
Frameworks
4.1 Enterprise Architecture frame-
work
NIST Enterprise Architecture Model initiated in 1989, one of the
earliest frameworks for enterprise architecture.[1]
An enterprise architecture framework (EA frame-
work) denes how to create and use an enterprise archi-
tecture. An architecture framework provides principles
and practices for creating and using the architecture de-
scription of a system. It structures architects thinking by
dividing the architecture description into domains, layers,
or views, and oers models - typically matrices and dia-
grams - for documenting each view. This allows for mak-
ing systemic design decisions on all the components of
the system and making long-term decisions around new
design requirements, sustainability, and support.[2]
4.1.1 Overview By 1980, IBMs Business Systems Planning (BSP) was
promoted as a method for analyzing and designing an or-
Enterprise architecture regards the enterprise as a large ganizations information architecture, with the following
and complex system or system of systems.[3] To manage goals:
the scale and complexity of this system, an architectural
framework provides tools and approaches that help ar-
chitects abstract from the level of detail at which builders
work, to bring enterprise design tasks into focus and pro-
duce valuable architecture description documentation.
The components of an architecture framework pro-
vide structured guidance that is divided into three main
areas:[4]
Descriptions of architecture: how to document the
enterprise as a system, from several viewpoints.
Each view describes one slice of the architecture; it
includes those entities and relationships that address
particular concerns of interest to particular stake-
holders; it may take the form of a list, a table, a
diagram, or a higher level of composite of such.
Methods for designing architecture: processes that
architects follow. Usually, an overarching enterprise
architecture process, composed of phases, broken
into lower-level processes composed of ner grained
activities. A process is dened by its objectives, in-
puts, phases (steps or activities) and outputs. It may
be supported by approaches, techniques, tools, prin-
ciples, rules, and practices.
Organization of architects: guidance on the team
structure and the governance of the team, including
the skills, experience, and training needed.
4.1.2 History
Since the 1970s people working in IS/IT have looked for
ways to engage business people to enable business roles
and processes - and to inuence investment in business
information systems and technologies with a view to the
wide and long term benets of the enterprise. Many of the
aims, principles, concepts and methods now employed in
EA frameworks were established in the 1980s, and can
be found in IS and IT architecture frameworks published
in that decade and the next.[7]
15
16 CHAPTER 4. FRAMEWORKS

In 1989, the National Institute of Standards and Tech-

nology (NIST) published the NIST Enterprise Architec-
ture Model.[12] This was a ve-layer reference model that
illustrates the interrelationship of business, information
system, and technology domains. It was promoted within
the U.S. federal government. It was not an EA frame-
work as we see it now, but it helped to establish the no-
tion of dividing EA into architecture domains or layers.
The NIST Enterprise Architecture Model seemingly was
the rst publication that consistently used the term En-
terprise Architecture.[11]
In 1990, the term Enterprise Architecture was formally
dened for the rst time as an architecture that denes
Overview of Enterprise Architecture Frameworks evolution and interrelates data, hardware, software, and commu-
(19872003).[4][5] On the left: The Zachman Framework 1987, nications resources, as well as the supporting organiza-
NIST Enterprise Architecture 1989, EAP 1992, TISAF 1997, tion required to maintain the overall physical structure
FEAF 1999 and TEAF 2000. On the right: TAFIM inuenced
[6] required by the architecture.[11][13]
by POSIX, JTA, JTAA, TOGAF 1995, DoD TRM and C4ISR
1996, and DoDAF 2003. In 1992, a paper by Zachman and Sowa[10] started thus
John Zachman introduced a framework for information
systems architecture (ISA) that has been widely adopted
1. understand the issues and opportunities with the cur- by systems analysts and database designers. The term en-
rent applications and technical architecture; terprise architecture did not appear. The paper was about
2. develop a future state and migration path for the using the ISA framework to describe, ...the overall infor-
technology that supports the enterprise; mation system and how it relates to the enterprise and its
surrounding environment. The word enterprise was used
3. provide business executives with a direction and de- as a synonym for business.
cision making framework for IT capital expendi-
In 1993, Stephen Spewaks book Enterprise Architecture
tures;
Planning (EAP) dened a process for dening architec-
4. provide the information system (IS) with a blueprint tures for the use of information in support of the business
for development. and the plan for implementing those architectures. The
business mission is the primary driver. Then the data re-
quired to satisfy the mission. Then the applications built
In 1982, when working for IBM and with BSP, John
to store and provide that data. Finally the technology
Zachman was perhaps the rst to mention Enterprise Ar-
to implement the applications. Enterprise Architecture
chitecture in the public domain. Then and in later pa-
Planning is a data-centric approach to architecture plan-
pers, Zachman used the word enterprise as a synonym for
ning. An aim is to improve data quality, access to data,
business. Although many popular information systems
adaptability to changing requirements, data interoperabil-
planning methodologies, design approaches, and various
ity and sharing, and cost containment. EAP has its roots
tools and techniques do not preclude or are not inconsis-
in IBMs Business Systems Planning (BSP).[11]
tent with enterprise-level analysis, few of them explicitly
address or attempt to dene enterprise architectures.[8] In 1994, the Open Group selected TAFIM from the US
However, in this article the term Enterprise Architec- DoD as a basis for development of The Open Group
ture was mentioned only once without any specic def- Architecture Framework (TOGAF), where architecture
inition and all subsequent works of Zachman used the meant IT architecture. TOGAF started out taking a
term Information Systems Architecture.[9][10] strategic and enterprise-wide, but technology-oriented,
view. It emerged from the desire to rationalize a messy IT
In 1986, the PRISM architecture framework was devel-
estate. Right up to version 7, TOGAF was still focused
oped as a result of the research project sponsored by a
on dening and using a Technical Reference Model (or
group of companies, including IBM, which was seem-
foundation architecture) to dene the platform services
ingly the rst published EA framework.[11]
required from the technologies that an entire enterprise
In 1987, John Zachman, who was a marketing specialist uses to support business applications.[7]
at IBM, published the paper, A Framework for Informa-
In 1996, the US IT Management Reform Act, more com-
tion Systems Architecture.[9] The paper provided a classi-
monly known as the Clinger-Cohen Act, repeatedly di-
cation scheme for artifacts that describe (at several levels
rected that a US federal government agencys investment
of abstraction) the what, how, where, who, when and why
in IT must be mapped to identiable business benets. In
of information systems. Given IBM already employed
addition, it made the agency CIO responsible for, ...de-
BSP, Zachman had no need to provide planning process.
veloping, maintaining and facilitating the implementation
The paper did not mention enterprise architecture.
4.1. ENTERPRISE ARCHITECTURE FRAMEWORK 17

of a sound and integrated IT architecture for the execu- ness principles, business goals, and strategic drivers of the
tive agency. organization are dened elsewhere.[7] In other words, En-
By 1997, Zachman had renamed and refocused his ISA terprise Architecture is not a business strategy, planning
framework as an EA framework; it remained a classi- or management methodology. Enterprise Architecture
cation scheme for descriptive artifacts, not a process for strives to align business information systems technology
planning systems or changes to systems. with given business strategy, goals and drivers. The TO-
GAF 9.1 specication claried, that, A complete enter-
In 1998, The Federal CIO Council began developing prise architecture description should contain all four ar-
the Federal Enterprise Architecture Framework (FEAF) chitecture domains (business, data, application, technol-
in accordance with the priorities enunciated in Clinger- ogy), but the realities of resource and time constraints of-
Cohen and issued it in 1999. FEAF was a process much ten mean there is not enough time, funding, or resources
like TOGAFs ADM, in which The architecture team to build a top-down, all-inclusive architecture description
generates a sequencing plan for the transition of systems, encompassing all four architecture domains, even if the
applications, and associated business practices predicated enterprise scope is [...] less than the full extent of the
upon a detailed gap analysis [between baseline and target overall enterprise.[16]
architectures].
In 2013, TOGAF[17] is the most popular Architecture
In 2001, the US Chief CIO council published A practical framework (judged by published certication numbers)
guide to Federal Enterprise Architecture, which starts, An that some assume it denes EA.[7] However, some still
enterprise architecture (EA) establishes the Agency-wide use the term Enterprise Architecture as a synonym for
roadmap to achieve an Agencys mission through optimal Business Architecture, rather than covering all four archi-
performance of its core business processes within an e- tecture domains - business, data, applications and tech-
cient information technology (IT) environment. At that nology.
point, the processes in TOGAF, FEAF, EAP and BSP
were clearly related.
In 2002/3, in its Enterprise Edition, TOGAF 8 shifted fo-
4.1.3 EA framework topics
cus from the technology architecture layer to the higher
business, data and application layers. It introduced struc-
tured analysis, after Information Engineering, which fea-
tures, for example, mappings of organization units to
business functions and data entities to business functions.
Today, business functions are often called business ca-
pabilities. And many enterprise architects regard their
business function/capability hierarchy/map as the funda-
mental Enterprise Architecture artifact. They relate data
entities, use cases, applications and technologies to the
functions/capabilities.
In 2006, the popular book Enterprise Architecture As
Strategy[14] reported the results of work by MITs Center
for Information System Research. This book emphasises
the need for enterprise architects to focus on core busi-
ness processes (Companies excel because they've [de-
cided] which processes they must execute well, and have
implemented the IT systems to digitise those processes.) Artist impression.[18]
and to engage business managers with the benets that
strategic cross-organisational process integration and/or
standardisation could provide.
Architecture and building governance
A 2008 research project for the development of profes-
sional certicates in enterprise and solution architecture People who remodel a home are aware that the architect
by the British Computer Society (BCS) showed that en- produces detailed drawings that specify plumbing, elec-
terprise architecture has always been inseparable from trical, and building construction information for the en-
information system architecture, which is natural, since tire structure. The architect responsible for the design
business people need information to make decisions and produces (or oversees others who produce) blueprints for
carry out business processes.[7] each phase of the projectfrom structural changes to size
In 2011, the TOGAF 9.1. specication says: Business and layout of rooms. Moreover, to successfully complete
planning at the strategy level provides the initial direc- the project, the architect operates within a framework of
tion to enterprise architecture.[15] Normally, the busi- building codes. City or county inspections ensure the
work complies with building codes.
18 CHAPTER 4. FRAMEWORKS

Enterprise architecture works in a similar manner.[18] An

architecture description document can be thought of as
the blueprint for the procurement and realization of a sys-
tem. But an enterprise architecture includes more than
just an abstract description of the systems structure and
behavior. It includes also principles, policies and stan-
dards (akin to building codes) that ensure that systems are
Example of the federal enterprise architecture, which has dened
soundly constructed. Governance of the enterprise archi- ve architectural layers.[20]
tecture and of its implementation requires organization
and processes (akin to city and county inspectors and the
processes for checking building improvement projects). which encapsulated the technology component layer be-
hind the platform services dened in the Technical Ref-
erence Model - very much according to the philosophy
Architecture domain of TAFIM and POSIX.
The view of architecture domains as layers can be pre-
sented thus:

Environment (the external entities and activities

Layers of the enterprise architecture.[19]
Since Stephen Spewaks Enterprise Architecture Plan-
ning (EAP) in 1993, and perhaps before then, it has
been normal to divide enterprises architecture into four
architecture domains.
Business architecture,
monitored, supported or directed by the business).
Business Layer (business functions oering services
to each other and to external entities).
Data Layer (Business information and other valuable
stored data)
Information System Layer (business applications of-
fering information services to each other and to busi-
ness functions)
Technology Layer (generic hardware, network and
platform applications oering platform services to
each other and to business applications).

Data architecture, Each layer delegates work to the layer below. In each
layer, the components, the processes and the services can
Applications architecture, be dened at a coarse-grained level and decomposed into
ner-grained components, processes and services. The
Technology architecture. graphic shows a variation on this theme.

Note that the applications architecture is about the choice

of and relationships between applications in the enter- 4.1.4 Components of enterprise architec-
prises application portfolio, not about the internal archi- ture framework
tecture of a single application (which is often called ap-
plication architecture). In addition to three major framework components dis-
Many EA frameworks combine data and application do- cussed above.
mains into a single (digitized) information system layer,
sitting below the business (usually a human activity sys- 1. Description advice: some kind of Architecture Ar-
tem) and above the technology (the platform IT infras- tifacts Map or Viewpoint Library
tructure).
2. Process advice: some kind of Architecture Devel-
opment Method, with supporting guidance.
Layers of the enterprise architecture
3. Organization advice: including an EA Governance
Model
For many years, it has been common to regard the archi-
tecture domains as layers, with the idea that each layer
contains components that execute processes and oer An Ideal EA Framework should feature:
services to the layer above. This way of looking at the
architecture domains was evident in TOGAF v1 (1996), 1. Business Value Measurement Metrics
4.1. ENTERPRISE ARCHITECTURE FRAMEWORK 19

2. EA Initiative Model An example of the list of reference architecture patterns

in the application and information architecture domains
3. EA Maturity Model are available at Architectural pattern (computer science).
4. Enterprise Communication Model
View model
Most modern EA Frameworks (e.g. TOGAF, ASSIM-
PLER, EAF) include most of the above. Zachman has
always focused on architecture description advice. Logical Development
view view

Enterprise architecture domains and subdomains

Scenarios

System
& environment
Process Physical
view view

Illustration of the 4+1 view model of architecture.

A view model is a framework that denes the set of views

or approaches used in systems analysis, systems design,
or the construction of an enterprise architecture.
Since the early 1990s there have been a number of eorts
to dene standard approaches for describing and analyz-
Enterprise architecture reference architecture with sub domains
ing system architectures. Many of the recent Enterprise
The application and technology domains (not to be con- Architecture frameworks have some kind of set of views
fused with business domains) are characterized by do- dened, but these sets are not always called view models.
main capabilities and domain services. The capabili-
ties are supported by the services. The application ser-
vices are also referred to in service-oriented architecture Standardization
(SOA). The technical services are typically supported by
software products. Perhaps the best-known standard in the eld of software
architecture and system architecture started life as IEEE
The data view starts with the data classes which can be de- 1471, an IEEE Standard for describing the architecture of
composed into data subjects which can be further decom- a software-intensive system approved in 2000.
posed into data entities. The basic data model type which
is most commonly used is called merda (master entity In its latest version, the standard is published as
relationship diagrams assessment, see entity-relationship ISO/IEC/IEEE 42010:2011. The standard denes an ar-
model). The Class, subject and entity forms a hierarchi- chitecture framework as conventions, principles and prac-
cal view of data. Enterprises may have millions of in- tices for the description of architectures established within
stances of data entities. a specic domain of application and/or community of
stakeholders, and proposes an architecture framework is
The Enterprise Architecture Reference Traditional specied by:
Model oers clear distinction between the archi-
tecture domains (business, information/data, applica-
tion/integration and technical/infrastructure). These do- 1. the relevant stakeholders in the domain,
mains can be further divided into Sub domain disciplines.
2. the types of concerns arising in that domain,
An example of the EA domain and sub domains is in the
image on the right. 3. architecture viewpoints framing those concerns and
Many enterprise architecture teams consist of Individuals
with Skills aligned with the Enterprise Architecture Do- 4. correspondence rules integrating those viewpoints
mains and sub-domain disciplines. Here are some exam- cited before.
ples: enterprise business architect, enterprise documen-
tational architect, enterprise application architect, enter- Architecture frameworks conforming to the standard can
prise infrastructure architect, enterprise information ar- include additional methods, tools, denitions, and prac-
chitect, etc. tices beyond those specied.
20
4.1.5 Types of enterprise architecture Government frameworks
framework
Just a few of the Enterprise Architecture frameworks utilized to-
day, 2011[21]
Nowadays there are now countless EA frameworks, many
more than in the following listing.
Consortia-developed frameworks
ARCON A Reference Architecture for Collabo-
rative Networks not focused on a single enterprise
but rather on networks of enterprises[22][23]
Generalised Enterprise Reference Architecture and
Methodology (GERAM)
RM-ODP the Reference Model of Open Dis-
tributed Processing (ITU-T Rec. X.901-X.904 | Enterprise architecture frameworks that are released as
ISO/IEC 10746) denes an enterprise architecture open source:
framework for structuring the specications of open
distributed systems.
IDEAS Group a four-nation eort to develop a
common ontology for architecture interoperability
ISO 19439 Framework for enterprise modelling
TOGAF The Open Group Architecture Frame-
work a widely used framework including an ar-
chitectural Development Method and standards for
describing various types of architecture.
Defense industry frameworks
AGATE the France DGA Architecture Frame-
work
DNDAF[24] the DND/CF Architecture Frame-
work (CAN)
DoDAF the US Department of Defense Architec-
ture Framework Proprietary frameworks
MODAF the UK Ministry of Defence Architec-
ture Framework
NAF the NATO Architecture Framework
CHAPTER 4. FRAMEWORKS
European Space Agency Architectural Framework
(ESAAF) - a framework for European space-based
Systems of Systems[25][26]
Government Enterprise Architecture (GEA) a
common framework legislated for use by depart-
ments of the Queensland Government
FDIC Enterprise Architecture Framework
Federal Enterprise Architecture Framework
(FEAF) a framework produced in 1999 by the
US Federal CIO Council for use within the US
Government (not to be confused with the 2002
Federal Enterprise Architecture (FEA) guidance on
categorizing and grouping IT investments, issued by
the US Federal Oce of Management and Budget)
Nederlandse Overheid Referentie Architectuur
(NORA) a reference framework from the Dutch
Government E-overheid NORA
NIST Enterprise Architecture Model
Treasury Enterprise Architecture Framework
(TEAF) a framework for treasury, published by
the US Department of the Treasury in July 2000.[27]
Open-source frameworks
MEGAF[28] is an infrastructure for realizing archi-
tecture frameworks that conform to the denition of
architecture framework provided in ISO/IEC/IEEE
42010.
Praxeme, an open enterprise methodology, contains
an enterprise architecture framework called the En-
terprise System Topology (EST)
TRAK a general systems-oriented frame-
work based on MODAF 1.2 and released under
GPL/GFDL.
SABSA[29] is an open framework and methodol-
ogy for Enterprise Security Architecture and Ser-
vice Management, that is risk based and focuses on
integrating security into business and IT manage-
ment.
ASSIMPLER Framework an architecture frame-
work, based on the work of Mandar Vanarse at
Wipro in 2002
4.1. ENTERPRISE ARCHITECTURE FRAMEWORK
Avancier Methods (AM)[30] Processes and docu-
mentation advice for enterprise and solution archi-
tects, supported by training and certication.
BRM (Build-Run-Manage) Framework - an ar-
chitecture framework created by Sanjeev Sunny
Mishra during his early days at IBM in 2000.
Capgemini Integrated Architecture Framework
(IAF) from Capgemini company in 1993
Dragon1 - An open Visual Enterprise Architecture
Method recently recognized by The Open Group as
Architecture Framework
DYA framework developed by Sogeti since 2004.
Dynamic Enterprise Enterprise architecture concept
based on Web 2.0 technology
Extended Enterprise Architecture Framework -
from Institute For Enterprise Architecture Develop-
ments in 2003
EACOE Framework an Enterprise Architecture
framework, as an elaboration of the work of John
Zachman
IBM Information FrameWork (IFW) conceived by
Roger Evernden in 1996
OBASHI the OBASHI Business & IT methodol-
ogy and framework
Pragmatic Enterprise Architecture Framework
(PEAF)[31] - part of Pragmatic Family of Frame- 4.1.8 References
works developed by Kevin Lee Smith, Pragmatic
EA, from 2008 [1] The Chief Information Ocers Council (1999). Federal
Purdue Enterprise Reference Architecture devel-
oped by Theodore J. Williams at the Purdue Uni-
versity early 1990s.
SAP Enterprise Architecture Framework
Service-oriented modeling framework (SOMF),
based on the work of Michael Bell
Solution Architecting Mechanism (SAM)[32] A
coherent architecture framework consisting of a set
of integral modules.[33]
Zachman Framework an architecture framework,
based on the work of John Zachman at IBM in the
1980s
4.1.6 Criticism
Despite that EA frameworks have been widely discussed
and strongly associated with the very notion of EA, their
real practical value has been questioned:
21
Historical analysis of EA publications shows that
EA frameworks are nothing more than typical
management fads aggressively promoted by consult-
ing companies and gurus.[34]
Research shows that EA frameworks appear theo-
retical and impossible to implement.[35]
Vivek Kundra, the federal CIO of the United
States, argued that EA frameworks are worse than
useless.[36]
Jason Bloomberg reports that EA frameworks only
waste architects time instead of solving real prob-
lems. Frameworks are cocaine for executives - they
give them a huge rush and then they move to the next
framework.[37]
4.1.7 See also
Architecture patterns (EA reference architecture)
EABOK (The Guide to the Enterprise Architecture
Body of Knowledge)
Enterprise architecture
Enterprise architecture planning
Enterprise engineering
ISO/IEC/IEEE 42010
Reference architecture
Enterprise Architecture Framework Version 1.1.
September 1999.
[2] Tech Target. SearchCIO.
[3] The Open Group (2008) TOGAF Version 9. Van Haren
Publishing, 1 nov. 2008.p. 73
[4] Stephen Marley (2003). Architectural Framework.
NASA /SCI. At Webarchive.org, retrieved 3-04-2015.
[5] Jaap Schekkerman (2004) How to Survive in the Jungle of
Enterprise Architecture Frameworks. p.89 gives a similar
scheme.
[6] US Department of Defense (2001) Department of Defense
Technical Reference Model. Version 2.0. 9 April 2001. p.
11, mentioned that also the DoD TRM is inuenced by
POSIX.
[7] Graham Berrisford (2008-13) "A brief history of EA:
what is in it and what is not" on grahamberrisford.com,
last update 16/07/2013. Accessed 16/07?2003
[8] John Zachman (1982) Business Systems Planning and
Business Information Control Study: A comparison in IBM
Systems Journal 21(1). p32.
22 CHAPTER 4. FRAMEWORKS

[9] John A. Zachman (1987). A Framework for Information
Systems Architecture. In: IBM Systems Journal, vol 26, no
3. IBM Publication G321-5298.
[10] Zachman and Sowa (1992) Extending and formalising the
framework of information systems architecture IBM Sys-
tems Journal, Vol 31, No 3
[11] Svyatoslav Kotusev (2016). The History of Enterprise Ar-
chitecture: An Evidence-Based Review. In: Journal of En-
terprise Architecture, vol. 12, no. 1, pp. 29-37.
[12] W.B. Rigdon (1989). Architectures and Standards. In In-
formation Management Directions: The Integration Chal-
lenge (NIST Special Publication 500-167), E.N. Fong,
A.H. Goldne (Eds.), Gaithersburg, MD: National Insti-
tute of Standards and Technology (NIST), pp.135-150.
[26] Gianni, D., Lindman, N., Fuchs, J., & Suzic, R.
(2012). Introducing the european space agency architec-
tural framework for space-based systems of systems en-
gineering. In Complex Systems Design & Management
(pp. 335-346). Springer Berlin Heidelberg.
[27] US Department of the Treasury Chief Information Of-
cer Council (2000). Treasury Enterprise Architecture
Framework. Version 1, July 2000.
[28] MEGAF
[29] SABSA
[30] Avancier Methods (AM)
[31] Pragmatic EA

[13] Richardson, G.L.; Jackson, B.M.; Dickson, G.W. (1990). [32] Solution Architecting Mechanism (SAM)
A Principles-Based Enterprise Architecture: Lessons [33] Tony Shan and Winnie Hua (2006). Solution Architecting
from Texaco and Star Enterprise. MIS Quarterly. 14 (4): Mechanism. Proceedings of the 10th IEEE International
385403. doi:10.2307/249787. EDOC Enterprise Computing Conference (EDOC 2006),
[14] Jeanne W. Ross, Peter Weill, and David C. Robertson October 2006, p23-32.
( (2006) Enterprise Architecture As Strategy: Creating a
[34] Enterprise Architecture Frameworks: The Fad of the
Foundation for Business Execution. Harvard Business Re-
Century, Svyatoslav Kotusev, British Computer Society
view Press
(BCS), July 2016
[15] The Open Group (2011) TOGAF 9.1 > Part II: Archi-
[35] Sabine Buckl, Alexander Ernst, Josef Lankes and Chris-
tecture Development Method (ADM) > Preliminary Phase.
tian Schweda (2009). State of the Art in Enterprise Archi-
Accessed July 16, 2013
tecture Management. Software Engineering for Business
[16] The Open Group (2011) TOGAF 9.1 > Part II: Archi- Information Systems (SEBIS), Munich, Germany, pp. 1-
tecture Development Method (ADM) > Introduction to the 31.
ADM. Accessed July 16, 2013
[36] Two IT Gurus Face O on Value of Enterprise Architec-
[17] TOGAF 9.1 White Paper An Introduction to TOGAF ture Frameworks, Linda Tucci, visited 3 August 2016
Version 9.1 http://www.opengroup.org/togaf/
[37] Is Enterprise Architecture Completely Broken?", Jason
[18] Rob Thomas and Phil Cullen (2001). Building an En- Bloomberg, visited 3 August 2016
terprise Architecture framework. In: US Customs Today
April 2001.
4.1.9 External links
[19] Niles E Hewlett (2006) , The USDA Enterprise Architec-
ture Program. PMP CEA, Enterprise Architecture Team, Enterprise Architecture Frameworks: The Fad of
USDA-OCIO. January 25, 2006.
the Century (July 2016)
[20] FEA Consolidated Reference Model Document. white-
house.gov May 2005.

[21] Dennis E. Wisnosky (2011) Engineering Enterprise Archi-

tecture: Call to Action. in: Common Defense Quarterly.
January 2011, p. 9

[22] L.M. Camarinha-Matos, H. Afsarmanesh, Collaborative

Networks: Reference Modeling, Springer, 2008.

[23] Camarinha-Matos, L.M.; Afsarmanesh, H. (2008). On

reference models for collaborative networked organiza-
tions. International Journal Production Research. 46 (9):
24532469. doi:10.1080/00207540701737666.

[24] DNDAF

[25] Introducing the European Space Agency Architectural

Framework for Space-Based Systems of Systems Engi-
neering. Complex Systems Design & Management: 335
346. doi:10.1007/978-3-642-25203-7_24. Retrieved
2013-06-16.
Chapter 5

Open Source or Consortia-developed

frameworks

5.1 Enterprise Architecture Body Enterprise architecture practitioners should be aware that
the discipline has evolved since the most recent publica-
of Knowledge tion: perhaps the most notable being the extensions of
DODAF, including MODAF, and the work at the Object
The Enterprise Architecture Body of Knowledge Management Group to create a model that satises both
(EABOK) is a guide to Enterprise Architecture pro- frameworks.
duced by MITRE's Center for Innovative Computing
and Informatics, and is substantially funded by US
government agencies. It provides a critical review 5.1.2 Perspective
of enterprise architecture issues in the context of the
needs of an organization. Because it provides a "big EABOK (and the discipline it describes) is evolving (and
[1][2]
picture" view of needs and methods, some enterprise partially incomplete). It places enterprise architec-
architecture practitioners recommend it as starting point ture in context. Because there are so many dierent
for a business establishing an enterprise architecture frameworks and viewpoints about enterprise architecture,
unit. it provides a critique of alternatives (such as between the
original Zachman Framework, TOGAF and DODAF).
The bibliographies are particularly useful.

5.1.1 Overview It treats Enterprise Architecture as not including merely

The Guide to the Enterprise Architecture
Body of Knowledge (EABOK) organizes and
characterizes the knowledge content of the
Enterprise Architecture (EA) discipline. This
organization and characterization promotes
a consistent view of EA, establishes the
scope and bounds of the EA discipline, and
places the discipline in the context of related
disciplines. The EABOK subdivides EA into
knowledge areas and topics within each area,
presents an overview of the topic, and provides
the reader references for further information.
The EABOK is a guide to EA, not the body of
knowledge itself.
EABOK[1]
diagrams and technical descriptions, but gives a holistic
view that includes US legislative requirements and guid-
ance, as well as giving technologists a better understand-
ing of business needs with a quick explanation of the
value chain for a business as outlined by Michael Porter.
It is worth reading between the lines of many sections, the
comments make many experienced information systems
and business professionals appreciate the EABOK: while
it reviews a range of approaches, it is not frightened to put
a personal point of view:
Today Zachman sees his framework as a
thinking tool...The Zachman EA Framework
has contributed to the organization of several
later frameworks and much architectural
thinking.
EABOK[1]

The current printable version is marked DRAFT, dated

06-Feb-2004, and edited by Dr Paula J Hagan. It has been Another example of possible implied criticism of some
approved for public release; distribution unlimited. No EA practitioners:
updates have been made to any publicly released version
of this document since 2004, and the project appears to Many novice EA practitioners comment
have been abandoned. that they nd the DODAF too complex

23
24 CHAPTER 5. OPEN SOURCE OR CONSORTIA-DEVELOPED FRAMEWORKS

for a starting point to build an enterprise

architecture. Other practitioners nd the
DODAF a good source of product description
information to get them started.
EABOK[1]

While many of the references to legislation and guidance

are US-centric, the issues and the references are useful to
government agencies and businesses across the world.

5.1.3 See also

Enterprise Architecture

5.1.4 References Fig 1. GERAM Framework: This set of components is identied

in the rst image and briey described in the following. Start-
[1] Guide to the (Evolving) Enterprise Architecture Body of
ing from dened concepts to be used in enterprise integration
Knowledge. 2007-01-01. Note: The document is dated
(GERA), GERAM distinguishes between the methodologies for
2004-02-06 and marked as draft. That is the last version
enterprise integration (GEEM) and the languages used to describe
of the document put out by MITRE.
structure, contents and behaviour of the enterprise (GEML).
[2] EABOK Home. MITRE.

and integration. It contained several of building blocks,

5.1.5 External links
Enterprise Architecture
(EABOK) home page.
in which the methodologies and the corresponding lan-
guages have been implemented, such as:
Body of Knowledge
Enterprise modelling tools (GEMT) to support the
enterprise integration process.

5.2 Generalised Enterprise Refer- Ontological theories (OT),

ence Architecture and Method- Generic enterprise models (GEMs) and

ology Generic modules (GMs)

Generalised Enterprise Reference Architecture and The building blocks where designed to support the mod-
Methodology (GERAM) is a generalised enterprise elling process by providing means for more ecient
architecture framework for enterprise integration and modelling.[1]
business process engineering. It identies the set of com-
ponents recommended for use in enterprise engineer- The resulting enterprise model (EM) represents all or part
ing.[1] of the enterprise operation. These models will allow sim-
ulation of operational alternatives and thereby their evalu-
This framework was developed in the 1990s by a joint ation leading. GERAM provides a generic description of
task force of both the International Federation of Au- all the elements recommended in enterprise engineering
tomatic Control (IFAC) and the International Federa- and integration.
tion of Information Processing (FIP]) on enterprise ar-
chitectures for enterprise integration. The development Generalised Enterprise Reference Architecture and
started with the evaluation of then-existing frameworks Methodology (GERAM) is an enterprise-reference archi-
for enterprise application integration, which was devel- tecture that models the whole life history of an enterprise
oped into an overall denition of a so-called generalised integration project from its initial concept in the eyes of
architecture.[2] the entrepreneurs who initially developed it, through its
denition, functional design or specication, detailed de-
sign, physical implementation or construction, and nally
5.2.1 Overview operation to obsolescence. The architecture aims to be
a relatively simple framework upon which all the func-
One of the basics of GERAM is that enterprise modelling tions and activities involved in the aforementioned phases
was seen as the major issue in enterprise engineering of the life of the enterprise-integration project can be
5.2. GENERALISED ENTERPRISE REFERENCE ARCHITECTURE AND METHODOLOGY
mapped. It also will permit the tools used by the investi-
gators or practitioners at each phase to be indicated. The
architecture dened will apply to projects, products, and
processes; as well as to enterprises.[3]
5.2.2 History
Generalised Enterprise Reference Architecture and
Methodology (GERAM) was developed in the 1990s by
an IFAC/IFIP Task Force on Architectures for Enterprise
Integration, which consisted of Peter Bernus, James G.
Nell and others. The IFAC/IFIP Task Force on Archi-
tectures for Enterprise Integration was establishment in
1990 and had studied enterprise-reference architectures
ever since.[3]
The task force established the requirements to be satised
by candidate enterprise-reference architectures and their
associated methodologies to fulll the needs of industry
for such aids to enterprise integration. The result has been
called GERAM, for Generalized Enterprise-Reference
Architecture and Methodology, by the Task Force. The
Task Force has shown that such an architecture is feasi-
ble and that several architectures presently available in
the literature can already or potentially can full such
requirements.[3]
The development of enterprise-reference architecture has
evolved from the development of Design Methodology
for Advanced Manufacturing Systems in the 1980s,[4]
such as CIMOSA, the Open System Architecture for
CIM.[5][6] The GERAM framework was rst published
by Peter Bernus and Laszlo Nemes in 1994.[2]
5.2.3 Topics
Components
The eight main components, as shown in gure 1 are:
Generic Enterprise Reference Architecture (GERA):
Denes the enterprise related generic concepts rec-
ommended for use in enterprise integration projects.
These concepts include enterprise systems life cycle;
business process modeling; modeling languages for
dierent users of the architecture (business users,
system designers, IT modeling specialists, others);
integrated model representation in dierent model
views.
Generic Enterprise Engineering Methodologies
(GEEM): Describe the generic processes of enter-
prise integration. These methodologies may be
described in terms of process models with detailed
instruction for each step of the integration process.
Generic Enterprise Modeling Languages (GEML):
Dene the generic constructs (building blocks) for
25
enterprise modeling adapted to the dierent needs
of people creating and using enterprise models.
Generic Enterprise Modeling Tools (GEMT): De-
ne the generic implementation of enterprise-
integration methodologies and modeling languages
and other support for creation and use of enterprise
models.
Enterprise Models (EM): Represents the enterprise
operation. These models will be represented using
generic modeling language constructs.
Ontological Theories (OT): Formalise the most
generic aspects of enterprise-related concepts in
terms of essential properties and axioms.
Generic Enterprise Models (GEMs): Identify refer-
ence models (partial models) which capture con-
cepts common to many enterprises. GEMs will be
used in enterprise modeling to increase modeling
process eciency.
Generic Modules (GMs): Identify generally applica-
ble products to be employed in enterprise integra-
tion (e.g. tools, integrating infrastructures, others.).
Generic Enterprise Reference Architecture
Generic Enterprise Reference Architecture (GERA) de-
nes the enterprise related generic concepts recom-
mended for use in enterprise integration projects. These
concepts include life cycle; enterprise entity types,
enterprise modelling with business process modelling; in-
tegrated model representation in dierent model views
and modelling languages for dierent users of the
enterprise architecture (business users, system designers,
IT modelling specialists, among others).[1]
Life-Cycle Concept Provides for the identication of
the life-cycle phases for any enterprise entity from entity
conception to its nal end. The Figure 2: GERA Life-
Cycle Concept, shows the GERA life cycle phases of en-
terprise entities. A total of 9 life cycle phases has been
dened.
Identication phase allows the identication of the
enterprise business or any part of it in terms of its re-
lation to both its internal and external environment.
This includes the denition general commitments of
the integration or engineering activities to be carried
out in relevant projects.
Concept phase provides for the presentation of the
management visions, missions, values, operational
concepts (build/buy, etc.), policies, plus others.
Requirement phase allows the description of opera-
tional processes and collection of all their functional,
26 CHAPTER 5. OPEN SOURCE OR CONSORTIA-DEVELOPED FRAMEWORKS
Fig 2. GERA Life-Cycle Concept.
behavioural, informational and capability require-
ments.
Design phase is the specication of operational sys-
tem with all its components satisfying the above re-
quirements. Process and resources alternatives may
be specied which provide operational alternatives
to be used during the operation.
Implementation phase describes the real operational
system which may deviate from the designed system
due to enterprise preferences or availability of com-
ponents.
Build phase supports the system manifestation,
physical implementation of resources, testing and
validation for the designed processes and the sub-
sequent release for operation.
Operation phase employs the released operational
processes and the provided resources to support the
life cycle phases of the enterprise products.
System Change/Re-Engineering phase allows to
modify or re-engineer the operational processes ac-
cording to newly identied needs or capabilities pro-
vided by new technologies.
End of Life phase supports the recycling or disposal
of the operational system at the ending of its use in
the enterprise operation. This phase has to provide
concepts for recycling and/or disposal of all or part
of the system.
Fig 3. GERA Enterprise-Entity Concept.
Enterprise Entity Type Concept Identies entity
types to be used in enterprise engineering and enterprise
integration. Adopting a recursive view of integration al-
together ve entity types with their associated life-cycles
can be identied. The recursiveness of the rst four en-
tity types can be demonstrated by identifying the role of
the dierent entities, their products and the relations be-
tween them. Figure 3: GERA Enterprise Entity Concept,
shows the GERA life cycle phases of enterprise entities.
A total of 9 life cycle phases has been dened.
Strategic Enterprise Management Entity (type 1):
denes the necessity and the starting of any enter-
prise engineering eort.
Enterprise Engineering/Integration Entity (type 2):
provides the means to carry out the enterprise entity
type 1. It employs methodologies (type 5 entity) to
dene, design, implement and build the operation of
the enterprise entity (type 3 entity).
Enterprise Entity (type 3): is the result of the oper-
ation of entity type 2. It uses methodologies (entity
type 5) and the operational system provided by en-
tity type 2 to dene, design, implement and build the
products (services) of the enterprise (type 4 entity).
5.2. GENERALISED ENTERPRISE REFERENCE ARCHITECTURE AND METHODOLOGY 27

Product Entity (type 4): is the result of the operation

of entity type 3. It represents all products (services)
of the enterprise.
Methodology Entity (type 5): represents the
methodology to be employed in any enterprise en-
tity type.

Figure 3 represents the chain of enterprise entity devel-

opments. The type 1 entity will always start creation of
any lower level entity by identifying goal, scope and ob-
jectives for the particular entity. Development and im-
plementation of a new enterprise entity (or new business
unit) will then be done by a type 2 entity; whereas a type
3 entity will be responsible for developing and manufac-
turing a new product (type 4 entity). With the possi-
ble exception of the type 1 entity all enterprise entities
will have an associated entity-life cycle. However, it is
always the operational phase of the entity-life cycle in
which the lower entity is dened, created, developed and
built. The operation itself is supported by an associated
methodology for enterprise engineering, enterprise oper-
ation, product development and production support

Fig 5. GERA Generic-Reference-Architecture Concept.

the operation of enterprise entities and entity types in all

Fig 4: GERA Enterprise-Entity Concept--Type 3.
Figure 3 also shows the life cycle of the methodology
(type 5 entity) and the process model developed during
the early life cycle phases of the methodology. However,
there must be a clear distinction between the life cycle
of the methodology with its dierent phases and its pro-
cess model. The latter is used to support the operational
phase of a particular enterprise entity. The operational
relations of the dierent entity types are also shown in
Figure 4: GERA Enterprise Entity Concept (Type 3),
which demonstrates the contributions of the dierent en-
tities to the type 3 entity life-cycle phases. The manufac-
turing entity itself produces the enterprise product in the
course of its operation phase (type 3 entity).
its aspects: functional, behaviour, information, resources
and organisation. Models which can be used for deci-
sion support by evaluating operational alternatives or for
model driven operation control and monitoring.
To hide complexity of the resulting model it will be pre-
sented to the user in dierent sub-sets (views). This view
concept is shown in Figure 5: GERA Generic Refer-
ence Architecture Concept. It is applicable during all
phases of the life cycle. Please note that the views will
be generated from the underlying integrated model and
any model manipulation. That means any change being
done in one particular view will be reected in all relevant
aspects of the model. The GERA life cycle model has
dened four dierent views: function, information, de-
cision/organisation and resource/structure. Other views
may be dened if needed and supported by the modelling
tool. In addition, the life cycle model of GERA provides
for two dierent categories of modelling: operation con-
trol and customer-service related.

Enterprise Modelling concept Enterprise Modelling Modelling Language concept Modelling languages
concept provides process models of enterprise opera- increase the eciency of enterprise modelling. In ad-
tions. Process oriented modelling allows to represent dition they allow a common representation of the enter-
28 CHAPTER 5. OPEN SOURCE OR CONSORTIA-DEVELOPED FRAMEWORKS

prise operation. Modelling languages have to accommo-
date dierent users of enterprise models; for example,
business users, system designers, and IT-modelling spe-
cialists.
Modelling languages have to support the modelling of all
entity types across all phases of their respective life cy-
cles. In addition, modelling languages have to provide
generic constructs as well as macro constructs (GEMs)
built from generic ones. The latter will further enhance
modelling productivity.
Figure 5 shows the reference architecture for those enter-
prise entity life cycle phases which require generic con-
structs. The partial level shows the place of the GEMs in
the reference architecture. The particular level indicates Enterprise engineering methodologies may be described
the life cycle phases of the enterprise entity itself.
Generic Enterprise Engineering Methodologies
and should support the dierent life cycle phases shown
in Figure 2. The enterprise integration process itself
is usually directed towards the enterprise entity type 3
(see above) operation and carried out as an enterprise
engineering task by an enterprise entity type 2 (Figures
2 and 4). The integration task may start at any relevant
engineering phase (indicated in Figure 6: Enterprise
Engineering and the Life-Cycle Concept.) of the entity
life cycle and may employ any of those phases. There-
fore, the processes relating to the dierent phases of
enterprise engineering should be independent of each
other to support dierent sequences of engineering
tasks.
in terms of process models with detailed instruction for
each step of the integration process. This allows not only
a very good representation of the methodology for its un-
derstanding, but provides for identication of informa-
tion to be used and produced, resources needed and rel-
evant responsibilities to be assigned for the integration
process. Process representation of methodologies should
employ the relevant modelling language discussed below.

Generic Enterprise-Modelling Language

Generic enterprise modelling languages (GEML) dene

generic constructs (building blocks) for enterprise mod-
elling. Generic constructs which represent the dierent
elements of the operation improve both modelling e-
ciency and model understanding. These constructs have
to be adapted to the dierent needs of people creating and
using enterprise models. Therefore, dierent languages
may exist which accommodate dierent users (e.g. busi-
ness users, system designers, IT modelling specialists,
others).[1]
Modelling the enterprise operation means to describe its
processes and the necessary information, resources and
organisational aspects. Therefore, modelling languages
have to provide constructs capable of capturing the se-
mantics of enterprise operations. This is especially im-
portant if enterprise models are to support the enterprise
operation itself.
Model-based decision support and model-driven opera-
tion control and monitoring require modelling constructs
Fig 6. Enterprise Engineering and the Life-Cycle Concept. which are supporting the end users and which represent
the operational processes according to the users percep-
Generic Enterprise engineering methodologies (GEEM) tion.
describe the process of enterprise integration and, ac- Modelling languages increase the eciency of enterprise
cording to the GERAM framework (Figure 1), will re- modelling. In addition they allow a common represen-
sult in a model of the enterprise operation. The method- tation of the enterprise operation. Modelling languages
ologies will guide the user in the engineering task of have to support the modelling of all entity types across
enterprise modelling and integration. Dierent method- all phases of their respective life cycles. In addition,
ologies may exist which will guide the user through the modelling languages have to provide generic constructs
dierent tasks required in the integration process.[1] as well as macro constructs (GEMs) build from generic
Enterprise-engineering methodologies should orient ones. The latter will further enhance modelling produc-
themselves on the life-cycle concept identied in GERA tivity.
5.2. GENERALISED ENTERPRISE REFERENCE ARCHITECTURE AND METHODOLOGY
Generic Enterprise-Modelling Tool
Generic enterprise modelling tools (GEMT) dene the
generic implementation of the enterprise integration
methodologies and modelling languages and other sup-
port for creation and use of enterprise models. Modelling
tools should provide user guidance for both the modelling
process itself and for the operational use of the mod-
els. Therefore, enterprise modelling tools designs have
to encompass not only the modelling methodology, but
should provide model enactment capability for simula-
tion of operational processes as well. The latter should
also include analysis and evaluation capabilities for the
simulation results.[1]
Enterprise Models
Enterprise models (EMs) represent the enterprise opera-
tion mostly in the form of business processes. However,
in certain cases other representations may be suitable as
well. Business processes will be represented using the
generic modelling-language constructs dened above for
the relevant engineering methodology. Enterprise opera-
tions are usually rather complex and therefore dicult to
understand if all relevant aspects of the operation are rep-
resented in a common model. To reduce the model com-
plexity for the user, dierent views should be provided
which allow the users only to see the aspect of concern.[1]
Ontological Theories
Ontological theories (OT) formalise the most generic as- [6] AMICE Consortium (1991), Open System Architecture,
pects of enterprise related concepts in terms of essen-
tial properties and axioms. Ontological theories may be
considered as 'meta-models' since they consider facts and
rules about the facts and rules of the enterprise and its 5.2.6 Further reading
models.[1]
F.B. Vernadat (1996). Enterprise Modeling and In-
Generic Enterprise Models
Generic enterprise models (GEMs) identify reference
models (partial models) which capture concepts common
to many enterprises. GEMs will be used in enterprise
modelling to increase modelling process eciency.[1]
Generic Modules
Generic Modules (GMs) identify generally applicable
products to be employed in enterprise integration (e.g.
tools, integrating infrastructures, others.).[1]
5.2.4 See also
Computer Integrated Manufacturing
CIMOSA
29
Functional Software Architecture
ISO 19439
5.2.5 References
This article incorporates public domain material from the
National Institute of Standards and Technology website
http://www.nist.gov.
[1] J.G. Nell, NIST (1997). "An Overview of GERAM"
ICEIMT'97 International Conference on Enterprise Inte-
gration Modelling Technology 1997. Updated 30 January
1997
[2] P. Bernus, and L. Nemes (1994). A Framework to
Dene a Generic Enterprise Reference Architecture and
Methodology. In: Proceedings of the International Con-
ference on Automation, Robotics and Computer Vision
(ICARCV'94), Singapore, November 1012, 1994.
[3] J.G. Nell (2006). "Requirements and Methodology for
Enterprise-Reference Architectures: A New Work Item
Proposal". updated 20 May 1996.
[4] Doumeingts, G., Vallespir, B., Darracar, D., M., De-
sign Methodology for Advanced Manufacturing Systems,
Computers in Industry, Vol. 9, pp. 271-296, December
1987.
[5] AMICE Consortium (1989). Open System Architecture
for CIM, Research Report of ESPRIT Project 688, Vol. 1,
Springer-Verlag.
CIMOSA, AD 1.0, Architecture Description, ESPRIT Con-
sortium AMICE, Brussels, Belgium.
tegration: Principles and Applications, Chapman
& Hall, London. ISBN 0-412-60550-3
T.J. Williams and Hong Li, A Specication
and Statement of Requirements for GERAM (The
Generalised Enterprise Reference Architecture and
Methodology) with all Requirements illustrated by
Examples from the Purdue Enterprise Reference Ar-
chitecture and Methodology PERA, REPORT NUM-
BER 159 Purdue Laboratory for Applied Industrial
Control November 1995, Version 1.1
D. Shorter, Editor, An evaluation of CIM mod-
elling constructs - Evaluation report of constructs for
views according to ENV 40 003, In: Computers in
Industry - Vol. 24, Nrs 2-3
T.J. Williams, et al., Architectures for integrating
manufacturing activities and enterprises, In: Com-
puters in Industry - Vol. 24, Nrs 2-3
30 CHAPTER 5. OPEN SOURCE OR CONSORTIA-DEVELOPED FRAMEWORKS
ENV 40 003 Computer Integrated Manufacturing - 5.3.1 The Need for Architecture Interop-
Systems Architecture - Framework for Enterprise
Modelling CEN/CENELEC, 1990
ENV 12 204 Advanced Manufacturing Technology tralian, Canadian, UK & US defence departments. The
- Systems Architecture - Constructs for Enterprise main purpose of IDEAS is to support coalition military
Modelling CEN TC 310/WG1, 1995
Charles J. Petrie, Jr (1992). Enterprise Integration each others capabilities, communications mechanisms
Modelling; ICEIMT Conference Proceedings, The and standard procedures.
MIT Press. ISBN 0-262-66080-6
5.2.7 External links
GERAM: Generalised Enterprise Reference Archi-
tecture and Methodology Version 1.6.3. by Peter
Bernus, March 1999.
5.3 IDEAS Group
The IDEAS Group is the International Defence En-
terprise Architecture Specication for exchange Group.
The deliverable of the project is a data exchange format
for military Enterprise Architectures. The scope is four
nation (plus NATO as observers) and covers MODAF
(UK), DoDAF (USA), DNDAF (Canada) and the Aus-
tralian Defence Architecture Framework (AUSDAF).
The initial scope for exchange is the architectural data
required to support coalition operations planning -
Systems - communications systems, networks, soft-
ware applications, etc.
Communications links between systems
Information specications - the types of information
(and their security classications) that the comms
architecture will handle
Platforms & facilities.
System & operational functions (activities)
People & organizations
Architecture meta-data - who owns it, who was the
architect, name, version, description, etc.
The work has begun with the development of a formal
ontology to specify the data exchange semantics. The
W3C Resource Description Framework (RDF) and Web
Ontology Language (OWL) will be the format used for
data exchange. A demonstration of multinational inter-
operability is scheduled for September 2007, based on
exchanging process models for casualty tracking.
erability
The need for IDEAS was identied in 2005 by the Aus-
operations planning. The ability to exchange architec-
tures between countries enables better understanding of
5.3.2 Military Application
Sharing of standard operating procedures and
doctrine. Each nation has its own operating pro-
cedures, which are usually represented in process
models (e.g. a DoDAF OV-5 Product). An ability
to share these processes between partner nations en-
ables better understanding and more ecient joint
operations.
Sharing of systems information. The nations
generally use dierent communications systems,
weapon systems and platforms. An ability to share
technical information (within classication limits)
enables better understanding of how partner nations
systems communicate and function. This allows for
better orchestration of sensors and eects across the
coalition.
Change management. The procurement cycles in
each of the nations are generally not coordinated
with each other. Ability to share future systems in-
formation amongst partner nations allows for better
forward planning.
Identication of system options. In planning a
coalition operation, it is useful for the planner to
have an accurate picture of each nations capability
contribution. This allows for selection of best ca-
pability, and reduction in redundancy and start-up
eort.
Identication of network conguration. It is im-
portant for each nation to have an understanding of
the comms laydown for an operation. An ability to
provide each nation with the same understanding of
the comms structure means there is less re-work and
less opportunity for gaps in understanding between
the nations
Assessment of Relative Performance. IDEAS
will enable exchange of complete Enterprise Archi-
tecture models, potentially allowing simulation of
capability prior to operational commitment.
Force Structures. Coalition nations will be able
to share organisational structures and orders of bat-
tle with partners (again, subject to issues of security
classication).
5.4. RM-ODP 31

5.3.3 Ontology [2] NATO C3 Agency Workshop on ontology, NC3A The

Hague, March 2008 - http://www.ideasgroup.org/file_
IDEAS is a formal, higher-order, 4D (see four dimension- download/3/MOD+Ontology.pdf
alism) ontology. It is extensional (see Extension (meta- [3] Special Oer - A Forensic Approach to Information Sys-
physics)), using physical existence as its criterion for tems Development | Cutter Consortium
identity. In practical terms, this means the ontology is
well suited to managing change over time and identifying [4] Tolk, Andreas; Jain, Lakhmi C. (Eds.) Intelligence-Based
Systems Engineering. Springer, 2011, ISBN 978-3-642-
elements with a degree of precision that is not possible
17930-3
using names alone.
The ontology is being built using the BORO Method
which has proven useful for the multi-disciplinary team 5.3.7 External links
working on IDEAS. BORO forces the ontology devel-
oper to consider each concept in terms of its physical ex- IDEAS Group Ocial site
tent. This means there can be no argument about names Presentation on IDEAS by Dave McDaniel from In-
or meaning - something either exists or it doesn't. The tegrated EA 2008
BORO Method also deals with classes and relationships
by tracing them back to their members (classes) or ends IDEAS Group on LinkedIn
(relationships). Conceptual Interoperability

5.3.4 Implementation
5.4 RM-ODP
To date, there have been three IDEAS implementations:
Reference Model of Open Distributed Processing
IDEAS Ontology Development Plug-in for Sparx (RM-ODP) is a reference model in computer science,
Systems - Enterprise Architect. The Beta test which provides a co-ordinating framework for the stan-
version can be downloaded from http://www. dardization of open distributed processing (ODP). It
modelfutures.com/software/ supports distribution, interworking, platform and tech-
nology independence, and portability, together with an
An OV-5 export interface for Telelogic System Ar-
enterprise architecture framework for the specication of
chitect. The interface was developed by Silver Bul-
ODP systems.
let inc. under contract to the DoD
An OV-5 import/export interface for Sparx En-
terprise Architect developed by Model Futures for
MOD (under sub-contract to Serco Consulting)
The MOD Ontology Demonstrator - used
the IDEAS model to demonstrate a sim-
ple geopolitical ontology. It can be down-
loaded from http://www.modaf.com/News/69/
mod-ontology-demonstrator-released
The UK MOD AV-2 demonstrator - implemented
a shared ontology based on IDEAS that is used to
populate AV-2 in MODAF
The RM-ODP view model, which provides ve generic and com-
plementary viewpoints on the system and its environment.
5.3.5 IDEAS Publications & Presentations
RM-ODP, also named ITU-T Rec. X.901-X.904
The IDEAS work has been presented at a number of and ISO/IEC 10746, is a joint eort by the
conferences.[1][2]
It has also been cited in a Cutter Con- International Organization for Standardization (ISO), the
[3]
sortium white paper and in a book on Systems Engi- International Electrotechnical Commission (IEC) and
neering from Springer Verlag[4] the Telecommunication Standardization Sector (ITU-T)
.[1]

5.3.6 Notes
[1] Bailey, Ian; Partridge, Chris. Working with Extensional
Ontology for Defence Applications. Ontology in Intelli-
gence Conference, 2009, GMU, Fairfax, VA
5.4.1 Overview
The RM-ODP is a reference model based on precise
concepts derived from current distributed processing
32 CHAPTER 5. OPEN SOURCE OR CONSORTIA-DEVELOPED FRAMEWORKS

developments and, as far as possible, on the use of
formal description techniques for specication of the
architecture. Many RM-ODP concepts, possibly under
dierent names, have been around for a long time and
have been rigorously described and explained in exact
philosophy (for example, in the works of Mario Bunge)
and in systems thinking (for example, in the works of
Friedrich Hayek). Some of these conceptssuch as
abstraction, composition, and emergencehave recently
been provided with a solid mathematical foundation in
category theory.
RM-ODP has four fundamental elements:
an object modelling approach to system specica-
tion;
the specication of a system in terms of separate but
interrelated viewpoint specications;
the denition of a system infrastructure providing
distribution transparencies for system applications;
and
2. Foundations:[7] Contains the denition of the con-
cepts and analytical framework for normalized de-
scription of (arbitrary) distributed processing sys-
tems. It introduces the principles of conformance
to ODP standards and the way in which they are ap-
plied. In only 18 pages, this standard sets the basics
of the whole model in a clear, precise and concise
way.
3. Architecture:[8] Contains the specication of the re-
quired characteristics that qualify distributed pro-
cessing as open. These are the constraints to which
ODP standards must conform. This recommenda-
tion also denes RM-ODP viewpoints, subdivisions
of the specication of a whole system, established to
bring together those particular pieces of information
relevant to some particular area of concern.
4. Architectural Semantics:[9] Contains a formalization
of the ODP modeling concepts by interpreting many
concepts in terms of the constructs of the dierent
standardized formal description techniques.

a framework for assessing system conformance.

Viewpoints modeling and the RM-ODP framework
The RM-ODP family of recommendations and interna-
tional standards denes a system of interrelated essential Most complex system specications are so extensive that
concepts necessary to specify open distributed processing no single individual can fully comprehend all aspects of
systems and provides a well-developed enterprise archi- the specications. Furthermore, we all have dierent in-
tecture framework for structuring the specications for terests in a given system and dierent reasons for examin-
any large-scale systems including software systems. ing the systems specications. A business executive will
ask dierent questions of a system make-up than would
a system implementer. The concept of RM-ODP view-
5.4.2 History points framework, therefore, is to provide separate view-
points into the specication of a given complex system.
Much of the preparatory work that led into the adop- These viewpoints each satisfy an audience with interest
tion of RM-ODP as an ISO standard was carried out by in a particular set of aspects of the system. Associated
the Advanced Networked Systems Architecture (ANSA) with each viewpoint is a viewpoint language that opti-
project. This ran from 1984 until 1998 under the leader- mizes the vocabulary and presentation for the audience
ship of Andrew Herbert (now MD of Microsoft Research of that viewpoint.
in Cambridge), and involved a number of major comput- Viewpoint modeling has become an eective approach
ing and telecommunication companies. Parts 2 and 3 of for dealing with the inherent complexity of large dis-
the RM-ODP were eventually adopted as ISO standards tributed systems. Current software architectural prac-
in 1996. Parts 1 and 4 were adopted in 1998. tices, as described in IEEE 1471, divide the design ac-
tivity into several areas of concerns, each one focusing
on a specic aspect of the system. Examples include the
5.4.3 RM-ODP topics
4+1 view model, the Zachman Framework, TOGAF,
DoDAF and, of course, RM-ODP.
RM-ODP standards
A viewpoint is a subdivision of the specication of a
RM-ODP consists of four basic ITU-T Recommenda- complete system, established to bring together those par-
tions and ISO/IEC International Standards:[2][3][4][5] ticular pieces of information relevant to some particular
area of concern during the analysis or design of the sys-
1. Overview:[6] Contains a motivational overview of tem. Although separately specied, the viewpoints are
ODP, giving scoping, justication and explanation not completely independent; key items in each are identi-
of key concepts, and an outline of the ODP archi- ed as related to items in the other viewpoints. Moreover,
tecture. It contains explanatory material on how each viewpoint substantially uses the same foundational
the RM-ODP is to be interpreted and applied by its concepts (dened in Part 2 of RM-ODP). However, the
users, who may include standard writers and archi- viewpoints are suciently independent to simplify rea-
tects of ODP systems. soning about the complete specication. The mutual con-
5.4. RM-ODP 33

sistency among the viewpoints is ensured by the architec- exibility. However, this makes more dicult, among
ture dened by RM-ODP, and the use of a common ob- other things, the development of industrial tools for mod-
ject model provides the glue that binds them all together. eling the viewpoint specications, the formal analysis of
More specically, the RM-ODP framework provides ve the specications produced, and the possible derivation
generic and complementary viewpoints on the system and of implementations from the system specications.
its environment: In order to address these issues, ISO/IEC and the
ITU-T started a joint project in 2004: ITU-T Rec.
The enterprise viewpoint, which focuses on the pur- X.906|ISO/IEC 19793: Information technology - Open
pose, scope and policies for the system. It describes distributed processing - Use of UML for ODP system
the business requirements and how to meet them. specications. This document (usually referred to as
UML4ODP) denes use of the Unied Modeling Lan-
The information viewpoint, which focuses on the guage 2 (UML 2; ISO/IEC 19505), for expressing the
semantics of the information and the information specications of open distributed systems in terms of the
processing performed. It describes the information viewpoint specications dened by the RM-ODP.
managed by the system and the structure and content
It denes a set of UML Proles, one for each viewpoint
type of the supporting data.
language and one to express the correspondences be-
The computational viewpoint, which enables distri- tween viewpoints, and an approach for structuring them
bution through functional decomposition on the sys- according to the RM-ODP principles. The purpose of
tem into objects which interact at interfaces. It de- UML4ODP to allow ODP modelers to use the UML
scribes the functionality provided by the system and notation for expressing their ODP specications in a stan-
its functional decomposition. dard graphical way; to allow UML modelers to use the
RM-ODP concepts and mechanisms to structure their
The engineering viewpoint, which focuses on the large UML system specications according to a mature
mechanisms and functions required to support dis- and standard proposal; and to allow UML tools to be used
tributed interactions between objects in the system. to process viewpoint specications, thus facilitating the
It describes the distribution of processing performed software design process and the enterprise architecture
by the system to manage the information and pro- specication of large software systems.
vide the functionality.
In addition, ITU-T Rec. X.906 | ISO/IEC 19793 en-
The technology viewpoint, which focuses on the ables the seamless integration of the RM-ODP enterprise
choice of technology of the system. It describes the architecture framework with the Model-Driven Archi-
technologies chosen to provide the processing, func- tecture (MDA) initiative from the OMG, and with the
tionality and presentation of information. service-oriented architecture (SOA).

5.4.4 RM-ODP and UML 5.4.5 Applications

Currently there is growing interest in the use of UML for In addition, there are several projects that have used or
system modelling. However, there is no widely agreed currently use RM-ODP for eectively structuring their
approach to the structuring of such specications. This systems specications:
adds to the cost of adopting the use of UML for system
specication, hampers communication between system The COMBINE project[10]
developers and makes it dicult to relate or merge sys-
tem specications where there is a need to integrate IT The ENVRI and ENVRIplus projects for common
systems. operations of environmental research infrastructures
are developing the ENVRI Reference Model[11]
Although the ODP reference model provides abstract lan-
guages for the relevant concepts, it does not prescribe par- The Reference Architecture for Space Data Systems
ticular notations to be used in the individual viewpoints. (RASDS)[12] From the Consultative Committee for
The viewpoint languages dened in the reference model Space Data Systems.
are abstract languages in the sense that they dene what
concepts should be used, not how they should be repre- Interoperability Technology Association for Infor-
sented. This lack of precise notations for expressing the mation Processing (INTAP), Japan.[13]
dierent models involved in a multi-viewpoint specica-
tion of a system is a common feature for most enterprise The Synapses European project.[14]
architectural approaches, including the Zachman Frame-
work, the "4+1" model, or the RM-ODP. These ap- A 239-item reference list covering RM-ODP standards as
proaches were consciously dened in a notation- and well as related research, applications and case studies was
representation-neutral manner to increase their use and included in [15]
34 CHAPTER 5. OPEN SOURCE OR CONSORTIA-DEVELOPED FRAMEWORKS

5.4.6 See also [5] Some resources related to the current version of | ITU-T
X.906 | ISO/IEC 19793 Use of UML for ODP systems
Enterprise Architecture framework specications are also available from the RM-ODP re-
source site. They include the UML Proles of the ve
Enterprise Collaboration Architecture ODP viewpoints, the viewpoint metamodels, the GIF les
for the ODP-specic icons, etc.
Enterprise Modelling Methodology/Open Dis-
tributed Processing (EMM/ODP) [6] ISO/IEC 10746-1 | ITU-T Rec. X.901
Reference model
[7] ISO/IEC 10746-2 | ITU-T Rec. X.902
Triune Continuum Paradigm
[8] ISO/IEC 10746-3 | ITU-T Rec. X.903
View model
[9] ISO/IEC 10746-4 | ITU-T Rec. X.904
ISO/IEC JTC 1/SC 7
[10] COMBINE
5.4.7 Notes and references
[11] ENVRI Reference Model
[1] A complete and updated list of references to publications
related to RM-ODP (books, journal articles, conference [12] Reference Architecture for Space Data Systems (RASDS)
papers, etc.) is available at the RM-ODP resource site.
[13] Interoperability Technology Association for Information
[2] In the same series as the RM-ODP are a number of other Processing (INTAP)
standards and recommendations for the specication and
development of open and distributed system, for which
[14] The Synapses Project: a three-year project funded under
RM-ODP provides a standardization framework:
the EU 4th Framework Health Telematics Programme
ITU-T Rec. X.950 | ISO/IEC 13235-1:1998, Trad-
ing function: Specication. [15] Kilov, H., Linington, P.F., Romero, J.R., Tanaka, A., Val-
lecillo, A.: The reference model of open distributed pro-
ITU-T Rec. X.952 | ISO/IEC 13235-3:1998, Pro-
cessing: foundations, experience and applications. Com-
vision of Trading Function using OSI directory ser-
put. Stand. Interfaces 35, 247256 (2013)
vice.
ITU-T Rec. X.920 | ISO/IEC 14750:1999, Inter-
face Denition Language.
5.4.8 External links
ITU-T Rec. X.931 | ISO/IEC 14752:2000, Proto-
col support for computational interactions.
RM-ODP Resource site
ITU-T Rec. X.930 | ISO/IEC 14753:1999, Inter-
face references and binding.
Open Distributed Processing - Reference Model
ITU-T Rec. X.960 | ISO/IEC 14769:2001, Type
repository function.
RM-ODP information at LAMS, Swiss Federal In-
ITU-T Rec. X.910 | ISO/IEC 14771:1999, Naming stitute of Technology, Lausanne (EPFL), Switzer-
framework. land.
ITU-T Rec. X.911 | ISO/IEC 15414:2002,
Reference model - Enterprise language. Ocial Record of the ANSA project
ISO/IEC 19500-2:2003, General Inter-ORB Proto-
col (GIOP)/Internet Inter-ORB Protocol (IIOP). Computing Laboratory, University of Kent, Canter-
bury UK.
[3] Copies of the RM-ODP family of standards can be ob-
tained either from ISO or from ITU-T. Parts 1 to 4 of
the RM-ODP are available for from free download from FORMOSA (Formalisation of ODP Systems Archi-
ISO. All ODP-related ITU-T Recommendations, includ- tecture), University of Stirling, UK.
ing X.9xx series, are freely available from the ITU-T.
Distributed and Cooperative Systems, UMPC,
[4] There is also a very useful hyperlinked version of Parts Paris, France.
2 and 3 of the RM-ODP, together with an index to the
Reference Model, made available in keeping with a res-
olution of the ISO council. The Table of Contents and ILR, Networks and ComputerScience Department
Index were prepared by Lovelace Computing and are be- of ENST, Paris France.
ing made available by Lovelace Computing as a service to
the standards community. Distributed Systems Technology Center, Australia.
5.5. THE OPEN GROUP ARCHITECTURE FRAMEWORK 35

provide a common vocabulary

include a list of recommended standards
include a list of compliant products that can be used
to implement the building blocks

The ANSI/IEEE Standard 1471-2000 specication of ar-

chitecture (of software-intensive systems) may be stated
as: the fundamental organization of a system, embodied
in its components, their relationships to each other and
the environment, and the principles governing its design
and evolution.
However TOGAF has its own view, which may be spec-
ied as either a formal description of a system, or a
detailed plan of the system at component level to guide
its implementation, or as the structure of components,
their interrelationships, and the principles and guidelines
governing their design and evolution over time.
The Architecture Development Method (ADM) is core
of TOGAF which describes a method for developing and
managing the lifecycle of enterprise architecture.

Structure of the TOGAF Architecture Development Method

(ADM).[1] 5.5.2 TOGAF pillars
Enterprise architecture domains
5.5 The Open Group Architecture
TOGAF is based on four interrelated areas of specializa-
Framework tion called architecture domains:

The Open Group Architecture Framework (TOGAF)
is a framework for enterprise architecture that pro-
vides an approach for designing, planning, implement-
ing, and governing an enterprise information technology
architecture.[2] TOGAF is a high level approach to design.
It is typically modeled at four levels: Business, Applica-
tion, Data, and Technology. It relies heavily on modu-
larization, standardization, and already existing, proven
technologies and products.
TOGAF has been developed starting 1995 by The
Open Group, based on DoD's TAFIM. As of 2016,
The Open Group reports that TOGAF is employed by
80% of Global 50 companies and 60% of Fortune 500
companies.[3]
5.5.1 Overview
An architecture framework is a set of tools which
can be used for developing a broad range of dierent
architectures.[4] It should: Architecture Development Method
Business architecture which denes the business
strategy, governance, organization, and key business
processes of the organization
Applications architecture which provides a blueprint
for the individual systems to be deployed, the inter-
actions between the application systems, and their
relationships to the core business processes of the
organization with the frameworks for services to be
exposed as business functions for integration
Data architecture which describes the structure of
an organizations logical and physical data assets and
the associated data management resources
Technical architecture, or technology architecture,
which describes the hardware, software, and net-
work infrastructure needed to support the deploy-
ment of core, mission-critical applications

The Architecture Development Method (ADM) is ap-

describe a method for dening an information sys- plied to develop an enterprise architecture which will
tem in terms of a set of building blocks meet the business and information technology needs of
show how the building blocks t together an organization. It may be tailored to the organizations
needs and is then employed to manage the execution of
contain a set of tools architecture planning activities.[5]
36 CHAPTER 5. OPEN SOURCE OR CONSORTIA-DEVELOPED FRAMEWORKS

The process is iterative and cyclic. Each step checks with Gaining TOGAF Certied status automatically confers
Requirements. Phase C involves some combination of free membership of the Association of Enterprise Archi-
both Data Architecture and Applications Architecture. tects.[9]
Additional clarity can be added between steps B and C
in order to provide a complete information architecture.
History
Performance engineering working practices are applied
to the Requirements phase, and to the Business Architec-
ture, Information System Architecture, and Technology
architecture phases. Within Information System Archi-
tecture, it is applied to both the Data Architecture and
Application Architecture.

Enterprise Continuum

The Enterprise Continuum is a way of classifying so-

lutions and architectures on a continuum that ranges
from generic foundation architectures through to tailored
organization-specic both within and outside the Archi-
tecture Repository.[6] These include architectural mod-
els, architectural patterns, architecture descriptions, and
other artifacts. These artifacts may exist within the enter-
prise and also in the IT industry at large.
The Enterprise Continuum consists of both the Ar-
chitecture Continuum and the Solutions Continuum.
The Architecture Continuum species the structuring of DoD Standards-Based Architecture Planning Process in
reusable architecture assets and includes rules, represen- TAFIM.[10]
tations, and relationships of the information system(s)
available to the enterprise. The Solutions Continuum de- TOGAF was initiated in the early 1990s as methodology
scribes the implementation of the Architecture Contin- for the development of technical architecture, and has
uum by dening reusable solutions building blocks. been developed by The Open Group into an extensive
enterprise architecture framework.[11] In 1995, the rst
version of TOGAF (TOGAF 1.0) was presented. This
version was mainly based on the Technical Architecture
5.5.3 TOGAF culture Framework for Information Management (TAFIM), de-
veloped since the late 1980s by the US Department of
TOGAF Certied Tools Defense

The Open Group has a certication program for TOGAF In December 2001
9 Tools. For the latest register of certied tools see The
Open Group register.[7]
Qualications
The Open Group oversees formal qualications in TO-
GAF at two levels, which can be taken following formal
training or self-study.[8]
Foundation (Level I) Ensures that an individual under-
stands Enterprise Architecture along with core concepts
and terminology of TOGAF.[8]
Certied (Level II) Further to the Foundation quali-
cation, this establishes that the candidate is able to analyse
and apply their knowledge to business problems.[8]
[12]
TOGAF 7, the Technical Edition,
was published. TOGAF 8 (Enterprise Edition) was
rst published in December 2002 and republished in up-
dated form as TOGAF 8.1 in December 2003. Around
2005 TOGAFTM became a registered trademark of The
Open Group.[13] In November 2006 the Open Group re-
leased TOGAF 8.1.1. According to The Open Group, as
of February 2011, over 15,000 individuals are TOGAF
Certied.[14] As of September 2012 the ocial register
has over 20,000 certied individuals.
An evolutionary development from TOGAF 8, TOGAF
9 includes many new features including:[15][16]
Increased rigor, including a formal Content Meta-
model that links the artifacts of TOGAF to-
gether (although there are some problems with the
Metamodel)[17]
Architecture repository and the Enterprise Contin-
uum
5.5. THE OPEN GROUP ARCHITECTURE FRAMEWORK
Elimination of unnecessary dierences, and many
more examples and templates
Additional guidelines and techniques include:
A formal business-driven approach to architecture
Business capability-based planning
Guidance on how to use TOGAF to develop Security
Architectures and SOA
The latest version is TOGAF 9.1, launched on 1 Decem-
ber 2011.[18]
The Open Group provides TOGAF free of charge
to organizations for their own internal noncommercial
purposes.[19]
Criticism
Despite TOGAF being considered as the de facto stan-
dard in an EA practice, it is not without its critics:
Research evidence shows that most TOGAF rec-
ommendations are usually found inapplicable and
not followed even in the organizations included in
the list of TOGAF-users provided by The Open
Group.[20] That is why TOGAF can be considered
only as a toolkit of random EA-related recommen-
dations and "using TOGAF can be best explained
as studying TOGAF and then doing something else
instead"[21]
Real examples demonstrating the actual practical
usage of TOGAFs recommendations are missing.
There is a pressing need for some detailed worked
examples and use cases. Although these were re-
quested, they were not forthcoming from TOGAF
trainers or The Open Group[22]
EA practitioners report that TOGAF can hardly
be followed step-by-step. Our initial assumptions
about TOGAF were that it would be a sort of
'methodology' that we could follow to produce our
EA, however this turned out not to be the case[22]
TOGAFs prescriptions are vague and inarticulate
since it only states that the ADM should be adapted
without specifying how[23]
Jason Bloomberg argues that for many organiza-
tions, TOGAF has gained traction simply because
its better than doing nothing[24]
5.5.4 References
[1] Stephen Marley (2003). Architectural Framework, at
aiwg.gsfc.nasa.gov, NASA /SCI. Retrieved 10 Dec 2008
(webarchive.org).
37
[2] Dirk Draheim, Gerald Weber eds. (2007) Trends in Enter-
prise Application Architecture: 2nd International Confer-
ence, TEAA 2006, Berlin, Germany, November 29 - De-
cember 1, 2006, Revised Selected Papers. p. 260
[3] TOGAF Worldwide
[4] TOGAF Introduction The Open Group Architecture
Framework. Accessed 22 Jan 2009.
[5] The process ow can be seen as an image located here:
Architecture Development Cycle
[6] Enterprise Continuum. The Open Group. Retrieved 4
January 2014.
[7] The Open Group Tool Certication Register
[8] TOGAF 9 Certication. The Open Group. Retrieved 11
January 2014.
[9] TOGAF Certication FAQ. The Open Group. Re-
trieved 11 January 2014.
[10] Department of Defense (1996). Technical Architecture
Framework for Information Management. Vol. 4. April
1996
[11] Marc Lankhorst (2013) Enterprise Architecture at Work:
Modelling, Communication and Analysis p. 23
[12] Jaap Schekkerman (2003) How to Survive in the Jungle of
Enterprise Architecture. p. 119
[13] Tom van Sante, Hans Van Den Bent (2007) Togaf the
Open Group Architectural Framework: A Management
Guide. p. iv
[14] 15,000 certications
[15] Whats New in TOGAF 9?". The Open Group. 2009.
Retrieved 13 January 2017.
[16] Veryard, Richard (2009). TOGAF 9. Retrieved 13 Jan-
uary 2017.
[17] Gerber A; Van der Merwe, A; Kotze, P: 2010. Towards
the Formalisation of the TOGAF Content Metamodel us-
ing Ontologies. To appear in: Proceedings of The 12th
International Conference on Enterprise Information Sys-
tems (ICEIS 2010). INSTICC
[18] TOGAF 9.1 White Paper An Introduction to TOGAF
Version 9.1 http://www.opengroup.org/togaf/
[19] The Open Group (2011). TOGAF Version 9 - Down-
load. Architecture Forum. Retrieved on 2011-11-
17 from http://www.opengroup.org/architecture/togaf9/
downloads.htm.
[20] Enterprise architecture is not TOGAF, Kotusev, S., Jan-
uary 2016
[21] The critical scrutiny of TOGAF, Kotusev, S., April
2016
[22] Anderson, P., Backhouse, G., Townsend, J., Hedges, M.
and Hobson, P. (2009). Doing Enterprise Architecture:
Enabling the Agile Institution. Bristol, United Kingdom:
Joint Information Systems Committee (JISC).
38 CHAPTER 5. OPEN SOURCE OR CONSORTIA-DEVELOPED FRAMEWORKS

[23] Winter, K., Buckl, S., Matthes, F. and Schweda, C. M.

(2010). Investigating the State-of-the-Art in Enterprise Ar-
chitecture Management Methods in Literature and Practice.
In: Sansonetti, A., ed. Proceedings of the 4th Mediter-
ranean Conference on Information Systems, Tel Aviv, Is-
rael.

[24] Enterprise Architecture: Don't Be a Fool with a Tool,

Jason Bloomberg, visited 19 May 2016

5.5.5 External links

Ocial website
TOGAF 9.1 Online

TOGAF 8.1.1 Online

Developer.com: TOGAF: Establishing Itself As the

Denitive Method for Building Enterprise Architec-
tures in the Commercial World (June 2004)
TOGAF or not TOGAF: Extending Enterprise Ar-
chitecture beyond RUP (January 2007)
Practical advice: How to bring TOGAF to life (Oc-
tober 2007)
Chapter 6

Commercial frameworks

6.1 Integrated Architecture 6.2 OBASHI

Framework
The OBASHI methodology provides a framework and
method for capturing, illustrating and modeling the rela-
The Integrated Architecture Framework (IAF) is an
tionships, dependencies and dataows between business
enterprise architecture framework that covers business,
and Information technology (IT) assets and resources in
information, information system and technology
a business context.
infrastructure.[1][2]
This framework has been developed by Capgemini since
the 1990s, from the experience of practicing architects on
projects for clients across the group. The rst version was
released in 1996 and was based on the Zachman Frame-
work and Spewaks ideas about Enterprise Architecture
Planning.[3]
The Integrated Architecture Framework is:

A comprehensive framework to deliver market-

leading solutions
Adaptable to the specic needs of an organization
Scalable from individual projects to enterprise-wide
transformation A Business and IT (B&IT) diagram built using the OBASHI
Framework.
A recognized architecture framework in The Open
Groups IT Architecture Certication program It is a formal and structured way of communicat-
(ITAC).[4] ing the logical and physical relationships and depen-
dencies between IT assets and resources (Ownership,
The Integrated Architecture Framework has evolved Business Processes, Applications, Systems, Hardware,
based on real-world experience, and continues to provide and Infrastructure) to dene the business services of a
strong focus on the need to understand business require- modern enterprise.
ments and drivers, and the need for all aspects of the ar-
chitecture and all architectural decisions to be traceable The name OBASHI is a licensed trademark of OBASHI
back to these business priorities. Ltd.

6.1.1 References 6.2.1 Core Principle

[1] Enterprise, Business and IT Architecture and the Inte-
grated Architecture Framework at capgemini.com
[2] van't Wout, J., Waage, M., Hartman, H., Stahlecker, M.,
Hofman, A. (2010). The Integrated Architecture Frame-
work Explained - (link)
[3] Jaap Schekkerman (2003). How to Survive in the Jungle
of Enterprise Architecture Frameworks. page 139-144.
[4] ITAC List of Recognized Methods at opengroup.org
OBASHI is based around a core principle: that IT exists
for one reason, namely, to manage the ow of data be-
tween business assets.
Business resources (which include people) and IT assets
are either providers of data, consumers of data or provide
the conduit through which the data can ow.
The role of IT is to support, process and optimise the ow
of data to maximise business/organisational performance.

39
40 CHAPTER 6. COMMERCIAL FRAMEWORKS

6.2.2 The Origins of OBASHI of the plant. These models derive real-time input from
digital sensors attached to physical equipment through-
The OBASHI framework was invented by Fergus out the manufacturing process and are built to understand
Cloughley and Paul Wallis of Stroma Software Ltd. dur- the contextual relationship between the assets and process
ing late 2001, following their collaboration on a project ow.
to help plant managers visualise and understand how and By linking the model to the commodities markets the
why IT assets supported business services within British real costs/values of ow can be displayed, monitored and
Petroleum, Grangemouth, Scotland. trended as dollars per second, enabling the transposition
The subsequent OBASHI methodology was born out of from tonnes per hour. In turn, this enables business pro-
the need for business professionals to easily understand cesses to be optimised around value, and each assets con-
the dollar per second value of dataow that supports their tribution to the cost/value of the ow be evaluated in -
business services in a simple and meaningful way so ac- nancial terms.
curate and better informed operational and strategic de-
cisions could be made.
Data ows in the modern business
Cloughley and Wallis recognized that by developing a
methodology around the OBASHI framework, the exist- The contextual understanding of the relationships be-
ing methods for costing and valuing the ow of data in tween physical assets and ows is used within OBASHI
the Oil & Gas / Process Control industry could be made to model the ow of data between business services and
universally applicable to ows of data in all sectors. IT equipment.
The methodology entails capturing, documenting, model- Within the OBASHI methodology, business resources
ing, analysing, simulating and optimizing the cost / value and IT assets are regarded as either providers of data, con-
of the ow of data between assets and business resources. sumers of data, or provide the conduit through which the
data can ow.
DCS - CAD in Process control People provide and consume data daily, as do applica-
tions and systems. Hardware and cables act as conduits
The Oil & Gas, Chemical, Pharmaceutical, Power Gener- through which data ows: between desks, through oce
ation, Water, Food and Beverage, Cement, Steelmaking and corporate networks, across the internet, through deep
and Paper industries have relied on Distributed Control sea cables and via satellites.
Systems (DCS) to manage and control their Manufactur- Across all businesses, the equivalents of the pipes, valves,
ing and Process Control systems. pumps, meters and sensors of the oil and gas industry are
The ow of data for I/O control purposes is fundamen- the people, hubs, cables, routers, servers, and desktops
tal to the safe and ecient function of plant operations. through which data ows.
A clear and concise understanding of the cause and ef- By utilising comparable contextual relationships the
fect of this data ow is a prerequisite to plant operations, OBASHI methodology enables dataow to be analysed in
business optimization and Health and Safety governance. a similar manner to that of process ow within the man-
This clear and concise understanding is supported by a ufacturing industry, which is central to business perfor-
rigorous approach to documentation, namely: Computer mance optimisation.
Aided Design (CAD) diagrams & models; Piping and
Instrumentation diagrams (P&IDs); Process Flow Dia-
grams (PFDs); and Cause and Eect diagrams.
6.2.3 Characteristics
Many other add-on technologies can be linked to the The OBASHI Methodology models the enterprise/an
ows of plant data to support and optimise the plant run- organisation in six horizontal layers. The layers provide
ning conditions, for example: Chemical Process model- a framework (the OBASHI framework) for organising
ing, Computer simulation, Process optimization and plant individual elements that represent individual Business or
maintenance management systems. IT assets and resources. The layers are:
The OBASHI Framework and methodology were de-
veloped to mimic this rigorous approach and provide con- Ownership
textual documentation to support safe and ecient IT & Business Process
Business operational practices.
Application

Data ows in the Oil and Gas Industries System

Hardware
Computer models are used within manufacturing and
process industries to control and simulate the operation Infrastructure
6.2. OBASHI 41

Placing the elements above or below each other within the Ownership Layer The Ownership Layer contains ele-
framework signies a relationship between the elements. ments representing the person(s) or group(s) that owns,
For example, placing an Owner element above a Business or is responsible for, business processes portrayed in the
Process element signies that the business processes be- Business Layer. Ownership elements can be positioned
longs to that owner. Placing a business function above an beneath other ownership elements to create a hierarchy of
application signies that the process uses that application owners. Example owners could be: Accountancy, Plan-
etc... ning Manager, Logistics, New York, Purchasing Ocer
Elements can be connected on the diagram to denote a and Environmental Health.
physical relationship, such as the connection between a
hardware element and an infrastructure element. De-
pendencies can also be documented on the diagram
to show explicit non-obvious relationships between ele-
ments, such as the reliance of a business process on a third
party resource.
Each element can be referenced to supporting documen-
tation to provide a supporting context for that element.
The ow of data (dataows) can be superimposed on the
diagrams to depict a sequence of elements required to
support a business service.
The combination of one or more OBASHI diagrams form
a contextual model for analysis. Business Layer The Business Layer contains elements
representing the business processes or functions that are
being used by the Owner(s). These elements are posi-
The OBASHI Framework tioned under their appropriate Owner. Examples could
be: Monthly Balance, Sales Transactions, Tank Stock
These Layers provide the framework for organising the Management, Production Data and Capture Budgeting.
elements that represent individual Business or IT assets /
resources.
The six layers are:

Ownership

Business Process

Application

System

Hardware
Application Layer The Application Layer contains el-
ements representing software applications. These are po-
Infrastructure
sitioned beneath the business processes that utilise them.
Examples could include: Excel, Oracle, Sage, SAP and
They are collectively known as OBASHI PeopleSoft.
42 CHAPTER 6. COMMERCIAL FRAMEWORKS

System Layer The System Layer contains elements
representing the operating systems on which the appli-
cations run. These elements are positioned beneath the
appropriate applications. Examples could be: Windows
XP, Unix, Solaris, Linux and Vista.
resources and dataows in an easy-to-understand visual
format.
Through the use of a tool which supports the OBASHI
Framework a repository of elements and relationships can
be established. By using a graphical interface to create the
B&IT diagrams the tool can build an interactive model of
these relationships, with the B&IT diagram acting as a
dynamic interface.

Hardware Layer The Hardware Layer contains ele-

ments representing the computer hardware on which the
operating systems run. These elements are positioned be-
neath the appropriate operating systems. Examples could
be: Workstations, Servers, Laptops, Tablet PCs, and Main-
frames.

Infrastructure Layer The Infrastructure Layer con-

tains elements representing the network infrastructure
into which the hardware is connected. Infrastructure el-
ements can be positioned beneath other infrastructure
elements to create a hierarchy that supports the busi-
ness. Examples could be: Switches, Routers, Multiplexers,
Bridges and Hubs.

B&IT Diagrams Behind each element information can be stored within the
repository: business, nancial and/or technical. This data
The OBASHI framework is used to create Business and may be captured manually, or automatically from data
IT (B&IT) diagrams. A B&IT diagram is a diagrammatic held within existing systems. This information can then
representation of the logical and physical relationships be viewed, manipulated and analysed within its business
(connectivity) between an organisations IT assets and re- context.
sources and the business operations which they support.
A B&IT diagram is made up of elements. Individual el-
ements represent individual business and IT assets and Rules
resources.
By employing the OBASHI framework, B&IT dia- The OBASHI Framework comprises the following rules
grams are able to accurately depict the complex inter- which govern the implicit and explicit relationships be-
relationships and dependencies of business processes, IT tween elements.
6.2. OBASHI 43

1. An element placed beneath or above another ele-

ment has an implicit relationship with that element.

2. All elements within the same layer have an implicit

relationship to each other.

3. Connected elements have an explicit relationship to

each other, with the following rules governing con-
nectivity:

4. A connection is a bi-directional relationship

(a) An Infrastructure element may be connected

to one or more Infrastructure or Hardware el-
ements.
(b) A Hardware element may be connected to one
or more Infrastructure or System elements.
(c) A System element may be connected to one or
more Hardware or Application elements.
(d) An Application element may be connected to
one or more System, Application or Business The DAV enables cost/value statistics to be generated to
elements. understand the contribution IT assets make to the busi-
ness. Analysis of the DAV can highlight vulnerabilities,
(e) A Business element may be connected to one mis-alignment and areas for consolidation.
or more Application, Business or Owner ele-
ments.
(f) An Owner element may be connected to one 6.2.4 Fields of use
or more Business or Owner elements.
The OBASHI Methodology can be used in the following
5. A dependency is a uni-directional relationship i.e. elds:
element X may be dependent on element Y, but el-
ement Y might not be dependent on element X. Availability
6. An element may have one or more instances within Business Architecture
a layer.
Business Continuity
7. An element can exist on more than one OBASHI
diagram. Business Process Management (BPM)
8. A dataow comprises two or more connected ele- Business Service Management
ments.
Business Technology Optimisation (BTO)
9. A dataow can contain one or more dataows, en-
abling a hierarchy of dataows. Change Management

10. A dataow may span multiple Business and IT dia- CHAZOP (Computer Hazardous Operation Analy-
grams. sis)

COBIT
The Dataow Analysis View (DAV) Data Center Management
The OBASHI Dataow Analysis View (DAV) is a Enterprise Architecture (EA)
graphical and statistical representation of all the business
and IT resources, and attributed nancial values, that sup- Governance & Auditing
port an individual data ow. A DAV illustrates to busi- Grid Computing
ness professionals how and why IT systems interact with
day-to-day business processes. Information Architecture (IA)
All of the physical assets required for the logical data ow Enterprise Information Security Architecture
to exist are documented as a sequence. A sequence shows (EISA)
all of the IT and Business assets and resources involved
in the data ow. Infrastructure Management
44 CHAPTER 6. COMMERCIAL FRAMEWORKS

IT Service Management 6.3.1 Overview

IT Security The IFW business models describe the business of the
ITIL bank and are an ecient communication bridge between
business and technology communities. They are de-
On Demand/Utility Computing signed to be readily accessible to business users and fo-
cus on industry issues in areas such as Customer Insight,
Performability
Multi-Channel Transformation, Core Systems and Risk
Risk Management & Compliance.

Service Oriented Architecture (SOA) The IFW comprises:

SOX Information Models: providing banking data con-

Technical Architecture tent to address areas such as enterprise-wide view
of information
Process Models: providing banking business pro-
6.2.5 See also
cesses content to address areas such as business pro-
cess reengineering
6.2.6 References
Integration Models: providing business services
APMG-International (2010), The OBASHI content to address areas such as services oriented
Methodology. The Stationery Oce ISBN architectures
978-0-11-706857-5.
The IFW business models typically support over 80% of
Neil McNaughton, Editor, Oil Information Technol- business requirements and can be easily customized and
ogy Journal, Oilit.com. Business and IT Mapping, extended to cover the specic requirements of a bank.
Petroleum Exploration Society Great Britain Data The IFW business models will assist a bank in implement-
Management Conference, Technology Watch Report, ing a exible, reusable, extensible and easily customizable
London (December 11, 2007) architecture, which in turn will enable the bank to:
Karl Jeery, Editor, Seeing IT in a Business Context,
Digital Energy Journal, Feature Article, (August 7, Be more adaptive and to respond quickly to changing
2007) customer needs

John M A Burns, Seeing a new bigger picture, The In-
stitute of Scientic and Technical Communicators,
Feature Article, (Summer 2016)
Focus on achieving competitive dierentiation
Identify and leverage best practice behaviors across
the organization

6.2.7 External links In its conception, the IFW was an enterprise architec-
ture framework created as an alternative to the Zachman
The ocial OBASHI Website Framework.[1] In 1987 John Zachman proposed the
Zachman Framework to describe Information Architec-
The ocial OBASHI community Forum ture with the six concepts: The what related to data, how
The ocial OBASHI Mind Map related to process, where related to network and location,
who related to actors and people, when related to time,
The APMG-International OBASHI Webpage and at last why related to motivation.

6.3 Information Framework 6.3.2 Industry Models

This framework has become part of what is commonly
Information FrameWork (IFW) is an enterprise archi- known as the Industry Models.[4] The IBM Industry Mod-
tecture framework, populated with a comprehensive set els are used primarily for the development of internal
of banking specic business models. It was developed as
company standards, and provide an overall integration
an alternative to the Zachman Framework by Roger Ev- layer across an organizations existing and future IT in-
ernden.[1][2][3] vestments. With their strong business and IT orientation,
The banking specic business models represent good IBM Industry Models are designed to be customized to
practice in banking and is a natural extension to the reect the precise needs of every company using them.
Component Business Model. Hence, every company will have its own customized
6.3. INFORMATION FRAMEWORK 45

industry-specic version of IBMs data, process and ser- The third challenge is addressing the requirements of ef-
vice models, allowing them to represent areas that are ciency, growth and resiliency to provide more relevant,
unique to their business and constitute competitive advan- robust, timely, and cost eective information to business
tage. In addition, the models can be easily augmented to decision makers. Customer retention is important in a
embrace industry extensions, jurisdiction and company- volatile market so attention must also be paid to enhanc-
specic extensions easily. ing the customer experience.
The Industry Models(IFW) has products for the following
industries: IBM Banking Data Warehouse (BDW)
Banking and Financial Markets (Data, Process, Ser- The BDW is a derivative of the BFMDW and contains
vices), content only relevant to the banking industry.
Insurance (Data, Process, Services),
Healthcare (Data), IBM Financial Markets Data Warehouse (FMDW)
Telecommunications (Data), The FMDW is a derivative of the BFMDW and contains
Retail (Data). only content relevant to the nancial markets industry.

While in some markets IBM Industry Models have be-

come de facto standards, their purpose is not to standard-
ize at the level of an industry, but to provide the basis for
dening corporate standards. IBMs approach is to facil-
itate or embody the most important industry standards,
which are most often data models or messaging formats.
Architectural elements in the IBM Industry Models are
data models, process models and service models.
6.3.3 Banking and nancial markets
The Information Framework for banking and nancial
markets contains products containing data, process and
services models primarily focused on data warehouse and
service-oriented architecture domains.
IBM Banking and Financial Markets Data Ware-
house (BFMDW)
The banking and nancial markets industry is tackling
three core challenges head on. The rst is focused on its
medium-to-longer term future and how the organization
perceives the issues of revenue and risk. Central to the There are many benets to be derived from using the BPS
decision about what risks to accept is the need to accu- models, such as:
rately quantify those risks for trades, hedge funds, coun-
terparties and pricing. The management of risk is strate-
gic to an organizations corporate intent and survival.
The second area of focus is how to respond to the ever
growing demands of regulatory compliance including re-
quirements such as Basel II/III,[5] the Single Euro Pay-
[6]
ments Area (SEPA), the Standards Maintenance Orga-
[7]
nization (MISMO), International Financial Reporting
Standards (IFRS)[8] for International Accounting Stan-
dards (IAS), the Capital Adequacy Directive (CAD) and
AntiMoney Laundering (AML) and others. The invest-
ments in meeting compliance requirements can be sig-
nicant so the challenge is how to do this without im-
pacting protability. Organizations that can turn such in- Be better able to ensure completeness in terms of
vestments into market advantage will reap the benets.
IBM Banking Process and Service Models (BPS)
The pace of change in the nancial services industry
has accelerated markedly in recent years. Mergers and
acquisitions, the introduction of channel architecture,
the development of technologies such as internet bank-
ing and telephone banking, the introduction of product
bundling and the shift in focus from transactional sys-
tems to customer-facing systems such as operational sin-
gle view of customer have all brought about extensive
changes in the way nancial services organizations oper-
ate. By necessity, standalone solutions have been devel-
oped, supported by an array of individual processes and
procedures that often mimic and duplicate each other, but
are suciently disparate to cause cost and training issues
for nancial services organizations, impairing the syner-
gies and savings available to a coherent, strategic organi-
zation. A structured approach to any business or IT ini-
tiative is imperative to the success of projects. Utilizing
the BPS models can act as the formal blueprint for pro-
cess and services design and be utilized as a tool to bring
both business and IT together.
Increase customer satisfaction, grow the customer
base and reduce the cost of selling and servicing cus-
tomers
Identify opportunities to streamline processes, mak-
ing service delivery cheaper and quicker
Identify processes that essentially do the same thing
and therefore should be amenable to rationalization.
This reduces training and maintenance overheads,
improves your cost-income ratio and provides bet-
ter and less costly service to your customers
regulatory compliance and risk management, poten-
46 CHAPTER 6. COMMERCIAL FRAMEWORKS

tially releasing capital to provide additional lending LOB Policy Administration / Claim (Group), Financial
and investment capacity Transaction / Investment, Reinsurance Management, In-
termediary Management, Provider Management, Human
Designed to be understood by both business and IT,
Resource Management, Customer Relationship Manage-
and acts as a communication bridge between com-
ment, Marketing Management, Product Development,
munities.
Risk Policy Management, Risk Mitigation and Assess-
Provides an environment in which reuse possibilities ment, and Risk Reporting and Review.
can be identied and veried.
Provides a rm basis on which integration or SOA 6.3.5 Other industries
solutions can be built.
Allows you to construct services within a formalized Healthcare : Contains products containing data
model. models primarily focused on the Data Warehouse
domain.
Provides traceability from service denitions back to
business requirements. Telecommunications : Contains products containing
data models primarily focused on the Data Ware-
The BPS models have coverage in the following areas: house domain.
Sales & Relationship Management; KYC/Account Open-
ing; Lending; Card Products Administration; Commer- Retail : Contains products containing data models
cial / Syndicated Lending; Mortgages; Trade Finance; primarily focused on the Data Warehouse domain.
Savings, Investments & Term Deposits; Transfer Ser-
vices; Payments -Direct Debit / Credit Transfer / Deposit
/ Withdrawal; Cash Management; Wealth Management; 6.3.6 References
Product & Marketing Management; Regulatory & Com-
pliance; Best Execution/MiFID; Trade Processing; Cor- [1] Information FrameWork, Systems Journal article, Roger
Evernden
porate Actions; Asset & Liability Management; and Hu-
man Resource Administration. [2] Rik Maes. A generic framework for information manage-
ment. Universiteit van Amsterdam, Department of Ac-
countancy & Information Management, 1999.
6.3.4 Insurance
[3] Greefhorst, Danny, Henk Koning, and Hans van Vliet.
Contains products containing data, process and ser- The many faces of architectural descriptions. Informa-
vices models primarily focused on Data Warehouse and tion Systems Frontiers 8.2 (2006): 103-113.
Services Oriented Architecture domains.
[4] Industry Models

IBM Insurance Application Architecture (IAA) [5] Basel II/III

The Insurance Application Architecture (IAA) is a com- [6] Single Euro Payments Area (SEPA)
prehensive set of insurance specic models that repre- [7] Mortgage Industry Standards Maintenance Organization
sents best practices in insurance and is a natural extension (MISMO)
to the Component Business Model. The IAA models pro-
vide the insurance specic business content to accelerate [8] (IFRS)
the projects that result from moving to an On Demand
Business and pick up the denition of the components
that take you there. IAA describes the business of the in- 6.3.7 Further reading
surer and is an ecient communication bridge between
business and technology communities. It is designed to Evernden, Roger. Information FrameWork
be readily accessible to business users and by focusing (IFW)". IBM Systems Journal, Volume 35, Num-
on industry issues such as Sales and Customer Services, ber 1, Page 37 (1996)
Marketing and Analytics, Customer Relationship Man-
agement, Policy Administration, Product Development, Evernden, Roger and Evernden, Elaine, Information
Insurance Claims and Risk and Compliance. First: Integrating Knowledge and Information Ar-
chitecture for Business Advantage, Kindle Edition,
The IAA models have coverage in the following areas: Routledge 25 June 2012
LOB Customer Acquisition (Individual Insurance), LOB
Underwriting (Individual Insurance), LOB Customer Ac- Capital Adequacy Directive
quisition (Group Insurance), LOB Policy Administra-
tion (Individual), LOB Claim Management (Individual), Industry Models at IBM.com
6.4. ZACHMAN FRAMEWORK 47

ture, an update of the 1987 original in the 1990s ex-

tended and renamed .[6]
One of the later versions of the Zachman Frame-
work, oered by Zachman International as industry
standard.

The Zachman Framework of enterprise architecture

6.4 Zachman Framework

The Zachman Framework is an enterprise ontology and
is a fundamental structure for Enterprise Architecture
which provides a formal and structured way of viewing
and dening an enterprise. The ontology is a two dimen-
sional classication schema that reects the intersection
between two historical classications. The rst are prim- Collage of Zachman Frameworks as presented in several books
on Enterprise Architecture from 1997 to 2005.
itive interrogatives: What, How, When, Who, Where,
and Why. The second is derived from the philosophi-
cal concept of reication, the transformation of an ab- In other sources the Zachman Framework is introduced
stract idea into an instantiation. The Zachman Frame- as a framework, originated by and named after John
work reication transformations are: Identication, Def- Zachman, represented in numerous ways, see image.
inition, Representation, Specication, Conguration and This framework is explained as, for example:
Instantiation.[1]
a framework to organize and analyze data,[7]
The Zachman Framework is not a methodology in that
it does not imply any specic method or process for a framework for enterprise architecture.[8]
collecting, managing, or using the information that it
describes.;[2] rather, it is an ontology whereby a schema a classication system, or classication scheme[9]
for organizing architectural artifacts (in other words, de- a matrix, often in a 6x6 matrix format
sign documents, specications, and models) is used to
take into account both who the artifact targets (for ex- a two-dimensional model[10] or an analytic model.
ample, business owner and builder) and what particu-
a two-dimensional schema, used to organize the de-
lar issue (for example, data and functionality) is being
tailed representations of the enterprise.[11]
addressed.[3]
The framework is named after its creator John Zachman, Beside the frameworks developed by John Zachman, nu-
who rst developed the concept in the 1980s at IBM. It merous extensions and/or applications have been devel-
has been updated several times since.[4] oped, which are also sometimes called Zachman Frame-
works, however they generally tend to be graphical over-
lays of the actual framework itself.
6.4.1 Overview
The Zachman Framework summarizes a collection of
The title Zachman Framework refers to The Zachman perspectives involved in enterprise architecture. These
Framework for Enterprise Architecture with version 3.0 perspectives are represented in a two-dimensional matrix
being the most current. The Zachman Framework has that denes along the rows the type of stakeholders and
evolved in its thirty-year history to include: with the columns the aspects of the architecture. The
framework does not dene a methodology for an archi-
The initial framework, named A Framework for In- tecture. Rather, the matrix is a template that must be
formation Systems Architecture, by John Zachman lled in by the goals/rules, processes, material, roles, lo-
published in an 1987 article in the IBM Systems cations, and events specically required by the organiza-
journal.[5] tion. Further modeling by mapping between columns in
the framework identies gaps in the documented state of
The Zachman Framework for Enterprise Architec- the organization.[12]
48 CHAPTER 6. COMMERCIAL FRAMEWORKS

The framework is a logical structure for classifying and

organizing the descriptive representations of an enter-
prise. It is signicant to both the management of the en-
terprise, and the actors involved in the development of
enterprise systems.[13] While there is no order of priority
for the columns of the Framework, the top-down order of
the rows is signicant to the alignment of business con-
cepts and the actual physical enterprise. The level of de-
tail in the Framework is a function of each cell (and not
the rows). When done by IT the lower level of focus is on
information technology, however it can apply equally to
physical material (ball valves, piping, transformers, fuse
boxes for example) and the associated physical processes, Simple example of the 1992 Framework.
roles, locations etc. related to those items.
In the 1987 article A Framework for Information Sys-
tems Architecture[15] Zachman noted that the term ar-
6.4.2 History chitecture was used loosely by information systems pro-
fessionals, and meant dierent things to planners, de-
In the 1980s John Zachman had been involved at signers, programmers, communication specialists, and
IBM in the development of business system planning others.[16] In searching for an objective, independent ba-
(BSP), a method for analyzing, dening and designing sis upon which to develop a framework for information
an information architecture of organizations. In 1982 systems architecture, Zachman looked at the eld of clas-
Zachman[14] had already concluded that these analyses sical architecture, and a variety of complex engineering
could reach far beyond automating systems design and projects in industry. He saw a similar approach and con-
managing data into the realms of strategic business plan- cluded that architectures exist on many levels and in-
ning and management science in general. It may be em- volves at least three perspectives: raw material or data,
ployed in the (in that time considered more esoteric) ar- function of processes, and location or networks.[16]
eas of enterprise architecture, data-driven systems de-
sign, data classication criteria, and more.[14] The Information Systems Architecture is designed to be
a classication schema for organizing architecture mod-
els. It provides a synoptic view of the models needed for
Information Systems Architecture Framework enterprise architecture. Information Systems Architec-
ture does not dene in detail what the models should con-
tain, it does not enforce the modeling language used for
each model, and it does not propose a method for creating
these models.[17]

Extension and formalization

In the 1992 article Extending and Formalizing the

Framework for Information Systems Architecture John
F. Sowa and John Zachman present the framework and
its recent extensions and show how it can be formalized
in the notation of conceptual graphs.[18] Also in 1992:

John Zachmans co-author John Sowa

proposed the additions of the Scope perspec-
tive of the planner (bounding lists common
to the enterprise and its environment) and
the Detailed Representation perspective of
the sub-contractor (being the out of context
vendor solution components). The Who,
When and Why columns were brought into
public view, the notion of the four levels of
metaframeworks and a depiction of integration
The original 1987 Information Systems Architecture Frame-
associations across the perspectives were all
work. outlined in the paper. Keri Anderson Healey
assisted by creating a model of the models
6.4. ZACHMAN FRAMEWORK 49

(the framework metamodel) which was also Concept

included in the article.
Stan Locke, Enterprise Convergence in Our The basic idea behind the Zachman Framework is that
Lifetime, from THE ENTERPRISE NEWSLET- the same complex thing or item can be described for dif-
TER[19] ferent purposes in dierent ways using dierent types
of descriptions (e.g., textual, graphical). The Zachman
Framework provides the thirty-six necessary categories
for completely describing anything; especially complex
Later during the 1990s[19]
things like manufactured goods (e.g., appliances), con-
structed structures (e.g., buildings), and enterprises (e.g.,
Methodologists like Clive Finkelstein refocused on the organization and all of its goals, people, and tech-
the top two framework rows which he labeled nologies). The framework provides six dierent trans-
Enterprise Engineering and has one of the most suc- formations of an abstract idea (not increasing in detail,
cessful methods for converging the business needs but transforming) from six dierent perspectives.[24]
with information engineering implementation, and
It allows dierent people to look at the same thing from
determining a logical build sequence of the pieces.
dierent perspectives. This creates a holistic view of the
environment, an important capability illustrated in the
gure.[25]
Framework for enterprise architecture

In the 1997 paper Concepts of the Framework for En- Views of rows
terprise Architecture Zachman said that the framework
should be referred to as a Framework for Enterprise Each row represents a total view of the solution from a
Architecture, and should have from the beginning. In particular perspective. An upper row or perspective does
the early 1980s however, according to Zachman, there not necessarily have a more comprehensive understand-
was little interest in the idea of Enterprise Reengineer- ing of the whole than a lower perspective. Each row rep-
ing or Enterprise Modeling and the use of formalisms resents a distinct, unique perspective; however, the de-
and models was generally limited to some aspects of ap- liverables from each perspective must provide sucient
plication development within the Information Systems detail to dene the solution at the level of perspective and
community.[20] must translate to the next lower row explicitly.[26]
In 2008 Zachman Enterprise introduced the Zachman Each perspective must take into account the requirements
Framework: The Ocial Concise Denition as a new of the other perspectives and the restraint those perspec-
Zachman Framework standard. tives impose. The constraints of each perspective are ad-
ditive. For example, the constraints of higher rows aect
the rows below. The constraints of lower rows can, but
Extended and modied frameworks do not necessarily aect the higher rows. Understanding
the requirements and constraints necessitates communi-
Since the 1990s several extended frameworks have been cation of knowledge and understanding from perspective
proposed, such as: to perspective. The Framework points the vertical direc-
tion for that communication between perspectives.[26]
Matthew & McGee (1990)[21] extended the three
initial perspectives what, how and where, to
event (the when), reason (the why) and organi-
zation (the who).[16]

Evernden (1996) presented an alternative

Information FrameWork.

The Integrated Architecture Framework developed

by Capgemini since 1996.[22]
The Veterans Aairs Zachman Framework with an explanation
[27][28]
Vladan Jovanovic et all (2006) presents a Zachman of its rows.
Cube, an extended of the Zachman Framework into
a multidimensional Zachmans Cube.[23] The current version (3.)) of the Zachman Framework cat-
egorizes the rows as follows<zachman.com>I

6.4.3 Zachman Framework topics Executive Perspective (Scope Contents) - The rst ar-
chitectural sketch is a "bubble chart" or Venn dia-
50 CHAPTER 6. COMMERCIAL FRAMEWORKS

gram, which depicts in gross terms the size, shape,
partial relationships, and basic purpose of the nal
structure. It corresponds to an executive summary
for a planner or investor who wants an overview or
estimate of the scope of the system, what it would
cost, and how it would relate to the general environ-
ment in which it will operate.
Business Management Perspective (Business Con-
cepts) - Next are the architects drawings that de-
pict the nal building from the perspective of the
owner, who will have to live with it in the daily rou-
tines of business. They correspond to the enterprise
(business) models, which constitute the designs of
the business and show the business entities and pro-
cesses and how they relate.
sic model of each column is uniquely dened, yet re-
lated across and down the matrix.[26] In addition, the
six categories of enterprise architecture components, and
the underlying interrogatives that they answer, form the
columns of the Zachman Framework and these are:[24]
1. Inventory Sets What
2. Process Flows How
3. Distribution Networks Where
4. Responsibility Assignments Who
5. Timing Cycles When
6. Motivation Intentions Why

Architect Perspective (System Logic) - The archi-

In Zachmans opinion, the single factor that makes his
tects plans are the translation of the drawings into
framework unique is that each element on either axis of
detail requirements representations from the de-
the matrix is explicitly distinguishable from all the other
signers perspective. They correspond to the system
elements on that axis. The representations in each cell of
model designed by a systems analyst who must de-
the matrix are not merely successive levels of increasing
termine the data elements, logical process ows, and
detail, but actually are dierent representations dif-
functions that represent business entities and pro-
ferent in context, meaning, motivation, and use. Because
cesses.
each of the elements on either axis is explicitly dierent
Engineer Perspective (Technology Physics) - The from the others, it is possible to dene precisely what be-
[24]
contractor must redraw the architects plans to rep- longs in each cell.
resent the builders perspective, with sucient de-
tail to understand the constraints of tools, technol-
Models of cells
ogy, and materials. The builders plans correspond
to the technology models, which must adapt the in-
The Zachman Framework typically is depicted as a
formation systems model to the details of the pro-
bounded 6 x 6 matrix with the Communication Inter-
gramming languages, input/output (I/O) devices, or
rogatives as Columns and the Reication Transformations
other required supporting technology.
as Rows. The framework classications are repressed by
Technician Perspective (Tool Components) - Sub- the Cells, that is, the intersection between the Interroga-
[29]
contractors work from shop plans that specify the tives and the Transformations.
details of parts or subsections. These correspond The cell descriptions are taken directly from version 3.0
to the detailed specications that are given to pro- of the Zachman Framework.
grammers who code individual modules without be-
ing concerned with the overall context or struc-
Executive Perspective
ture of the system. Alternatively, they could
represent the detailed requirements for various
commercial-o-the-shelf (COTS), government o- 1. (What) Inventory Identication
the-shelf (GOTS), or components of modular sys- 2. (How) Process Identication
tems software being procured and implemented
rather than built. 3. (Where) Distribution Identication
Enterprise Perspective or (Operations Instances) 4. (Who) Responsibility Identication

5. (When) Timing Identication

Focus of columns
6. (Why) Motivation Identication
In summary, each perspective focuses attention on the
same fundamental questions, then answers those ques- Business Management Perspective
tions from that viewpoint, creating dierent descrip-
tive representations (i.e., models), which translate from 1. (What) Inventory Denition
higher to lower perspectives. The basic model for the fo-
cus (or product abstraction) remains constant. The ba- 2. (How) Process Denition
6.4. ZACHMAN FRAMEWORK
3. (Where) Distribution Denition
4. (Who) Responsibility Denition
5. (When) Timing Denition
6. (Why) Motivation Denition
Architect Perspective
1. (What) Inventory Representation
2. (How) Process Representation
3. (Where) Distribution Representation
4. (Who) Responsibility Representation
5. (When) Timing Representation
6. (Why) Motivation Representation
Engineer Perspective
1. (What) Inventory Specication
2. (How) Process Specication
3. (Where) Distribution Specication
4. (Who) Responsibility Specication
5. (When) Timing Specication
6. (Why) Motivation Specication
Technician Perspective
1. (What) Inventory Conguration
2. (How) Process Conguration
3. (Where) Distribution Conguration
4. (Who) Responsibility Conguration
5. (When) Timing Conguration
6. (Why) Motivation Conguration
Enterprise Perspective
1. (What) Inventory Instantiations
2. (How) Process Instantiations
3. (Where) Distribution Instantiations
4. (Who) Responsibility Instantiations
5. (When) Timing Instantiations
6. (Why) Motivation Instantiations
51
Since the product development (i.e., architectural arti-
fact) in each cell or the problem solution embodied by
the cell is the answer to a question from a perspective,
typically, the models or descriptions are higher-level de-
pictions or the surface answers of the cell. The rened
models or designs supporting that answer are the detailed
descriptions within the cell. Decomposition (i.e., drill
down to greater levels of detail) takes place within each
cell. If a cell is not made explicit (dened), it is implicit
(undened). If it is implicit, the risk of making assump-
tions about these cells exists. If the assumptions are valid,
then time and money are saved. If, however, the assump-
tions are invalid, it is likely to increase costs and exceed
the schedule for implementation.[26]
Framework set of rules
Example of Zachman Framework Rules.
The framework comes with a set of rules:[30]
Rule 1 The columns have no order : The columns are
interchangeable but cannot be reduced or created
Rule 2 Each column has a simple generic model : Ev-
ery column can have its own meta-model
Rule 3 The basic model of each column must be
unique : The basic model of each column, the re-
lationship objects and the structure of it is unique.
Each relationship object is interdependent but the
representation objective is unique.
Rule 4 Each row describes a distinct, unique perspec-
tive : Each row describes the view of a particular
business group and is unique to it. All rows are usu-
ally present in most hierarchical organizations.
Rule 5 Each cell is unique : The combination of 2,3
& 4 must produce unique cells where each cell rep-
resents a particular case. Example: A2 represents
business outputs as they represent what are to be
eventually constructed.
Rule 6 The composite or integration of all cell mod-
els in one row constitutes a complete model from the
perspective of that row : For the same reason as for
not adding rows and columns, changing the names
may change the fundamental logical structure of the
Framework.
52 CHAPTER 6. COMMERCIAL FRAMEWORKS

Rule 7 The logic is recursive : The logic is relational

Views

between two instances of the same entity. Functional

view
Information Organizational Infrastructure
view view view

Planner

Work

Perspectives
Owner

products
The framework is generic in that it can be used to classify
Designer

Builder

the descriptive representations of any physical object as TEAF Matrix of Views and
well as conceptual objects such as enterprises. It is also Perspectives.
recursive in that it can be used to analyze the architec-
tural composition of itself. Although the framework will
carry the relation from one column to the other, it is still a
fundamentally structural representation of the enterprise
and not a ow representation.
Framework for EA Direc-
tion, Description, and Accomplishment Overview.
Flexibility in level of detail

One of the strengths of the Zachman Framework is that

it explicitly shows a comprehensive set of views that can
be addressed by enterprise architecture.[12] Some feel that
following this model completely can lead to too much em-
phasis on documentation, as artefacts would be needed TEAF Products.
for every one of the thirty cells in the framework. Zach-
man, however, indicates that only the facts needed to
solve the problem under analysis need be populated.
John Zachman clearly states in his documentation, pre-
sentations, and seminars that, as framework, there is ex-
ibility in what depth and breadth of detail is required for TEAF Work Products for
each cell of the matrix based upon the importance to a EA Direction, Description, and Accomplishment.
given organization. An automaker whose business goals
may necessitate an inventory and process-driven focus,
could nd it benecial to focus their documentation ef-
Other sources:
forts on What and How columns. By contrast, a travel
agent company, whose business is more concerned with
people and event-timing, could nd it benecial to focus The TEAF matrix is called a customization sample,
their documentation eorts on Who, When, and Where see here, p. 22
columns. However, there is no escaping the Why col-
umns importance as it provides the business drivers for
all the other columns. Standards based on the Zachman Framework

Zachman Framework is also used as a framework to de-

6.4.4 Applications and inuences scribe standards, for example standards for healthcare
and healthcare information system. Each cell of the
framework contains such a series of standards for health-
Since the 1990s the Zachman Framework has been
care and healthcare information system.[33]
widely used as a means of providing structure for
Information Engineering-style enterprise modeling.[31]
The Zachman Framework can be applied both in com-
Mapping other frameworks
mercial companies and in government agencies. Within
a government organization the framework can be applied
Another application of the Zachman Framework is as ref-
to an entire agency at an abstract level, or it can be ap-
erence model for other enterprise architectures, see for
plied to various departments, oces, programs, subunits
example these four:
and even to basic operational entities.[32]

Customization

Zachman Framework is applied in customized frame- EAP mapped to the Zach-

works such as the TEAF, built around the similar frame- man Framework, 1999
works, the TEAF matrix.
6.4. ZACHMAN FRAMEWORK 53

C4ISR AE, 1997.

Mapping the C4ISR, 1999

DOE AE, 1998.

DoD Products Map to the
Zachman Framework Cells, 2003.

DODAF, 2003.
Mapping a part of the
DoDAF, 2007.
The Federal Enterprise Architecture Framework
(FEAF) is based on the Zachman Framework but
Other examples: only addresses the rst three columns of Zachman,
using slightly dierent names, and focuses in the top
Analysis of the Rational Unied Process as a of the three rows.[37] (see here)
Process,[34]

How the Model-driven architecture (MDA) models Example: One-VA Enterprise Architecture The
used in software development map to the Zachman Zachman Framework methodology has for example been
Framework.[35] used by the United States Department of Veterans Af-
fairs (VA) to develop and maintain its One-VA Enter-
Mapping the IEC 62264 models onto the Zach- prise Architecture in 2001. This methodology required
man framework for analysing products information dening all aspects of the VA enterprise from a business
traceability.[36] process, data, technical, location, personnel, and require-
Mapping the TOGAF Architecture Development ments perspective. The next step in implementing the
Method (e.g. the methodology) to the Zachman methodology has been to dene all functions related to
Framework.[6] each business process and identify associated data ele-
ments. Once identied, duplication of function and in-
consistency in data denition can be identied and re-
Base for other enterprise architecture frameworks solved, .[38]

Less obvious are the ways the original Zachman frame-

work has stimulated the development of other enterprise
architecture frameworks, such as in the NIST Enterprise
Architecture Model, the C4ISR AE, the DOE AE, and
the DoDAF: Integrated Process Flow for
VA IT Projects (2001)

NIST Enterprise Architecture VA Zachman Framework

Model.[26] Portal
54 CHAPTER 6. COMMERCIAL FRAMEWORKS

However, this tool permitted dening entities and rela-

tionships and for dening properties upon both entities
and relationships, which made it sucient for building
an EA repository, considering the technology available
VA EA Repository Intro- in early 2003. The personal motivation in selecting this
duction (2008) tool was that none of the commercial repository tools then
available provided a true Zachman Framework represen-
tation, and were highly proprietary, making it dicult to
incorporate components from other vendors or from open
source.
This diagram emphasizes several important interpreta-
A Tutorial on the Zachman tions of the Zachman Framework and its adaptation to
Architecture Framework information technology investment management.

1. Progressing through the rows from top to bottom,

The Department of Veterans Aairs at the beginning of one can trace-out the Systems Development Life
the 21st century planned to implement an enterprise ar- Cycle (SDLC) which is a de facto standard across
chitecture fully based on the Zachman Framework. the Information Industry;

The Zachman Framework was used as a reference 2. The diagram emphasizes the importance of the
model to initiate enterprise architecture planning in often-neglected Zachman Row-Six (the Integrated,
2001. Operational Enterprise View). Representations in
Mr. Zuechs interpretation of Zachman row-six con-
Somewhere in between the VA Zachman Frame- sist, largely, of measurable service improvements
work Portal was constructed. and cost savings/avoidance that result from the busi-
ness process and technology innovations that were
This VA Zachman Framework Portal is still in use as developed across rows two through ve.
a reference model for example in the determination
of EA information collected from various business
Row-six provides measured return on investment for
and project source documents.
Individual Projects and, potentially, for the entire
investment portfolio. Without row-six the Framework
Eventually an enterprise architecture repository was cre- only identies sunk-cost, but the row-six ROI permits it
ated at the macro level by the Zachman framework and to measure benets and to be used in a continuous im-
at a cell level by the meta-model outlined below.[39] provement process, capturing best practices and applying
them back through row-two.

6.4.5 Criticism
While the Zachman Framework is widely discussed, its
practical value has been questioned:

The framework is purely speculative, non-empirical

VA EA Meta-Model Cell Details Enlarged.
This diagram[40] has been incorporated within the
VA-EA to provide a symbolic representation of the
metamodel it used, to describe the One-VA Enterprise
Architecture and to build an EA Repository without the
use of Commercial EA Repository Software. It was
developed using an object oriented database within the
Caliber-RM Software Product. Caliber-RM is intended
to be used as a software conguration management tool;
not as an EA repository.
and based only on the conceptual argument that the
equivalency [between the architectural representa-
tions of the manufacturing and construction indus-
tries] would strengthen the argument that an analo-
gous set of architectural representations is likely to
be produced during the process of building any com-
plex engineering product, including an information
system[5]
Practical feedback shows that the general idea
of creating comprehensive descriptions of enter-
prises as suggested by the Zachman Framework is
unrealistic[41]
In 2004 John Zachman admitted that the frame-
work is theoretical and has never been fully imple-
6.4. ZACHMAN FRAMEWORK
mented: If you ask who is successfully implement-
ing the whole framework, the answer is nobody that
we know of yet[42]
There are no detailed examples demonstrating the
successful practical application of the framework[43]
EA practitioner Stanley Gaver argues that the anal-
ogy to classical architecture rst made by John
Zachman is faulty and incomplete[44]
Jason Bloomberg argues that enterprise isnt an or-
dinary system like a machine or a building, and cant
be architected or engineered as such[45]
This criticism suggests that the Zachman Framework can [14] Business Systems Planning and Business Information
hardly reect actual best practice in EA. Control Study: A comparisment. In: IBM Systems Jour-
6.4.6 See also
Conceptual schema
Data model
Enterprise Architecture framework
Enterprise Architecture Planning
FDIC Enterprise Architecture Framework
View model
6.4.7 References
[1] John Zachmans Concise Denition of the Zachman
Framework, 2008
[2] The Zachman Framework: The Ocial Concise Deni-
tion. Zachman International. 2008.
[3] A Comparison of the Top Four Enterprise Architecture
Methodologies, Roger Sessions, Microsoft Developer Net-
work Architecture Center,
[4] The Zachman Framework Evolution. Zachman Inter-
national. April 2009.
[5] A framework for information systems architecture
(PDF). IBM Systems Journal, Vol. 26. No. 3,. 1987.
[6] The Open Group (19992006). ADM and the Zachman
Framework in: TOGAF 8.1.1 Online. Accessed 25 Jan
2009.
[7] William H. Inmon, John A. Zachman, Jonathan G. Geiger
(1997). Data Stores, Data Warehousing, and the Zachman
Framework: Managing Enterprise Knowledge. McGraw-
Hill, 1997. ISBN 0-07-031429-2.
[8] Pete Sawyer, Barbara Paech, Patrick Heymans (2007).
Requirements Engineering: Foundation for Software Qual-
ity. page 191.
55
[9] Kathleen B. Hass (2007). The Business Analyst as Strate-
gist: Translating Business Strategies Into Valuable Solu-
tions. page 58.
[10] Harold F. Tipton, Micki Krause (2008). Information Se-
curity Management Handbook, Sixth Edition, Volume 2.
page 263.
[11] O'Rourke, Fishman, Selkow (2003). Enterprise Architec-
ture Using the Zachman Framework. page 9.
[12] James McGovern et al. (2003). A Practical Guide to En-
terprise Architecture. p. 127-129.
[13] Marc Lankhorst et al. (2005). Enterprise Architecture at
Work. p. 24.
nal, vol 21, no 3, 1982. p. 31-53.
[15] John A. Zachman (1987). " A Framework for Information
Systems Architecture. In: IBM Systems Journal, vol 26,
no 3. IBM Publication G321-5298.
[16] Durward P. Jackson (1992). Process-Based Planning in
Information Resource Management. In: Emerging Infor-
mation Technologies for Competitive Advantage and Eco-
nomic Development. Proceedings of 1992 Information
Resources Management Association International Con-
ference. Mehdi Khosrowpour (ed). ISBN 1-878289-17-9.
[17] Alain Wegmann et al. (2008). Augmenting the Zachman
Enterprise Architecture Framework with a Systemic Con-
ceptualization. Presented at the 12th IEEE International
EDOC Conference (EDOC 2008), Mnchen, Germany,
September 1519, 2008.
[18] John F. Sowa and John Zachman (1992). Extending and
Formalizing the Framework for Information Systems Ar-
chitecture In: IBM Systems Journal, Vol 31, no.3, 1992.
p. 590-616.
[19] Stan Locke (2008). Enterprise Convergence in Our Life-
time In: THE ENTERPRISE NEWSLETTER, TEN42
September 16, 2008
[20] John A. Zachman (1997). "Concepts of the Framework
for Enterprise Architecture: Background, Description and
Utility". Zachman International. Accessed 19 Jan 2009.
[21] R.W. Matthews. &. W.C. McGee (1990). Data Model-
ing for Software Development. in: IBM Systems Journal
29(2). pp. 228234
[22] Jaap Schekkerman (2003). How to Survive in the Jungle
of Enterprise Architecture Frameworks. page 139-144.
[23] Vladan Jovanovic, Stevan Mrdalj & Adrian Gardiner
(2006). A Zachman Cube. In: Issues in Information Sys-
tems. Vol VII, No. 2, 2006 p. 257-262.
[24] VA Enterprise Architecture Innovation Team (2001).
Enterprise Architecture: Strategy, Governance, & Imple-
mentation report Department of Veterans Aairs, August,
2001.
56 CHAPTER 6. COMMERCIAL FRAMEWORKS

[25] The government information factory and the Zachman [41] Kim, Y.G. and Everest, G.C. (1994). Building an IS archi-
Framework by W. H. Inmon, 2003. p. 4. Accessed July tecture: Collective wisdom from the eld. In: Information
14, 2009. & Management, vol. 26, no. 1, pp. 1-11.

[26] The Chief Information Ocers Council (1999). Federal
Enterprise Architecture Framework Version 1.1.
September 1999
[27] US Department of Veterans Aairs (2002) A Tutorial on
the Zachman Architecture Framework. Accessed 06 Dec
2008.
[28] Bill Inmon called this image A simple example of The
Zachman Framework in the article John Zachman - One
of the Best Architects I Know Originally published 17
November 2005.
[29] Zachman, John A. Ocial Home of The Zachman
Framework". Zachman International. Retrieved 14
February 2015.
[30] Adapted from: Sowa, J.F. & J.A. Zachman, 1992,
and Inmon, W.H, J.A. Zachman, & J.G. Geiger, 1997.
University of Omaha
[31] Ian Graham (1995). Migrating to Object Technology: the
semantic object modelling approach. Addison-Wesley,
ISBN 0-201-59389-0. p. 322.
[32] Jay D. White (2007). Managing Information in the Public
Sector. p. 254.
[33] ZACHMAN ISA FRAMEWORK FOR HEALTHCARE
INFORMATICS STANDARDS, 1997.
[42] Erecting the Framework, Part III, Interview with John
Zachman by Dan Ruby, visited 19 May 2016
[43] Ylimaki, T. and Halttunen, V. (2006). Method Engineer-
ing in Practice: A Case of Applying the Zachman Frame-
work in the Context of Small Enterprise Architecture Ori-
ented Projects. In: Information, Knowledge, Systems
Management, vol. 5, no. 3, pp. 189-209.
[44] Why Doesnt the Federal Enterprise Architecture
Work?", Stanley B. Gaver, visited 19 May 2016
[45] Is Enterprise Architecture Completely Broken?", Jason
Bloomberg, visited 19 May 2016
6.4.8 External links
The Zachman Framework: The Ocial Concise
Denition by John A. Zachman at Zachman Inter-
national, 2009.
The Zachman Framework Evolution: overview of
the evolution of the Zachman Framework by John
P. Zachman at Zachman International, April 2009.
UML, RUP, and the Zachman Framework: Better
together, by Vitalie Temnenco, IBM, 15 Nov 2006.

[34] DJ de Villiers (2001). Using the Zachman Framework

to Assess the Rational Unied Process, In: The Rational
Edge Rational Software 2001.

[35] David S. Frankel, Harmon, P., Mukerji, J., Odell, J.,

Owen, M., Rivitt, P., Rosen, M... & Soley, R. M. et
al. (2003) The Zachman Framework and the OMGs
Model Driven Architecture White paper. Business Process
Trends.

[36] Herv Panetto, Salah Bana, Grard Morel (2007).

Mapping the models onto the Zachman framework for
analysing products information traceability : A case
Study.

[37] Roland Traunmller (2004). Electronic Government p. 51

[38] Statement of Dr. John A. Gauss, Assistant Secretary for

Information and Technology, Department of Veterans Af-
fairs, before the Subcommittee on Oversight and Inves-
tigations Committee on Veterans Aairs U.S. House of
Representatives. March 13, 2002.

[39] Meta-Model Cell Details Accessed 25 Dec 2009

[40] This diagram is the exclusive work of Albin Martin Zuech

of Annapolis Maryland, who placed it in the public do-
main in 2001. Al Zuech maintains the original visio dia-
gram in numerous stages of its development between 2000
and present. Al Zuech was the Director, Enterprise Ar-
chitecture Service at the Department of Veterans Aairs
from 2001 until 2007.
Chapter 7
Defense industry frameworks
7.1 Department of Defense Archi-
tecture Framework
DoD Architecture Framework v1.5.[1]
DoDAF Architecture Framework Version 2.0[2]
The Department of Defense Architecture Framework
(DoDAF) is an architecture framework for the United
States Department of Defense (DoD) that provides vi-
sualization infrastructure for specic stakeholders con-
cerns through viewpoints organized by various views.
These views are artifacts for visualizing, understanding,
and assimilating the broad scope and complexities of
an architecture description through tabular, structural,
57
behavioral, ontological, pictorial, temporal, graphical,
probabilistic, or alternative conceptual means.
This Architecture Framework is especially suited to large
systems with complex integration and interoperability
challenges, and it is apparently unique in its employment
of operational views. These views oer overview and
details aimed to specic stakeholders within their domain
and in interaction with other domains in which the system
will operate.[3]
7.1.1 Overview
The DoDAF provides a foundational framework for de-
veloping and representing architecture descriptions that
ensure a common denominator for understanding, com-
paring, and integrating architectures across organiza-
tional, joint, and multinational boundaries. It establishes
data element denitions, rules, and relationships and a
baseline set of products for consistent development of
systems, integrated, or federated architectures. These ar-
chitecture descriptions may include families of systems
(FoS), systems of systems (SoS), and net-centric capabil-
ities for interoperating and interacting in the non-combat
environment.[1]
All major U.S. DoD weapons and information technol-
ogy system acquisitions are required to develop and docu-
ment an enterprise architecture (EA) using the views pre-
scribed in the DoDAF. While it is clearly aimed at mil-
itary systems, DoDAF has broad applicability across the
private, public and voluntary sectors around the world,
and represents one of a large number of systems archi-
tecture frameworks.[4][5]
The purpose of DoDAF is to dene concepts and
models usable in DoDs six core processes:[6]
1. Joint Capabilities Integration and Develop-
ment (JCIDS)
2. Planning, Programming, Budgeting, and Exe-
cution (PPBE)
3. Defense Acquisition System (DAS)
4. Systems Engineering (SE)
5. Operational Planning (OPLAN)
58 CHAPTER 7. DEFENSE INDUSTRY FRAMEWORKS

6. Capability Portfolio Management (CPM) 2.02 [8] DoDAF V2.0 is published on a public website.[9]
In addition, DoDAF 2.0s specic goals were to:[6] Other derivative frameworks based on DoDAF include
the NATO Architecture Framework (NAF) and Ministry
1. Establish guidance for architecture content as of Defence Architecture Framework. Like other EA
a function of purpose t for purpose approaches, for example The Open Group Architecture
2. Increase utility and eectiveness of architec- Framework (TOGAF), DoDAF is organized around a
tures via a rigorous data model the DoDAF shared repository to hold work products. The reposi-
Meta Model (DM2) -- so the architectures can tory is dened by the common database schema Core
be integrated, analyzed, and evaluated to with Architecture Data Model 2.0 and the DoD Architecture
more precision. Registry System (DARS). A key feature of DoDAF is
interoperability, which is organized as a series of lev-
els, called Levels of Information System Interoperability
7.1.2 History (LISI). The developing system must not only meet its in-
ternal data needs but also those of the operational frame-
work into which it is set.

7.1.3 Capabilities and mission

See the diagram for a depiction of the Capabilities Em-

phasis, as tied in with mission/course of action, threads,
Evolution of the DoDAF since the 1990s. The DoDAF V2.0 was
activities, and architectures.
released in May, 2009.[1]

The rst version of the development DoDAF was de-

veloped in the 1990s under the name C4ISR Architec-
ture Framework. In the same period the reference model
TAFIM, which was initiated in 1986, was further devel-
oped. The rst C4ISR Architecture Framework v1.0, re-
leased 7 June 1996, was created in response to the pas-
sage of the Clinger-Cohen Act. It addressed the 1995
Deputy Secretary of Defense directive that a DoD-wide
eort be undertaken to dene and develop a better means
and process for ensuring that C4ISR capabilities were in-
teroperable and met the needs of the warghter. Contin-
ued development eort resulted in December 1997 in the Capabilities Described with Architectures
second version, C4ISR Architecture Framework v2.0.[1]
The DoD has moved toward a focus on the delivery of
In August 2003 the DoDAF v1.0 was released, which re-
capabilities, which are the reason for creating the sys-
structured the C4ISR Framework v2.0 to oer guidance,
tem/service. The Capability Models describe capability
product descriptions, and supplementary information in
taxonomy and capability evolution. A capability thread
two volumes and a Desk Book. It broadened the appli-
would equate to the specic activities, rules, and systems
cability of architecture tenets and practices to all Mission
that are linked to that particular capability.
Areas rather than just the C4ISR community. This doc-
ument addressed usage, integrated architectures, DoD The concept of capability, as dened by its Meta-model
and Federal policies, value of architectures, architecture Data Group allows one to answer questions such as:
measures, DoD decision support processes, development
techniques, analytical techniques, and the CADM v1.01, How does a particular capability or capabilities sup-
and moved towards a repository-based approach by plac- port the overall mission/vision?
ing emphasis on architecture data elements that comprise
architecture products.[1] In February 2004 the documen- What outcomes are expected to be achieved by a
tation of Version 1.0 was released with volume I: De- particular capability or set of capabilities?
nitions and Guidelines, II: Product Descriptions and a
Deskbook. In April 2007 the Version 1.5 was released What services are required to support a capability?
with a documentation of Denitions and Guidelines,
Product Descriptions and Architecture Data Descrip- What is the functional scope and organizational span
tion. of a capability or set of capabilities?

On May 28, 2009 DoDAF v2.0 was approved by the De- What is our current set of capabilities that we are
partment of Defense.[7] The current version is DoDAF managing as part of a portfolio?
7.1. DEPARTMENT OF DEFENSE ARCHITECTURE FRAMEWORK 59

[10]
Each view depicts certain perspectives of an architecture
The Mission or Course of Action is described by a Con- as described below. Only a subset of the full DoDAF
cept of Operations (CONOPS), and is organized by Ca- viewset is usually created for each system development.
pabilities. The gure represents the information that links the op-
erational view, systems and services view, and technical
standards view. The three views and their interrelation-
Capabilities are described by Threads. ships driven by common architecture data elements
Threads are described by Activities executed in se- provide the basis for deriving measures such as interop-
rial or parallel. erability or performance, and for measuring the impact
of the values of these metrics on operational mission and
Activities are grouped into Mission Areas. Activities task eectiveness.[1]
dene operations for an Architecture.

Architectures are organized by mission areas. Ar- All view

chitectures provide proper resourcing of capabilities
required by the Mission or Course of Action.
7.1.4 Version 1.5 views
All view (AV) products provide overarching descriptions
of the entire architecture and dene the scope and context
of the architecture. The DoDAF V1.5 AV products are
dened as:

AV-1 Overview and Summary Information Scope,

purpose, intended users, environment depicted,
analytical ndings (if applicable)
AV-2 Integrated Dictionary Denitions of all terms
used in all products.

Operational view

Operational View (OV) products provide descriptions of

DoDAF V1.5 Linkages Among Views. [1]
the tasks and activities, operational elements, and infor-
mation exchanges required to accomplish DoD missions.
The OV provides textual and graphical representations of
operational nodes and elements, assigned tasks and ac-
tivities, and information ows between nodes. It denes
the type of information exchanged, the frequency of ex-
changes, the tasks and activities supported by these ex-
changes and the nature of the exchanges. The DoDAF
V1.5 OV products are dened as:

OV-1 High Level Operational Concept Graphic

DoD C4ISR Framework
The DoDAF V1.5 denes a set of products, a view model, OV-2 Operational Node Connectivity Description
that act as mechanisms for visualizing, understanding,
and assimilating the broad scope and complexities of an
architecture description through graphic, tabular, or tex-
tual means. These products are organized under four
views:
All view (AV)
Operational view (OV)
High level graphical and textual description of
operational concept (high level organizations,
missions, geographic conguration, connectivity,
etc.).
Operational nodes, activities performed at each
node, and connectivities and information ow
between nodes.
OV-3 Operational Information Exchange Matrix
Information exchanged between nodes and the
relevant attributes of that exchange such as media,
quality, quantity, and the level of interoperability
required.

Systems view (SV) OV-4 Organizational Relationships Chart

Command, control, coordination, and other
Technical standards view (TV) relationships among organizations.
60 CHAPTER 7. DEFENSE INDUSTRY FRAMEWORKS

OV-5 Operational Activity Model Activities, relation- SV-4a/SV-4b Systems/Services Functionality Description
ships among activities, inputs and outputs. In addi- The SV-4a documents system functional hierarchies
tion, overlays can show cost, performing nodes, or and system functions, and the system data ows
other pertinent information. between them. The SV-4 from DoDAF v1.0 is des-
ignated as 'SV-4a' in DoDAF v1.5. Although there
OV-6a Operational Rules Model One of the three is a correlation between OV-5 or business-process
products used to describe operational activity se- hierarchies and the system functional hierarchy
quence and timing that identies the business rules of SV-4a, it need not be a one-to-one mapping,
that constrain the operation. hence, the need for the Operational Activity to
Systems Function Traceability Matrix (SV-5a),
OV-6b Operational State Transition Description which provides that mapping.
One of the three products used to describe opera-
tional activity sequence and timing that identies SV-5a, SV-5b, SV-5c Operational Activity to Systems
responses of a business process to events. Function, Operational Activity to Systems and Ser-
vices Traceability Matrices
OV-6c Operational Event-Trace Description One of Operational Activity to SV-5a and SV-5b is a spec-
the three products used to describe operational ac- ication of the relationships between the set of
tivity sequence and timing that traces the actions in operational activities applicable to an architecture
a scenario or critical sequence of events. and the set of system functions applicable to that
architecture. The SV-5 and extension to the SV-5
OV-7 Logical Data Model Documentation of the data from DoDAF v1.0 is designated as 'SV-5a' and
requirements and structural business process rules SV-5b in DoDAF v1.5 respectively.
of the Operational View. (In DoDAF V1.5. This
SV-6 Systems/Services Data Exchange Matrix
corresponds to DIV-2 in DoDAF V2.0.)
Species the characteristics of the system data
exchanged between systems. This product focuses
Systems and services view on automated information exchanges (from OV-3)
that are implemented in systems. Non-automated
Systems and services view (SV) is a set of graphical and information exchanges, such as verbal orders, are
textual products that describe systems and services and captured in the OV products only.
interconnections providing for, or supporting, DoD func- SV-7 Systems/Services Performance Parameters Matrix
tions. SV products focus on specic physical systems with Species the quantitative characteristics of sys-
specic physical (geographical) locations. The relation- tems and system hardware/software items, their
ship between architecture data elements across the SV to interfaces (system data carried by the interface as
the OV can be exemplied as systems are procured and well as communications link details that implement
elded to support organizations and their operations. The the interface), and their functions. It species the
DoDAF V1.5 SV products are: current performance parameters of each system,
interface, or system function, and the expected or
SV-1 Systems/Services Interface Description required performance parameters at specied times
Depicts systems nodes and the systems resident at in the future. Performance parameters include all
these nodes to support organizations/human roles technical performance characteristics of systems
represented by operational nodes of the OV-2. for which requirements can be developed and spec-
SV-1 also identies the interfaces between systems ication dened. The complete set of performance
and systems nodes. parameters may not be known at the early stages
of architecture denition, so it should be expected
SV-2 Systems/Services Communications Description that this product will be updated throughout the
Depicts pertinent information about communica- systems specication, design, development, testing,
tions systems, communications links, and commu- and possibly even its deployment and operations
nications networks. SV-2 documents the kinds of life-cycle phases.
communications media that support the systems
and implements their interfaces as described in SV-8 Systems/Services Evolution Description
SV-1. Thus, SV-2 shows the communications Captures evolution plans that describe how the
details of SV-1 interfaces that automate aspects of system, or the architecture in which the system is
the needlines represented in OV-2. embedded, will evolve over a lengthy period of
time. Generally, the timeline milestones are critical
SV-3 Systems-Systems, Services-Systems, Services- for a successful understanding of the evolution
Services Matrices timeline.
provides detail on the interface characteristics de-
scribed in SV-1 for the architecture, arranged in SV-9 Systems/Services Technology Forecast Denes
matrix form. the underlying current and expected supporting
7.1. DEPARTMENT OF DEFENSE ARCHITECTURE FRAMEWORK 61

technologies that have been targeted using standard 7.1.5 Version 2.0 viewpoints
forecasting methods. Expected supporting tech-
nologies are those that can be reasonably forecast
given the current state of technology and expected
improvements. New technologies should be tied to
specic time periods, which can correlate against
the time periods used in SV-8 milestones.

SV-10a Systems/Services Rules Model Describes the

rules under which the architecture or its systems be-
have under specied conditions.

SV-10b Systems/Services State Transition Description

A graphical method of describing a system (or
system function) response to various events by
changing its state. The diagram basically represents [11]
the sets of events to which the systems in the Diagram of DoDAF V2.0 Viewpoints.
architecture will respond (by taking an action to
move to a new state) as a function of its current
state. Each transition species an event and an
action.

SV-10c Systems/Services Event-Trace Description

Provides a time-ordered examination of the system
data elements exchanged between participating
systems (external and internal), system functions,
or human roles as a result of a particular scenario.
Each event-trace diagram should have an accom-
panying description that denes the particular
scenario or situation. SV-10c in the Systems and
Services View may reect system-specic aspects
or renements of critical sequences of events
described in the Operational View.
Evolution of DoDAF V1.5 Views to DoDAF V2.0 Viewpoints.[12]
SV-11 Physical Schema One of the architecture prod-
ucts closest to actual system design in the Frame-
work. The product denes the structure of the vari-
ous kinds of system data that are utilized by the sys-
tems in the architecture. (In DoDAF V1.5. This
corresponds to DIV-3 in DoDAF V2.0.)

Technical standards view

Technical standards view (TV) products dene techni-

cal standards, implementation conventions, business rules
and criteria that govern the architecture. The DoDAF
V1.5 TV products are as follows:

TV-1 Technical Standards Prole - Extraction

of standards that applies to the given architecture.
(In DoDAF V1.5. Renamed to StdV-1 in DoDAF
V2.0.)

TV-2 Technical Standards Forecast - Description

of emerging standards that are expected to apply to
the given architecture, within an appropriate set of Mapping of DoDAF V1.5 Views to DoDAF V2.0 Viewpoints.[13]
timeframes. (In DoDAF V1.5. Renamed to StdV-2
in DoDAF V2.0.) In DoDAF V2.0, architectural viewpoints are composed
62 CHAPTER 7. DEFENSE INDUSTRY FRAMEWORKS

of data that has been organized to facilitate understand- Materiel (e.g., equipment, aircraft, and vessels) and
ing. To align with ISO Standards, where appropriate, the Personnel Types.
terminology has changed from Views to Viewpoint (e.g.,
the Operational View is now the Operational Viewpoint). The architectures for DoDAF V1.0 and DoDAF V1.5
may continue to be used. When appropriate (usually indi-
All Viewpoint (AV) Describes the overarching aspects cated by policy or by the decision-maker), DoDAF V1.0
of architecture context that relate to all viewpoints. and V1.5 architectures will need to update their archi-
tecture. When pre-DoDAF V2.0 architecture is com-
Capability Viewpoint (CV) New in DoDAF V2.0. Ar-
pared with DoDAF V2.0 architecture, concept dier-
ticulates the capability requirements, the delivery
ences (such as Node) must be dened or explained for the
timing, and the deployed capability.
newer architecture. In regard to DoDAF V1.5 products,
Data and Information Viewpoint (DIV) New in they have been transformed into parts of the DoDAF
DoDAF V2.0. Articulates the data relationships V2.0 models. In most cases, the DoDAF V2.0 Meta-
and alignment structures in the architecture content model supports the DoDAF V1.5 data concepts, with one
for the capability and operational requirements, notable exception: Node. Node is a complex, logical con-
system engineering processes, and systems and cept that is represented with more concrete concepts.
services.
Operational Viewpoint (OV) Includes the operational All Viewpoint (AV)
scenarios, activities, and requirements that support
capabilities. AV-1 Overview and Summary Information
Describes a Projects Visions, Goals, Objectives,
Project Viewpoint (PV) New in DoDAF V2.0. De- Plans, Activities, Events, Conditions, Measures,
scribes the relationships between operational and Eects (Outcomes), and produced objects.
capability requirements and the various projects be-
ing implemented. The Project Viewpoint also de- AV-2 Integrated Dictionary An architectural data
tails dependencies among capability and operational repository with denitions of all terms used
requirements, system engineering processes, sys- throughout
tems design, and services design within the Defense
Acquisition System process.
Capability Viewpoint (CV)
Services Viewpoint (SvcV) New in DoDAF V2.0.
Presents the design for solutions articulating the CV-1 Vision Addresses the enterprise concerns associ-
Performers, Activities, Services, and their Ex- ated with the overall vision for transformational en-
changes, providing for or supporting operational deavours and thus denes the strategic context for
and capability functions. a group of capabilities. The purpose of the CV-1
is to provide a strategic context for the capabilities
Standards Viewpoint (StdV) Renamed from Techni-
described in the Architecture Description.
cal Standards View. Articulates the applicable op-
erational, business, technical, and industry policies, CV-2 Capability Taxonomy Captures capability tax-
standards, guidance, constraints, and forecasts that onomies. The model presents a hierarchy of capa-
apply to capability and operational requirements, bilities. These capabilities may be presented in the
system engineering processes, and systems and ser- context of a timeline. The CV-2 species all the
vices. capabilities that are referenced throughout one or
Systems Viewpoint (SV) Articulates, for legacy sup- more architectures.
port, the design for solutions articulating the sys-
CV-3 Capability Phasing The planned achievement
tems, their composition, interconnectivity, and con-
of capability at dierent points in time or during
text providing for or supporting operational and ca-
specic periods of time. The CV-3 shows the capa-
pability functions. Note, System has changed in
bility phasing in terms of the activities, conditions,
DoDAF V2.0 from DoDAF V1.5: System is not just
desired eects, rules complied with, resource con-
computer hardware and computer software. Sys-
sumption and production, and measures, without re-
tem is now dened in the general sense of an as-
gard to the performer and location solutions
semblage of components - machine, human - that
perform activities (since they are subtypes of Per- CV-4 Capability Dependencies The dependencies be-
former) and are interacting or interdependent. This tween planned capabilities and the denition of log-
could be anything, i.e., anything from small pieces ical groupings of capabilities.
of equipment that have interacting or interdependent
elements, to Family of Systems (FoS) and System of CV-5 Capability to Organizational Development Mapping
Systems (SoS). Note that Systems are made up of The fulllment of capability requirements shows
7.1. DEPARTMENT OF DEFENSE ARCHITECTURE FRAMEWORK 63

the planned capability deployment and interconnec- OV-6a Operational Rules Model One of three mod-
tion for a particular Capability Phase. The CV-5
shows the planned solution for the phase in terms
of performers and locations and their associated
concepts.
CV-6 Capability to Operational Activities Mapping
A mapping between the capabilities required and
the operational activities that those capabilities
support.
CV-7 Capability to Services Mapping A mapping be-
tween the capabilities and the services that these ca-
pabilities enable.
els used to describe activity (operational activity). It
identies business rules that constrain operations.
OV-6b State Transition Description One of three
models used to describe operational activity (ac-
tivity). It identies business process (activity)
responses to events (usually, very short activities).
OV-6c Event-Trace Description One of three models
used to describe activity (operational activity). It
traces actions in a scenario or sequence of events.
Project Viewpoint (PV)

Data and Information Viewpoint (DIV) PV-1 Project Portfolio Relationships It describes the
dependency relationships between the organiza-
DIV-1 Conceptual Data Model The required high- tions and projects and the organizational structures
level data concepts and their relationships. needed to manage a portfolio of projects.

DIV-2 Logical Data Model The documentation of the PV-2 Project Timelines A timeline perspective on pro-
data requirements and structural business process grams or projects, with the key milestones and inter-
(activity) rules. In DoDAF V1.5, this was the OV-7. dependencies.

DIV-3 Physical Data Model The physical implemen- PV-3 Project to Capability Mapping A mapping of
tation format of the Logical Data Model enti- programs and projects to capabilities to show how
ties, e.g., message formats, le structures, physical the specic projects and program elements help to
schema. In DoDAF V1.5, this was the SV-11. achieve a capability.

Note, see Logical data model for discussion of the rela- Services Viewpoint (SvcV)
tionship of these three DIV data models, with comparison
of the Conceptual, Logical & Physical Data Models. SvcV-1 Services Context Description The identica-
tion of services, service items, and their intercon-
nections.
Operational Viewpoint (OV)
SvcV-2 Services Resource Flow Description A de-
OV-1 High-Level Operational Concept Graphic scription of Resource Flows exchanged between
The high-level graphical/textual description of the services.
operational concept.
SvcV-3a Systems-Services Matrix The relationships
OV-2 Operational Resource Flow Description A de- among or between systems and services in a given
scription of the Resource Flows exchanged between Architectural Description.
operational activities.
SvcV-3b Services-Services Matrix The relationships
OV-3 Operational Resource Flow Matrix A descrip- among services in a given Architectural Description.
tion of the resources exchanged and the relevant at- It can be designed to show relationships of interest,
tributes of the exchanges. (e.g., service-type interfaces, planned vs. existing
interfaces).
OV-4 Organizational Relationships Chart The orga-
nizational context, role or other relationships among SvcV-4 Services Functionality Description The func-
organizations. tions performed by services and the service data
ows among service functions (activities).
OV-5a Operational Activity Decomposition Tree
The capabilities and activities (operational activi- SvcV-5 Operational Activity to Services Traceability Matrix
ties) organized in a hierarchal structure. A mapping of services (activities) back to opera-
tional activities (activities).
OV-5b Operational Activity Model The context of
capabilities and activities (operational activities) and SvcV-6 Services Resource Flow Matrix It provides
their relationships among activities, inputs, and out- details of service Resource Flow elements being
puts; Additional data can show cost, performers or exchanged between services and the attributes of
other pertinent information. that exchange.
64 CHAPTER 7. DEFENSE INDUSTRY FRAMEWORKS

SvcV-7 Services Measures Matrix The measures system data ows among system functions (activi-
(metrics) of Services Model elements for the ties).
appropriate timeframe(s).
SV-5a Operational Activity to Systems Function
SvcV-8 Services Evolution Description The planned Traceability Matrix
incremental steps toward migrating a suite of ser- A mapping of system functions (activities) back to
vices to a more ecient suite or toward evolving operational activities (activities).
current services to a future implementation. SV-5b Operational Activity to Systems Traceability Matrix
A mapping of systems back to capabilities or oper-
SvcV-9 Services Technology & Skills Forecast The
ational activities (activities).
emerging technologies, software/hardware prod-
ucts, and skills that are expected to be available in a SV-6 Systems Resource Flow Matrix Provides
given set of time frames and that will aect future details of system resource ow elements being
service development. exchanged between systems and the attributes of
that exchange.
SvcV-10a Services Rules Model One of three models
used to describe service functionality. It identies SV-7 Systems Measures Matrix The measures (met-
constraints that are imposed on systems functional- rics) of Systems Model elements for the appropriate
ity due to some aspect of system design or imple- timeframe(s).
mentation.
SV-8 Systems Evolution Description The planned in-
SvcV-10b Services State Transition Description cremental steps toward migrating a suite of systems
One of three models used to describe service to a more ecient suite, or toward evolving a current
functionality. It identies responses of services to system to a future implementation.
events.
SV-9 Systems Technology & Skills Forecast The
SvcV-10c Services Event-Trace Description One of emerging technologies, software/hardware prod-
three models used to describe service functionality. ucts, and skills that are expected to be available in a
It identies service-specic renements of critical given set of time frames and that will aect future
sequences of events described in the Operational system development.
Viewpoint.
SV-10a Systems Rules Model One of three models
used to describe system functionality. It identies
Standards Viewpoint (StdV) constraints that are imposed on systems functional-
ity due to some aspect of system design or imple-
StdV-1 Standards Prole The listing of standards that mentation.
apply to solution elements. In DoDAF V1.5, this
was the TV-1. SV-10b Systems State Transition Description One
of three models used to describe system func-
StdV-2 Standards Forecast The description of tionality. It identies responses of systems to
emerging standards and potential impact on current events.
solution elements, within a set of time frames. In
DoDAF V1.5, this was the TV-2. SV-10c Systems Event-Trace Description One of
three models used to describe system functionality.
It identies system-specic renements of critical
Systems Viewpoint (SV) sequences of events described in the Operational
Viewpoint.
SV-1 Systems Interface Description The iden-
tication of systems, system items, and their
interconnections. 7.1.6 Creating an integrated architecture
using DoDAF
SV-2 Systems Resource Flow Description A descrip-
tion of Resource Flows exchanged between systems. The DODAF 2.0 Architects Guide [14] repeated DOD In-

SV-3 Systems-Systems Matrix The relationships struction 4630.8 denition of an integrated architecture
among systems in a given Architectural Descrip- as An architecture consisting of multiple views facilitat-
tion. It can be designed to show relationships of ing integration and promoting interoperability across ca-
interest, (e.g., system-type interfaces, planned vs. pabilities and among integrated architectures. For the pur-
existing interfaces). poses of architecture development, the term integrated
means that data required in more than one of the architec-
SV-4 Systems Functionality Description The func- tural models is commonly dened and understood across
tions (activities) performed by systems and the those models. Integrated architectures are a property or
7.1. DEPARTMENT OF DEFENSE ARCHITECTURE FRAMEWORK
Illustration of the integrated architecture.[1]
design principle for architectures at all levels: Capabil-
ity,Component, Solution, and Enterprise (in the context
of the DoD Enterprise Architecture (EA) being a fed-
eration [of] architectures). In simpler terms, integra-
tion is seen in the connection from items common among
architecture products, where items shown in one archi-
tecture product (such as sites used or systems interfaced
or services provided) should have the identical number,
name, and meaning appear in related architecture prod-
uct views.
There are many dierent approaches for creating an in- ucts are required for each type of analysis, in the con-
tegrated architecture using DoDAF and for determining text of the Net-Ready Key Performance Parameter (NR-
which products are required. The approach depends on KPP):
the requirements and the expected results; i.e., what the
resulting architecture will be used for. As one exam-
ple, the DoDAF v1.0 listed the following products as the
minimum set of products required to satisfy the deni-
tion of an OV, SV and TV. One note: while the DoDAF
does not list the OV-1 artifact as a core product, its de-
velopment is strongly encouraged. The sequence of the
artifacts listed below gives a suggested order in which the
artifacts could be developed. The actual sequence of view
generation and their potential customization is a function
of the application domain and the specic needs of the
eort.
AV-1 : Overview and Summary Information
AV-2 : Integrated Dictionary
OV-1 : High Level Operational Concept Graphic
OV-5 : Operational Activity Model
OV-2 : Operational Node Connectivity Description
OV-3 : Operational Informational Exchange Matrix
65
SV-1 : System Interface Description
TV-1 : Technical Standards Prole
One concern about the DoDAF is how well these products
meet actual stakeholder concerns for any given system of
interest. One can view DoDAF products, or at least the
3 views, as ANSI/IEEE 1471-2000 or ISO/IEC 42010
viewpoints. But to build an architecture description
that corresponds to ANSI/IEEE 1471-2000 or ISO/IEC
42010, it is necessary to clearly identify the stakehold-
ers and their concerns that map to each selected DoDAF
product. Otherwise there is the risk of producing prod-
ucts with no customers.
DoDAF V1.5 Products Matrix[15]
The gure DoDAF V1.5 Products Matrix shows how
the DoD Chairman of the Joint Chiefs of Sta Instruction
(CJCSI) 6212.01E species which DoDAF V1.5 prod-
Initial Capabilities Document (ICD). Documents
the need for a materiel solution to a specic capa-
bility gap derived from an initial analysis of alter-
natives executed by the operational user and, as re-
quired, an independent analysis of alternatives. It
denes the capability gap in terms of the functional
area, the relevant range of military operations, de-
sired eects, and time.
Capability Development Document (CDD). A doc-
ument that captures the information necessary to de-
velop a proposed program(s), normally using an evo-
lutionary acquisition strategy. The CDD outlines an
aordable increment of militarily useful, logistically
supportable and technically mature capability.
Capability Production Document (CPD). A docu-
ment that addresses the production elements specic
to a single increment of an acquisition program.
Information Support Plan (ISP).[16] The identica-
tion and documentation of information needs, in-
66
frastructure support, IT and NSS interface require-
ments and dependencies focusing on net-centric, in-
teroperability, supportability and suciency con-
cerns (DODI 4630.8).[17]
Tailored Information Support Plan (TISP). The pur- DM2 is important to a particular viewer of Departmental
pose of the TISP process is to provide a dynamic and processes:
ecient vehicle for certain programs (ACAT II and
below) to produce requirements necessary for I&S
Certication. Select program managers may request
to tailor the content of their ISP (ref ss). For pro-
grams not designated OSD special interest by ASD
(NII)/DOD CIO, the component will make nal de-
cision on details of the tailored plan subject to mini-
mums specied in the TISP procedures linked from
the CJCSI 6212 resource page and any special needs
identied by the J-6 for the I&S certication pro-
cess.
7.1.7 Representation
Representations for the DoDAF products may be drawn
from many diagramming techniques including:
tables
IDEF
Entity-relationship diagrams (ERDs)
UML
SysML
There is a UPDM (Unied Prole for DoDAF and
MODAF) eort within the OMG to standardize the rep-
resentation of DoDAF products when UML is used.
DoDAF generically describes in the representation of the
artifacts to be generated, but allows considerable exi-
bility regarding the specic formats and modeling tech-
niques. The DoDAF deskbook provides examples in us-
ing traditional systems engineering and data engineering
techniques, and secondly, UML format.[18] DoDAF pro-
claims latitude in work product format, without profess-
ing one diagramming technique over another.
In addition to graphical representation, there is typically a
requirement to provide metadata to the Defense Informa-
tion Technology Portfolio Repository (DITPR) or other
architectural repositories.
7.1.8 Meta-model
DoDAF has a meta-model underpinning the framework,
dening the types of modelling elements that can be used
in each view and the relationships between them. DoDAF
versions 1.0 thru 1.5 used the CADM meta-model, which
was dened in IDEF1X (then later in UML) with an XML
CHAPTER 7. DEFENSE INDUSTRY FRAMEWORKS
Schema derived from the resulting relational database.
From version 2.0, DoDAF has adopted the IDEAS Group
foundation ontology as the basis for its new meta-model.
This new meta-model is called DM2"; an acronym for
DoDAF Meta-Model. Each of these three levels of the
1. The conceptual level or Conceptual Data Model
(CDM) denes the high-level data constructs from
which Architectural Descriptions are created in
non-technical terms, so that executives and man-
agers at all levels can understand the data basis
of Architectural Description. Represented in the
DoDAF V2.0 DIV-1 Viewpoint.
2. The Logical Data Model (LDM) adds technical in-
formation, such as attributes to the CDM and, when
necessary, claries relationships into an unambigu-
ous usage denition. Represented in the DoDAF
V2.0 DIV-2 Viewpoint.
3. The Physical Exchange Specication (PES) consists
of the LDM with general data types specied and
implementation attributes (e.g., source, date) added,
and then generated as an XSD. Represented in the
DoDAF V2.0 DIV-3 Viewpoint.[6]
The purposes of the DM2 are:
1. Establish and dene the constrained vocabulary for
description and discourse about DoDAF models
(formerly products) and their usage in the 6 core
processes
2. Specify the semantics and format for federated EA
data exchange between:architecture development
and analysis tools and architecture databases across
the DoD Enterprise Architecture (EA) Community
of Interest (COI) and with other authoritative data
sources
3. Support discovery and understandability of EA data:
(a) Discovery of EA data using DM2 categories
of information
(b) Understandability of EA data using DM2s
precise semantics augmented with linguistic
traceability (aliases)
4. Provide a basis for semantic precision in architec-
tural descriptions to support heterogeneous archi-
tectural description integration and analysis in sup-
port of core process decision making.[6]
The DM2 denes architectural data elements and enables
the integration and federation of Architectural Descrip-
tions. It establishes a basis for semantic (i.e., understand-
ing) consistency within and across Architectural Descrip-
tions. In this manner, the DM2 supports the exchange and
7.1. DEPARTMENT OF DEFENSE ARCHITECTURE FRAMEWORK
reuse of architectural information among JCAs, Compo- 7.1.11 See also
nents, and Federal and Coalition partners, thus facilitat-
ing the understanding and implementation of interoper-
ability of processes and systems. As the DM2 matures to
meet the ongoing data requirements of process owners,
decision makers, architects, and new technologies, it will
to a resource that more completely supports the require-
ments for architectural data, published in a consistently
understandable way, and will enable greater ease for dis-
covering, sharing, and reusing architectural data across
organizational boundaries.[6]
To facilitate the use of information at the data layer, the
DoDAF describes a set of models for visualizing data
through graphic, tabular, or textual means. These views 7.1.12 References
relate to stakeholder requirements for producing an Ar-
chitectural Description.[6]
7.1.9 Relationship to other architecture
frameworks
The UPDM (Unied Prole for DoDAF and MODAF)
is an OMG initiative to standardize UML and SysML us-
age for USA and UK defense architecture frameworks.
In addition, the multi-national IDEAS Group, which is
supported by Australia, Canada, Sweden, UK, USA, with
NATO observers, has launched an initiative to develop a
formal ontology for enterprise architectures.
7.1.10 Criticism
The use of DoDAF at the U.S. Department of Defense
for developing enterprise architecture can hardly be con- [10] DODAF 2.0 Capability Viewpoint.
sidered successful:
In 2004 it was reported that despite three years of
eort and over $203 million in reported obligations,
DoDs architecture remains insuciently dened,
and the way in which the department makes busi-
ness systems investments decisions remains largely
unchanged.[19]
In 2005 it was reported that despite spending al-
most four years and about $318 million, DoD does
not have an eective architecture programme.[20]
In 2013 it was reported that even though DoD has
spent more than 10 years and at least $379 million on
its business enterprise architecture, its ability to use
the architecture to guide and constrain investments
has been limited.[21]
The historical analysis shows that the use of DoDAF
at the U.S. Department of Defense provides the
most spectacular example of progressing time and
money investments in [enterprise architecture], but
getting the same unsatisfactory results.[22]
67
IDEAS Group
IUID
MODAF Meta-Model
NCOW
European Space Agency Architectural Framework
(ESAAF) - a framework for European space-based
Systems of Systems
[1] DoD (2007) DoD Architecture Framework Version 1.5.
23 April 2007
[2] DoD (2009) DoD Architecture Framework Version 2.0.
28 May 2009
[3] (reference: Zachman Framework)
[4] Architecture Framework FAQ. Retrieved 2007-08-07.
[5] CJCSM 3170.01C OPERATION OF THE JOINT CA-
PABILITIES INTEGRATION AND DEVELOPMENT
SYSTEM. 1 May 2007. mandatory appendices for ICD,
CDD, and CPD, e.g. pg E-A-5 Mandatory: OV-1
[6] DoDAF Meta Model (DM2)".
[7] DoD CIO Memo Releasing DoDAF 2.0
[8] http://dodcio.defense.gov/dodaf20.aspx
[9] DoD CIO DoDAF Website
[11] Diagram of DoDAF V2.0 Viewpoints
[12] Evolution of DoDAF V1.5 Views to DoDAF V2.0 View-
points
[13] Mapping of DoDAF V1.5 Views to DoDAF V2.0 View-
points
[14] DoDAF V2.0 Volume 2 Architects Guide May 2009
(PDF).
[15] DoDAF V1.5 Products Matrix
[16] Information Support Plan (DAU ACQuipedia entry)".
[17] E4.A2 ISP Architecture Guidance, Procedures for In-
teroperability and Supportability of Information Technol-
ogy (IT) and National Security Systems (NSS) (PDF), 2004,
p. 83
[18] https://acc.dau.mil/GetAttachment.aspx?id=31667&
pname=file&lang=en-US&aid=28906
[19] GAO (2004). DoD Business Systems Modernization: Lim-
ited Progress in Development of Business Enterprise Archi-
tecture and Oversight of Information Technology Invest-
ments. Washington, DC: Government Accountability Of-
ce.
68 CHAPTER 7. DEFENSE INDUSTRY FRAMEWORKS

[20] GAO (2005). DoD Business Systems Modernization: Knowledge Management/ Decision Support
Long-Standing Weaknesses in Enterprise Architecture De-
velopment Need to Be Addressed. Washington, DC: Gov- Metadata Registry
ernment Accountability Oce.
Naval Architecture Elements Reference Guide
[21] GAO (2013). DoD Business Systems Modernization: Fur-
ther Actions Needed to Address Challenges and Improve Universal Joint Task List (UJTL)
Accountability. Washington, DC: Government Account-
CJCSI 6212.01 document
ability Oce.

[22] Enterprise Architecture Frameworks: The Fad of the

Century, Svyatoslav Kotusev, British Computer Society 7.2 MODAF
(BCS), July 2016

The British Ministry of Defence Architecture Frame-

7.1.13 Further reading work (MODAF) is an Architecture Framework which
denes a standardised way of conducting Enterprise Ar-
Dennis E. Wisnosky and Joseph Vogel (2004). chitecture, originally developed by the UK Ministry of
Dodaf Wizdom: a Practical Guide to Planning, Man- Defence.
aging and Executing Projects to Build Enterprise Ar- Initially the purpose of MODAF was to provide rigour
chitectures using the Department of Defense Archi- and structure to support the denition and integration
tecture Framework. Wizdom Systems, Inc., 2004. of MOD equipment capability, particularly in support of
ISBN 1-893990-09-5. Network Enabled Capability (NEC).
More recently, MOD has additionally been using
7.1.14 External links MODAF to underpin the use of the Enterprise Architec-
ture approach to the capture of the information about the
DoDAF V2.02 business to identify the processes and resources required
to deliver the vision expressed in the strategy.
DoDAF V2.0
Printable version of DoDAF V1.5 Volume 1
Printable version of DoDAF V1.5 Volume 2
7.2.1 Overview
Printable version of DoDAF V1.5 Volume 3 MODAF is an internationally recognised enterprise ar-
chitecture framework developed by the MOD to support
DoDAF V2.0 Journal : The electronic interface for
Defence planning and change management activities. It
DoDAF support.
does this by enabling the capture and presentation of in-
DoDAF V2.0 Promulgation Memo May 28, 2009 formation in a rigorous, coherent and comprehensive way
that aids the understanding of complex issues, thereby
DoDAF section of Architecture Framework Forum providing managers with the key factors they should con-
Information resource dedicated to DoDAF as it re- sider when making decisions about changes to the busi-
lates to other architecture frameworks ness. It is used extensively in Defence acquisition to
support systems engineering, particularly in support of
DoD Business Enterprise Architecture BEA 10.0
Network Enabled Capability (NEC), which is about the
(February 14, 2013)
coherent integration of sensors, decision-makers, weapon
Demystifying DoDAF Video Series systems and support capabilities to achieve the desired ef-
fect.
Two Presentations on DoDAF 2.0 from Integrated
With the publication of the MOD Information Strategy
EA Conferences 2008 and 2009
(MODIS)[4] and its Enterprise Architecture (EA) Sub-
Department of Defense Information Enterprise Ar- Strategy, the MOD has recognised the utility of EA to
chitecture support business improvement. MODAF is central to the
use of EA in MOD.
DoD Architecture Registry System
MODAF is managed and maintained by sta working for
DoD Information Technology Portfolio Repository the MODs Chief Information Ocer[5] (CIO), as part of
their role to provide Information Policy and Standards.
DoD Information Technology Standards and Prole Additional support is provided by the MODs System En-
Registry gineering and Integration Group, as part of their role in
Joint C4I Program Assessment Tool developing the System of Systems Approach (SOSA),[6]
a common set of principles, rules, and standards to enable
Joint Common System Function List the delivery of better interoperability between systems.
7.2. MODAF 69

MOD is working closely with its International Allies
to ensure coherence with their architecture frameworks
to enable the sharing of information about capabili-
ties elded in coalition operations in-order to support
interoperability. MODAF was developed from the
US Department of Defense Architecture Framework
(DoDAF) version 1.0, but has been extended and modi-
ed to meet MOD requirements by the addition of Strate-
gic, Acquisition and Service Oriented Viewpoints and the
provision of the M3.
MODAF version 1.0 was released in 2005, following de-
velopment work by the MODAF Partners, a collabora-
tive team of MOD sta and contractors from a number
of industry partners and has been continuously improved
since Version 1.0, the latest release, version 1.2.004, was
released in May 2010
Service Orientated Viewpoint (SOV) describes the
services, (i.e. units of work supplied by providers to
consumers), required to support the processes de-
scribed in the operational Views;
Systems Viewpoint (SV) describes the physical im-
plementation of the Operational and Service Orien-
tated Views and, thereby, dene the solution;
Acquisition Viewpoint (AcV) describes the depen-
dencies and timelines of the projects that will of de-
liver the solution;
Technical Viewpoint (TV) denes the standards that
are to be applied to the solution;
All Viewpoint (AV) provides a description and glos-
sary of the contents of the architecture.

The relationship between the data in the MODAF Views

7.2.2 History is dened in the MODAF Meta Model, known as the M3.
The M3 provides a logical structure for the storage of the
MODAF was initially developed for MOD from two par- data in a database and, subsequent, provides the necessary
allel work strands, an MOD-funded research programme coherence for the data to be shared with other MODAF
undertaken by QinetiQ (formerly the Defence Evaluation architectures.
Research Agency) and a separate DoDAF-based devel-
opment by MODAF Partners, a consortium of Cornwell
Management Consulting (now Serco) and PA Consulting 7.2.4 Functionality of Framework
Group with Model Futures providing the technical in-
put, and extended by other key suppliers such as Logica In MOD, MODAF has primarily been used in acquisi-
and Vega through work for the MOD Integration Author- tion domains, programmes and delivery teams to support
ity (as of April 2008 the System Engineering Integration the delivery of military capability, particularly NEC. A
Group (SEIG)). The draft version of MODAF combined number of MODAF architectures directly support oper-
the metamodel developed from the QinetiQ research pro- ations in Afghanistan. In addition, MODAF is widely
gramme and the views developed by MODAF Partners. used by its industry partners, such as BAE Systems,
The meta-model was subsequently replaced with the M3 Thales, Lockheed Martin, Boeing and Serco. It is also
for the released version of MODAF. used by other government departments and agencies,
such as GCHQ, and external bodies such as the National
Air Trac Services (NATS). MODAF is used by the
7.2.3 Framework Swedish Armed Forces to support the development of
military capability, and it has been adapted by NATO
MODAF provides a set of templates (called Views) that to form the core of the NATO Architecture Framework
provide a standard notation for the capture of informa- (NAF).
tion about a business in order to identify ways to improve
the business. Each MODAF View oers a dierent per-
spective on the business to support dierent stakeholder 7.2.5 Harmonisation
interests, presented in a format, usually graphical, that
aids understanding of how a business operates. MODAF will continue in its current form for the fore-
seeable future. However, MOD is working closely with
The Views are divided into seven categories (View- the United States Department of Defense, the Canadian
points): Department of National Defence, the Australian Depart-
ment of Defence, and the Swedish Armed Forces to de-
Strategic Viewpoint (StV) denes the desired busi- velop the International Defence Enterprise Architecture
ness outcome, and what capabilities are required to Specication (IDEAS). Although the focus for IDEAS
achieve it; has been the ability to provide a mechanism to bet-
ter enable the exchange of architecture information be-
Operational Viewpoint (OV) denes (in abstract tween Nations, the IDEAS Management Group are also
rather than physical terms) the processes, informa- actively considering how their architecture frameworks
tion and entities needed to full the capability re- should converge, perhaps into a single unied architec-
quirements; ture framework.[7]
70
7.2.6 Tools and Tooling
The MOD is agnostic about which software tools should
or should not be used to develop MODAF architecture
descriptions. The key requirement is that they should cor-
rectly implement the M3[8] with downloads in Sparx Sys-
tems Enterprise Architect; HTML and XMI formats. to
provide a coherent structure against which architecture
information can be exchanged. A number of tools oer
this functionality.
The MOD has been working with the Object Manage-
ment Group (OMG) to develop the Unied Prole for
DoDAF and MODAF (UPDM), an abstract UML pro-
le that implements the MODAF Metamodel (M3), it-
self an abstract UML prole for UML modelling tools,
as well as the DODAF metamodel (DM2) . It is based on
the Unied Modelling Language (UML) and extends the
Systems Modelling Language (SysML) UML prole.
7.2.7 Terminology
An architectural framework or architecture frame-
work is a specication of how to organise and present
architectural models. An architectural framework con-
sists of a standard set of views, which each have a specic
purpose.
An architectural description is a contiguous, coher-
ent model of an enterprise. An architectural description
comprises architectural products. MODAF is not an
architectural description.
A view is a specication of a way to present an aspect
of the enterprise. Views are dened with one or more
purposes in mind - e.g., showing the logical topology of
the enterprise, describing a process model, dening a data
model, etc.
An architectural product is a model of a particular as-
pect of the enterprise. An architectural product conforms
to a view.
A viewpoint is a collection of views. Viewpoints are
usually categorized by domain - e.g., in MODAF there
are seven viewpoints.
7.2.8 Applications
Although originally developed by the UK Ministry of De-
fence, MODAF is the standard architecture framework
for other organisations, such as:
GCHQ
Swedish Armed Forces
BAE Systems use MODAF on a number of internal The NATO Architecture Framework is an Enterprise
programmes, most notably their TRAiDE environ- Architecture framework by the NATO derived from the
ment DoDAF Enterprise architecture.
CHAPTER 7. DEFENSE INDUSTRY FRAMEWORKS
EADS use MODAF as part of the Modelling and
Simulation process for NetCOS their Synthetic En-
vironment
Thales Group use MODAF in their work for UK
MOD
Avolution use MODAF widely within the UK De-
fence and Security sectors
BAA Limited
In addition, revision 3 of the NATO Architecture Frame-
work (NAF) is identical to MODAF at its core, but
extends the framework by adding views for Bandwidth
Analysis, SOA and Standards congurations.
MODAF is also the basis for other frameworks such as
TRAK, a domain-free framework, which is based on
MODAF 1.2
7.2.9 References
[1] 513014N 0730W / 51.50389N 0.12500W
[2] Defence in the Community. Ministry of Defence. Re-
trieved 22 March 2010.
[3] Defence Spending. Ministry of Defence. Retrieved 22
March 2010.
[4] Error pages Archived 18 May 2010 at the Wayback Ma-
chine.
[5] House of Commons Hansard Written Answers for 13 Jan
2009 (pt 0004)
[6] Archived 13 October 2010 at the Wayback Machine.
[7] IDEAS Group. IDEAS DM2 MetaModel. IDEAS
Group.
[8] Ministry of Defence | About Defence | Corporate Publi-
cations | Information Management | MODAF | MODAF
Meta Model
7.2.10 External links
MOD Site for MODAF
modaf.com - the MODAF user site
7.3 NATO Architecture Frame-
work
7.4. AGATE ARCHITECTURE FRAMEWORK 71

The current NATO C3 System Architecture Framework
v2 (NAF v2), issued by NATO in September 2004 pro-
vides guidance on describing communication and infor-
mation systems. Revision 3 of the NATO Architecture
Framework (NAF), promulgated in November 2007, is
identical to MODAF at its core, but extends the frame-
work by adding views for Bandwidth Analysis, Semicon-
ductor Optical Ampliers (SOA) and standard congu- In most other respects, the MODAF documentation is t
rations.
The seven views are:
NATO All View (NAV)
NATO Capability View (NCV)
NATO Operational View (NOV)
NATO Service-Oriented View (NSOV)
NATO Systems View (NSV)
NATO Technical View (NTV)
NATO Programme View (NPV)
Each view has a set of subviews.
The SOA views dier signicantly between
MODAF and NAF. In particular, MODAF han-
dles in service orchestration in the Operational
Viewpoint (OV-5) whereas NAF uses NSOV-5
MODAF does not have a TV-3 view
for use in developing NAF architectures.
7.3.3 External links
NATO C3 Board
NATO Architecture Framework v3
The initial work done on the bandwidth and fre-
quency view in NAF v3 has since been further in-
vestigated by UK MOD CIO-J6 as part of the Spec-
trum Management work for CCEB
NATO Presentation on NAF by Frits Broekema
from Integrated EA Conference 2009
Summary of changes from NAF v2 to v3

7.3.4 See also

7.3.1 NAF Meta-Model (NMM)
European Space Agency Architectural Framework
NAF uses the same meta-model as MODAF. The meta- (ESAAF) - a framework for European space-based
model is documented in chapter 5 of the NATO Archi- Systems of Systems
tecture Framework. Version 3.1 of the NMM is identical
to v1.2.003 of the MODAF Meta-Model
7.4 AGATE Architecture Frame-
7.3.2 Using the UK Ministry of Defence's work
MODAF Documentation for NAF
Work AGATE (Atelier de Gestion de l'ArchiTEcture des sys-
tmes d'information et de communication) is a frame-
The documentation of the NAF Rev 3 views (Chapter work for modeling [1]
computer or communication systems
4) does not always align well with the NAF Meta Model architecture.
(Chapter 5). This is particularly the case with some of It is promoted by the Dlgation Gnrale pour
the examples, which are based on DoDAF version 1.0. l'Armement (DGA), the French government agency
Some NAF users nd it useful to rst of all refer the o- which conducts development and evaluation programs
cial MODAF Documentation - . This is a useful strategy, for weapon systems for the French military. All ma-
as the MOD documentation can be somewhat easier to jor DGA weapons and information technology system
follow, and NAF and MODAF share a common meta- procurements are required to document their proposed
model. However, there are some issues to consider: system architecture using the set of views prescribed in
AGATE.
The MODAF documentation covers version 1.2.004 AGATE is similar to DoDAF, promoted by U.S. Depart-
of the meta-model which has some small dierences ment of Defense (DoD) or MODAF, promoted by UK
from v3.1 of the NAF Meta-Model (which was a Ministry of Defence (MoD). It is only available in French.
NATO release of v1.2.001 of the MODAF Meta-
Model). At the time of writing, plans were in place
to update the NAF Meta-Model to correspond with 7.4.1 Scope
MODAF v1.2.004. At any time though, there is a
chance of NAF being behind MODAF as updates AGATE denes architectural views for systems and sys-
are made. tems of systems, covering:
72 CHAPTER 7. DEFENSE INDUSTRY FRAMEWORKS

Stakes and objectives of the system 7.4.5 See also

Description of the related organizations Dlgation Gnrale pour l'Armement

processes and information ows Department of Defense Architecture Framework

(DoDAF)
Security requirements, in compliance with DGA NATO Architecture Framework (NAF)
policy
British Ministry of Defence Architecture Frame-
Services of the system, and traceability with opera- work (MODAF)
tional needs
OBASHI The OBASHI Business & IT methodology
Logical architecture of the system and framework

Physical architecture of the systems, and hardware

and software products used in this architecture
7.4.6 References
[1] AGATE v3 Reference Manual (First ed.). MINISTRE
Life cycle of the system DE LA DFENSE. 5 December 2005. Retrieved 6 June
2014.

7.4.2 AGATE Views [2] Manuel de rfrence AGATE V3, December 2005, El-
ments de dpart AGATE et Origine
An AGATE model is organized into 5 views:
7.4.7 External links
Stakes, Objectives, and context about the system
AGATE page on French Defense procurement web-
Business architecture: describes organizations and site
Business processes managed by the modelized
short presentation of AGATE on French Defense
Information system
procurement portal
Service-oriented architecture: describes the
Services of the system.

Logical architecture of the system

Physical architecture of the systems, and hardware

and software products used in this architecture

7.4.3 Representation

The AGATE meta-model is dened using a UML repre-

sentation.
Visio elements for the AGATE representation are pro-
vided by the DGA.

7.4.4 History

The rst DGA initiative for a standardized French ar-

chitecture framework was initialized in July 2001, under
the acronym AMAC. The denomination was changed to
AGATE in November of the same year.[2]

March 2004: Version 2.1

December 2005: Version 3

Chapter 8

Government frameworks

8.1 Government Enterprise Archi- The QGEA is a federated architecture, which acknowl-
edges that the Queensland Government is a single enter-
tecture prise composed of autonomous agencies. Agencies are
responsible for their own enterprise architectures, yet are
The Queensland Government Enterprise Architec- able to leverage and contribute to whole of-Government
ture (now known as the QGEA 2.0) is an initiative of the architectures and investments through a single consistent
Queensland Government Chief Information Oce (QG- framework. The current state assessment of each depart-
CIO) in Australia. QGEA 2.0 is the collection of ICT ments business, information, application and technology
policies and associated documents that guides agency ICT component assets (called the ICT Baseline reporting ac-
initiatives and investments to improve the compatibility tivity) enables ICT portfolio investment analysis both at
and cost-eectiveness of ICT across the government. The the department and whole-of-Government level.
QGEA provides the decision making and management
structures to support the development of better services
for Queenslanders, more ecient and eective use of 8.1.2 History
information and ICT in government and eective part-
nering with the private sector through the application of The former Department of Communication and Informa-
whole-of-Government, cross agency and agency informa- tion, Local Government, Planning and Sport commenced
tion and information communications technology policies a project in early 1999 to dene what was called at the
and practices.[1] time a Government Information Architecture with the
aim of improving the interoperability of communication
and information systems and the sharing of information
8.1.1 Description resources across Queensland Government agencies.
The QGEA is a tailored EA which delivers a comprehen- Loosely based on the META Group Enterprise Architec-
sive set of processes, frameworks, policies, guidelines and ture Service methodology the rst version was published
tools to describe how the Queensland Government organ- in May 2001.
ises its resources to support service delivery. After an internal review of IT management across the
The QGEA assists agencies, multi-agency projects, Queensland Government in 2005 this original eort was
shared service providers and whole-of-Government ini- replaced by the expanded Government Enterprise Archi-
tiatives to: tecture (GEA). At the same time the notion of enterprise
architecture became enshrined in legislation in the form
of the Financial Management Standard. This became one
deliver services in a coordinated, cost eective and
of the rst known examples of enterprise architecture be-
ecient manner
ing explicitly mandated by a government body.
improve the integration and alignment of decision In 2006, the rst GEA alignment report was completed
making across the Queensland Government by all agencies. As recommended in the former Service
support coordinated decision making about strategic Delivery Performance Commissions Review of ICT gov-
directions, policies and standards ernance in the Queensland Government, the Queensland
Government Chief Information Oce and Queensland
use information and ICT to achieve their business Government Chief Technology Oce were established
objectives and assigned joint management of the GEA.

guide the development, use, and management of in- The QGEA 2.0 was developed in 2008 and released to
formation and ICT resources over time agencies for consultation. QGEA was adopted in pref-
erence to GEA to better reect it as a Queensland Gov-
position themselves for future needs. ernment developed framework. The QGEA 2.0 was of-

73
74
cially launched on 21 April 2009.
8.1.3 See also
Enterprise Architecture
Federal Enterprise Architecture
8.1.4 References
[1] Queensland Government Enterprise Architecture
Framework 2.0, (PDF). The State of Queensland
(Department of Public Works). 2009.
8.1.5 External links
QGEA
Queensland Government Chief Information Oce
8.2 FDIC Enterprise Architecture
Framework
FDICs Enterprise Architecture Framework from 2005.[1]
FDIC Enterprise Architecture Framework is the
Enterprise Architecture framework of the United States
Federal Deposit Insurance Corporation (FDIC). A lot of
the current article is about the Enterprise Architecture
Framework developed around 2005, and currently anno
2011 out-of-date.
8.2.1 Overview
The FDICs framework for implementing its Enterprise
Architecture is based on Federal and industry best prac-
tices, including the Chief Information Ocer (CIO)
Councils Federal Enterprise Architecture Framework
(FEAF) and the Zachman Framework for Enterprise Ar-
chitecture. FDICs framework has been tailored to em-
phasize security. The FDIC EA framework complies
CHAPTER 8. GOVERNMENT FRAMEWORKS
with the FEAF and highlights the importance of security
to all other components of the architecture.[2]
The FDIC EA framework includes ve components. The
rst component, the Business Architecture, focuses on
FDICs business needs. The next three components, the
Data Architecture, Applications Architecture, and Tech-
nical Infrastructure Architectures, focus on the techno-
logical capabilities that support the business and informa-
tion needs. The nal component, the Security Architec-
ture, focuses on specic aspects of interest to the Corpo-
ration that span the enterprise and must be integral parts
of all other architectures.[2]
8.2.2 History
Historically, Federal agencies have managed IT invest-
ments autonomously. Until the new millennium, there
has been little incentive for agencies to partner to eec-
tively reuse IT investments, share IT knowledge, and ex-
plore joint solutions. Starting in the second half of the
1990 a collective, government-wide eort, supported by
the Federal CIO Council, utilizing the Federal Enterprise
Architecture (FEA), has been undertaken in an eort to
yield signicant improvements in the management and
reuse of IT investments, while improving services to citi-
zens, and facilitating business relationships internally and
externally.[3]
The Federal Deposit Insurance Corporation (FDIC) rst
realized the value of Enterprise Architecture in 1997,
when two business executives had to reconcile data that
had come from dierent systems for a high-prole report
to the banking industry. The FDICs rst EA blueprint
was published in December 2002.[4]
In 2004 the FDIC received a 2004 Enterprise Archi-
tecture Excellence Award from the Zachman Institute
for Framework Advancement (ZIFA) for its initiative to
manage corporate data collaboratively.[5]
8.2.3 EA framework topics
FDIC EA framework
The FDIC EA framework from 2005 included ve com-
ponents.
Business Architecture : The Business Architecture
describes the activities and processes performed by
the Corporation to achieve its mission and to realize
its vision and goals. Developing the Business Ar-
chitecture is the rst step in creating an Enterprise
Architecture (EA) that links the Corporations busi-
ness needs to its Information Technology (IT) envi-
ronment. Maximizing IT support for these require-
ments will optimize Corporate performance.[2]
8.2. FDIC ENTERPRISE ARCHITECTURE FRAMEWORK
Data Architecture : The Data Architecture describes
the activities required to obtain and maintain data
that supports the information needed by the Corpo-
rations major business areas. Data and information
are dierent. Data is the foundation of information.
Data is the raw material that is processed and rened
to generate information. Information consists of a
collection of related data that has been processed
into a form that is meaningful to the recipient.[2]
Applications Architecture : The Applications Archi-
tecture describes the major types of applications
that manage data to produce the information needed
to support the activities of the Corporation. The Ap-
plications Architecture provides a framework that
enables the migration from the current applications
catalog and software development environment to
the target integrated applications, development and
engineering environments. The target architecture
promotes the use of commercial and government
o-the-shelf products, consolidating applications,
where applicable, and the use of emerging technolo-
gies where appropriate.[2]
Technical Infrastructure Architecture : The IT in-
frastructure provides access to application systems
and oce automation tools used in performance
of the business processes. The Corporation places
high priority on maintaining a consistent, available,
and reliable technical infrastructure. The Techni-
cal Architecture describes the underlying technol-
ogy for the Corporations business, data, and appli-
cation processing. It includes the technologies used
for communications, data storage, application pro-
cessing, and computing platforms.[2]
Security Architecture : The Security Architecture
establishes a framework for integrating safeguards
into all layers of the FDICs Enterprise Architec-
ture. The security architecture uses a risk manage-
ment and information assurance strategy that pro-
vides access control, condentiality, integrity, and
non-repudiation for the Corporations information Five-Year Technology Roadmap, 2008.
and systems.[2]
Future IT development
Self-Funding Model for Future IT Development, 2008.[6]
75
The banking business model has become more complex,
giving rise to nancial instruments such as collateralized
debt obligations (CDOs) and structured investment vehi-
cles (SIVs) to manage risk. These instruments have cre-
ated greater dependencies between the domestic and in-
ternational nancial markets. Financial institutions must,
therefore, strike a balance between regulatory, legisla-
tive and banker concerns while appropriately managing
risk.[6]
As cost savings are realized from a simplied IT envi-
ronment and more ecient processes, the savings will be
reinvested for IT improvements or accrue to the Corpo-
ration. This self-funding model is shown on the right.[6]
Five-year technology roadmap
The technology roadmap outlines the major initiatives for
standardizing the IT environment and increasing ITs ef-
ciency and eectiveness over the next ve years. The
initiatives were determined by various sources including
business-side IT roadmaps, executive management plan-
ning meetings, client planning sessions, and client year-
end reviews. The three major initiatives identied are en-
terprise architecture, security and privacy programs, and
scal discipline.[6]
The enterprise architecture initiative will focus on sim-
plifying the environment to ensure stable and economical
performance for mission-critical applications. Simplify-
ing the environment to decrease costs will include activ-
ities, such as decreasing the number of application sys-
tems and migrating applications o the mainframe. E-
ciencies will also be gained by expanding capabilities for
manipulating large data sets and storing traditional paper-
based les electronically. The SOA service center will
manage code (or services) for all development teams to
discover and use, which will save time and costs in appli-
cation development, testing and deployment.[6]
The organization will continue to enhance IT security and
privacy programs to address new and evolving risks by
improving controls over sensitive data. In some cases,
76
technology, such as scanning outgoing e-mail for sensi-
tive information and encrypting removable storage de-
vices, can mitigate potential risks. The other cornerstone
of mitigating risk is educating employees of emerging se-
curity and privacy issues.[6]
Lastly, in order to continue sound scal discipline and re-
sponsibility, the organization will establish IT baselines
and metrics, study steady-state costs, manage service level
agreements, and more judiciously choose new develop-
ment projects. These three areas enterprise architec-
ture, security and privacy programs, and scal discipline
are shown below with the estimated time frames.[6]
8.2.4 See also
NIST Enterprise Architecture Model
8.2.5 References
[1] OIG (2005). Implementation of E-Government Princi-
ples. May 2005
[2] Implementation of E-Government Principles AUDIT RE-
PORT, Report No. 05-018, May 2005
[3] FDIC (2003). Information Technology Strategic Plan
20042007
[4] Gregg Kreizman, Cathleen E. Blanton (2005) "The FDIC
Is Aligning IT to Business Through Enterprise Architec-
ture" Gartner, Inc.
[5] FDIC Receives Technology Award
[6] CIO Council (2008) Information Technology Strategic
Plan 20082013, January 23, 2008. Archived January 3,
2011, at the Wayback Machine.
8.2.6 Further reading
Gartner (2005) The FDIC Is Aligning IT to Business
Through Enterprise Architecture. Industrial research
paper. 8.3.2
Pallab Saha (2007). Handbook of Enterprise Systems
Architecture in Practice. Chapter IX gives a detailed
case study of the FDIC.
8.2.7 External links
FDIC Homepage.
8.3 Federal Enterprise Architec-
ture
A federal enterprise architecture (FEA) is the
enterprise architecture of a federal government. It pro- Structure of the U.S. Federal Enterprise Architecture Frame-
vides a common approach for the integration of strategic, work (FEAF) Components, presented in 2001.
CHAPTER 8. GOVERNMENT FRAMEWORKS
business and technology management as part of organi-
zation design and performance improvement. [1]
The most familiar federal enterprise architecture is the
enterprise architecture of the Federal government of the
United States, the U.S. Federal Enterprise Architec-
ture (FEA) and the corresponding U.S. Federal En-
terprise Architecture Framework (FEAF). This lemma
will focus on this particular enterprise architecture and
enterprise architecture framework.
8.3.1 Overview
Enterprise architecture (EA) is a management best prac-
tice for aligning business and technology resources to
achieve strategic outcomes, improve organizational per-
formance and guide federal agencies to better execute
their core missions. An EA describes the current and fu-
ture state of the agency, and lays out a plan for transi-
tioning from the current state to the desired future state.
A federal enterprise architecture is a work in progress to
achieve these goals.[2]
The U.S. Federal Enterprise Architecture (FEA) is an
initiative of the U.S. Oce of Management and Bud-
get, Oce of E-Government and IT, that aims to realize
the value of enterprise architecture within the U.S. Fed-
eral Government. Enterprise Architecture became a rec-
ognized strategic and management best practice in U.S.
Federal Government with the passage of the Clinger-
Cohen Act in 1996.
There are numerous benets that accrue from implement-
ing and using an enterprise architecture within the U.S.
Federal Government. Among them is to provide a com-
mon approach for IT acquisition in the United States fed-
eral government. It is also designed to ease sharing of in-
formation and resources across federal agencies, reduce
costs, and improve citizen services.
History
[3]
8.3. FEDERAL ENTERPRISE ARCHITECTURE
In September 1999, the Federal CIO Council pub-
lished the Federal Enterprise Architecture Framework
(FEAF) Version 1.1 for developing an Enterprise Archi-
tecture (EA) within any Federal Agency for a system that
transcends multiple inter-agency boundaries. It builds
on common business practices and designs that cross or-
ganizational boundaries, among others the NIST Enter-
prise Architecture Model. The FEAF provides an endur-
ing standard for developing and documenting architec-
ture descriptions of high-priority areas. It provides guid-
ance in describing architectures for multi-organizational
functional segments of the Federal Government.[3] At the
time of release, the Governments IT focus on Y2K issues
and then the events of September 2001 diverted attention
from EA implementation, though its practice in advance
and subsequent to this may have ameliorated the impact
of these events. Interim releases since that time have pro-
vided successive increases in denition for the core refer-
ence models (see below), as well as a very robust method-
ology for actually developing an architecture in a series
of templates forming the Federal Segment Architecture
Methodology (FSAM) and its next generation replace-
ment, the Collaborative Planning Methodology (CPM),
which was designed to be more exible, more widely ap-
plicable, and more inclusive of the larger set of planning
disciplines.
These federal architectural segments collectively consti-
tute the federal enterprise architecture. In 2001, the
Federal Architecture Working Group (FAWG) was spon-
soring the development of Enterprise Architecture prod-
ucts for trade and grant Federal architecture segments.
Method s prescribed way of approaching a particular
problem. As shown in the gure, the FEAF partitions
a given architecture into business, data, applications, and
technology architectures. The FEAF overall framework
created at that time (see image) includes the rst three
columns of the Zachman Framework and the Spewak's
Enterprise Architecture Planning methodology.[3]
In May 2012 OMB published a full new guide, the Com-
mon Approach to Federal Enterprise Architecture.[4]
Released as part of the federal CIOs policy guidance and
management tools for increasing shared approaches to IT
service delivery, the guide presents an overall approach
to developing and using Enterprise Architecture in the
Federal Government. The Common Approach promotes
increased levels of mission eectiveness by standardiz-
ing the development and use of architectures within and
between Federal Agencies. This includes principles for
using EA to help agencies eliminate waste and duplica-
tion, increase shared services, close performance gaps,
and promote engagement among government, industry,
and citizens.
On January 29, 2013, the White House released Ver-
sion 2 of the Federal Enterprise Architecture Frame-
work (FEAF-II), to government agencies, making it pub-
lic about a year later.[5] The document meets the criteria
set forth by Common Approach, emphasizing that strate-
77
gic goals drive business services, which in turn provide
the requirements for enabling technologies. At its core is
the Consolidated Reference Model (CRM), which equips
OMB and Federal agencies with a common language and
framework to describe and analyze investments.
Overall the Federal Enterprise Architecture (FEA) is
mandated by a series of federal laws and mandates. These
federal laws have been:
GPRA 1993 : Government Performance and Re-
form Act
PRA 1995 : Paperwork Reduction Act
CCA 1996 : Clinger-Cohen Act
GPEA 1998 : The Government Paperwork Elimi-
nation Act
FISMA 2002 : Federal Information Security Man-
agement Act
E-Gov 2002 : Electronic Government
Supplementary OMB circulars have been:
A-11 : Preparation, Submission and Execution of
the Budget
A-130 : OMB Circular A-130 Management of Fed-
eral Information Resources, rst issued in Decem-
ber 1985
8.3.3 Collaborative planning methodology
The Collaborative Planning Methodology (CPM) is a
simple, repeatable process that consists of integrated,
multi-disciplinary analysis that results in recommenda-
tions formed in collaboration with leaders, stakeholders,
planners, and implementers. It is intended as a full plan-
ning and implementation lifecycle for use at all levels of
scope dened in the Common Approach to Federal En-
terprise Architecture: International, National, Federal,
Sector, Agency, Segment, System, and Application.[4][5]
8.3.4 Version 2 reference models
The Consolidated Reference Model of the Federal En-
terprise Architecture Framework (FEAF) equips OMB
and Federal agencies with a common language and frame-
work to describe and analyze investments. It consists of
a set of interrelated reference models designed to facil-
itate cross-agency analysis and the identication of du-
plicative investments, gaps and opportunities for collabo-
ration within and across agencies. Collectively, the refer-
ence models comprise a framework for describing impor-
tant elements of federal agency operations in a common
and consistent way. Through the use of the FEAF and
78 CHAPTER 8. GOVERNMENT FRAMEWORKS

Security Reference Model (SRM) The SRM provides

a common language and methodology for discussing
security and privacy in the context of federal agen-
cies business and performance goals.

8.3.5 Version 1 reference models

Federal Enterprise Architecture.

[1]
its vocabulary, IT portfolios can be better managed and Federal Enterprise Architecture.
leveraged across the federal government, enhancing col-
laboration and ultimately transforming the Federal gov- The FEA is built using an assortment of reference models
ernment. that develop a common taxonomy and ontology for de-
The ve reference models in version 1 (see below) have scribing IT resources. FEA Version 1 reference models
been regrouped and expanded into six in the FEAF-II. (see image) included the following:

Performance Reference Model (PRM) This refer- performance reference model,

ence model supports architectural analysis and business reference model,
reporting in the strategy sub-architecture view of
the overall EA. The PRM links agency strategy, service component reference model,
internal business components, and investments,
providing a means to measure the impact of those data reference model and
investments on strategic outcomes.
technical reference model.
Business Reference Model (BRM) This reference
model, which combines the Business and Service It is designed to ease sharing of information and resources
Component Reference Models from FEAF v1, across federal agencies, reduce costs, and improve citizen
supports architectural analysis and reporting in services. It is an initiative of the US Oce of Manage-
the business services sub-architecture view of the ment and Budget that aims to comply with the Clinger-
overall EA. The BRM describes an organization Cohen Act.
through a taxonomy of common mission and sup-
port service areas instead of through a stove-piped
organizational view, thereby promoting intra- and Performance Reference Model (PRM)
inter-agency collaboration.

Data Reference Model (DRM) The DRM facilitates

discovery of existing data holdings residing in si-
los and enables understanding the meaning of the
data, how to access it, and how to leverage it to sup-
port performance results.

Application Reference Model (ARM) The ARM cat-

egorizes the system- and application-related stan-
dards and technologies that support the delivery of
service capabilities, allowing agencies to share and
reuse common solutions and benet from economies
of scale.
Performance reference model, 2005.[1]
Infrastructure Reference Model (IRM) The IRM
categorizes the network/cloud related standards and The PRM is a standardized framework to measure the
technologies to support and enable the delivery of performance of major IT investments and their contribu-
voice, data, video, and mobile service components tion to program performance.[1] The PRM has three main
and capabilities. purposes:
8.3. FEDERAL ENTERPRISE ARCHITECTURE 79

1. Help produce enhanced performance information to Services for Citizens

improve strategic and daily decision-making;
Mode of Delivery
2. Improve the alignment and better articulate the
Support Delivery of Services
contribution of inputs to outputs and outcomes,
thereby creating a clear line of sight to desired re- Management of Government Resources
sults;

3. Identify performance improvement opportunities The Business Reference Model provides a framework
that span traditional organizational structures and that facilitates a functional (as opposed to organizational)
boundaries view of the federal governments LoBs, including its in-
ternal operations and its services for the citizens, inde-
pendent of the agencies, bureaus and oces that perform
The PRM uses a number of existing approaches to per-
them. By describing the federal government around com-
formance measurement, including the Balanced Score-
mon business areas instead of by a stovepiped, agency-
card, Baldrige Criteria,[6] value measuring methodology,
by-agency view, the BRM promotes agency collaboration
program logic models, the value chain, and the Theory of
and serves as the underlying foundation for the FEA and
Constraints. In addition, the PRM was informed by what
E-Gov strategies.[1]
agencies are currently measuring through PART assess-
ments, GPRA, enterprise architecture, and Capital Plan- While the BRM does provide an improved way of think-
ning and Investment Control. The PRM is currently com- ing about government operations, it is only a model; its
posed of four measurement areas: true utility can only be realized when it is eectively used.
The functional approach promoted by the BRM will do
Mission and Business Results little to help accomplish the goals of E-Government if
it is not incorporated into EA business architectures and
Customer Results the management processes of all Federal agencies and
OMB.[1]
Processes and Activities

Technology Service Component Reference Model (SRM)

Business Reference Model (BRM)

Main article: Business Reference Model

The FEA business reference model" is a function-driven

Service Component Reference Model.[7]

Business Reference Model overview.[1]
framework for describing the business operations of the
Federal Government independent of the agencies that
perform them. This business reference model provides an
organized, hierarchical construct for describing the day-
to-day business operations of the Federal government us-
ing a functionally driven approach. The BRM is the rst
layer of the Federal Enterprise Architecture and it is the
main viewpoint for the analysis of data, service compo-
nents and technology.[1]
The BRM is broken down into four areas:
The Service Component Reference Model (SRM) is a
business and performance-driven, functional framework
that classies Service Components with respect to how
they support business and/or performance objectives.[1]
The SRM is intended for use to support the discovery of
government-wide business and application Service Com-
ponents in IT investments and assets. The SRM is struc-
tured across horizontal and vertical service domains that,
independent of the business functions, can provide a
leverage-able foundation to support the reuse of applica-
tions, application capabilities, components, and business
services.
80 CHAPTER 8. GOVERNMENT FRAMEWORKS

The SRM establishes the following domains: Provides an introduction and high-level overview of
the contents that will be detailed in Volumes 24 of
Customer Services the model;

Process Automation Services Encourages community of interest development of

the remaining volumes; and
Business Management Services
Provides the basic concepts, strategy, and structure
Digital Asset Services to be used in future development.
Business Analytical Services
The DRM is the starting point from which data archi-
Back Oce Services tects should develop modeling standards and concepts.
The combined volumes of the DRM support data clas-
Support Services
sication and enable horizontal and vertical information
sharing.
Each Service Domain is decomposed into Service Types.
For example, the three Service Types associated with the
Customer Services Domain are: Customer Preferences; Technical Reference Model (TRM)
Customer Relationship Management; and Customer Ini-
tiated Assistance. And each Service Type is decomposed
further into components. For example, the four compo-
nents within the Customer Preferences Service Type in-
clude: Personalization; Subscriptions; Alerts and Noti-
cations; and Prole Management.[7]

Data Reference Model (DRM)

Main article: Data Reference Model

The Data Reference Model (DRM) describes, at an

Technical Reference Model.[1]

The TRM is a component-driven, technical framework

categorizing the standards and technologies to support
The DRM Collaboration Process.[1] and enable the delivery of Service Components and capa-
bilities. It also unies existing agency TRMs and E-Gov
aggregate level, the data and information that support guidance by providing a foundation to advance the reuse
government program and business line operations. This and standardization of technology and Service Compo-
[1]
model enables agencies to describe the types of interac- nents from a government-wide perspective.
tion and exchanges that occur between the Federal Gov- The TRM consists of:
ernment and citizens.[1] The DRM categorizes govern-
ment information into greater levels of detail. It also Service Areas : represent a technical tier supporting
establishes a classication for Federal data and identi- the secure construction, exchange, and delivery of
es duplicative data resources. A common data model Service Components. Each Service Area aggregates
will streamline information exchange processes within the standards and technologies into lower-level func-
the Federal government and between government and ex- tional areas. Each Service Area consists of multiple
ternal stakeholders. Service Categories and Service Standards. This hi-
Volume One of the DRM provides a high-level overview erarchy provides the framework to group standards
of the structure, usage, and data-identication constructs. and technologies that directly support the Service
This document: Area. (Purple headings)
8.3. FEDERAL ENTERPRISE ARCHITECTURE
Service Categories : classify lower levels of technolo-
gies and standards with respect to the business or
technology function they serve. In turn, each Ser-
vice Category comprises one or more Service Stan-
dards. (Bold-face groupings)
Service Standards : dene the standards and tech-
nologies that support a Service Category. To support
agency mapping into the TRM, many of the Service
Standards provide illustrative specications or tech-
nologies as examples.(Plain text)
The gure on the right provides a high-level depiction of
the TRM.
Aligning agency capital investments to the TRM lever-
ages a common, standardized vocabulary, allowing in-
teragency discovery, collaboration, and interoperability.
Agencies and the federal government will benet from
economies of scale by identifying and reusing the best
solutions and technologies to support their business func-
tions, mission, and target architecture. Organized in a
hierarchy, the TRM categorizes the standards and tech-
nologies that collectively support the secure delivery, ex-
change, and construction of business and application Ser-
vice Components that may be used and leveraged in a
component-based or service-oriented architecture.[1]
8.3.6 Architecture levels
In the FEA enterprise, segment, and solution architec-
ture provide dierent business perspectives by varying
the level of detail and addressing related but distinct con-
cerns. Just as enterprises are themselves hierarchically
organized, so are the dierent views provided by each
type of architecture. The Federal Enterprise Architec-
ture Practice Guidance (2006) has dened three types of
architecture:[2]
Federal Enterprise Architecture levels and attributes[2]
Enterprise architecture,
Segment architecture, and
Solution architecture.
By denition, Enterprise Architecture (EA) is funda- Results of the Federal Enterprise Architecture program
mentally concerned with identifying common or shared are considered unsatisfactory:
81
assets whether they are strategies, business processes,
investments, data, systems, or technologies. EA is driven
by strategy; it helps an agency identify whether its re-
sources are properly aligned to the agency mission and
strategic goals and objectives. From an investment per-
spective, EA is used to drive decisions about the IT in-
vestment portfolio as a whole. Consequently, the primary
stakeholders of the EA are the senior managers and exec-
utives tasked with ensuring the agency fullls its mission
as eectively and eciently as possible.[2]
By contrast, "segment architecture" denes a simple
roadmap for a core mission area, business service, or en-
terprise service. Segment architecture is driven by busi-
ness management and delivers products that improve the
delivery of services to citizens and agency sta. From
an investment perspective, segment architecture drives
decisions for a business case or group of business cases
supporting a core mission area or common or shared ser-
vice. The primary stakeholders for segment architecture
are business owners and managers. Segment architecture
is related to EA through three principles:
structure: segment architecture inherits the frame-
work used by the EA, although it may be extended
and specialized to meet the specic needs of a core
mission area or common or shared service.
reuse : segment architecture reuses important assets
dened at the enterprise level including: data; com-
mon business processes and investments; and appli-
cations and technologies.
alignment : segment architecture aligns with ele-
ments dened at the enterprise level, such as busi-
ness strategies, mandates, standards, and perfor-
mance measures.[2]
"Solution architecture" denes agency IT assets such as
applications or components used to automate and im-
prove individual agency business functions. The scope
of a solution architecture is typically limited to a single
project and is used to implement all or part of a system or
business solution. The primary stakeholders for solution
architecture are system users and developers. Solution
architecture is commonly related to segment architecture
and enterprise architecture through denitions and con-
straints. For example, segment architecture provides def-
initions of data or service interfaces used within a core
mission area or service, which are accessed by individ-
ual solutions. Equally, a solution may be constrained to
specic technologies and standards that are dened at the
enterprise level.[2]
8.3.7 Program results
82 CHAPTER 8. GOVERNMENT FRAMEWORKS

Stanley Gaver, a participant of the FEA program, 8.3.10 External links

reports that Enterprise Architecture within the fed-
eral government hasnt been working, and far more e-gov FEA Program Oce webpage
often than not hasnt delivered useful results. More-
over, signicant parts of the federal EA program Federal Enterprise Architecture Institute website
[8]
have been complete and utter failures. Federal Chief Information Ocers Council website
The ocial report to the U.S. Congress in 2011
DoD CIO Enterprise Architecture & Standards
reported that most departments and agencies re-
ported they expect to realize the benets from FEA with ADOit
their respective enterprise architecture programs
[...] sometime in the future. What this suggests is Baldrige Performance Excellence Program
that the real value in the federal government from
developing and using enterprise architectures re-
mains largely unrealized.[9] 8.4 NIST Enterprise Architecture
Model
8.3.8 See also
Business reference model
Department of Defense Architecture Framework
FDIC Enterprise Architecture Framework
Physical data model
Reference model
Treasury Enterprise Architecture Framework

8.3.9 References
[1] FEA Consolidated Reference Model Document.FEA
Consolidated Reference Model Document Version 2.3
October 2007. Accessed 28 April 2009.

[2] Federal Enterprise Architecture Program Management

Oce (2007). FEA Practice Guidance.

[3] Chief Information Ocer Council (2001) A Practical

Guide to Federal Enterprise Architecture. Feb. 2001.

[4] Common Approach to Federal Enterprise Architecture NIST Enterprise Architecture Model.
(PDF). Oce of Management and Budget. May 2012.
Archived from the original (PDF) on 2013-03-08.
NIST Enterprise Architecture Model (NIST EA
[5] FEA Consolidated Reference Model Document. Federal Model) is a late-1980s reference model for enterprise ar-
chitecture. It denes an enterprise architecture[1] by the
Enterprise Architecture Framework version 2 January 29,
2013. Accessed 2 April 2015. interrelationship between an enterprises business, infor-
[6] 20152016 Baldrige Excellence Framework. Baldrige
mation, and technology environments.[2]
Performance Excellence Program. National Institute of Developed late-1980s by the National Institute of Stan-
Standards and Technology. January 15, 2015. Archived dards and Technology (NIST) and others, the federal gov-
from the original on August 4, 2016. ernment of the United States promoted this reference
[7] FEA (2005) FEA Records Management Prole, Version model in the 1990s as the foundation for enterprise ar-
1.0. December 15, 2005. chitectures of individual U.S. government agencies and
in the overall federal enterprise architecture.[2]
[8] Why Doesnt the Federal Enterprise Architecture
Work?", Stanley B. Gaver, visited 19 May 2016.

[9] GAO (2011). Opportunities to Reduce Potential Duplica- 8.4.1 Overview

tion in Government Programs, Save Tax Dollars, and En-
hance Revenue. Washington, DC: Government Account- The NIST Enterprise Architecture Model is a ve-layered
ability Oce. model for enterprise architecture, designed for organiz-
8.4. NIST ENTERPRISE ARCHITECTURE MODEL 83

ing, planning, and building an integrated set of infor- External Models or Views
mation and information technology architectures. The ES1 ES2 ES3 ES4 External Level
ve layers are dened separately but are interrelated
and interwoven.[2] The model dened the interrelation as
follows:[3]
Conceptual Model Conceptual Level

Business Architecture drives the information archi-

tecture

Information architecture prescribes the information IS1 IS2 Physical Level

systems architecture Physical Models

Information systems architecture identies the data

architecture The notion of a three-schema model was rst introduced in 1975
by the ANSI/X3/SPARC three level architecture, which deter-
[5]
Data Architecture suggests specic data delivery mined three levels to model data.
systems, and

Data Delivery Systems (Software, Hardware, Com- External schema for user views
munications) support the data architecture.
Conceptual schema integrates external schemata
The hierarchy in the model is based on the notion that Internal schema that denes physical storage struc-
an organization operates a number of business functions, tures
each function requires information from a number of
source, and each of these sources may operate one or
more operation systems, which in turn contain data or- At the center, the conceptual schema denes the ontology
ganized and stored in any number of data systems.[4] of the concepts as the users think of them and talk about
them. The physical schema according to Sowa (2004)
describes the internal formats of the data stored in the
8.4.2 History database, and the external schema denes the view of the
data presented to the application programs".[7]
The NIST Enterprise Architecture Model is initiated in Since the 1970s the NIST had held a series of four work-
1988 in the fth workshop on Information Management shops on Database and Information Management Di-
Directions sponsored by the NIST in cooperation with the rections. Each of the workshops addresses a specic
Association for Computing Machinery (ACM), the IEEE theme:[8]
Computer Society, and the Federal Data Management
Users Group (FEDMUG). The results of this research
project were published as the NIST Special Publication What information about database technology does
500-167, Information Management Directions: The Inte- the manager need to make prudent decisions about
gration Challenge.[3] using new technology, in 1975.

What information can help a manager assess the

The emerging eld of information management impact on a database system?" in 1977.

With the proliferation of information technology start- "Information management tools from the standpoint
ing in the 1970s, the job of information management had of: uses; policies and controls; logical and physical
taken a new light, and also began to include the eld of database design in 1980; and
data maintenance. No longer was information manage-
ment a simple job that could be performed by almost any- The nature of information resource management
one. An understanding of the technology involved, and practice and problems in 1985.
the theory behind it became necessary. As information
storage shifted to electronic means, this became more and The fth workshop in 1989 was held by the National
more dicult.[3] Computer Systems Laboratory (NCSL) of the NIST. By
One of the rst overall approaches to building then this was one of the four institutes, that performed
information systems and systems information man- the technical work of the NIST. The specic goal of
agement from the 1970s was the three-schema approach. the NCSL was to conduct research and provide scien-
It proposes to use three dierent views in systems devel- tic and technical services to aid Federal agencies in the
opment, in which conceptual modelling is considered to selection, acquisition, application, and use of computer
be the key to achieving data integration:[6] technology.[9]
84 CHAPTER 8. GOVERNMENT FRAMEWORKS

NIST workshop on Information Management Direc-

tions

The fth Information Management Directions work-

shop in 1989 focused on integration and productivity in
information management. Five working groups consid-
ered specic aspects of the integration of knowledge,
data management, systems planning, development and
maintenance, computing environments, architectures and
standards. Participants came from academia, industry,
government and consulting rms. Among the 72 par-
ticipants were Tom DeMarco, Ahmed K. Elmagarmid,
Elizabeth N. Fong, Andrew U. Frank,[10] Robert E.
Fulton,[11] Alan H. Goldne,[12] Dale L. Goodhue,[13]
Richard J. Mayer, Shamkant Navathe, T. William Olle,
W. Bradford Rigdon, Judith A. Quillard, Stanley Y. W.
Su,[14] and John Zachman.
Tom DeMarco delivered the keynote speech, claiming
that standards do more harm than good when they work
against the prevailing culture, and that the essence of
standardization is discovery, not innovation.[15] The ve
working groups met to discuss dierent aspects of inte-
gration:

the integration of knowledge and data management

Model of Enterprise Architecture, 1989
the integration of technical and business data man-
agement

the integration of systems planning, development, To illustrate the levels of architecture, what has become
and maintenance tools and methods known as the NIST Enterprise Architecture Model, was
presented (see image). In this concept the three layers of
the integration of distributed, heterogeneous com- the three-schema approach are divided into ve layers.
puting environments, and

architectures and standards.

Application in the 1990s

In the third working group on systems planning was
chaired by John Zachman, and adopted the Zachman
Framework as a basis for discussion. In a way the NIST Enterprise Architecture Model was
ahead of his time. According to Zachman (1993) in the
The fth working group on architectures and standards
1980s the architecture was acknowledged as a topic of
was chaired W. Bradford Rigdon of the McDonnell Dou-
interest, but there was still little consolidated theory con-
glas Information Systems Company (MDISC), a division
cerning this concept.[19] Software architecture, for exam-
of McDonnell Douglas. Rigdon et al. (1989) [16] ex-
ple. become an important topic not until the second half
plained that discussions about architecture in that time
of the nineties.[20]
mostly focus on technology concerns. Their aim was
to takes a broader view, and describes the need for To support the NIST Enterprise Architecture Model in
an enterprise architecture that includes an emphasis on the 1990s, it was widely promoted within the U.S. fed-
business and information requirements. These higher eral government as Enterprise Architecture management
level issues impact data and technology architectures and tool.[2] The NIST Enterprise Architecture Model is ap-
decisions.[17] In order to do so, the working group ad- plied as foundation in multiple Enterprise Architecture
dressed three issues:[18] frameworks of U.S. Federal government agencies and
in the overall Federal Enterprise Architecture Frame-
work.[2] In coordinating this eort the NIST model was
The levels of architecture in an enterprise
further explained and extended in the 1997 Memoranda
Problems addressed by architecture 97-16 (Information Technology Architectures)" issued
by the US Oce of Management and Budget.,[21] see fur-
Benets and risks of having architecture ther Information Technology Architecture.
8.4. NIST ENTERPRISE ARCHITECTURE MODEL
8.4.3 NIST Enterprise Architecture Model Levels of architecture
topics
Foundations
According to Rigdon et al. (1989) an architecture is a
clear representation of a conceptual framework of com-
ponents and their relationship at a point in time.[22] It
may for example represent a view of a current situa-
tion with islands of automation, redundant processes and
data inconsistencies[23] or a future integrated automa-
tion information structure towards which the enterprise
will move in a prescribed number on years.[24] The role
of standards in architecture is to enable or constrain the
architecture and serve as its foundation.[23]
In order to develop an enterprise architecture Rigdon
acknowledge:[17]
There are multiple ways to develop an architecture
There are multiple ways to implement standards
Development and implementation should be cus-
tomized to the environment
Some sample elements of how the Enterprise Architec-
Yet, every architecture itself can be divided into dif-
ture can be described in more detail is shown in the illus-
ferent levels.
tration.
The dierent levels of an enterprise architecture can be
visualized as a pyramid: On top the business unit of an
enterprise, and at the bottom the delivery system within
the enterprise. The enterprise can consist of one or
more business units, working in specic business area.
The ve levels of architecture are dened as: Business
Unit, Information, Information System, Data and Deliv-
ery System.[23]
The separate levels of an enterprise architecture are inter-
related in a special way. On every level the architectures
assumes or dictates the architectures at the higher level.
The illustration on the right gives an example of which
elements can constitute an Enterprise Architecture.
Sample elements of an Enterprise Architecture (1989).
85
Each layer of architecture in the model has a specic
intention:[25]
Business Architecture level: This level can picture
the total or a subunit of any corporation, which are
in contact with external organizations.
Information architecture level: This level species
types of content, presentation forms, and format of
the information required.
Information systems architecture level: Specica-
tions for automated and procedure-oriented infor-
mation systems.
Data Architecture level: Framework for mainte-
nance, access and use of data, with data dictionary
and other naming conventions.
Data Delivery Systems level: Technical implemen-
tation level of software, hardware, and communica-
tions that support the data architecture.
Information Technology Architecture
The Memoranda 97-16 (Information Technology Ar-
chitectures)" gave the following denition of enterprise
architecture:[21]
The Enterprise Architecture is the explicit de-
scription of the current and desired relationships
among business and management process and
information technology. It describes the target
situation which the agency wishes to create and
maintain by managing its IT portfolio.
The documentation of the Enterprise Architec-
ture should include a discussion of principles
and goals.[26] For example, the agencys over-
all management environment, including the bal-
ance between centralization and decentraliza-
tion and the pace of change within the agency,
should be clearly understood when developing
the Enterprise Architecture. Within that envi-
ronment, principles and goals set direction on
such issues as the promotion of interoperability,
open systems, public access, end-user satisfac-
tion, and security.
In this guidance the ve component model of the NIST
was adopted and further explained. Agencies were per-
mitted to identify dierent components as appropriate
and to specify the organizational level at which specic
86 CHAPTER 8. GOVERNMENT FRAMEWORKS

aspects of the components will be implemented. Al- be shared corporately, for minimizing redundancy,
though the substance of these components, sometimes and for supporting new applications[30]
called architectures or sub-architectures, must be ad-
dressed in every agencys complete Enterprise Architec- Technology Infrastructure : The Technology In-
ture, agencies have great exibility in describing, combin- frastructure component describes and identies the
ing, and renaming the components, which consist of:[21] physical layer including, the functional characteris-
tics, capabilities, and interconnections of the hard-
Business Processes: This component of the Enter- ware, software, and communications, including net-
prise Architecture describes the core business pro- works, protocols, and nodes. It is the wiring dia-
cesses which support the organizations missions. gram of the physical IT infrastructure.[31]
The Business Processes component is a high-level
analysis of the work the agency performs to support
the organizationss mission, vision, and goals, and With the exception of the Business Processes component,
is the foundation of the ITA. Analysis of the busi- the interrelationships among and priorities of these com-
ness processes determine the information needed ponents are not prescribed by this guidance; there is no
and processed by the agency. This aspect of the ITA hierarchy of relationships implied. Furthermore, agen-
must be developed by senior program managers in cies should document not only their current environment
conjunction with IT managers. Without a thorough for each of these components, but also the target environ-
understanding of its business processes and their re- ment that is desired.[21]
lation to the agency missions, the agency will not be
able to use its ITA eectively.
Business processes can be described by decompos- 8.4.4 Applications
ing the processes into derivative business activi-
ties. There are a number of methodologies and
related tools available to help agencies decompose
processes. Irrespective of the tool used, the model
should remain at a high enough level to allow a broad
agency focus, yet suciently detailed to be useful in
decision-making as the agency identies its informa-
tion needs. Agencies should avoid excessive empha-
sis on modeling business processes, which can result
in a waste of agency resources.[27]
Information Flows and Relationships: This compo-
nent analyzes the information utilized by the organi-
zation in its business processes, identifying the infor-
mation used and the movement of the information FDIC EA Framework.[32]
within the agency. The relationships among the var-
ious ows of information are described in this com- The NIST Framework was picked up by several U.S. fed-
ponent. These information ows indicate where the eral agencies and used as the basis for their information
information is needed and how the information is strategy.[33] The reference model is applicated the follow-
shared to support mission functions.[28] ing frameworks:
Applications : The Applications component identi-
es, denes, and organizes the activities that cap- Department of Energy (DOE) Information Archi-
ture, manipulate, and manage the business informa- tecture [34]
tion to support mission operations. It also describes
the logical dependencies and relationships among FDIC Enterprise Architecture Framework is the
business activities.[29] Enterprise Architecture framework of the Federal
Data Descriptions: This component of the Enter- Deposit Insurance Corporation (FDIC).
prise Architecture identies how data is maintained,
accessed, and used. At a high level, agencies dene Federal Enterprise Architecture Framework
the data and describe the relationships among data (FEAF) : The 1999 documentation of the Federal
elements used in the agencys information systems. Enterprise Architecture Framework Version 1.1
The Data Descriptions and Relationships compo- explains how the NIST Framework is used as a
nent can include data models that describe the data foundation of the FEA Framework.[2]
underlying the business and information needs of the
agency. Clearly representing the data and data rela- NWS Enterprise Architecture : Enterprise Archi-
tionships is important for identifying data that can tecture of the National Weather Service[35]
8.4. NIST ENTERPRISE ARCHITECTURE MODEL
8.4.5 See also
Application Portability Prole (APP)
History of business architecture
Open-system environment reference model
Technical Architecture Framework for Information
Management (TAFIM)
Treasury Information System Architecture Frame-
work
8.4.6 References
This article incorporates public domain material from the
National Institute of Standards and Technology website
http://www.nist.gov.
[1] Chief Information Ocer Council (2001) A Practical
Guide to Federal Enterprise Architecture Version 1.0 Pref-
ace. February 2001.
[2] The Chief Information Ocers Council (1999). Federal
Enterprise Architecture Framework Version 1.1.
September 1999.
[3] Elizabeth N. Fong and Alan H. Goldne (1989)
Information Management Directions: The Integration
Challenge. National Institute of Standards and Tech-
nology (NIST) Special Publication 500-167, September
1989.
[4] John O'Looney (2002). Wiring Governments: Challenges
and Possibilities for Public Managers. Greenwood Pub-
lishing Group. p.67.
[5] Matthew West and Julian Fowler (1999). High Quality
Data Models. The European Process Industries STEP
Technical Liaison Executive (EPISTLE).
[6] STRAP SECTION 2 APPROACH. Retrieved 30
September 2008.
[7] John F. Sowa (2004). The Challenge of Knowledge
Soup, in: Research Trends in Science, Technology and
Mathematics Education. Edited by J. Ramadas & S. Chu-
nawala, Homi Bhabha Centre, Mumbai, 2006.
[8] Fong and Goldne (1989, p. 5)
[9] Fong and Goldne (1989, p. i)
[10] Frank, Andrew U. Research Group Geoinformation, Vi-
enna. Accessed JUly 15, 2013.
[11] David Terraso (2004) "Robert Fulton, 72, dies: Engi-
neering professor and county commissioner". at whis-
tle.gatech.edu
[12] Alan H. Goldne at DBLP.
[13] Dale Goodhue at DBLP.
[14] Stanley Y. W. Su at DBLP.
87
[15] Fong and Goldne (1989, p. ix)
[16] W. Bradford Rigdon (1989) Architectures and Stan-
dards. In: Information Management Directions: The In-
tegration Challenge. E.N. Fong and A.H. Goldne (eds.).
NIST Sept 1989. p. 135-150
[17] Rigdon (1989), p. 136
[18] Fong and Goldne (1989, p. 136)
[19] J.A Zachman (1993) Concepts for Framework for EA -
Enterprise Architecture Resources. Zachman International,
Inc. paper. p. 1
[20] Leonor Barroca, Jon Hall and Patrick Hall (200) "An In-
troduction and History of Software Architectures, Com-
ponents, and Reuse" in: Software Architectures, 2000 p.
1
[21] Franklin D. Raines, US OBM (1997) Memoranda 97-16
(Information Technology Architectures) M-97-16, issued
June 18, 1997.
[22] Rigdon et al. (1989, p. 136)
[23] Rigdon (1989), p. 137
[24] Rigdon et al. (1989, p. 137-38)
[25] Rigdon et al. (1989, p. 139-140)
[26] Examples of published architectural frameworks in-
clude the Treasury Information System Architecture
Framework (TISAF), the US Department of Defense
Technical Architecture Framework for Information Man-
agement (TAFIM), and the Department of Energys Infor-
mation Architecture Volume 1.
[27] The US Department of Defense includes aspects of the
Business Processes element in its Operational Architec-
ture; the US Department of Treasury incorporates it into
its business view.
[28] The US Department of Agriculture has incorporated this
component into its Business Architecture, while the US
Department of Defense and Treasury have built it into
their Operational Architectures.
[29] The US Department of Energy incorporates Business Ap-
plications into its Applications Subarchitecture, while the
US Department of Treasury includes them in its Func-
tional Architecture.
[30] The US Department of Agriculture has included in this
element in its Business/Data Architecture, while the US
Department of Treasury incorporates it in its Information
Architecture.
[31] The US Department of Agriculture had incorporated this
architecture into its Technical Standard and Telecommu-
nications Architectures. US DoD uses its System Archi-
tecture, and US Treasury its Infrastrucsture to describe
the physical layer.
[32] OIG (2005). Implementation of E-Government Princi-
ples. May 2005
88 CHAPTER 8. GOVERNMENT FRAMEWORKS

[33] Exclusive Interview with John Zachman by Roger Ses-

sions. In: Perspectives of the International Association of
Software Architects. April 2006.

[34] Federal Aviation Administration (1998) Federal Informa-

tion Architecture Initiatives. February 1998

[35] Bobby Jones (2003) NWS Enterprise Architecture. In:

20th International Conference on Interactive Information
and Processing Systems. 2004.

8.4.7 External links

8.5 Treasury Enterprise Architec- TEAF view model.[1]

ture Framework
Guidance to Treasury bureaus concerning the devel-
opment and evolution of information systems archi-
tecture,

A unifying concept, common principles, technolo-

gies, and standards for information systems, and

A template for the development of the Enterprise

Architecture.

The TEAFs functional, information and organizational

architecture views collectively model the organization s
processes, procedures, and business operations. By
grounding the architecture in the business of the orga-
TEAF Work Products for EA Direction, Description, and nization, the TEAF denes the core business procedures
Accomplishment.[1] and enterprise processes. Through its explicit models, a
TEAF-based architecture enables the identication and
Treasury Enterprise Architecture Framework reasoning of enterprise- [1]
and system-level concerns and
(TEAF) was an Enterprise architecture framework for investment decisions.
treasury, based on the Zachman Framework. It was
developed by the US Department of the Treasury and
8.5.2 History
published in July 2000.[2] May 2012 this framework
has been subsumed by evolving Federal Enterprise
The Treasury Enterprise Architecture Framework
Architecture Policy as documented in The Common
(TEAF) is derived from earlier treasury models, such as
Approach to Federal Enterprise Architecture.[3]
the US Treasury model (TISAF) released 1997, and the
The material presented here is obsolete and only useful Federal Enterprise Architecture Framework (FEAF),
for historical reference and is not the current policy in released in 1999.[4] The rst version of the TEAF was
use by the Department of the Treasury. released July 2000.

8.5.1 Overview

The Treasury Enterprise Architecture Framework

(TEAF) an architectural framework that supports
Treasurys business processes in terms of products.
This framework guides the development and redesign
of the business processes for various bureaus in order
to meet the requirements of recent legislation in a
rapidly changing technology environment. The TEAF
prescribes architectural views and delineates a set of
notional products to portray these views.[1]
The TEAF describes provides:[1]
Blueprint Roadmap to Treasury IT Modernization.[5]
In the new millennium the Treasury Enterprise Architec-
ture Framework (TEAF) has developed into the Treasury
Enterprise Architecture (TEA), which aims to establish a
roadmap for the modernization and optimization of the
U.S. Treasury Departments business processes and IT
environment. The Treasury Enterprise Architecture will
provide a framework to guide IT investment planning,
8.5. TREASURY ENTERPRISE ARCHITECTURE FRAMEWORK
streamline systems, and ensure that IT programs align
with business requirements and strategic goals.[6]
8.5.3 TEAF Topics
Enterprise Architecture
EA Development Environment.[2]
Eective management and strategic decision mak-
ing, especially for information technology (IT) invest-
ments, require an integrated view of the enterprise
understanding the interrelationships among the business
organizations, their operational processes, and the infor-
mation systems that support them. An Enterprise Archi-
tecture formalizes the identication, documentation, and
management of these interrelationships, and supports the
management and decision processes. The Enterprise Ar-
chitecture provides substantial support for evolution of an
enterprise as it anticipates and responds to the changing
needs of its customers and constituents. The Enterprise
Architecture is a vital part of the enterprises decision-
making process, and will evolve along with the enter-
prises mission.[2]
The TEAF has been designed to help both the bureaus
and the Department develop and maintain their Enter-
prise Architectures. The TEAF aims to establish a com-
mon Enterprise Architecture structure, consistent prac-
tices, and common terminology; and to institutionalize
Enterprise Architecture governance across the Depart-
ment. This architectural consistency will facilitate inte-
gration, information sharing, and exploitation of common
requirements across Treasury.[2]
Enterprise Architecture Framework
The purpose of the Enterprise Architecture Framework is
to provide a structure for producing an Enterprise Archi-
tecture (EA) and managing Enterprise Architecture as-
sets. To reduce the complexity and scope of developing
and using an Enterprise Architecture, it must be subdi-
vided so that portions may be used independently or built
89
Overview of a Framework for EA Direction, Description, and
Accomplishment Overview.[2]
incrementally in separate projects. The TEAF subdivides
an Enterprise Architecture by:[2]
Views
Perspectives
Work products
The TEAF identies, as shown in the gure, resources
and work products that provide direction for EA devel-
opment, work products constituting the EA description,
and work products documenting how to accomplishment
an EA implementation. The resources and work prod-
ucts for EA direction and accomplishment are not part of
the EA description itself, but are developed and applied
during the overall enterprise life cycle. The TEAF Ma-
tri, organizes the subdivisions of the EA description and
demonstrates the relationships among them. The follow-
ing sections describe the subdivisions of the EA and their
relationships to the TEAF Matrix.[2]
TEAF Matrix of Views and Perspectives
Views
Functional Information Organizational Infrastructure
view view view view
Planner
Work
Perspectives
Owner
Designer
products
Builder
TEAF Matrix of Views and Perspectives.[2]
The TEAF Matrix is a simplied portrayal of an EA
structure to aid in understanding important EA aspects
from various vantage points (views and perspectives).
90 CHAPTER 8. GOVERNMENT FRAMEWORKS

The TEAF Matrix aims to provide a simple, uniform a specic methodology or a specic bureaus approach.
structure to an entire framework. As depicted in the g- Each organization needs to follow a documented Enter-
ure, the TEAF Matrix consists of four architectural views prise Life Cycle methodology appropriate to its size, the
(Functional, Information, Organizational, and Infrastruc- complexity of its enterprise, and the scope of its needs.[2]
ture), which are shown as columns, and four perspectives
(Planner, Owner, Designer, and Builder), which appear
as rows. The TEAF Matrix is a four-by-four matrix with Products
a total of 16 cells. The views and perspectives are de-
scribed in the following sections.[2]
When an EA description work product is shown within
one cell of the TEAF Matrix, it means that the main van-
tage points for developing that work product correspond
to that column (view) and row (perspective). However,
information from other views (and sometimes other per-
spectives) is needed to produce a work product. Not all
cells must be lled-in by producing an associated work
product. Each bureau must dene in its EA Roadmap its
plans for producing and using an EA to match its needs.[2]

Enterprise Life Cycle activities TEAF Products.[1]

The TEAF provides a unifying concept, common termi-

TEAF Enterprise Life Cycle activities [2]
An Enterprise Life Cycle integrates the management,
business, and engineering life cycle processes that span
the enterprise to align its business and IT activities. En-
terprise Life Cycle refers generally to an organizations
approach for managing activities and making decisions
during ongoing refreshment of business and technical
practices to support its enterprise mission. These activ-
ities include investment management, project denition,
conguration management, accountability, and guidance
for systems development according to a System Develop-
ment Life Cycle (SDLC). The Enterprise Life Cycle ap-
plies to enterprise-wide planning activities and decision
making. By contrast, a System Development Life Cycle
generally refers to practices for building individual sys- ity Description. The Node Connectivity Description for
tems. Determining what systems to build is an enterprise-
level decision.[2]
The gure on the left depicts notional activities of an En- depicts the systems corresponding to the system nodes.
terprise Life Cycle methodology. Within the context of The System Interface Description can be produced at four
this document, Enterprise Life Cycle does not refer to levels, as described below. Level 1 is an essential work
nology and principles, common standards and formats, a
normalized context for strategic planning and budget for-
mulation, and a universal approach for resolving policy
and management issues. It describes the enterprise infor-
mation systems architecture and its components, includ-
ing the architecture s purpose, benets, characteristics,
and structure. The TEAF introduces various architec-
tural views and delineates several modeling techniques.
Each view is supported with graphics, data repositories,
matrices, or reports (i.e., architectural products).[1]
The gure shows a matrix with four views and four per-
spectives. Essential products are shown across the top
two rows of the matrix. It is notable that the TEAF in-
cludes an Information Assurance Trust model, the Tech-
nical Reference Model, and standards proles as essen-
tial work products. These are not often addressed as crit-
ical framework components. One of these frameworks
should provide a means to logically structure and organize
the selected EA products. Now, in order to eectively
create and maintain the EA products, a toolset should be
selected.[1]
System Interface Description
The System Interface Description (SID) links together
the Organizational and Infrastructure Views by depict-
ing the assignments of systems and their interfaces to the
nodes and needlines described in the Node Connectiv-
a given architecture shows nodes (not always dened in
physical terms), while the System Interface Description
8.5. TREASURY ENTERPRISE ARCHITECTURE FRAMEWORK 91

[4] Jaap Schekkerman (2003). How to Survive in the Jungle

of Enterprise Architecture Frameworks. p.113

[5] Standards and Conguration Management Team (SCMT)

of the Treasury Enterprise Architecture Sub-Council
(TEAC) (2007). Treasury Technical Standards Prole.
May 2007

[6] E-Government U.S. Treasury Department, accessed 09

Dec 2008.

8.5.6 External links

System Interface Description, Levels 1, 2, 3, 4Generic Exam- U.S. Treasury - Oce of the CIO homepage.
ples.
Other Architectures and Frameworks, The Open
Group 1999-2006.
product, while Levels 2, 3, and 4 are supporting work
products.[2]
The System Interface Description identies the interfaces
between nodes, between systems, and between the com-
ponents of a system, depending on the needs of a par-
ticular architecture. A system interface is a simplied
or generalized representation of a communications path-
way or network, usually depicted graphically as a straight
line, with a descriptive label. Often, pairs of connected
systems or system components have multiple interfaces
between them. The System Interface Description depicts
all interfaces between systems and/or system components
that are of interest to the architect.[2]
The graphic descriptions and/or supporting text for the
System Interface Description should provide details con-
cerning the capabilities of each system. For example, de-
scriptions of information systems should include details
concerning the applications present within the system, the
infrastructure services that support the applications, and
the means by which the system processes, manipulates,
stores, and exchanges data.[2]

8.5.4 See also

Department of Defense Architecture Framework.

Federal Enterprise Architecture

Conceptual schema

8.5.5 References
[1] FEA Consolidated Reference Model Document. white-
house.gov May 2005.

[2] US Department of the Treasury Chief Information Of-

cer Council (2000). Treasury Enterprise Architecture
Framework. Version 1, July 2000.

[3] whitehouse.gov (May 12, 2012)The Common Approach

to Federal Enterprise Architecture. Accessed January 10,
2013
Chapter 9

Lifecycles

9.1 Enterprise life cycle synchronized, systems migrate eciently from legacy
technology environments through evolutionary and incre-
mental developments, and the Agency is able to demon-
strate its return on investment (ROI). The gure on top
illustrates the interaction of the dynamic and interactive
cycles as they would occur over time.[1]

9.1.2 Enterprise life cycle topics

Enterprise architecture process

Illustration of the Enterprise Life Cycle.[1]

Enterprise life cycle (ELC) in enterprise architecture is

the dynamic, iterative process of changing the enterprise
over time by incorporating new business processes, new
technology, and new capabilities, as well as maintenance,
disposition and disposal of existing elements of the
enterprise.[1]

9.1.1 Overview Enterprise Architecture Process.[1]

The enterprise life cycle is a key concept in enterprise As a prerequisite to the development of every enterprise
architecture (EA), enterprise engineering[2] and systems architecture, each Agency should establish the need to de-
engineering.[3] The Enterprise Architecture process is velop an EA and formulate a strategy that includes the
closely related to similar processes, as program manage- denition of a vision, objectives, and principles. The g-
ment cycle or systems development life cycle, and has ure shows a representation of the EA process. Executive
similar properties to those found in the product life cy- buy-in and support should be established and an architec-
cle.[4] tural team created within the organization. The team de-
The concept of enterprise life cycle aids in the implemen- nes an approach and process tailored to Agency needs.
tation of an enterprise architecture, and the capital plan- The architecture team implements [1]
the process to build
ning and investment control (CPIC) process that selects, both the baseline and target EAs.
controls, and evaluates investments. Overlying these pro- The architecture team also generates a sequencing plan
cesses are human capital management and information for the transition of systems, applications, and associ-
security management. When these processes work to- ated business practices predicated upon a detailed gap
gether eectively, the enterprise can eectively manage analysis. The architecture is employed in the CPIC and
information technology as a strategic resource and busi- the enterprise engineering and program management pro-
ness process enabler. When these processes are properly cesses via prioritized, incremental projects and the inser-

92
9.1. ENTERPRISE LIFE CYCLE 93

tion of emerging new technologies. Lastly, the architec-

tures are maintained through a continuous modication
to reect the Agencys current baseline and target busi-
ness practices, organizational goals, visions, technology,
and infrastructure.[1]

Architecture life cycle

TEAF Enterprise Life Cycle activities[6]

The enterprise life cycle applies to enterprise-wide plan-

ning activities and decision making. By contrast, a Sys-
tem Development Life Cycle generally refers to practices
for building individual systems. Determining what sys-
tems to build is an enterprise-level decision.[6]
The gure on the right depicts notional activities of an
DoDAF Architecture Life Cycle.[5]
enterprise life cycle methodology. Within the context of
this document, Enterprise Life Cycle does not refer to
The gure depicts the life of the architecture as it evolves
a specic methodology or a specic bureaus approach.
and shows the process that the architecture description
Each organization needs to follow a documented Enter-
supports in the development, analysis, and evolution of
prise Life Cycle methodology appropriate to its size, the
the implemented architecture. In this illustration, the
complexity of its enterprise, and the scope of its needs.[6]
Operational View is used to drive the requirements that
are evaluated against the Systems View. Operational de-
ciencies are derived from the analysis, and viable candi- Enterprise Performance Life Cycle
dates are identied. These candidates can take the form
of either materiel or non- materiel solutions and are mod-
eled back into the Operational and Systems Views of the
architecture.[5]
The architecture is re-analyzed, and the process continues
until the operational deciencies are minimized. The -
nal sets of viable candidates are assessed for operational
viability. Based on the results of the assessments, de-
sign changes are made and submitted for inclusion into
the budgeting process. This process of developing, ana-
lyzing, and modifying continues throughout the architec-
tures life cycle.[5]

Enterprise life cycle activities

An enterprise life cycle integrates the management, busi-
ness, and engineering life cycle processes that span the
enterprise to align its business and IT activities. Enter-
prise life cycle refers generally to an organizations ap-
proach for managing activities and making decisions dur-
ing ongoing refreshment of business and technical prac-
tices to support its enterprise mission. These activities
include investment management, project denition, con-
guration management, accountability, and guidance for
systems development according to a system development
life cycle (SDLC).[6]
Illustration of the Enterprise Performance Life Cycle of the U.S.
Department of Health & Human Services.[7]
The Enterprise Performance Life Cycle (EPLC) encom-
passes the major business functions executed under the
Oce of the Chief Information Ocer (CIO), and in
particular shows at a high level the relationship among the
dierent business functions and both the general order
and the iterative nature of their execution. The placement
of enterprise architecture in the center of the EPLC con-
ceptual diagram, shown in the gure, reects the support-
94 CHAPTER 9. LIFECYCLES

ing and enabling role that enterprise architecture serves [7] U.S. Department of Health & Human Services (2007).
for the major business functions in the Enterprise Perfor- HHS Enterprise Architecture Governance Plan FY2007.
mance Life Cycle.[7]
The Enterprise Architecture (EA) Program explicitly 9.1.5 Further reading
considers the information needs of the Enterprise Perfor-
mance Life Cycle (EPLC) processes in developing and Alain Bernard, Serge Tichkiewitch (2008). Meth-
enhancing the EA Framework, collecting and populating ods and Tools for Eective Knowledge Life-Cycle-
data in the EA Repository, and developing views, reports, Management.
and analytical tools that can be used to facilitate the ex-
ecution of the EPLC processes. The EPLC conceptual Peter Bernus, Laszlo Nemes, Gnter Schmidt
diagram in the gure provides a Departmental perspec- (2003). Handbook on Enterprise Architecture.
tive of key business functions. The EPLC is also relevant
from an individual investment or project perspective, as Jerey O. Grady (2006). System requirements anal-
each new investment passes through each phase of the ysis
EPLC. The investment-level perspective is detailed in the
Arturo Molina, Jose Manuel Sanchez, Andrew Ku-
Enterprise Performance Life Cycle Framework.[7]
siak (1998). Handbook of Life Cycle Engineering:
Concepts, Models, and Technologies.
9.1.3 See also Franois Vernadat (1996). Enterprise Modeling and
Integration: Principles and Applications.
Business analysis
Enterprise architecture planning
9.1.6 External links
Enterprise modeling
Enterprise Life Cycle Management presentation
Organizational life cycle
2005
Product lifecycle management
EA in the Federal Enterprise Life Cycle EA in the
Service-oriented modeling life cycle Federal Enterprise Life Cycle presentation 2006.
Software lifecycle processes
Systems development life cycle 9.2 ISO 12207
Technology life cycle
The ISO/IEC 12207 Systems and software engineering
Whole-life cost Software life cycle processes[1] is an international stan-
dard for software lifecycle processes. It aims to be the
Enterprise integration
standard that denes all the tasks required for developing
and maintaining software.
9.1.4 References The ISO/IEC 12207 standard establishes a process of
lifecycle for software, including processes and activities
[1] Chief Information Ocer Council (2001). A Practical
applied during the acquisition and conguration of the
Guide to Federal Enterprise Architecture
services of the system. Each Process has a set of out-
[2] Kosanke, Kurt, F. Vernadat, and Martin Zelm]. comes associated with it. There are 23 Processes, 95 Ac-
CIMOSA: enterprise engineering and integration. tivities, 325 Tasks and 224 Outcomes (the new ISO/IEC
Computers in industry 40.2 (1999): 83-97. 12207:2008 Systems and software engineering Soft-
[3] Ronald E. Giachetti (2011) Design of Enterprise Systems:
ware life cycle processes denes 43 system and software
Theory, Architecture, and Methods. p. 7 processes).
The standard has the main objective of supplying a com-
[4] Alain Bernard, Serge Tichkiewitch (2008). Methods and
Tools for Eective Knowledge Life-Cycle-Management. p. mon structure so that the buyers, suppliers, develop-
403 ers, maintainers, operators, managers and technicians in-
volved with the software development use a common lan-
[5] DoD Architecture Framework Working Group (2003). guage. This common language is established in the form
DoD Architecture Framework Version 1.0 Deskbook 15 of well dened processes. The structure of the standard
August 2003. was intended to be conceived in a exible, modular way
[6] US Department of the Treasury Chief Information Of- so as to be adaptable to the necessities of whoever uses
cer Council (2000). Treasury Enterprise Architecture it. The standard is based on two basic principles: mod-
Framework. Version 1, July 2000. ularity and responsibility. Modularity means processes
9.2. ISO 12207
with minimum coupling and maximum cohesion. Re-
sponsibility means to establish a responsibility for each
process, facilitating the application of the standard in
projects where many people can be legally involved.
The set of processes, activities and tasks can be adapted
according to the software project. These processes are
classied in three types: basic, for support and organi-
zational. The support and organizational processes must
exist independently of the organization and the project
being executed. The basic processes are instantiated ac-
cording to the situation.
9.2.1 History
ISO/IEC 12207:2008 is newest version of the inter-
national standards.
Revises: ISO/IEC 12207:1995/Amd 2:2004
Revises: ISO/IEC 12207:1995/Amd 1:2002
First version was published 1995
9.2.2 Primary lifecycle processes
The primary lifecycle processes contain the core of pro-
cesses involved in creating a software product. These pro-
cesses are divided into six dierent main processes:
Acquisition
Supply
Development
Operation
Maintenance
Destruction
Because the primary lifecycle processes cover a very large
area a scope was dened. This entry explains all the pri-
mary lifecycle processes but will explain the Acquisition
and Development processes more extensively.
9.2.3 Activities
Each phase within the primary lifecycle processes can be
divided into dierent activities. This chapter explains the
dierent activities for each primary lifecycle process..
Acquisition
Acquisition covers all the activities involved in initiating a
project. The acquisition phase can be divided into dier-
ent activities and deliverables that are completed chrono-
logically.
95
Initiation: during this activity the following tasks are
completed
The need is described why to acquire, develop,
or enhance a product;
System requirements are dened and approved
if applicable;
The global software requirements are dened;
Evaluation of other options, like a purchase of
an o-the-shelf product or enhancement of an
existing product;
If an o-the-shelf product is purchased, the
software requirements of this product need to
be analyzed.
An acquisition plan is developed, this plan will
be used further on during the acquisition phase
Acceptance criteria are dened.
Request for proposal preparation: during this activ-
ity the following tasks are completed
Acquisition requirements, like System require-
ments and technical constraints such as target
environment, are dened.
Required ISO/IEC 12207 process for the
project are dened and changed accordingly if
needed.
Contract milestones for reviewing and sup-
pliers progress audits are dened.
Prepare Contract: during this activity the following
tasks are completed
Selection procedure for suppliers are devel-
oped;
Suppliers, based on the developed selection
procedure, are selected;
The tailor-made ISO/IEC 12207 standard
must be included in the contract;
Negotiate changes: during this activity the following
tasks are completed
Negotiations are held with the selected suppli-
ers;
Update contract: during this activity the following
tasks are completed
Contract is updated with the result from the
negotiations in the previous activity.
Supplier monitoring: during this activity the follow-
ing tasks are completed
Activities of the suppliers according to the
agreements made are monitored;
Work together with suppliers to guarantee
timely delivery if needed.
96 CHAPTER 9. LIFECYCLES

Acceptance and completion: during this activity the
following tasks are completed
Acceptance tests and procedures are devel-
oped;
Acceptance and testing on the product is con-
Execute Integration test
ducted;
Conguration management on the delivered
product is conducted;
Supply
The dierent modules are tested for correct
functioning. If this is the case the project can
move to the next activity, else the project re-
turns to the module design phase to correct any
errors.
The communication between modules is
tested for correct functioning. If this is the
case the project can move to the next activity,
else the project falls back to the high level de-
sign to correct any errors.

During the supply phase a project management plan is de- Execute System test
veloped. This plan contains information about the project
This test checks whether all functional require-
such as dierent milestones that need to be reached. This
ments are present in the product. If this is the
project management plan is needed during the next phase
case the product is completed and the product
which is the development phase.
is ready to be transferred to the customer. Else
the project falls back to the software require-
Development ments activity and the functional requirements
have to be adjusted.
During the development phase the software product is de-
signed, created and tested and will result in a software Operation
product ready to be released to the customer. Throughout
time many people have developed means of developing a The operation and maintenance phases occur simultane-
software application. The choice of developing method ously, the operation-phase consists of activities like assist-
often depends on the present situation. The development ing users in working with the created software product.
method which is used in many projects is the V-model.
Techniques that can be used during the development are
UML for designing and TMap for testing. This entry con- Maintenance
tains the most important steps of the V-model.
The maintenance-phase consists of maintenance-tasks to
Dene functional requirements: during this activity keep the product up and running. The maintenance
the following tasks are completed includes any general enhancements, changes and addi-
tions, which might be required by the end-users.These
Gather the functional requirements, or de- defects and deciencies are usually documented by the
mands, for the product that is to be created. developing organisation to enable future solutions and
known issues addressing in any future maintenance re-
Create High level design: during this activity the fol- leases. There is no disposal phase
lowing tasks are completed

A basic layout of the product is created. This 9.2.4 Deliverables

means the setup of dierent modules and how
they communicate with each other. This de- The dierent deliverables that are developed per activity
sign does not contain very much detail about are explained in this chapter.
the modules.

Create Module design Acquisition

The dierent modules present in the High level Acquisition covers the activities involved in initiating a
design are designed separately. The modules project. The acquisition phase can be divided into dier-
are designed in as much detail as possible. ent activities and deliverables that are completed chrono-
logically.
Coding

The code is created according to the high level Initiation: during this activity the following deliver-
design and the module design. ables are developed:

Execute Module test Initiation documents;

9.2. ISO 12207 97

Request for proposal preparation: during this activ- Module test: during this activity the following deliv-
ity the following deliverables are developed: erables are developed:
Request for proposal; Module test report, this test report contains
Prepare Contract: during this activity the following the test-results which are formed after a mod-
deliverables are developed: ule test of the application. Based on this test-
report the project-team can decide which ac-
Contract: this is a draft agreement between the tion to undertake further.
company and suppliers, set up by the company.
Integration test: during this activity the following
Negotiate Changes: during this activity the follow- deliverables are developed:
ing deliverables are developed:
Input from the suppliers: suppliers can react Integration test report, this test report contains
on the draft agreement submitted by the com- the test-results which are formed after an inte-
pany, this reaction will result in input from the gration test of the application. Based on this
suppliers test-report the project-team can decide which
action to undertake further.
Update Contract: during this activity the following
deliverables are developed: System test: during this activity the following deliv-
erables are developed:
Final Contract;
System test report;
Supplier monitoring: during this activity the follow-
ing deliverables are developed:
Supplier Monitor Report: this report covers 9.2.5 Example
the advances of the suppliers involved based
on dierent milestones. The method presented in this entry can be used in a com-
pany that is responsible for creating and maintaining a
Acceptance and completion: during this activity the software product for a customer. Especially when this
following deliverables are developed: company decides to build an application from scratch and
Acquisition report: this report covers the ac- that maintenance and assisting in the operation is also
ceptance and completion of the acquisition done by the company developer.
phase.

9.2.6 See also

Development
IEEE 12207
During the development phase the software product is de-
signed, created and tested and will result in a software Software development process
product ready to be sold to the customer.
Software release life cycle
Dene Software Requirements: during this activity
the following deliverables are developed: ISO/IEC 15288

Software Requirements: this is a collection of ISO/IEC 15504

dierent functional requirements;
Meta-modeling technique
High level design: during this activity the following
deliverables are developed:
V model
High level design;
Unied Modeling Language
Module design: during this activity the following de-
liverables are developed: Build management
Module design; Release management
Coding: during this activity the following deliver-
ables are developed: Application Lifecycle Framework

Code; ISO/IEC JTC 1/SC 7

98 CHAPTER 9. LIFECYCLES

9.2.7 References systems. Like anything that is manufactured on an as-

sembly line, an SDLC aims to produce high-quality sys-
[1] ISO/IEC 12207:2008 Systems and software engineering tems that meet or exceed customer expectations, based
Software life cycle processes on customer requirements, by delivering systems which
move through each clearly dened phase, within sched-
Mitchell H. Levine (2006). Analyzing the Deliv- uled time frames and cost estimates.[3] Computer sys-
erables Produced in the Software Development Life tems are complex and often (especially with the recent
Cycle. Audit Serve, Inc. Retrieved 2011-10-28. rise of service-oriented architecture) link multiple tradi-
tional systems potentially supplied by dierent software
SSC San Diego Process Asset Library. Archived vendors. To manage this level of complexity, a number of
from the original on June 24, 2006. Retrieved 2006- SDLC models or methodologies have been created, such
02-19. as "waterfall"; "spiral"; "Agile software development";
"rapid prototyping"; "incremental"; and synchronize and
stabilize.[4]
9.3 Systems Development Life Cy- SDLC can be described along a spectrum of agile to it-
cle erative to sequential methodologies. Agile methodolo-
gies, such as XP and Scrum, focus on lightweight pro-
cesses which allow for rapid changes (without neces-
For other uses, see SDLC (disambiguation). sarily following the pattern of SDLC approach) along
The systems development life cycle (SDLC), also the development cycle. Iterative methodologies, such as
Rational Unied Process and dynamic systems develop-
ment method, focus on limited project scope and expand-
ing or improving products by multiple iterations. Sequen-
tial or big-design-up-front (BDUF) models, such as wa-
terfall, focus on complete and correct planning to guide
large projects and risks to successful and predictable re-
sults. Other models, such as anamorphic development,
tend to focus on a form of development that is guided by
project scope and adaptive iterations of feature develop-
ment.
In project management a project can be dened both with
a project life cycle (PLC) and an SDLC, during which
slightly dierent activities occur. According to Taylor
(2004), the project life cycle encompasses all the activ-
ities of the project, while the systems development life
cycle focuses on realizing the product requirements".[5]
SDLC is used during the development of an IT project, it
describes the dierent stages involved in the project from
Model of the systems development life cycle, highlighting the
the drawing board, through the completion of the project.
maintenance phase. The SDLC isn't a methodology per se, but rather a de-
scription of the phases in the life cycle of a software ap-
referred to as the application development life-cycle, plication. These phases (broadly speaking) are, investiga-
is a term used in systems engineering, information sys- tion, analysis, design, build, test, implement, and mainte-
tems and software engineering to describe a process for nance and support. All software development method-
planning, creating, testing, and deploying an informa- ologies (such as the more commonly known waterfall and
tion system.[1] The systems development life-cycle con- scrum methodologies) follow the SDLC phases but the
cept applies to a range of hardware and software cong- method of doing that varies vastly between methodolo-
urations, as a system can be composed of hardware only, gies. In the Scrum methodology, for example, one could
software only, or a combination of both.[2] say a single user story goes through the all the phases
of the SDLC within a single 2 week sprint. Contrast
this to the waterfall methodology, as another example,
9.3.1 Overview where every business requirement (recorded in the anal-
ysis phase of the SDLC in a document called the Busi-
A systems development life cycle is composed of a num- ness Requirements Specication) is translated into fea-
ber of clearly dened and distinct work phases which ture/functional descriptions (recorded in the design phase
are used by systems engineers and systems developers in a document called the Functional Specication) which
to plan for, design, build, test, and deliver information
9.3. SYSTEMS DEVELOPMENT LIFE CYCLE
are then all built in one go as a collection of solution fea-
tures typically over a period of three to nine months, or
more. These methodologies are obviously quite dier-
ent approaches yet, they both contain the SDLC phases
in which a requirement is born, then travels through the
life cycle phases ending in the nal phase of maintenance
and support, after-which (typically) the whole life cycle
starts again for a subsequent version of the software ap-
plication.
9.3.2 History and details
The product life cycle describes the process for building
information systems in a very deliberate, structured and
methodical way, reiterating each stage of the products
life. The systems development life cycle, according to
Elliott & Strachan & Radford (2004), originated in the
1960s, to develop large scale functional business systems
in an age of large scale business conglomerates. Informa-
tion systems activities revolved around heavy data pro-
cessing and number crunching routines.[6]
Several systems development frameworks have been
partly based on SDLC, such as the structured systems
analysis and design method (SSADM) produced for the
UK government Oce of Government Commerce in the
1980s. Ever since, according to Elliott (2004), the tradi-
tional life cycle approaches to systems development have
been increasingly replaced with alternative approaches
and frameworks, which attempted to overcome some of
the inherent deciencies of the traditional SDLC.[6]
9.3.3 Phases
The system development life cycle framework provides a
sequence of activities for system designers and developers
to follow. It consists of a set of steps or phases in which
each phase of the SDLC uses the results of the previous
one.
The SDLC adheres to important phases that are essen-
tial for developers, such as planning, analysis, design,
and implementation, and are explained in the section be-
low. It includes evaluation of present system, information
gathering, feasibility study and request approval. A num-
ber of SDLC models have been created: waterfall, foun-
tain, spiral, build and x, rapid prototyping, incremental,
synchronize and stabilize. The oldest of these, and the
best known, is the waterfall model: a sequence of stages
in which the output of each stage becomes the input for
the next. These stages can be characterized and divided
up in dierent ways, including the following:[7]
Preliminary analysis: The objective of phase 1 is
to conduct a preliminary analysis, propose alterna-
tive solutions, describe costs and benets and submit
a preliminary plan with recommendations.
99
1. Conduct the preliminary analysis: in this
step, you need to nd out the organiza-
tions objectives and the nature and scope
of the problem under study. Even if a
problem refers only to a small segment
of the organization itself, you need to
nd out what the objectives of the orga-
nization itself are. Then you need to see
how the problem being studied ts in with
them.
2. Propose alternative solutions: In dig-
ging into the organizations objectives
and specic problems, you may have al-
ready covered some solutions. Alternate
proposals may come from interviewing
employees, clients, suppliers, and/or con-
sultants. You can also study what com-
petitors are doing. With this data, you
will have three choices: leave the system
as is, improve it, or develop a new system.
3. Describe the costs and benets.
Systems analysis, requirements denition: De-
nes project goals into dened functions and oper-
ation of the intended application. It is the process
of gathering and interpreting facts, diagnosing prob-
lems and recommending improvements to the sys-
tem. Analyzes end-user information needs and also
removes any inconsistencies and incompleteness in
these requirements.
A series of steps followed by the developer
are:[8]
1. Collection of Facts: End user require-
ments are obtained through documenta-
tion, client interviews, observation and
questionnaires,
2. Scrutiny of the existing system: Identify
pros and cons of the current system in-
place, so as to carry forward the pros and
avoid the cons in the new system.
3. Analyzing the proposed system: Solu-
tions to the shortcomings in step two are
found and any specic user proposals are
used to prepare the specications.
Systems design: Describes desired features and op-
erations in detail, including screen layouts, business
rules, process diagrams, pseudocode and other doc-
umentation.
Development: The real code is written here.
Integration and testing: Brings all the pieces
together into a special testing environment, then
checks for errors, bugs and interoperability.
100 CHAPTER 9. LIFECYCLES

Acceptance, installation, deployment: The nal

stage of initial development, where the software is
put into production and runs actual business.

Maintenance: During the maintenance stage of the

SDLC, the system is assessed to ensure it does not
become obsolete. This is also where changes are
made to initial software. It involves continuous eval-
uation of the system in terms of its performance.

Evaluation: Some companies do not view this as

an ocial stage of the SDLC, while others con-
sider it to be an extension of the maintenance stage,
The tenth phase occurs when the system is disposed of and the
and may be referred to in some circles as post- task performed is either eliminated or transferred to other sys-
implementation review. This is where the system tems. The tasks and work products for each phase are described
that was developed, as well as the entire process, is in subsequent chapters.[10]
evaluated. Some of the questions that need to be
answered include: does the newly implemented sys-
tem meet the initial business requirements and ob- tem planning is done, a feasibility study should be con-
jectives? Is the system reliable and fault-tolerant? ducted to determine if creating a new or improved system
Does the system function according to the approved is a viable solution. This will help to determine the costs,
functional requirements? In addition to evaluating benets, resource requirements, and specic user needs
the software that was released, it is important to as- required for completion. The development process can
sess the eectiveness of the development process. If only continue once management approves of the recom-
there are any aspects of the entire process, or certain mendations from the feasibility study.[11]
stages, that management is not satised with, this is Following are dierent components of the feasibility
the time to improve. Evaluation and assessment is a study:
dicult issue. However, the company must reect
on the process and address weaknesses.
Operational feasibility
Disposal: In this phase, plans are developed for
discarding system information, hardware and soft- Economic feasibility
ware in making the transition to a new system. The
purpose here is to properly move, archive, discard Technical feasibility
or destroy information, hardware and software that
Human factors feasibility
is being replaced, in a manner that prevents any
possibility of unauthorized disclosure of sensitive Legal/Political feasibility
data. The disposal activities ensure proper migra-
tion to a new system. Particular emphasis is given
to proper preservation and archival of data pro- System analysis
cessed by the previous system. All of this should be
done in accordance with the organizations security The goal of system analysis is to determine where the
requirements.[9] problem is, in an attempt to x the system. This step in-
volves breaking down the system in dierent pieces to
In the following example (see picture) these stages of the analyze the situation, analyzing project goals, breaking
systems development life cycle are divided in ten steps down what needs to be created and attempting to engage
from denition to creation and modication of IT work users so that denite requirements can be dened.
products:
Not every project will require that the phases be sequen- Design
tially executed. However, the phases are interdependent.
Depending upon the size and complexity of the project, In systems design, the design functions and operations
phases may be combined or may overlap.[10] are described in detail, including screen layouts, business
rules, process diagrams and other documentation. The
output of this stage will describe the new system as a col-
System investigation
lection of modules or subsystems.
The system investigates the IT proposal. During this step, The design stage takes as its initial input the requirements
we must consider all current priorities that would be af- identied in the approved requirements document. For
fected and how they should be handled. Before any sys- each requirement, a set of one or more design elements
9.3. SYSTEMS DEVELOPMENT LIFE CYCLE 101

will be produced as a result of interviews, workshops, Unit testing

and/or prototype eorts.
System testing
Design elements describe the desired system features in
detail, and generally include functional hierarchy dia-
Integration testing
grams, screen layout diagrams, tables of business rules,
business process diagrams, pseudo-code, and a complete
Black-box testing
entity-relationship diagram with a full data dictionary.
These design elements are intended to describe the sys-
White-box testing
tem in sucient detail, such that skilled developers and
engineers may develop and deliver the system with mini- Regression testing
mal additional input design.
Automation testing
Environments
User acceptance testing
Environments are controlled areas where systems devel-
opers can build, distribute, install, congure, test, and ex- Software performance testing
ecute systems that move through the SDLC. Each envi-
ronment is aligned with dierent areas of the SDLC and
is intended to have specic purposes. Examples of such Training and transition
environments include the:
Once a system has been stabilized through adequate test-
ing, the SDLC ensures that proper training on the system
Development environment, where developers can is performed or documented before transitioning the sys-
work independently of each other before trying to tem to its support sta and end users.
merge their work with the work of others,
Training usually covers operational training for those
Common build environment, where merged work can people who will be responsible for supporting the system
be built, together, as a combined system, as well as training for those end users who will be using
the system after its delivery to a production operating en-
Systems integration testing environment, where basic
vironment.
testing of a systems integration points to other up-
stream or downstream systems can be tested, After training has been successfully completed, systems
engineers and developers transition the system to its nal
User acceptance testing environment, where business production environment, where it is intended to be used
stakeholders can test against their original business by its end users and supported by its support and opera-
requirements, tions sta.
Production environment, where systems nally get
deployed to, for nal use by their intended end users.
Operations and maintenance

Testing The deployment of the system includes changes and en-

The code is tested at various levels in software testing.
Unit, system and user acceptance testings are often per-
formed. This is a grey area as many dierent opinions
exist as to what the stages of testing are and how much, if
any iteration occurs. Iteration is not generally part of the
waterfall model, but the means to rectify defects and val-
idate xes prior to deployment is incorporated into this
phase.
The following are types of testing that may be relevant,
depending on the type of system under development:
hancements before the decommissioning or sunset of the
system. Maintaining the system is an important aspect
of SDLC. As key personnel change positions in the or-
ganization, new changes will be implemented. There are
two approaches to system development; there is the tra-
ditional approach (structured) and object oriented. Infor-
mation Engineering includes the traditional system ap-
proach, which is also called the structured analysis and
design technique. The object oriented approach views
the information system as a collection of objects that are
integrated with each other to make a full and complete
information system.

Defect testing the failed scenarios, including defect

tracking Evaluation
Path testing
The nal phase of the SDLC is to measure the eective-
Data set testing ness of the system and evaluate potential enhancements.
102
9.3.4 Systems analysis and design
The systems analysis and design (SAD) is the pro-
cess of developing information systems (IS) that eec-
tively use hardware, software, data, processes, and peo-
ple to support the companys businesses objectives. Sys-
tem analysis and design can be considered the meta-
development activity, which serves to set the stage and
bound the problem. SAD can be leveraged to set the cor-
rect balance among competing high-level requirements in
the functional and non-functional analysis domains. Sys-
tem analysis and design interacts strongly with distributed
enterprise architecture, enterprise I.T. Architecture, and
business architecture, and relies heavily on concepts such
as partitioning, interfaces, personae and roles, and de-
ployment/operational modeling to arrive at a high-level
system description. This high level description is then
further broken down into the components and modules
which can be analyzed, designed, and constructed sep-
arately and integrated to accomplish the business goal.
SDLC and SAD are cornerstones of full life cycle prod-
uct and system planning.
9.3.5 Object-oriented analysis
Object-oriented analysis (OOA) is the process of ana-
lyzing a task (also known as a problem domain), to de-
velop a conceptual model that can then be used to com-
plete the task. A typical OOA model would describe
computer software that could be used to satisfy a set
of customer-dened requirements. During the analysis
phase of problem-solving, a programmer might consider
a written requirements statement, a formal vision docu-
ment, or interviews with stakeholders or other interested
parties. The task to be addressed might be divided into
several subtasks (or domains), each representing a dif-
ferent business, technological, or other areas of inter-
est. Each subtask would be analyzed separately. Im-
plementation constraints, (e.g., concurrency, distribution,
persistence, or how the system is to be built) are not con-
sidered during the analysis phase; rather, they are ad-
dressed during object-oriented design (OOD).
The conceptual model that results from OOA will typi- 9.3.6 Life cycle
cally consist of a set of use cases, one or more UML class
diagrams, and a number of interaction diagrams. It may Management and control
also include some kind of user interface mock-up.
The input for object-oriented design is provided by the
output of object-oriented analysis. Realize that an out-
put artifact does not need to be completely developed to
serve as input of object-oriented design; analysis and de-
sign may occur in parallel, and in practice the results of
one activity can feed the other in a short feedback cycle
through an iterative process. Both analysis and design can
be performed incrementally, and the artifacts can be con-
tinuously grown instead of completely developed in one
shot.
CHAPTER 9. LIFECYCLES
Some typical (but common to all types of design analysis)
input artifacts for object-oriented:
Conceptual model: Conceptual model is the result
of object-oriented analysis, it captures concepts in
the problem domain. The conceptual model is ex-
plicitly chosen to be independent of implementation
details, such as concurrency or data storage.
Use case: Use case is a description of sequences of
events that, taken together, lead to a system doing
something useful. Each use case provides one or
more scenarios that convey how the system should
interact with the users called actors to achieve a spe-
cic business goal or function. Use case actors may
be end users or other systems. In many circum-
stances use cases are further elaborated into use case
diagrams. Use case diagrams are used to identify the
actor (users or other systems) and the processes they
perform.
System Sequence Diagram: System Sequence dia-
gram (SSD) is a picture that shows, for a particular
scenario of a use case, the events that external ac-
tors generate, their order, and possible inter-system
events.
User interface documentations (if applicable): Doc-
ument that shows and describes the look and feel of
the end products user interface. It is not mandatory
to have this, but it helps to visualize the end-product
and therefore helps the designer.
Relational data model (if applicable): A data model
is an abstract model that describes how data is rep-
resented and used. If an object database is not
used, the relational data model should usually be cre-
ated before the design, since the strategy chosen for
object-relational mapping is an output of the OO de-
sign process. However, it is possible to develop the
relational data model and the object-oriented design
artifacts in parallel, and the growth of an artifact can
stimulate the renement of other artifacts.
The SDLC phases serve as a programmatic guide to
project activity and provide a exible but consistent way
to conduct projects to a depth matching the scope of
the project. Each of the SDLC phase objectives are de-
scribed in this section with key deliverables, a description
of recommended tasks, and a summary of related control
objectives for eective management. It is critical for the
project manager to establish and monitor control objec-
tives during each SDLC phase while executing projects.
Control objectives help to provide a clear statement of
9.3. SYSTEMS DEVELOPMENT LIFE CYCLE 103

and timeline of the project and will be part of the initial

project description eort leading to project approval. The
middle section of the WBS is based on the seven systems
development life cycle phases as a guide for WBS task
development. The WBS elements should consist of mile-
stones and tasks as opposed to activities and have a
denitive period (usually two weeks or more). Each task
must have a measurable output (e.x. document, decision,
or analysis). A WBS task may rely on one or more ac-
tivities (e.g. software engineering, systems engineering)
and may require close coordination with other tasks, ei-
ther internal or external to the project. Any part of the
project needing support from contractors should have a
SPIU phases related to management controls.[12] statement of work (SOW) written to include the appro-
priate tasks from the SDLC phases. The development of
a SOW does not occur during a specic phase of SDLC
the desired result or purpose and should be used through- but is developed to include the work from the SDLC pro-
out the entire SDLC process. Control objectives can be cess that may be conducted by external resources such as
grouped into major categories (domains), and relate to contractors.[12]
the SDLC phases as shown in the gure.[12]
To manage and control any SDLC initiative, each project
Baselines
will be required to establish some degree of a work break-
down structure (WBS) to capture and schedule the work
Baselines are an important part of the systems develop-
necessary to complete the project. The WBS and all pro-
ment life cycle. These baselines are established after four
grammatic material should be kept in the project de-
of the ve phases of the SDLC and are critical to the iter-
scription section of the project notebook. The WBS for-
ative nature of the model .[13] Each baseline is considered
mat is mostly left to the project manager to establish in a
as a milestone in the SDLC.
way that best describes the project work.
There are some key areas that must be dened in the WBS functional baseline: established after the conceptual
as part of the SDLC policy. The following diagram de- design phase.
scribes three key areas that will be addressed in the WBS
in a manner established by the project manager.[12] The allocated baseline: established after the preliminary
diagram shows coverage spans numerous phases of the design phase.
SDLC but the associated MCD has a subset of primary
mappings to the SDLC phases. For example, Analysis product baseline: established after the detail design
and Design is primarily performed as part of the Acqui- and development phase.
sition and Implementation Domain and System Build and
Prototype is primarily performed as part of delivery and updated product baseline: established after the pro-
support. duction construction phase.

Work breakdown structured organization Complementary methodologies

Complementary software development methods to sys-

tems development life cycle are:

Software prototyping

Joint applications development (JAD)

Rapid application development (RAD)

Extreme programming (XP);

Work breakdown structure.[12]
Open-source development
The upper section of the work breakdown structure
(WBS) should identify the major phases and milestones End-user development
of the project in a summary fashion. In addition, the up-
per section should provide an overview of the full scope Object-oriented programming
104
9.3.7 Strengths and weaknesses
Few people in the modern computing world would use
a strict waterfall model for their SDLC as many mod-
ern methodologies have superseded this thinking. Some
will argue that the SDLC no longer applies to models like
Agile computing, but it is still a term widely in use in
technology circles. The SDLC practice has advantages
in traditional models of systems development, that lends
itself more to a structured environment. The disadvan-
tages to using the SDLC methodology is when there is
need for iterative development or (i.e. web development
or e-commerce) where stakeholders need to review on
a regular basis the software being designed. Instead of
viewing SDLC from a strength or weakness perspective,
it is far more important to take the best practices from
the SDLC model and apply it to whatever may be most
appropriate for the software being designed.
A comparison of the strengths and weaknesses of SDLC:
An alternative to the SDLC is rapid application develop-
ment, which combines prototyping, joint application de-
velopment and implementation of CASE tools. The ad-
vantages of RAD are speed, reduced development cost, 9.3.10 Further reading
and active user involvement in the development process.
Blanchard, B. S., & Fabrycky, W. J. (2006) Sys-
9.3.8 See also
Application lifecycle management
IPO Model
Software development methodologies
System lifecycle
9.3.9 References
[1] SELECTING A DEVELOPMENT APPROACH. Re-
trieved 17 July 2014.
[2] Parag C. Pendharkara; James A. Rodgerb; Girish
H. Subramanian (November 2008). An empirical
study of the CobbDouglas production function prop-
erties of software development eort. Informa-
tion and Software Technology. 50 (12): 11811188.
doi:10.1016/j.infsof.2007.10.019.
[3] Systems Development Life Cycle from. FOLDOC. Re-
trieved 2013-06-14.
[4] Software Development Life Cycle (SDLC), Power Point,
Powered by Google Docs
[5] James Taylor (2004). Managing Information Technology
Projects. p.39..
[6] Georey Elliott & Josh Strachan (2004) Global Business
Information Technology. p.87.
[7] QuickStudy: System Development Life Cycle, By Russell
Kay, May 14, 2002
CHAPTER 9. LIFECYCLES
[8] Control and Audit, Information Systems. SDLC (August
2013 ed.). Chapter 5: Institute of Chartered Accountants
of India. p. 5.28.
[9] Radack, S. (n.d.). The system development life cycle
(sdlc). Retrieved from http://csrc.nist.gov/publications/
nistbul/april2009_system-development-life-cycle.pdf
[10] US Department of Justice (2003). INFORMATION RE-
SOURCES MANAGEMENT Chapter 1. Introduction.
[11] Marakas, James A. O'Brien, George M. (2010). Man-
agement information systems (10th ed.). New York:
McGraw-Hill/Irwin. pp. 485489. ISBN 0073376817.
[12] U.S. House of Representatives (1999). Systems Develop-
ment Life-Cycle Policy. p.13.
[13] Blanchard, B. S., & Fabrycky, W. J.(2006) Systems engi-
neering and analysis (4th ed.) New Jersey: Prentice Hall.
p.31
[14] Post, G., & Anderson, D., (2006). Management informa-
tion systems: Solving business problems with information
technology. (4th ed.). New York: McGraw-Hill Irwin.
tems engineering and analysis (4th ed.) New Jersey:
Prentice Hall.
Cummings, Haag (2006). Management Information
Systems for the Information Age. Toronto, McGraw-
Hill Ryerson
Beynon-Davies P. (2009). Business Information
Systems. Palgrave, Basingstoke. ISBN 978-0-230-
20368-6
Computer World, 2002, Retrieved on June 22, 2006
from the World Wide Web:
Management Information Systems, 2005, Retrieved
on June 22, 2006 from the World Wide Web:
This article is based on material taken from the Free
On-line Dictionary of Computing prior to 1 November
2008 and incorporated under the relicensing terms of
the GFDL, version 1.3 or later.
9.3.11 External links
The Agile System Development Lifecycle
Pension Benet Guaranty Corporation Informa-
tion Technology Solutions Lifecycle Methodology
FSA Life Cycle Framework
HHS Enterprise Performance Life Cycle Frame-
work
The Open Systems Development Life Cycle
9.4. TECHNOLOGY LIFE CYCLE 105

System Development Life Cycle Evolution Model- integrated circuits used in a smartphone.
ing The development of a competitive product or process can
Zero Deviation Life Cycle have a major eect on the lifespan of the technology,
making it shorter. Equally, the loss of intellectual prop-
Integrated Defense AT&L Life Cycle Management erty rights through litigation or loss of its secret elements
Chart, the U.S. DoD form of this concept. (if any) through leakages also work to reduce a technol-
ogys lifespan. Thus, it is apparent that the management
of the TLC is an important aspect of technology devel-
9.4 Technology Life Cycle opment.
Most new technologies follow a similar technology ma-
turity lifecycle describing the technological maturity of a
product. This is not similar to a product life cycle, but
applies to an entire technology, or a generation of a tech-
nology.
Technology adoption is the most common phenomenon
driving the evolution of industries along the industry life-
cycle. After expanding new uses of resources they end
with exhausting the eciency of those processes, produc-
ing gains that are rst easier and larger over time then ex-
haustingly more dicult, as the technology matures. In
fact, many authors sustain that actual economical trends
presents clear symptoms of technological maturity, with
particular attention to many traditional industrial sec-
tors including automotive and aeronautical ones.[1] Those
considerations allows a clear verication of the state of
The typical life-cycle of a manufacturing process or production
system from the stages of its initial conception to its culmination technological maturity of the largest part of today trans-
as either a technique or procedure of common practice or to its port vehicles industrial sector and that sustainability ac-
demise. The Y-axis of the diagram shows the business gain to the tion are necessary for both reducing environmental im-
proprietor of the technology while the X-axis traces its lifetime. pact and levels of technological maturity.[2]

The technology life-cycle (TLC) describes the commer-

cial gain of a product through the expense of research 9.4.1 The four phases of the technology
and development phase, and the nancial return during life-cycle
its vital life. Some technologies, such as steel, paper or
cement manufacturing, have a long lifespan (with minor The TLC may be seen as composed of four phases:
variations in technology incorporated with time) while in
other cases, such as electronic or pharmaceutical prod-
ucts, the lifespan may be quite short. 1. The research and development (R&D) phase
(sometimes called the bleeding edge) when in-
The TLC associated with a product or technological ser- comes from inputs are negative and where the
vice is dierent from product life-cycle (PLC) dealt with prospects of failure are high
in product life-cycle management. The latter is concerned
with the life of a product in the marketplace with respect 2. The ascent phase when out-of-pocket costs have
to timing of introduction, marketing measures, and busi- been recovered and the technology begins to gather
ness costs. The technology underlying the product (for strength by going beyond some Point A on the TLC
example, that of a uniquely avoured tea) may be quite (sometimes called the leading edge)
marginal but the process of creating and managing its life
as a branded product will be very dierent. 3. The maturity phase when gain is high and stable,
The technology life cycle is concerned with the time and the region, going into saturation, marked by M, and
cost of developing the technology, the timeline of recov-
4. The decline (or decay phase), after a Point D, of
ering cost, and modes of making the technology yield a
reducing fortunes and utility of the technology.
prot proportionate to the costs and risks involved. The
TLC may, further, be protected during its cycle with
patents and trademarks seeking to lengthen the cycle and S-curve
to maximize the prot from it.
The product of the technology may be a commodity such The shape of the technology lifecycle is often referred to
as polyethylene plastic or a sophisticated product like the as S-curve.[3]
106 CHAPTER 9. LIFECYCLES

9.4.2 Technology perception dynamics
There is usually technology hype at the introduction of
any new technology, but only after some time has passed
can it be judged as mere hype or justied true acclaim.
Because of the logistic curve nature of technology adop-
tion, it is dicult to see in the early stages whether the
hype is excessive.
The two errors commonly committed in the early stages
of a technologys development are:
tting an exponential curve to the rst part of the
growth curve, and assuming eternal exponential
growth
tting a linear curve to the rst part of the growth
curve, and assuming that take-up of the new tech-
nology is disappointing
Syndication stage: This stage represents the demon-
stration and commercialisation of a new technology,
such as, product, material or process with potential
for immediate utilisation. Many innovations are put
on hold in R&D laboratories. Only a very small per-
centage of these are commercialised. Commerciali-
sation of research outcomes depends on technical as
well non-technical, mostly economic factors.
Diusion stage: This represents the market penetra-
tion of a new technology through acceptance of the
innovation, by potential users of the technology. But
supply and demand side factors jointly inuence the
rate of diusion.
Substitution stage: This last stage represents the de-
cline in the use and eventual extension of a tech-
nology, due to replacement by another technology.
Many technical and non-technical factors inuence
the rate of substitution. The time taken in the sub-
stitution stage depends on the market dynamics.

9.4.3 Licensing options

Large corporations develop technology for their own ben-

et and not with the objective of licensing. The tendency
to license out technology only appears when there is a
threat to the life of the TLC (business gain) as discussed
later.[5]

Rogers bell curve Licensing in the R&D phase

Similarly, in the later stages, the opposite mistakes can be
There are always smaller rms (SMEs) who are inade-
made relating to the possibilities of technology maturity
quately situated to nance the development of innovative
and market saturation.
R&D in the post-research and early technology phases.
The technology adoption life cycle typically occurs in an By sharing incipient technology under certain conditions,
S curve, as modelled in diusion of innovations theory. substantial risk nancing can come from third parties.
This is because customers respond to new products in dif- This is a form of quasi-licensing which takes dierent for-
ferent ways. Diusion of innovations theory, pioneered mats. Even large corporates may not wish to bear all costs
by Everett Rogers, posits that people have dierent lev- of development in areas of signicant and high risk (e.g.
els of readiness for adopting new innovations and that aircraft development) and may seek means of spreading
the characteristics of a product aect overall adoption. it to the stage that proof-of-concept is obtained.
Rogers classied individuals into ve groups: innova-
In the case of small and medium rms, entities such as
tors, early adopters, early majority, late majority, and lag-
venture capitalists ('angels), can enter the scene and help
gards. In terms of the S curve, innovators occupy 2.5%,
to materialize technologies. Venture capitalists accept
early adopters 13.5%, early majority 34%, late majority
both the costs and uncertainties of R&D, and that of
34%, and laggards 16%.
market acceptance, in reward for high returns when the
The four stages of technology life cycle are as follows:[4] technology proves itself. Apart from nance, they may
provide networking, management and marketing support.
Innovation stage: This stage represents the birth of Venture capital connotes nancial as well as human cap-
a new product, material of process resulting from ital.
R&D activities. In R&D laboratories, new ideas are
generated depending on gaining needs and knowl- Larger rms may opt for Joint R&D or work in a consor-
edge factors. Depending on the resource allocation tium for the early phase of development. Such vehicles
and also the change element, the time taken in the are called strategic alliances strategic partnerships.
innovation stage as well as in the subsequent stages With both venture capital funding and strategic (research)
varies widely. alliances, when business gains begin to neutralize devel-
9.4. TECHNOLOGY LIFE CYCLE 107

opment costs (the TLC crosses the X-axis), the ownership The exercise of this option is, generally, inferior to seek-
of the technology starts to undergo change. ing participatory exploitation; in other words, engage-
In the case of smaller rms, venture capitalists help clients ment in joint venture, typically in regions where the tech-
enter the stock market for obtaining substantially larger nology would be in the ascent phase,as say, a developing
funds for development, maturation of technology, prod- country. In addition to providing nancial opportunity
uct promotion and to meet marketing costs. A major it allows the technology-owner a degree of control over
route is through initial public oering (IPO) which in- its use. Gain ows from the two streams of investment-
vites risk funding by the public for potential high gain. based and royalty incomes. Further, the vital life of the
technology is enhanced in such strategy.
At the same time, the IPOs enable venture capitalists to
attempt to recover expenditures already incurred by them
through part sale of the stock pre-allotted to them (sub-
Licensing in the decline phase
sequent to the listing of the stock on the stock exchange).
When the IPO is fully subscribed, the assisted enterprise
becomes a corporation and can more easily obtain bank After reaching a point such as D in the above diagram,
loans, etc. if needed. the earnings from the technology begin to decline rather
rapidly. To prolong the life cycle, owners of technology
Strategic alliance partners, allied on research, pursue sep- might try to license it out at some point L when it can still
arate paths of development with the incipient technol- be attractive to rms in other markets. This, then, traces
ogy of common origin but pool their accomplishments the lengthening path, LL'. Further, since the decline is
through instruments such as 'cross-licensing'. Generally, the result of competing rising technologies in this space,
contractual provisions among the members of the con- licenses may be attracted to the general lower cost of the
sortium allow a member to exercise the option of inde- older technology (than what prevailed during its vital life).
pendent pursuit after joint consultation; in which case the
optee owns all subsequent development. Licenses obtained in this phase are 'straight licenses.
They are free of direct control from the owner of the tech-
nology (as would otherwise apply, say, in the case of a
Licensing in the ascent phase joint-venture). Further, there may be fewer restrictions
placed on the licensee in the employment of the technol-
The ascent stage of the technology usually refers to some ogy.
point above Point A in the TLC diagram but actually it The utility, viability, and thus the cost of straight-licenses
commences when the R&D portion of the TLC curve depends on the estimated 'balance life' of the technology.
inects (only that the cashow is negative and unremu- For instance, should the key patent on the technology have
nerative to Point A). The ascent is the strongest phase of expired, or would expire in a short while, the residual via-
the TLC because it is here that the technology is superior bility of the technology may be limited, although balance
to alternatives and can command premium prot or gain. life may be governed by other criteria such as knowhow
The slope and duration of the ascent depends on com- which could have a longer life if properly protected.
peting technologies entering the domain, although they
It is important to note that the license has no way of know-
may not be as successful in that period. Strongly patented
ing the stage at which the prime, and competing technolo-
technology extends the duration period.
gies, are on their TLCs. It would, of course, be evident to
The TLC begins to atten out (the region shown as M) competing licensor rms, and to the originator, from the
when equivalent or challenging technologies come into growth, saturation or decline of the protability of their
the competitive space and begin to eat away marketshare. operations.
Till this stage is reached, the technology-owning rm The license may, however, be able to approximate the
would tend to exclusively enjoy its protability, prefer- stage by vigorously negotiating with the licensor and com-
ring not to license it. If an overseas opportunity does petitors to determine costs and licensing terms. A lower
present itself, the rm would prefer to set up a controlled cost, or easier terms, may imply a declining technology.
subsidiary rather than license a third party.
In any case, access to technology in the decline phase is
a large risk that the licensee accepts. (In a joint-venture
Licensing in the maturity phase this risk is substantially reduced by licensor sharing it).
Sometimes, nancial guarantees from the licensor may
The maturity phase of the technology is a period of stable work to reduce such risk and can be negotiated.
and remunerative income but its competitive viability can There are instances when, even though the technology
persist over the larger timeframe marked by its 'vital life'. declines to becoming a technique, it may still contain
However, there may be a tendency to license out the tech- important knowledge or experience which the licensee
nology to third parties during this stage to lower risk of rm cannot learn of without help from the originator.
decline in protability (or competitivity) and to expand This is often the form that technical service and technical
nancial opportunity. assistance contracts take (encountered often in develop-
108 CHAPTER 9. LIFECYCLES

ing country contracts). Alternatively, consulting agencies 9.4.6 References

may ll this role.
[1] Trancossi, M. (2015). A response to industrial ma-
turity and energetic issues: a possible solution based
on constructal law. European Transport Research Re-
9.4.4 Technology development cycle view, 7(1), 1-14. http://link.springer.com/article/10.
1007/s12544-014-0150-4
According to the Encyclopedia of Earth, In the sim-
[2] TRANCOSSI, M. What price of speed? A critical revi-
plest formulation, innovation can be thought of as being
sion through constructal optimization of transport modes.
composed of research, development, demonstration, and International Journal of Energy and Environmental Engi-
deployment.[6] neering, 2014, 1-24. http://link.springer.com/article/10.
Technology development cycle describes the process of a 1007/s40095-015-0160-6
new technology through the stages of technological ma- [3] Dr. Chandana Jayalath (22 April 2010). Understanding
turity: S-curve Innovation. Improvementandinnovation.com.
Retrieved 15 October 2012.
1. Research and development [4] Technology Management - Growth & Lifecycle, Shahid
kv, Sep 28, 2009, Attribution Non-commercial
2. Scientic demonstration [5] Bayus, B. (1998). An Analysis of Product Lifetimes in
a Technologically Dynamic Industry. Management Sci-
3. System deployment ence, 44(6), pp.763-775.
[6] Technological Innovation. Encyclopedia of Earth. Re-
4. Diusion trieved 27 January 2016.

5. Commercial maturity
9.5 Whole-life cost
9.4.5 See also Whole-life cost, or Life-cycle cost (LCC), refers to the
total cost of ownership over the life of an asset.[1] Also
Background, foreground, sideground and post- commonly referred to as cradle to grave or womb to
ground intellectual property tomb costs. Costs considered include the nancial cost
which is relatively simple to calculate and also the en-
Business cycle vironmental and social costs which are more dicult to
quantify and assign numerical values. Typical areas of
Diusion (business) expenditure which are included in calculating the whole-
life cost include, planning, design, construction and ac-
Disruptive technology quisition, operations, maintenance, renewal and rehabili-
tation, depreciation and cost of nance and replacement
Mass customization or disposal.

Network eects 9.5.1 Financial

New product development Whole-life cost analysis is often used for option evalua-
tion when procuring new assets and for decision-making
Technological revolution to minimize whole-life costs throughout the life of an as-
set. It is also applied to comparisons of actual costs for
Technological transitions similar asset types and as feedback into future design and
acquisition decisions.
Technology acceptance model The primary benet is that costs which occur after an
asset has been constructed or acquired, such as main-
Technology adoption life cycle tenance, operation, disposal, become an important con-
sideration in decision-making. Previously, the focus has
Technology readiness level (TRL) been on the up-front capital costs of creation or acquisi-
tion, and organisations may have failed to take account of
Technology roadmap the longer-term costs of an asset. It also allows an anal-
ysis of business function interrelationships. Low devel-
Toolkits for user innovation opment costs may lead to high maintenance or customer
9.5. WHOLE-LIFE COST 109

service costs in the future. When making this calculation, Asset management
the depreciation cost on the capital expense should not be
included (refer page 2 of [2]
9.5.2 Environmental and social
Main article: Life cycle assessment
During the life of the asset, decisions about how to main-
tain and operate the asset need to be taken in context with
the eect these activities might have on the residual life of
the asset. If by investing 10% more per annum in main-
tenance costs the asset life can be doubled, this might be
a worthwhile investment.
Other issues which inuence the lifecycle costs of an asset
include:

The use of environmental costs in a whole-life analysis site conditions,

allows a true comparison options, especially where both
are quoted as good for the environment. For a major historic performance of assets or materials,
project such as the construction of a nuclear power sta-
eective monitoring techniques,
tion it is possible to calculate the environmental impact
of making the concrete containment, the water required appropriate intervention strategies.
for rening the copper for the power plants and all the
other components. Only by undertaking such an analysis
Although the general approach to determining whole-life
is it possible to determine whether one solution carries a
[3] costs is common to most types of asset, each asset will
lower or higher environmental cost than another.
have specic issues to be considered and the detail of the
Almost all major projects have some social impact. This assessment needs to be tailored to the importance and
may be the compulsory re-location of people living on value of the asset. High cost assets (and asset systems)
land about to be submerged under a reservoir or a threat will likely have more detail, as will critical assets and as-
to the livelihood of small traders from the development set systems.
of a hypermarket nearby.
Maintenance expenditure can account for many times the
initial cost of the asset. Although an asset may be con-
structed with a design life of 30 years, in reality it will
possibly perform well beyond this design life. For assets
9.5.3 Whole-life cost topics like these a balanced view between maintenance strate-
gies and renewal/rehabilitation is required. The appropri-
ateness of the maintenance strategy must be questioned,
Project appraisal the point of intervention for renewal must be challenged.
The process requires proactive assessment which must be
Whole-life costing is a key component in the economic based on the performance expected of the asset, the con-
appraisal associated with evaluating asset acquisition pro- sequences and probabilities of failures occurring, and the
posals. An economic appraisal is generally a broader level of expenditure in maintenance to keep the service
based assessment, considering benets and indirect or in- available and to avert disaster.
tangible costs as well as direct costs.
In this way, the whole-life costs and benets of each op-
9.5.4 IT industry usage
tion are considered and usually converted using discount
rates into net present value costs and benets. This results
Whole-life cost is often referred to as "total cost of own-
in a benet cost ratio for each option, usually compared ership (TCO)" when applied to IT hardware and soft-
to the do-nothing counterfactual. Typically the highest ware acquisitions. Use of the term TCO appears to
benet-cost ratio option is chosen as the preferred option. have been popularised by Gartner Group in 1987[4] but
Historically, asset investments have been based on expe- its roots are considerably older, dating at least to the rst
dient design and lowest cost construction. If such invest- quarter of the twentieth century.[5]
ment has been made without proper analysis of the stan- It has since been developed as a concept with a number
dard of service required and the maintenance and inter- of dierent methodologies and software tools. A TCO
vention options available, the initial saving may result in assessment ideally oers a nal statement reecting not
increased expenditure throughout the assets life. only the cost of purchase but all aspects in the further
By using whole-life costs, this avoids issues with decisions use and maintenance of the equipment, device, or sys-
being made based on the short-term costs of design and tem considered. This includes the costs of training sup-
construction. Often the longer-term maintenance and op- port personnel and the users of the system, costs associ-
eration costs can be a signicant proportion of the whole- ated with failure or outage (planned and unplanned), di-
life cost. minished performance incidents (i.e. if users are kept
110 CHAPTER 9. LIFECYCLES

waiting), costs of security breaches (in loss of reputa- [3] Whole Life Costing For Sustainable Drainage
tion and recovery costs), costs of disaster preparedness
and recovery, oor space, electricity, development ex- [4] About Gartner TCO
penses, testing infrastructure and expenses, quality assur- [5] TCO: Whats Old is New
ance, boot image control, marginal incremental growth,
decommissioning, e-waste handling, and more. When in-
corporated in any nancial benet analysis (e.g., ROI, 9.5.8 Further reading
IRR, EVA, ROIT, RJE) TCO provides a cost basis for
determining the economic value of that investment. Riggs, James L., (1982), Engineering economics.
McGraw-Hill, New York, 2nd edition, 1982.
Understanding and familiarity with the term TCO has
been somewhat facilitated as a result of various compar- Norris, G. A. (2001): Integrating Life Cycle Cost
isons between the TCO of open source and proprietary Analysis and LCA, in: The International Journal of
software. Because the software cost of open source soft- Life Cycle Assessment, Jg. 6, H. 2, p. 118120.
ware is often zero, TCO has been used as a means to jus-
tify the up-front licensing costs of proprietary software. Schaltegger, S. & Burritt, R. (2000): Contemporary
Studies which attempt to establish the TCO and provide Environmental Accounting. Issues, Concepts and
comparisons have as a result been the subject of many Practice. Sheeld: Greenleaf Publ.
discussions regarding the accuracy or perceived bias in
Kicherer, A.; Schaltegger, S.; Tschochohei, H. &
the comparison.
Ferreira Pozo, B.: Eco-Eciency. Combining Life
Cycle Assessment and Life Cycle Costs via Normal-
9.5.5 Automobile industry, nances ization, International Journal of LCA, 2007, Vol 12,
No 7, 537-543.
Total cost of ownership is also common in the automobile
industry. In this context, the TCO denotes the cost of
owning a vehicle from the purchase, through its mainte-
9.5.9 External links
nance, and nally its sale as a used car. Comparative TCO Whole-life cost forum
studies between various models help consumers choose a
car to t their needs and budget. Whole-life costing for sustainable drainage
TCO can and often does vary dramatically against TCA BSRIA article: What is whole life cost analysis?"
(total cost of acquisition), although TCO is far more
relevant in determining the viability of any capital in- Role of depreciation
vestment, especially with modern credit markets and
nancing. TCO also directly relates to a businesss to- Cost Structure and Life Cycle Cost (LCC) for Mil-
tal costs across all projects and processes and, thus, its itary Systems - Papers presented at the RTO Stud-
protability. Some instances of TCO appear to refer ies, Analysis and Simulation Panel (SAS) Sympo-
to total cost of operation, but this may be a subset of sium held in Paris, France, 24-25 October 2001
the total cost of ownership if it excludes maintenance and
support costs.

9.5.6 See also

Benets Realisation Management
Infrastructure
Asset management
Life Cycle Thinking

9.5.7 References
[1] Association of Local Government Engineers New
Zealand: Infrastructure Asset Management Manual,
June 1998 - Edition 1.1
[2] http://www.business.govt.nz/procurement/pdf-library/
agencies/guides-and-tools/guide-total-cost-ownership.
pdf
Chapter 10

Modelling

10.1 Enterprise modelling prise in general is a unit of economic organization or ac-

tivity. These activities are required to develop and deliver
products and/or services to a customer. An enterprise in-
Business Model Integration
cludes a number of functions and operations such as pur-
chasing, manufacturing, marketing, nance, engineering,
Business Model and research and development. The enterprise of interest
Process Model Data Model are those corporate functions and operations necessary
Process Process Process Data Data Data
to manufacture current and potential future variants of a
product.[4]
Logical
Pseudocode Model The term enterprise model is used in industry to rep-
Requirements Physical
resent diering enterprise representations, with no real
Application Prototypes
Document Model standardized denition.[5] Due to the complexity of en-
terprise organizations, a vast number of diering enter-
prise modelling approaches have been pursued across in-
User Application Database I/O Data dustry and academia.[6] Enterprise modelling constructs
View Panels Programs Generation Structures
can focus upon manufacturing operations and/or business
operations; however, a common thread in enterprise mod-
Graphical representation of some types of models in enterprise
elling is an inclusion of assessment of information tech-
modelling. A business model illustrates the functions associated nology. For example, the use of networked computers
with a process that are performance and the organizations that to trigger and receive replacement orders along a mate-
perform these functions. In software development often both rial supply chain is an example of how information tech-
business process models and data models are being developed nology is used to coordinate manufacturing operations
as part of the process of creating application programs on the within an enterprise.[4]
one side and databases on the other side.[1]
The basic idea of enterprise modelling according to
Enterprise modelling is the abstract representation, Ulrich Frank[7] is to oer dierent views on an enter-
description and denition of the structure, processes, prise, thereby providing a medium to foster dialogues
information and resources of an identiable business, between various stakeholders - both in academia and in
government body, or other large organization.[2] practice. For this purpose they include abstractions suit-
able for strategic planning, organisational (re-) design
It deals with the process of understanding an enter- and software engineering. The views should complement
prise business and improving its performance through each other and thereby foster a better understanding of
creation of enterprise models. This includes the mod- complex systems by systematic abstractions. The views
elling of the relevant business domain (usually relatively should be generic in the sense that they can be applied to
stable), business processes (usually more volatile), and any enterprise. At the same time they should oer ab-
Information technology. stractions that help with designing information systems
which are well integrated with a companys long term
strategy and its organisation. Hence, enterprise models
10.1.1 Overview
can be regarded as the conceptual infrastructure that sup-
port a high level of integration.[7]
Enterprise modelling is the process of building models
of whole or part of an enterprise with process models,
data models, resource models and or new ontologies etc.
It is based on knowledge about the enterprise, previous
models and/or reference models as well as domain ontolo-
gies using model representation languages.[3] An enter-

111
112 CHAPTER 10. MODELLING

10.1.2 History according to Gershefski (1971) represent in detail all as-

pects of the rm including the physical operations of
Enterprise modelling has its roots in systems modelling the company, the accounting and nancial practices fol-
and especially information systems modelling. One of lowed, and the response to investment in key areas[14]
the earliest pioneering works in modelling information Programming the modelled relationships into the com-
systems has been done by Young and Kent (1958),[8][9] puter is not always necessary: enterprise models, under
who argued for a precise and abstract way of specify- dierent names, have existed for centuries and were de-
ing the informational and time characteristics of a data scribed, for example, by Adam Smith, Walter Bagehot,
processing problem. They wanted to create a nota- and many others.
tion that should enable the analyst to organize the prob-
According to Fox and Gruninger (1998) from a design
lem around any piece of hardware". Their work was a
perspective, an enterprise model should provide the lan-
rst eort to create an abstract specication and invari-
guage used to explicitly dene an enterprise... From
ant basis for designing dierent alternative implementa-
an operations perspective, the enterprise model must be
tions using dierent hardware components. A next step
able to represent what is planned, what might happen,
in IS modelling was taken by CODASYL, an IT industry
and what has happened. It must supply the informa-
consortium formed in 1959, who essentially aimed at the
tion and knowledge necessary to support the operations
same thing as Young and Kent: the development of a
of the enterprise, whether they be performed by hand or
proper structure for machine independent problem de-
machine.[12]
nition language, at the system level of data processing.
This led to the development of a specic IS information In a two-volume set entitled The Managerial Cybernetics
algebra.[9] of Organization Staord Beer introduced a model of the
enterprise, the Viable System Model (VSM). Volume 2,
The rst methods dealing with enterprise modelling
The Heart of Enterprise,[15] analyzed the VSM as a re-
emerged in the 1970s. They were the entity-relationship
cursive organization of ve systems: System One (S1)
approach of Peter Chen (1976) and SADT of Douglas
through System Five (S5). Beers model diers from oth-
T. Ross (1977), the one concentrate on the information
ers in that the VSM is recursive, not hierarchical: In a
view and the other on the function view of business
recursive organizational structure, any viable system con-
entities.[3] These rst methods have been followed end
tains, and is contained in, a viable system.[15]
1970s by numerous methods for software engineering,
such as SSADM, Structured Design, Structured Analy-
sis and others. Specic methods for enterprise modelling Function modelling
in the context of Computer Integrated Manufacturing ap-
peared in the early 1980s. They include the IDEF fam-
ily of methods (ICAM, 1981) and the GRAI method by
Guy Doumeingts in 1984[10] followed by GRAI/GIM by
Doumeingts and others in 1992.[11]
These second generation of methods were activity-
based methods which have been surpassed on the one
hand by process-centred modelling methods developed
in the 1990s such as Architecture of Integrated Infor-
mation Systems (ARIS), CIMOSA and Integrated En-
terprise Modeling (IEM). And on the other hand by
object-oriented methods, such as Object-oriented analy-
sis (OOA) and Object-modelling technique (OMT).[3]

10.1.3 Enterprise modelling basics

Enterprise model
An enterprise model is a representation of the structure,
activities, processes, information, resources, people, be-
havior, goals, and constraints of a business, government,
or other enterprises.[12] Thomas Naylor (1970) dened
a (simulation) model as an attempt to describe the in-
terrelationships among a corporations nancial, market-
ing, and production activities in terms of a set of mathe-
matical and logical relationships which are programmed
into the computer.[13] These interrelationships should
Example of a function model of the process of Maintain Repara-
ble Spares in IDEF0 notation.
Function modelling in systems engineering is a structured
representation of the functions, activities or processes
within the modelled system or subject area.[16]
A function model, also called an activity model or process
model, is a graphical representation of an enterprise's
function within a dened scope. The purpose of the func-
tion model are to describe the functions and processes,
assist with discovery of information needs, help identify
10.1. ENTERPRISE MODELLING 113

opportunities, and establish a basis for determining prod- based on the data requirements for the application that
uct and service costs.[17] A function model is created with is being developed, perhaps in the context of an activity
a functional modelling perspective. A functional perspec- model. The data model will normally consist of entity
tives is one or more perspectives possible in process mod- types, attributes, relationships, integrity rules, and the
elling. Other perspectives possible are for example be- denitions of those objects. This is then used as the start
havioural, organisational or informational.[18] point for interface or database design.[20]
A functional modelling perspective concentrates on de-
scribing the dynamic process. The main concept in this
Business process modelling
modelling perspective is the process, this could be a func-
tion, transformation, activity, action, task etc. A well-
known example of a modelling language employing this
perspective is data ow diagrams. The perspective uses
four symbols to describe a process, these being: Check status
of working group
Working
group still
Yes [Send]
Send current
active? issue list
Working Friday at
group 6 PM
active Pacic Time

Process: Illustrates transformation from input to

No
output.

Store: Data-collection or some sort of material. Issue list

Flow: Movement of data or material in the process.

Example of business process modelling with Business Process
External Entity: External to the modelled system, Model and Notation.
but interacts with it.
Business process modelling, not to be confused with the
Now, with these symbols, a process can be represented wider Business Process Management (BPM) discipline,
as a network of these symbols. This decomposed pro- is the activity of representing processes of an enterprise,
cess is a DFD, data ow diagram. In Dynamic En- so that the current (as is) process may be analyzed and
terprise Modeling, for example, a division is made in improved in future (to be). Business process modelling
the Control model, Function Model, Process model and is typically performed by business analysts and managers
Organizational model. who are seeking to improve process eciency and qual-
ity. The process improvements identied by business pro-
cess modelling may or may not require Information Tech-
Data modelling nology involvement, although that is a common driver for
the need to model a business process, by creating a pro-
cess master.
Activity
Model
Change management programs are typically involved to
Detailed Data Create/Update put the improved business processes into practice. With
Logical Data
Requirements
Model Conceptual Data Model
advances in technology from large platform vendors, the
Entities/Subtypes vision of business process modelling models becoming
Attributes
Technical
Environment
Relationships fully executable (and capable of simulations and round-
Integrity Rules
Create/Update trip engineering) is coming closer to reality every day.
Performance Physical Data
Considerations Model Physical Data Model
Tables
Columns
Keys/Indices
Systems architecture
Triggers
Business Create/Update
Data Data The RM-ODP reference model identies enterprise mod-
Data
elling as providing one of the ve viewpoints of an open
distributed system. Note that such a system need not be
The data modelling process. a modern-day IT system: a banking clearing house in the
19th century may be used as an example ([21] ).
Data modelling is the process of creating a data model by
applying formal data model descriptions using data mod-
elling techniques. Data modelling is a technique for den- 10.1.4 Enterprise modelling techniques
ing business requirements for a database. It is sometimes
called database modelling because a data model is even- There are several techniques for modelling the enterprise
tually implemented in a database.[19] such as
The gure illustrates the way data models are developed
and used today. A conceptual data model is developed Active Knowledge Modeling,[22]
114 CHAPTER 10. MODELLING

Design & Engineering Methodology for Organiza- engineering principals to the management of enterprises.
tions (DEMO) It encompasses the application of knowledge, principles,
and disciplines related to the analysis, design, implemen-
Dynamic Enterprise Modeling tation and operation of all elements associated with an en-
Enterprise Modelling Methodology/Open Dis- terprise. In essence this is an interdisciplinary eld which
tributed Processing (EMM/ODP) combines systems engineering and strategic management
as it seeks to engineer the entire enterprise in terms of the
Extended Enterprise Modeling Language products, processes and business operations. The view is
one of continuous improvement and continued adapta-
Multi-Perspective Enterprise Modelling tion as rms, processes and markets develop along their
(MEMO),[23] life cycles. This total systems approach encompasses the
Process modelling such as BPMN, CIMOSA, DYA, traditional areas of research and development, product
IDEF3, LOVEM, PERA, etc. design, operations and manufacturing as well as informa-
tion systems and strategic management.[25] This elds is
Integrated Enterprise Modeling (IEM), and related to engineering management, operations manage-
ment, service management and systems engineering.
Modelling the enterprise with multi-agent systems.
In the context of software development a specic eld
More enterprise modelling techniques are developed into of enterprise engineering has emerged, which deals with
Enterprise Architecture framework such as: the modelling and integration of various organizational
and technical parts of business processes.[26] In the con-
text of information systems development it has been the
ARIS - ARchitecture of Integrated Information Sys- area of activity in the organization of the systems analy-
tems sis, and an extension of the scope of Information Mod-
[27]
DoDAF - the US Department of Defense Architec- elling. It can also be viewed as the extension and gen-
ture Framework eralization of the systems analysis and systems design
phases of the software development process.[28] Here En-
OBASHI The OBASHI Business & IT methodology terprise modelling can be part of the early, middle and
and framework late information system development life cycle. Explicit
representation of the organizational and technical sys-
RM-ODP - Reference Model of Open Distributed
tem infrastructure is being created in order to understand
Processing
the orderly transformations of existing work practices.[28]
TOGAF - The Open Group Architecture Frame- This eld is also called Enterprise architecture, or dened
work with Enterprise Ontology as being two major parts of En-
terprise architecture.[24]
Zachman Framework - an architecture framework,
based on the work of John Zachman at IBM in the
1980s 10.1.6 Related elds
Service-oriented modeling framework (SOMF), Business reference modelling
based on the work of Michael Bell
Services for Business

And metamodelling frameworks such as: Defense & National Security Environmental Management areas (4)
Citizens
Homeland Security Natural Resources
Purpose of Intelligence Operations Education Disaster Management
Government Law Enforcement Energy Community & Social Services Lines of
International Aairs & Commerce Health Economic Development Business (39)
Litigation & Judical Activities Transportation Workforce Management
Correctional Activities Income Security

Generalised Enterprise Reference Architecture and

General Science & Innovation

Direct Services for Citizens

Mechanisms Federal Financial Assistance
Knowledge Creation & Management Mode of Credit & Assurance
used to
Methodology achieve
Purpose
Public Goods Creation &
Management
Regulatory Compliance & Enforcement
Delivery Transfers to States &
Local Governments

Controls & Oversight

Government Legislative Relations
Support Delivery Revenue Collection
Operations Public Aairs
of Services Internal Risk Management &
Support Regulatory Development

10.1.5 Enterprise engineering

Mitigation
Functions Planning & Resource Allocation
General Government

Resource Supply Chain Management Management of Government Administrative Management

Management Human Resource Management Information & Technology
Resources
Functions Financial Management Management

Enterprise engineering is the discipline concerning the

design and the engineering of enterprises, regarding both
Example of the US FEA Business Reference Model.[29]
their business and organization.[24] In theory and practice
two types of enterprise engineering has emerged. A more
Business reference modelling is the development of
general connected to engineering and the management ofreference models concentrating on the functional and or-
enterprises, and a more specic related to software engi-
ganizational aspects of the core business of an enterprise,
neering, enterprise modelling and enterprise architecture.
service organization or government agency. In enter-
In the eld of engineering a more general enterprise prise engineering a business reference model is part of
engineering emerged, dened[25] as the application of an enterprise architecture framework. This framework
10.1. ENTERPRISE MODELLING 115

denes in a series of reference models, how to organize and cooperative decision processes, resource limitations,
the structure and views associated with an Enterprise Ar- environmental and geographical constraints, institutional
chitecture. and legal requirements and purely random uctuations.
A reference model in general is a model of something Economists therefore must make a reasoned choice of
that embodies the basic goal or idea of something and which variables and which relationships between these
can then be looked at as a reference for various purposes. variables are relevant and which ways of analyzing and
A business reference model is a means to describe the presenting this information are useful.
business operations of an organization, independent of
the organizational structure that perform them. Other Ontology engineering
types of business reference model can also depict the re-
lationship between the business processes, business func- Ontology engineering or ontology building is a subeld
tions, and the business areas business reference model. of knowledge engineering that studies the methods and
These reference model can be constructed in layers, and methodologies for building ontologies. In the domain
oer a foundation for the analysis of service components, of enterprise architecture, an ontology is an outline or
technology, data, and performance. a schema used to structure objects, their attributes and
relationships in a consistent manner.[4] As in enterprise
modelling, an ontology can be composed of other ontolo-
Economic modelling
gies. The purpose of ontologies in enterprise modelling is
to formalize and establish the sharability, re-usability, as-
i similation and dissemination of information across all or-
LM ganizations and departments within an enterprise. Thus,
an ontology enables integration of the various functions
and processes which take place in an enterprise.[32]
One common language with well articulated structure and
vocabulary would enable the company to be more e-
cient in its operations. A common ontology will allow
i2
for eective communication, understanding and thus co-
ordination among the various divisions of an enterprise.
There are various kinds of ontologies used in numerous
i1 environments. While the language example given ear-
lier dealt with the area of information systems and design,
IS2 other ontologies may be dened for processes, methods,
activities, etc., within an enterprise.[4]
IS1 Using ontologies in enterprise modelling oers several
Y1 Y2 Y
advantages. Ontologies ensure clarity, consistency, and
structure to a model. They promote ecient model def-
inition and analysis. Generic enterprise ontologies allow
A diagram of the IS/LM model for reusability of and automation of components. Be-
cause ontologies are schemata or outlines, the use of on-
Economic modelling is the theoretical representation of tologies does not ensure proper enterprise model deni-
economic processes by a set of variables and a set of tion, analysis, or clarity. Ontologies are limited by how
logical and/or quantitative relationships between them. they are dened and implemented. An ontology may or
The economic model is a simplied framework designed may not include the potential or capability to capture all
to illustrate complex processes, often but not always using of the aspects of what is being modelled.[4]
mathematical techniques. Frequently, economic models
use structural parameters. Structural parameters are un-
derlying parameters in a model or class of models.[30] A Systems thinking
model may have various parameters and those parameters
may change to create various properties.[31] Main article: Systems thinking
In general terms, economic models have two functions:
rst as a simplication of and abstraction from observed The modelling of the enterprise and its environment
data, and second as a means of selection of data based could facilitate the creation of enhanced understanding
on a paradigm of econometric study. The simplication of the business domain and processes of the extended
is particularly important for economics given the enor- enterprise, and especially of the relationsboth those
mous complexity of economic processes. This complex- that hold the enterprise together and those that extend
ity can be attributed to the diversity of factors that deter- across the boundaries of the enterprise. Since enterprise
mine economic activity; these factors include: individual is a system, concepts used in system thinking[33] can be
116
successfully reused in modelling enterprises.
This way a fast understanding can be achieved throughout
the enterprise about how business functions are working
and how they depend upon other functions in the organi-
zation. [12] Mark S. Fox and Michael Gruninger (1998) "Enterprise
10.1.7 See also
Business process modelling
Enterprise architecture
Enterprise Architecture framework
Enterprise integration
Enterprise life cycle
ISO 19439
Enterprise Data Modeling
10.1.8 References
[1] Paul R. Smith & Richard Sarfaty (1993). Creating a
strategic plan for conguration management using Com-
puter Aided Software Engineering (CASE) tools. Pa-
per For 1993 National DOE/Contractors and Facilities
CAD/CAE Users Group.
[2] Cornelius T. Leondes, Richard Henry Frymuth Jackson
(1992). Manufacturing and Automation Systems: Tech-
niques and Technologies. Academic Press, 1992. ISBN
0-12-012745-8, p.97
[3] F.B. Vernadat (1997). Enterprise Modelling Languages
ICEIMT'97 Enterprise Integration - International Con-
sensus. EI-IC ESPRIT Project 21.859.
[4] James K. Ostie (1996). An Introduction to Enterprise
Modeling and Simulation
[5] E. Aranow (1991). Modeling Exercises Shape Up En-
terprises. In: Software Magazine Vol.11 , p. 36-43
[6] C. J. Ptrie Jr. (1992). Introduction, In: Enterprise In-
tegration Modeling - Proceedings of the First International
Conference MIT Press, p. 563.
[7] Enterprise modeling by Ulrich Frank (2009) at wi-
inf.uni-due.de. Retrieved May 30, 2009.
[8] Young, J. W., and Kent, H. K. (1958). Abstract Formu-
lation of Data Processing Problems. In: Journal of In-
dustrial Engineering. Nov-Dec 1958. 9(6), pp. 471-479
[9] Janis A. Bubenko jr (2007) From Information Alge-
bra to Enterprise Modelling and Ontologies - a Historical
Perspective on Modelling for Information Systems. In:
Conceptual Modelling in Information Systems Engineering.
John Krogstie et al. eds. pp 1-18
[10] Doumeingts, Guy (1984) La Mthode GRAI. PhD. Thesis,
University of Bordeaux I, Bordeaux, France. (In French).
CHAPTER 10. MODELLING
[11] Doumeingts, G., Vallespir, B., Zanettin, M. and Chen, D.
(1992) GIM, GRAI Integrated Methodology - A methodol-
ogy for Designing CIM systems, Version 1.0. Unnumbered
Report, LAP/GRAI, University of Bordeaux I, France
Modeling". American Association for Articial Intelli-
gence.
[13] Naylor, T. (1970) Corporate simulation models and the
economic theory of the rm, in Schrieber, A. (editor)
Corporate simulation models, University of Washing-
ton Press, Seattle, 1970, pp 1-35.
[14] Gershefski, G. (1971) Whats happening in the world of
corporate models?", Interfaces, Vol 1, No 4. p.44
[15] Beer, Staord. (1979) The Heart of Enterprise, Wiley.
[16] FIPS Publication 183 released of IDEF December 1993
by the Computer Systems Laboratory of the National In-
stitute of Standards and Technology (NIST).
[17] Readers Guide to IDEF0 Function Models. Accessed 27
Nov 2008.
[18] Process perspectives. In: Metamodeling and method engi-
neering, Minna Koskinen, 2000.
[19] Whitten, Jerey L.; Lonnie D. Bentley, Kevin C. Dittman.
(2004). Systems Analysis and Design Methods. 6th edi-
tion. ISBN 0-256-19906-X.
[20] Matthew West and Julian Fowler (1999). Developing
High Quality Data Models. The European Process Indus-
tries STEP Technical Liaison Executive (EPISTLE).
[21] Haim Kilov. Business models - A Guide for Business and
IT. Prentice-Hall, 2002.
[22] Frank Lillehagen, John Krogstie (2008). Active Knowl-
edge Modeling of Enterprises. Springer, 2008. ISBN 3-
540-79415-8
[23] Ulrich Frank (2002). "Multi-Perspective Enterprise Mod-
eling (MEMO): Conceptual Framework and Modeling
Languages". In: Proceedings of the Hawaii International
Conference on System Sciences (HICSS-35). Los Alamitos,
CA. Ralph H. Sprague, Jr. (eds.). IEEE Computer Society
Press.
[24] Jan Dietz (2006). Enterprise Ontology - Theory and
Methodology. Springer-Verlag Berlin Heidelberg.
[25] Enterprise Engineering Research at Royal Holloway led
by Dr Alan Pilkington, Ver 9.08. Accessed 4 November
2008.
[26] Vernadat, F.B. (1996) Enterprise Modeling and Integra-
tion: Principles and Applications. Chapman & Hall, Lon-
don, ISBN 0-412-60550-3.
[27] J A Bubenko (1993). Extending the Scope of Informa-
tion Modelling. In: Proceedings of the 4th International
Workshop on the Deductive Approach to Information Sys-
tems and Databases, Costa Brava, Catalonia. 1993.
10.1. ENTERPRISE MODELLING 117

[28] Gustas, R and Gustiene, P (2003) Towards the Enter-

prise engineering approach for Information system mod-
elling across organisational and technical boundaries, in:
Proceedings of the fth International Conference on Enter-
prise Information Systems, vol. 3, Angers, France, 2003,
pp. 77-88.

[29] FEA (2005) FEA Records Management Prole, Version

1.0. December 15, 2005.

[30] Moatt, Mike. (2008) About.com Structural Parameters

Economics Glossary; Terms Beginning with S. Accessed
June 19, 2008.

[31] Moatt, Mike. (2008) About.com Structure Economics

Glossary; Terms Beginning with S. Accessed June 19,
2008.

[32] G. Fadel, M. Fox, M. Gruninger (1994). A Generic En-

terprise Resource Ontology. In: Proceedings of the 3rd
Workshop on Enabling Technologies: Infrastructure for
Collaborative Enterprises. p. 117-128

[33] (see, for example, (Weinberg, 1982), or, more gener-

ally, works by Bunge, for example, (Bunge, 2003) and by
Hayek, for example, (Hayek, 1967))

10.1.9 Further reading

August-Wilhelm Scheer (1992). Architecture of In-
tegrated Information Systems: Foundations of En-
terprise Modelling. Springer-Verlag. ISBN 3-540-
55131-X

Franois Vernadat (1996) Enterprise Modeling and

Integration: Principles and Applications, Chapman
& Hall, London, ISBN 0-412-60550-3

10.1.10 External links

Agile Enterprise Modeling. by S.W. Ambler, 2003-
2008.
Enterprise Modeling Anti-patterns. by S.W. Am-
bler, 2005.
Enterprise Modelling and Information Systems Ar-
chitectures - An International Journal (EMISA) is a
scholarly open access journal with a unique focus on
novel and innovative research on Enterprise Models
and Information Systems Architectures.
Chapter 11

Collaboration

11.1 Business analyst The BA may also support the development of training
material, participates in the implementation, and pro-
A business analyst (BA) is someone who analyzes an vides post-implementation support. This may involve the
organization or business domain (real or hypothetical) and development of project plans and often requires project
documents its business or processes or systems, assessing management skills.
the business model or its integration with technology.
The International Institute of Business Analysis (IIBA) 11.1.2 Typical deliverables
describes the role as a liaison among stakeholders in or-
der to understand the structure, policies, and operations 1. Business requirements, i.e. business plan, key per-
of an organization, and to recommend solutions that en- formance indicator, project plan...
able the organization to achieve its goals.[1]
2. Functional requirements, i.e. logical data models,
The role of a systems analyst can also be dened as a use case scenarios, work instructions, reports...
bridge between the business problems and the technol-
ogy solutions. Here business problems can be anything 3. Non-functional requirements
about business systems, for example the model, process,
or method. The technology solutions can be the use of 4. As-is processes, e.g. dataow diagrams, owcharts
technology architecture, tools, or software application.
5. To-be processes, e.g. dataow diagrams, owcharts
So System Analysts are required to analyze, transform
and ultimately resolve the business problems with the help 6. Data models, i.e. data requirements expressed as a
of technology. documented data model of some sort

7. Business case, a strategic plan containing sharehold-

11.1.1 Areas of business analysis ers risk and return

There are at least four types of business analysis: The BA records requirements in some form of require-
ments management tool, whether a simple spreadsheet or
1. Strategic planning to identify the organizations a complex application. Within the systems development
business needs life cycle, the business analyst typically performs a liai-
son function between the business side of an enterprise
2. Business model analysis to dene the organiza- and the providers of IT services.
tions policies and market approaches

3. Process design to standardize the organizations 11.1.3 Industries

workows
BAs work in dierent industries such as nance, banking,
4. Systems analysis the interpretation of business insurance, telecoms, utilities, software services, govern-
rules and requirements for technical systems (gen- ment and so on. Due to working on projects at a fairly
erally within IT) high level of abstraction, BAs can switch between any and
all industries.
The Business Analyst, sometimes, is someone who is a The business domain subject areas BAs may work in
part of the business operation and works with Information include workow, billing, mediation, provisioning and
Technology to improve the quality of the services being customer relationship management. The telecom indus-
delivered, sometimes assisting in Integration and Testing try has mapped these functional areas in their Telecom-
of new solutions. munications Operational Map (eTOM) model, Banking

118
11.2. SYSTEMS ANALYSIS
in the Information Framework (IFW) and Emergency 11.2.1 Overview
agencies in the Prevention Preparation Response and Re-
covery model (PPRR).
Finally, Business Analysts do not have a predened and
xed role, as they can take a shape in operations scaling,
sales planning, strategy devising or even in developmental
process.
11.1.4 See also
Business process reengineering
Change management analyst analysis is used in every eld where something is devel-
Information technology perform organic functions together, such as system engi-
International Institute of Business Analysis
Systems architect projects should be designed and managed.
Systems analyst
Use case
11.1.5 References
[1] International Institute of Business Analysis (IIBA). A
Guide to the Business Analysis Body of Knowledge, 2.0
(BABOK Guide 2). Cited in: Jerry Lee Jr. Ford (2010),
UML for the IT Business Analyst. p. 2
11.2 Systems analysis
This article is about the interdisciplinary eld. For the
analysis of systems in electrical engineering, see system
analysis.
The Merriam-Webster dictionary denes system analy-
sis as the process of studying a procedure or business
in order to identify its goals and purposes and create
systems and procedures that will achieve them in an ef-
cient way. Another view sees system analysis as a
problem-solving technique that decomposes a system into
its component pieces for the purpose of the studying how
well those component parts work and interact to accom-
plish their purpose.[1] Analysis and synthesis, as scientic
methods, always go hand in hand; they complement one
another. Every synthesis builds upon the results of a pre-
ceding analysis, and every analysis requires a subsequent
synthesis in order to verify and correct its results.
The eld of system analysis relates closely to
requirements analysis or to operations research. It
is also an explicit formal inquiry carried out to help a
decision maker identify a better course of action and
make a better decision than she might otherwise have
made.[2]
119
The terms analysis and synthesis stem from Greek, mean-
ing to take apart and to put together, respectively.
These terms are used in many scientic disciplines, from
mathematics and logic to economics and psychology, to
denote similar investigative procedures. Analysis is de-
ned as the procedure by which we break down an in-
tellectual or substantial whole into parts, while synthesis
means the procedure by which we combine separate ele-
ments or components in order to form a coherent whole.
[3]
System analysis researchers apply methodology to the
systems involved, forming an overall picture. System
oped. Analysis can also be a series of components that
neering. System engineering is an interdisciplinary eld
of engineering that focuses on how complex engineering
11.2.2 Information technology
The development of a computer-based information sys-
tem includes a system analysis phase. This helps produce
the data model, a precursor to creating or enhancing a
database. There are a number of dierent approaches
to system analysis. When a computer-based information
system is developed, system analysis (according to the
Waterfall model) would constitute the following steps:
The development of a feasibility study: determining
whether a project is economically, socially, techno-
logically and organizationally feasible
Fact-nding measures, designed to ascertain the re-
quirements of the systems end-users (typically in-
volving interviews, questionnaires, or visual obser-
vations of work on the existing system)
Gauging how the end-users would operate the sys-
tem (in terms of general experience in using com-
puter hardware or software), what the system would
be used for and so on
Another view outlines a phased approach to the process.
This approach breaks system analysis into 5 phases:
Scope Denition: denoting an instrument for ob-
serving, viewing, or examining
Problem analysis: analyzing the problem that arises
Requirements analysis: determining the conditions
that need to be met
Logical design: looking at the logical relationship
among the objects
Decision analysis: making a nal decision
120
Use cases are widely used system analysis modeling tools
for identifying and expressing the functional require-
ments of a system. Each use case is a business scenario
or event for which the system must provide a dened re-
sponse. Use cases evolved from object-oriented analysis.
11.2.3 Policy analysis
The discipline of what is today known as policy analysis
originated from the application of system analysis when it
was rst instituted by United States Secretary of Defense
Robert McNamara.
11.2.4 Practitioners
Practitioners of system analysis are often called up to dis-
sect systems that have grown haphazardly to determine
the current components of the system. This was shown
during the year 2000 re-engineering eort as business Template:System Engineering
and manufacturing processes were examined as part of
the Y2K automation upgrades.[4] Employment utilizing
system analysis include system analyst, business analyst,
manufacturing engineer, system architect, enterprise ar- 11.3 Information architecture
chitect, software architect, etc.
While practitioners of system analysis can be called upon
to create new systems, they often modify, expand or
document existing systems (processes, procedures and
methods). Researchers and practitioners rely on system
analysis. Activity system analysis has been already ap-
plied to various research and practice studies including
business management, educational reform, educational
technology, etc.
11.2.5 See also
11.2.6 References
[1] System Analysis and Design for the Global Enterprise by the Information Architecture Institute.[3]
Lonnie D. Bentley p.160 7th edition
[2] SYSTEMS ANALYSIS
[3] Tom Ritchey, Analysis and Synthesis.
[4] Gza HUSI: Mechatronics Control Systems
Chess analyst
11.2.7 Selected publications
Bentley, Lonnie D., Kevin C. Dittman, and Jerey
L. Whitten. System analysis and design methods.
(1986, 1997, 2004).
Hawryszkiewycz, Igor T. Introduction to system
analysis and design. Prentice Hall PTR, 1994.
CHAPTER 11. COLLABORATION
Whitten, Jeery L., Lonnie D. Bentley, and Kevin
C. Dittman. Fundamentals of system analysis and
design methods. (2004).
11.2.8 External links
Introduction to Social Macrodynamics
A useful set of guides and a case study about the
practical application of business and system analysis
methods
A comprehensive description of the discipline of
system analysis from Simmons College, Boston,
MA, USA (Archive of original from www.simmons.
edu)
System Analysis and Design introductory level
lessons
Information architecture (IA) is the structural design
of shared information environments; the art and science
of organizing and labelling websites, intranets, online
communities and software to support usability and nd-
ability; and an emerging community of practice focused
on bringing principles of design and architecture to the
digital landscape.[1] Typically, it involves a model or
concept of information that is used and applied to activi-
ties which require explicit details of complex information
systems. These activities include library systems and
database development.
Information architecture is considered to have been
founded by Richard Saul Wurman.[2] Today there is a
growing network of active IA specialists who constitute
11.3.1 Denition
Information architecture has somewhat dierent mean-
ings in dierent branches of Information systems or
Information technology:
1. The structural design of shared information
environments.[4]:4
2. The art and science of organizing and labeling web
sites, intranets, online communities, and software to
support ndability and usability.[1][5]
3. An emerging community of practice focused on
bringing principles of design and architecture to the
digital landscape.[4]:4[6]
11.3. INFORMATION ARCHITECTURE 121

4. The combination of organization, labeling, search Pioneers

and navigation systems within websites and
intranets.[4]:4 Richard Saul Wurman

5. Extracting required parameters/data of Engineering Peter Morville

Designs in the process of creating a knowledge-base
Louis Rosenfeld
linking dierent systems and standards.

6. A blueprint and navigational aid to the content of First generation

information-rich systems. [7]
Jorge Arango
7. A subset of data architecture where usable data
(a.k.a. information) is constructed in and designed Jesse James Garrett
or arranged in a fashion most useful or empirically
holistic to the users of this data. Adam Greeneld

Peter Merholz
8. The practice of organizing the information / content
/ functionality of a web site so that it presents the best Eric Reiss
user experience it can, with information and services
being easily usable and ndable (as applied to web Donna Spencer
design and development).[8]
Thomas Vander Wal

Christina Wodtke
Debate

The diculty in establishing a common denition for Second generation

information architecture arises partly from the terms
existence in multiple elds. In the eld of systems de- Abby Covert
sign, for example, information architecture is a compo-
nent of enterprise architecture that deals with the infor- Nick Finck
mation component when describing the structure of an Andrew Hinton
enterprise.
While the denition of information architecture is rela- Dan Klyn
tively well-established in the eld of systems design, it is Andrea Resmini
much more debatable within the context of online infor-
mation systems (i.e., websites). Andrew Dillon refers to
the latter as the big IAlittle IA debate.[9] In the little IA Inuencers
view, information architecture is essentially the applica-
tion of information science to web design which consid- David Weinberger
ers, for example, issues of classication and information
retrieval. In the big IA view, information architecture in-
volves more than just the organization of a website; it also 11.3.4 See also
factors in user experience, thereby considering usability
issues of information design. Applications architecture

Card sorting

11.3.2 Information architect Chief experience ocer

About the term information architect Richard Saul Content management

Wurman wrote: I mean architect as used in the words ar- Content strategy
chitect of foreign policy. I mean architect as in the creat-
ing of systemic, structural, and orderly principles to make Controlled vocabulary
something work the thoughtful making of either arti-
fact, or idea, or policy that informs because it is clear.[10] Data management

Data presentation architecture

11.3.3 Notable people in information ar- Digital humanities
chitecture
Ecological interface design
122
Enterprise information security architecture
Faceted classication
Human factors and ergonomics
Informatics
Interaction design
Process architecture
Site map
Social information architecture
Tree testing
User experience design
Visualization (graphics) Knowledge visualization
Waynding
Web graph
Web literacy (Infrastructure)
11.3.5 References
[1] What is IA?" (PDF). Information Architecture Institute.
[2] Richard Saul Wurman awarded for Lifetime Achieve-
ment. Smithsonian Cooper-Hewitt, National Design
Museum. Retrieved 19 April 2014.
[3] Join the IA Network. Information Architecture Insti-
tute.
[4] Morville & Rosenfeld 2007.
[5] Morville & Rosenfeld (2007). p. 4. The art and sci-
ence of shaping information products and experienced to
support usability and ndability.
[6] Resmini, A. & Rosati, L. (2012). A Brief History of In-
formation Architecture. Journal of Information Archi-
tecture. Vol. 3, No. 2. [Available at http://journalofia.
org/volume3/issue2/03-resmini/]. Originally published
in Resmini, A. & Rosati L. (2011). Pervasive Information
Architecture. Morgan Kauman. (Edited by the authors).
[7] Toms, Elaine (17 May 2012). Information interac-
tion: Providing a framework for information architec-
ture. Journal of the American Society for Information
Science and Technology. 53 (10.1002/asi.10094).
[8] Information Architecture. Mozilla Developer Network. solution development team, the solution architect trans-
[9] Dillon, A (2002). Information Architecture in JASIST: architecture for that solution and describing it through
Just where did we come from?". Journal of the American
Society for Information Science and Technology. 53 (10):
82123. doi:10.1002/asi.10090.
[10] Wurman, Introduction, in: Information Architects volves selecting the most appropriate technology for the
(1997). p. 16.
CHAPTER 11. COLLABORATION
11.3.6 Bibliography
Wurman, Richard Saul, ed. (1997). Information Ar-
chitects (1st ed.). Graphis Inc. ISBN 1-888-00138-
0.
Morville, Peter; Rosenfeld, Louis (2007).
Information architecture for the World Wide
Web (3rd ed.). Sebastopol, CA: O'Reilly &
Associates. ISBN 0-596-52734-9.
Brown, Peter (2003). Information Architecture with
XML (1st ed.). John Wiley & Sons Ltd. ISBN 0-
471-48679-5.
Wodtke, Christina (2009). Information Architecture
- Blueprints for the Web (2nd ed.). New Riders.
ISBN 0-321-60080-0.
Resmini, Andrea; Rosati, Luca (2011). Pervasive
Information Architecture - Designing Cross-channel
User Experiences (1st ed.). Morgan Kauman.
ISBN 0-123-82094-4.
11.3.7 Further reading
Wei Ding; Xia Lin (15 May 2009). Information
Architecture: The Design and Integration of Infor-
mation Spaces. Morgan & Claypool. ISBN 978-1-
59829-959-5.
Sue Batley (January 2007). Information Architec-
ture for Information Professionals. Woodhead Pub-
lishing. ISBN 978-1-84334-233-5.
Earl Morrogh (2003). Information Architecture: An
Emerging 21st Century Profession. Prentice Hall.
ISBN 9780130967466.
Peter Van Dijck (August 1, 2003). Information
Architecture for Designers: Structuring Web-
sites for Business Success. Rotovision. ISBN
9782880467319.
Alan Gilchrist; Barry Mahon (2004). Information
Architecture: Designing Information Environments
for Purpose. Facet. ISBN 9781856044875.
11.4 Solutions Architect
A solution architect, in information technology, is a
practitioner of solution architecture. Typically part of the
lates requirements created by functional analysts into the
architecture and design artifacts. The rest of the devel-
opment team then uses those artifacts to implement the
solution. The solution architects process typically in-
problem.[1][2]
11.5. SOFTWARE ARCHITECT 123

11.4.1 Overview of the role sourced. Both may employ a solution architect to govern
an implementation project, or play a leading role within
An individual performing the role of a solution architect it.
focuses on converting requirements into the architecture
and design that ultimately constitute the blueprint for the
solution. In that process, the solution architect usually re- 11.4.3 References
lies on design patterns from their previous engagements,
published reference architectures, and on guidance from [1] Breaking Down Software Development Roles, an Inter-
enterprise architecture. In their eorts, solution archi- net.com Developer eBook, 2006 Jupitermedia Corp.
tects balance architectural concerns of the projects with [2] R. Bogue Anatomy of a Software Development Role:
the concerns of the enterprise.[1][2][3] Solution Architect, [online] Available: http://www.
The solution architect is often the development team developer.com/mgmt/article.php/3504496
leader. As such, they are often expected to provide moti- [3] Mistrk Ivan, Antony Tang, Rami Bahsoon, Judith A.
vation and guidance to the entire development team dur- Staord. (2013), Aligning Enterprise, System, and Soft-
ing the systems development life cycle. The solution ar- ware Architectures. Business Science Reference.
chitect must ensure buy-in from the development team,
so that the team is motivated to match the detailed design
of the solution to the higher-level architecture.[1][2]
11.5 Software architect
Solution architects play an important role in ensuring that
the solution architecture aligns with the roadmaps estab-
A software architect is a software expert who makes
lished by the enterprise architecture, and that it adheres
high-level design choices and dictates technical standards,
to the enterprise architecture principles. Solution archi-
including software coding standards, tools, and platforms.
tects are both a consumer and contributor to enterprise
The leading expert is referred to as the chief architect.
architecture collateral. Often, the patterns and guidance
solution architects develop becomes reusable in a broader
enterprise architecture context.[3] 11.5.1 History
The software architect concept began to take hold when
11.4.2 Solution architects vs. enterprise object-oriented programming (OOP) was coming into
architects more widespread use (in the late 1990s and early years
of the 21st century). OOP allowed ever-larger and more
Solution architects in large organizations often act as the complex applications to be built, which in turn required
bridge between [architecture] and applications architec- increased high-level application and system oversight.
ture.
An enterprise architects deliverables are usually more ab-
11.5.2 Responsibilities
stract than a solution architects, but not always. The main
distinction between the two lies in their dierent goals.
The main responsibilities of a software architect include:
The enterprise architect is primarily employed to design,
plan, and govern strategic and cross-organisational ratio-
nalization or optimization of an enterprises services, pro- Limit choices available during development by
cesses, or components. The solution architect primarily
helps programmers and project managers in the design, choosing a standard way of pursuing
planning, and governance of projects of any kind. application development
A solution architect may have a reporting line to an enter- creating, dening, or choosing an
prise architect, but the inuence the enterprise architect application framework for the applica-
team has on solution architects depends on an organisa- tion
tions policies and management structure. So, the extent
to which a solution architects work derives from an en- Recognize potential reuse in the organization or in
terprise architects road maps vary from 0 to 100 percent. the application by
Where the solution architect starts and stops depends on
the funding model for the process of solution identica- observing and understanding the broader
tion and delivery. For example, an enterprise may employ system environment
a solution architect on a feasibility study, or to prepare a
solution vision or solution outline for an invitation to ten- creating the component design
der. A supplier may employ a solution architect at bid having knowledge of other applications in
time, before any implementation project is costed or re- the organization
124 CHAPTER 11. COLLABORATION

Subdivide a complex application, during the design
phase, into smaller, more manageable pieces
Grasp the functions of each component within the
application
Understand the interactions and dependencies
among components
Communicate these concepts to developers
System architect (singular), which is often used as a
synonym for application architect. However, if one
subscribes to Systems theory and the idea that an
enterprise can be a system, then System Architect
could also mean Enterprise Architect.
Systems architect (plural), which is often used as a
synonym for enterprise architect or solution archi-
tect.

The table below indicates many of the dierences be-

In order to perform these responsibilities eectively, soft-
ware architects often use tools or standardized model and
symbol sets such as Unied Modeling Language(UML)
and OOP to represent systems or develop artifacts. UML
has become an important tool for software architects to
use in communicating the overall system design to devel-
opers and other team members, comparable to the draw-
ings made by building architects.
11.5.3 Duties
The role of software architect generally has certain com-
mon traits:
Architects make high-level design choices much more of-
ten than low-level choices. In addition, the architect may
sometimes dictate technical standards, including coding
standards, tools, or platforms.
Software architects may also be engaged in the design of
the architecture of the hardware environment, or may fo-
cus entirely on the design methodology of the code.
Architects can use various software architectural models
that specialize in communicating architecture.
tween various kinds of software architects:
In the software industry, as the table above suggests, the
various versions of architect do not always have the same
goals.[1]
11.5.5 See also
Systems architecture / systems architect
Software architectural model
Software architecture
Hardware architecture / hardware architect
Systems engineering / systems engineer
Software engineering / software engineer
Requirements analysis / requirements engineer
Systems design
Electrical engineering
Electronics engineering

11.5.4 Other types of IT-related architects

11.5.6 References
The enterprise architect handles the interaction between
the business and IT sides of an organization and is [1] Anecdote about an interaction between Solution and En-
principally involved with determining the AS-IS and terprise Architect
TO-BE states from a business and IT process perspec-
tive. UnfortunatelyDubious - discuss. many organizations are
bundling the software architect duties within the role of 11.5.7 External links
Enterprise Architecture. This is primarily done as an ef-
International Association of Software Architects
fort to up-sell the role of a software architect and/or to
(IASA)
merge two disparate business-related disciplines to avoid
overhead.
An application architect works with a single software ap-
plication.
11.6 Systems architect
Other similar titles in use, but without consensus on their The systems architect is a professional gure in
exact meaning, include: information and communications technology. Systems
architects dene the architecture of a computerized sys-
Solution architect, which may refer to a person di- tem (i.e., a system composed of software and hardware)
rectly involved in advancing a particular business so- in order to fulll certain requirements. Such denitions
lution needing interactions between multiple appli- include: a breakdown of the system into components, the
cations. May also refer to an application architect. component interactions and interfaces (including with the
11.6. SYSTEMS ARCHITECT 125

environment, especially the user), and the technologies requirements into discrete partitions such that a
and resources to be used in the design. minimum of communications is needed among
The Systems Architects work must avoid implementation partitions, and between the user and the system.
issues and readily permit unanticipated exten- Partitioning large systems into (successive layers of)
sions/modications in future stages. Because of the subsystems and components each of which can be
extensive experience required for this, the Systems handled by a single engineer or team of engineers or
Architect is typically a very senior technician with sub- subordinate architect.
stantial, but general, knowledge of hardware, software,
and similar systems. But above all, the systems architect Interfacing with the design and implementation en-
must be reasonably familiar with the users domain of gineers and architects, so that any problems arising
experience (that is, the architect of an air trac system during design or implementation can be resolved in
needs to be more than supercially familiar with all of accordance with the fundamental design concepts,
the tasks of an air trac system, including those of all and user needs and constraints.
levels of users).
Ensuring that a maximally robust design is devel-
oped.
11.6.1 Overview
Generating a set of acceptance test requirements, to-
Systems Architects interface with multiple stakeholders gether with the designers, test engineers, and the
in an organization in order to understand the various lev- user, which determine that all of the high level
els of requirements, the domain, the viable technolo- requirements have been met, especially for the
gies, and anticipated development. Their work includes computer-human-interface.
determining multiple design alternatives, assessing such
Generating products such as sketches, models, an
alternatives based on all identied constraints (such as
early user guide, and prototypes to keep the user and
cost, schedule, space, power, safety, usability, reliabil-
the engineers constantly up to date and in agreement
ity, maintainability, availability, and so on), and selecting
on the system to be provided as it is evolving.
the most suitable options for further design. The output
of such work sets the core properties of the system, and Ensuring that all architectural products and products
those that are hardest to change later. with architectural input are maintained in the most
In small systems the architecture is typically dened di- current state and never allowed to become obsolete.
rectly by developers. In larger systems, a Systems Ar-
chitect may be appointed to outline the overall system
and interface with the users and stakeholders. Very large, 11.6.2 Systems architect: topics
highly complex systems may include multiple architects,
in which case the architects work together to integrate Large systems architecture was developed as a way to
their subsystems or aspects, and may respond to a Chief handle systems too large for one person to conceive of,
Architect responsible for the entire system. let alone design. Systems of this size are rapidly becom-
ing the norm, so architectural approaches and architects
In systems design, the architects and engineers are re- are increasingly needed to solve the problems of large sys-
sponsible for: tems. In general, increasingly large systems are reduced
to 'human' proportions by a layering approach, where
Interfacing with the user(s) and sponsor(s) and all each layer is composed of a number of individually com-
other stakeholders in order to determine their (evolv- prehensible sub-layers-- each having its own principal en-
ing) needs. gineer and/or architect. A complete layer at one level will
Generating the highest level of system requirements, be shown as a functional 'component' of a higher layer.
based on the users needs and other constraints.
Ensuring that this set of high level requirements is Users and sponsors
consistent, complete, correct, and operationally de-
ned. Architects are expected to understand human needs and
develop humanly functional and aesthetically pleasing
Performing costbenet analyses to determine products. A good architect is also the principal keeper of
whether requirements are best met by manual, soft- the users vision of the end product and of the process
ware, or hardware functions; making maximum use of deriving requirements from and implementing that vi-
of commercial o-the-shelf or already developed sion.
components.
Architects do not follow exact procedures. They commu-
Developing partitioning algorithms (and other nicate with users/sponsors in a highly interactive way
processes) to allocate all present and foreseeable together they extract the true requirements necessary for
126 CHAPTER 11. COLLABORATION

the designed system. The architect must remain con- tion space, whereas the user may be thinking in terms of
stantly in communication with the end users and with the solving a problem of getting people from point A to point
(principal) systems engineers. Therefore, the architect B in a reasonable amount of time and with a reasonable
must be intimately familiar with the users environment expenditure of energy, or of getting needed information
and problem, and with the engineering environment(s) of to customers and sta. A systems architect is expected to
likely solution spaces. combine knowledge of both the architecture of the users
world and of (all potentially useful) engineering systems
architectures. The former is a joint activity with the user;
High level requirements the latter is a joint activity with the engineers. The prod-
uct is a set of high level requirements reecting the users
The user requirements specication should be a joint requirements which can be used by the engineers to de-
product of the user and designer: the user brings his needs velop systems design requirements.
and wish list, the architect brings knowledge of what is
likely to prove doable within cost, time and other con- Because requirements evolve over the course of a project,
straints. When the user needs are translated into a set of especially a long one, an architect is needed until the sys-
high level requirements is also the best time to write the tem is accepted by the user: the architect ensures that
rst version of the acceptance test, which should, there- all changes and interpretations made during the course of
after, be religiously kept up to date with the requirements. development do not compromise the users viewpoint.
That way, the user will be absolutely clear about what s/he
is getting. It is also a safeguard against untestable require-
Cost/benet analyses
ments, misunderstandings, and requirements creep.
The development of the rst level of engineering require- Architects are generalists. They are not expected to be
ments is not a purely analytical exercise and should also experts in any one technology but are expected to be
involve both the architect and engineer. If any compro- knowledgeable of many technologies and able to judge
mises are to be made to meet constraints- the archi- their applicability to specic situations. They also ap-
tect must ensure that the nal product and overall look ply their knowledge to practical situations, but evaluate
and feel do not stray very far from the users intent. The the cost/benets of various solutions using dierent tech-
engineer should focus on developing a design that opti- nologies, for example, hardware versus software versus
mizes the constraints but ensures a workable and reli- manual, and assure that the system as a whole performs
able product. The provision of needed services to the according to the users expectations.
user is the true function of an engineered system. How-
Many commercial-o-the-shelf or already developed
ever, as systems become ever larger and more complex,
hardware and software components may be selected in-
and as their emphases move away from simple hardware
dependently according to constraints such as cost, re-
and software components, the narrow application of tra-
sponse, throughput, etc. In some cases, the architect
ditional systems development principles has been found
can already assemble the end system unaided. Or, s/he
to be insucient the application of more general prin-
may still need the help of a hardware or software en-
ciples of systems, hardware, and software architecture to
gineer to select components and to design and build
the design of (sub)systems is seen to be needed. An ar-
any special purpose function. The architects (or engi-
chitecture may also be seen as a simplied model of the
neers) may also enlist the aid of other specialists in
nished end product its primary function is to dene
safety, security, communications, special purpose hard-
the parts and their relationships to each other so that the
ware, graphics, human factors, test and evaluation, quality
whole can be seen to be a consistent, complete, and cor-
control, reliability, maintainability, availability, interface
rect representation of what the user had in mind espe-
management, etc. An eective systems architectural
cially for the computer-human-interface. It is also used to
team must have access to specialists in critical speciali-
ensure that the parts t together and relate in the desired
ties as needed.
way.
It is necessary to distinguish between the architecture of
the users world and the engineered systems architecture. Partitioning and layering
The former represents and addresses problems and solu-
tions in the users world. It is principally captured in the An architect planning a building works on the overall de-
computer-human-interfaces (CHI) of the engineered sys- sign, making sure it will be pleasing and useful to its in-
tem. The engineered system represents the engineering habitants. While a single architect by himself may be
solutions how the engineer proposes to develop and/or enough to build a single-family house, many engineers
select and combine the components of the technical in- may be needed, in addition, to solve the detailed problems
frastructure to support the CHI. In the absence of an ex- that arise when a novel high-rise building is designed. If
perienced architect, there is an unfortunate tendency to the job is large and complex enough, parts of the architec-
confuse the two architectures. But the engineer thinks ture may be designed as independent components. That
in terms of hardware and software and the technical solu- is, if we are building a housing complex, we may have
11.6. SYSTEMS ARCHITECT 127

one architect for the complex, and one for each type of cuss dierent solutions and results with users, engineers,
building, as part of an architectural team. and other architects. An early, draft version of the users
Large automation systems also require an architect and manual is invaluable, especially in conjunction with a pro-
much engineering talent. If the engineered system is large totype. Nevertheless, it is important that a workable, well
and complex enough, the systems architect may defer to written set of requirements, or specication, be created
a hardware architect and a software architect for parts of which is reasonably understandable to the customer (so
the job, although they all may be members of a joint ar- that they can properly sign o on it, but the principal
chitectural team. user requirements should be captured in a preliminary
user manual for intelligibility). But it must use precise
The architect should sub-allocate the system require- and unambiguous language so that designers and other
ments to major components or subsystems that are within implementers are left in no doubt as to meanings or inten-
the scope of a single hardware or software engineer, or tions. In particular, all requirements must be testable, and
engineering manager and team. But the architect must the initial draft of the test plan should be developed con-
never be viewed as an engineering supervisor. (If the item temporaneously with the requirements. All stakehold-
is suciently large and/or complex, the chief architect ers should sign o on the acceptance test descriptions,
will sub-allocate portions to more specialized architects.) or equivalent, as the sole determinant of the satisfaction
Ideally, each such component/subsystem is a suciently of the requirements, at the outset of the program.
stand-alone object that it can be tested as a complete
component, separate from the whole, using only a sim-
ple testbed to supply simulated inputs and record outputs. 11.6.3 Architect metaphor
That is, it is not necessary to know how an air trac con-
trol system works in order to design and build a data man- The use of any form of the word 'architect' is regulated
agement subsystem for it. It is only necessary to know the by 'title acts in many states in the US, and a person must
constraints under which the subsystem will be expected to be licensed as a building architect to use it.[1]
operate. In the UK the architects registration board excludes the
A good architect ensures that the system, however com- usage of architect (when used in context of software and
plex, is built upon relatively simple and clean concepts IT) from its restricted usage. [2]
for each (sub)system or layer and is easily understandable
by everyone, especially the user, without special training.
The architect will use a minimum of heuristics to ensure 11.6.4 See also
that each partition is well dened and clean of kludges,
work-arounds, short-cuts, or confusing detail and excep- Enterprise architecture
tions. As user needs evolve, (once the system is elded Enterprise architect
and in use), it is a lot easier subsequently to evolve a sim-
ple concept than one laden with exceptions, special cases, Hardware architecture
and lots of ne print.
Requirements analysis
Layering the architecture is important for keeping the ar-
chitecture suciently simple at each layer so that it re- Software architecture
mains comprehensible to a single mind. As layers are
Software engineering
ascended, whole systems at lower layers become simple
components at the higher layers, and may disappear alto- Systems architecture
gether at the highest layers.
Systems modeling

Acceptance test Systems engineering

The acceptance test is a principal responsibility of the sys-
tems architect. It is the chief means by which the pro-
gram lead will prove to the user that the system is as orig-
inally planned and that all involved architects and engi-
neers have met their objectives.
Communications with users and engineers
A building architect uses sketches, models, and drawings.
An automation systems (or software or hardware) archi-
tect should use sketches, models, and prototypes to dis-
Systems design
Business analyst
Service-oriented modeling framework (SOMF)
11.6.5 References
[1] The term architect is a professional title protected by
law and restricted, in most of the worlds jurisdictions, to
those who are trained in the planning, design and super-
vision of the construction of buildings. In these jurisdic-
tions, anyone who is not a licensed architect is prohibited
128 CHAPTER 11. COLLABORATION

from using this title in any way. In the State of New York, A project manager is a professional in the eld of project
and in other US states, the unauthorized use of the title management. Project managers have the responsibility of
architect is a crime and is subject to criminal proceed- the planning, procurement and execution of a project, in
ings.Architecture: Whats Legal, Whats Not (PDF). any domain of engineering. Project managers are rst
AIA New York State. Retrieved 9 July 2012.NYS point of contact for any issues or discrepancies arising
Architecture:Laws, Rules & Regulations:Article 147 Ar-
from within the heads of various departments in an orga-
chitecture. Retrieved 9 July 2012.
nization before the problem escalates to higher authori-
[2] What we do to regulate use of the title 'architect'". Ar- ties. Project management is the responsibility of a project
chitects Registration Board. Retrieved 1 December 2015. manager. This individual seldom participates directly in
the activities that produce the end result, but rather strives
to maintain the progress, mutual interaction and tasks of
11.6.6 Further reading various parties in such a way that reduces the risk of over-
all failure, maximizes benets, and minimizes costs.
Donald Firesmith et al.: The Method Framework for
Engineering System Architectures, (2008)
11.7.1 Overview
Mark W. Maier and Rechtin, Eberhardt, The Art of
Systems Architecting, Third Edition (2009) A project manager is the person responsible for accom-
Gerrit Muller, Systems architecting: A business plishing the project objectives. Key project management
perspective, CRC Press, (2012). responsibilities include

Eberhardt Rechtin, Systems Architecting: Creating &
Building Complex Systems, 1991.
J. H. Saltzer, M. F. Kaashoek, Principles of Com-
puter System Design: An Introduction, Morgan Kauf-
mann, 2009.
Rob Williams, Computer Systems Architecture: a
Networking Approach, Second Edition (December
2006).
dening and communicating project objectives that
are clear, useful and attainable
procuring the project requirements like workforce,
required information, various agreements and mate-
rial or technology needed to accomplish project ob-
jectives
managing the constraints of the project management
triangle, which are cost, time, scope and quality

A project manager is a client representative and has to

11.6.7 External links determine and implement the exact needs of the client,
based on knowledge of the organization they are rep-
Principles of Computer System Design: An Intro-
resenting. An expertise is required in the domain the
duction MIT OpenCourseWare
Project Managers are working to eciently handle all the
Systems Architecture : Canaxia Brings an Architect aspects of the project. The ability to adapt to the various
on Board, Article. internal procedures of the client and to form close links
with the nominated representatives, is essential in ensur-
ing that the key issues of cost, time, quality and above all,
client satisfaction, can be realized.
11.7 Project manager
11.7.2 Project Management Key Topics
to specify the reason why a project is important
to specify the quality of the deliverables
resource estimate
timescale
Investment, corporate agreement and funding
Implementation of management plan on to the
project
team building and motivation
US Navy 080111-N-8273J-033 Chief of Naval Operations
(CNO) Adm. Gary Roughead talks with project managers risk assessments and change in the project
11.7. PROJECT MANAGER 129

monitoring of the CCM is to standardize the education, experi-

ence and professional understanding needed to prac-
stakeholder management tice construction management at the highest level.
provider management
The Project Management Institute has made some
closing the project.[1]
headway into being a standardizing body with its
creation of the Project Management Professional
(PMP) designation.
Project Tools The tools, knowledge and techniques for
managing projects are often unique to Project Man- The Constructor Certication Commission of the
agement. For example: work breakdown structures, American Institute of Constructors holds semian-
critical path analysis and earned value management. nual nationwide tests. Eight American Construction
Understanding and applying the tools and techniques Management programs require that students take
which are generally recognized as good practices are these exams before they may receive their Bachelor
not sucient alone for eective project manage- of Science in Construction Management degree, and
ment. Eective project management requires that 15 other Universities actively encourage their stu-
the project manager understands and uses the knowl- dents to consider the exams.
edge and skills from at least four areas of expertise.
Examples are PMBOK, Application Area Knowl-
The Associated Colleges of Construction Educa-
edge: standards and regulations set forth by ISO for
tion, and the Associated Schools of Construction
project management, General Management Skills
have made considerable progress in developing na-
and Project Environment Management[2] There are
tional standards for construction education pro-
also many options for project management software
grams.
to assist in executing projects for the project man-
ager and his/her team.
The profession has recently grown to accommodate sev-
Project Teams When recruiting and building an eec- eral dozen Construction Management Bachelor of Sci-
tive team, the manager must consider not only the ence programs. Many universities have also begun of-
technical skills of each person, but also the criti- fering a masters degree in Project Management. These
cal roles and chemistry between workers. A project programs generally are tailored to working profession-
team has mainly three separate components: Project als who have project management experience or project
Manager, Core Team and Contracted Team. related experience; they provide a more intense and in
depth education surrounding the knowledge areas within
Risk Most of the project management issues that inu- the project management body of knowledge.
ence a project arise from risk, which in turn arises The United States Navy construction battalions, nick-
from uncertainty. The successful project manager named the SeaBees, puts their command through stren-
focuses on this as his/her main concern and attempts uous training and certications at every level. To become
to reduce risk signicantly, often by adhering to a a Chief Petty Ocer in the SeaBees is equivalent to a
policy of open communication, ensuring that project BS in Construction Management with the added benet
participants can voice their opinions and concerns. of several years of experience to their credit. See ACE
accreditation.
11.7.3 Types of Project Managers
Construction Project Manager Architectural Project Manager

Until recently, the American construction industry lacked

Architectural project manager are project managers in the
any level of standardization, with individual States deter-
eld of architecture. They have many of the same skills
mining the eligibility requirements within their jurisdic-
as their counterpart in the construction industry. And will
tion. However, several Trade associations based in the
often work closely with the construction project manager
United States have made strides in creating a commonly
in the oce of the General Contractor (GC), and at the
accepted set of qualications and tests to determine a
same time, coordinate the work of the design team and
project managers competency. numerous consultants who contribute to a construction
project, and manage communication with the client. The
The Construction Management Association of issues of budget, scheduling, and quality-control are the
America (CMAA) maintains the Certied Con- responsibility of the Project Manager in an architects of-
struction Manager (CCM) designation. The purpose ce.
130 CHAPTER 11. COLLABORATION

Insurance Claim Project Manager the Project Management Professional (PMP) designation
oered by the Project Management Institute, PRINCE2
In the insurance industry project managers often oversee or an advanced degree in project management, such as a
and manage the restoration of a clients home/oce after MSPM or other graduate degree in technology manage-
a re, ood. Covering the elds from electronics through ment.
to the demolition and constructions contractors.

Engineering Project Manager
In Engineering project management is the term used to
describe the task of seeing a product/device through the
stages of R&D/design to manufacturing stages. Work-
ing with various professionals in dierent elds of engi-
neering and manufacturing to go from concept to nished
product. Optionally, this can include dierent versions
and standards as required by dierent countries. Requir-
ing knowledge of laws, requirements and infrastructure.
Things like electrical voltages often change from country
to country.
Software Project Manager
11.7.4 Responsibilities
The Project Manager is accountable for ensuring that ev-
eryone on the team knows and executes his or her role,
feels empowered and supported in the role, knows the
roles of the other team members and acts upon the belief
that those roles will be performed.[3] The specic respon-
sibilities of the Project Manager may vary depending on
the industry, the company size, the company maturity,
and the company culture. However, there are some re-
sponsibilities that are common to all Project Managers,
noting:[4]
Developing the project plans
Managing the project stakeholders

A Software Project Manager has many of the same skills Managing communication
as their counterparts in other industries. Beyond the skills
normally associated with traditional project management Managing the project team
in industries such as construction and manufacturing, a Managing the project risk
software project manager will typically have an exten-
sive background in software development. Many soft- Managing the project schedule
ware project managers hold a degree in Computer Sci-
ence, Information Technology, Management of Informa- Managing the project budget
tion Systems or another related eld.
Managing the project conicts
In traditional project management a heavyweight, pre-
dictive methodology such as the waterfall model is of- Managing the project delivery
ten employed, but software project managers must also be
skilled in more lightweight, adaptive methodologies such
as DSDM, Scrum and XP. These project management 11.7.5 Education and Certications
methodologies are based on the uncertainty of developing
a new software system and advocate smaller, incremental Individuals wishing to obtain professional certications
development cycles. These incremental or iterative cy- may take one or more of the oerings available from a
cles are time boxed (constrained to a known period of variety of organizations:
time, typically from one to four weeks) and produce a The Project Management Institute oers the following
working subset of the entire system deliverable at the end credentials to project managers:[5][6]
of each iteration. The increasing adoption of lightweight
approaches is due largely to the fact that software require-
Project Management Professional (PMP)
ments are very susceptible to change, and it is extremely
dicult to illuminate all the potential requirements in Certied Associate in Project Management
a single project phase before the software development (CAPM),
commences.
Program Management Professional (PgMP)
The software project manager is also expected to be
familiar with the Software Development Life Cycle Risk Management Professional (PMI-RMP), and
(SDLC). This may require in depth knowledge of require-
ments solicitation, application development, logical and Scheduling Professional (PMI-SP)
physical database design and networking. This knowl-
edge is typically the result of the aforementioned educa- Portfolio Management Professional (PfMP)
tion and experience. There is not a widely accepted certi-
cation for software project managers, but many will hold Other institutions and organizations:
11.8. PROJECT MANAGEMENT OFFICE 131

AIMS (UK) Institute of Project Management oers
Certied Project Manager (CPM) and Diploma in
Project Management programs
PMLG oers The Certied Project Manager (CPM)
Boot Camp[7]
The University of Wisconsins Masters Certicate in
Project Management
[3] Russell, PMP, D. (2011). Accountability. In Succeeding
in the project management jungle: How to manage the
people side of projects (p. 29). New York, NY: AMA-
COM.
[4] Berrie, Michele, Project Manager Responsibilities, PM
Hut. Accessed 17. Oct 2009.
[5] Project Management Institute Family of Credentials

CompTIA oers Project+ Certication [6] http://www.projectmanagers.org/2012/11/

project-managers-as-consultants.html
The Canadian Construction Association (CCA) of-
fers Gold Seal Certication as a Project Manager. [7] company webpage. pmlg.com. PMLG. Retrieved 16
January 2014.

The UK Oce of Government Commerce oers

PRINCE2 certication. 11.7.8 Further reading
The Australian Institute of Project Manage-
ment (AIPM) oers Registered Project Manager US DoD (2003). Interpretive Guidance for Project
(RegPM) certication. Manager Positions. August 2003.

The Defense Acquisition University (DAU) and its
School of Program Management oers practitioner
training in every element of project management for
members of the Federal Government, Defense in-
dustry and allied nations.
Open source handbook for project managers Open
source handbook for project managers. July 2006.
Collection of scholarly articles Project Management
Training: Research. Nov 2012.

The University of Cape Town (UCT) is now oer-

ing Advanced Diploma in Business Project Manage-
ment (Postgraduate) at NQF Level 7. 11.8 Project management oce

There are other graduate programs in project and tech- A project management oce, abbreviated to PMO,
nology management, such as an MSPM. is a group or department within a business, agency or
enterprise that denes and maintains standards for project
The International Project Management Association management within the organization. The PMO strives
(IPMA) is an international network of national project to standardize and introduce economies of repetition in
management societies such as Association for Project the execution of projects. The PMO is the source of
Management in the UK. IPMA serves as an umbrella documentation, guidance and metrics on the practice of
organisation representing national societies which oer project management and execution.
their certications.
Darling & Whitty (2016) identify the denition of the
PMOs function has evolved over time:
11.7.6 See also
The 1800s project oce was a type of national gov-
Event Planning and Production ernance of the agricultural industry
Master of Science in Project Management
1939 appears as the earliest instance of the term
Project engineer 'project management oce' being published

Project management The 1950s concept of the PMO is representative of

what a contemporary PMO looks like
Project planning
Today the PMO is a dynamic entity used to solve
specic issues[1]
11.7.7 References
[1] https://www.apm.org.uk/WhatIsPM Often PMOs base project management principles on
industry-standard methodologies such as PRINCE2 or
[2] PMBOK Guide Third Edition 2004 p.12 guidelines such as PMBOK.
132 CHAPTER 11. COLLABORATION

11.8.1 Performance the publication of opinions without scientic basis in the

eld of science, medicine or law would not be tolerated,
According to the Standish CHAOS Report (2009),[2] and it is equally important for justication to be presented
68% of software projects do not meet time/cost/scope in the management eld.[1]
targets. Only 32% of projects were completed on time,
within budget and delivered measurable business and
stakeholder benets. 11.8.3 Types
There are many reasons for such failures. As per a
A PMO can be one of three types from an organizational
PricewaterhouseCoopers survey [3] of 1,524 organiza-
exposure perspective:
tions, inadequate project estimating and planning consti-
tutes 30% of project failures, lack of executive sponsor-
ship constitutes 16% and poorly dened goals and ob- enterprise PMO,
jectives constitutes 12%. It also found that using estab- organizational (departmental) PMO, or
lished project management approaches increased success
as measured by a projects key performance indicators of specialpurpose PMO.
quality, scope, schedule, budgets and benets. The survey
indicates that operating an established PMO is one of the The Project Management Institute (PMI) Program Man-
top three reasons that drives successful project delivery.[3] agement Oce Community of Practice (CoP), describes
Darling & Whitty (2016) found there is complexity of the PMO as a strategic driver for organizational excel-
interconnections in PMO intellectual capital and though lence, which seeks to enhance the practices of execu-
often the rationale for PMO establishment is to enhance tion management, organizational governance, and strate-
stakeholder satisfaction with projects often the establish- gic change leadership.[5]
ment of the PMO leads to signicant dissatisfaction by Darling & Whitty (2016) highlight many PMO typologies
senior management.[1] exist from the early 1800s as a collective for running gov-
ernment strategy in the agricultural sector, to the civil in-
11.8.2 Functions frastructure projects of the early 20th century to the early
2000s when the PMO became a commodity to be traded
PMOs may take other functions beyond standards and and traded upon. It would be impossible to group [1]
PMOs
methodology, and participate in Strategic project man- into specic types (Darling & Whitty, 2016).
agement either as facilitator or actively as owner of the
Portfolio Management process. Tasks[4] may include
11.8.4 See also
monitoring and reporting on active projects and portfo-
lios (following up project until completion), and report- P3O
ing progress to top management for strategic decisions on
what projects to continue or cancel. Project management
The degree of control and inuence that PMOs have on Project management software
projects depend on the type of PMO structure within the
enterprise; it can be: Program management

Supportive, with a consultative role List of project management software

Controlling, by requiring compliance for example Project Portfolio Management

Directive, by taking control and managing the Document management system

projects
There are many opinions and practices some say PMOs
must fulll, The PMBoK 5th edition dedicates a page
and a half to such discussion identifying 6 PMO func-
tions. (Hobbs & Aubry 2010) identied 27 distinct func-
tions of PMOs highlighting a number of these were found
to not correlate to enhanced project performance. Dar-
ling & Whitty (2016) state there is a need for evidence-
based management practice, that consultants and prac-
titioners are providing unproven solutions which organ-
isations both public and private are investing enormous
quantities of nance to without assured outcome, further
11.8.5 References
[1] Eric John Darling; Stephen Jonathan Whitty. The project
management oce: its just not what it used to be. Inter-
national Journal of Managing Projects in Business. Emer-
ald Publishing. 9 (2). doi:10.1108/IJMPB-08-2015-
0083.
[2] Domingues, Jorge (1 July 2009). The Curious Case of
the CHAOS Report 2009. Standish.
[3] The third global survey on the current state of project
management (PDF). PriceWaterhouseCoopers. 2013.
11.9. CHIEF INFORMATION OFFICER 133

[4] Funding for Government Olympic Executive / Olympic relevant for a Chief Information Ocer of an organiza-
Programme Programme Oce (PDF). Greater London tion who must balance roles in order to gain a competitive
Authority. 2012. advantage and keep the best interests of the organizations
employees. CIOs also have the responsibility of recruit-
[5] PMIs Program Management Oce (PMO Symposium): ing, so it is important that they take on the best employees
Asking Tough Questions, Identifying Solutions (Press re-
to complete the jobs the company needs fullling.
lease). PMI. 13 November 2012.
In addition, CIOs are directly required to map out both
the ICT strategy and ICT policy of an organization. The
ICT strategy covers future proong, procurement, and
11.9 Chief information ocer the external and internal standards laid out by an orga-
nization. Similarly, the CIO must write up the ICT pol-
Chief information ocer (CIO), chief digital infor- icy, detailing how ICT is utilized and applied. Both are
mation ocer (CDIO) or information technology (IT) needed for the protection of the organization in the short
director, is a job title commonly given to the most senior and long term and the process of strategizing for the fu-
executive in an enterprise responsible for the information ture. Paul Burtt, former CIO of AstraZeneca, also out-
technology and computer systems that support enterprise lines the CIOs role of IT governance, which he refers
goals. Generally, the CIO reports directly to the chief to as the clarifying of accountability and the role of
executive ocer but may also report to the chief operat- committees.[8]
ing ocer or chief nancial ocer. In military organiza-
tions, they report to the commanding ocer. The Chief
Information Ocer role was rst dened[1] in 1981 by 11.9.3 Risks involved
William R. Synnott, former Senior Vice President of the
Bank of Boston, and William H. Gruber, former profes- As the CIO has a large number of responsibilities such
sor at the MIT Sloan School of Management.[2] as provision of nance, recruitment of professionals and
development of policy and strategy, the risks are conse-
quently vast. The CIO of U.S company Target was forced
11.9.1 The need for CIOs into resignation in 2014 after the theft of 40 million credit
card details and 70 million customer details by hackers.[9]
CIOs or CDIOs form a key part of any business that uti- CIOs carry out a large number of roles and therefore the
lizes technology and data. In recent times, it has been chance of failure is very high. In this way, any CIO must
identied that an understanding of just business or just be knowledgeable about the industry so they can adapt
IT is not sucient.[3] CIOs manage IT resources and plan and reduce the chance of error.
"ICT including policy and practice development, plan-
ning, budgeting, resourcing and training.[4] In addition
to this, CIOs are becoming increasingly important in cal- 11.9.4 Information technology
culating how to increase prots via the use of ICT frame-
works, as well as the vital role of reducing expenditure Information technology and its systems have become so
and limiting damage by setting up controls and planning important that the CIO has come to be viewed in many
for possible disasters. Computer Weekly magazine high- organizations as a key contributor in formulating strategic
lights that 53% of IT leaders report a shortage of people goals for an organization. The prominence of the CIO po-
with high-level personal skills in the workplace.[5] CIOs sition has greatly risen as information, and the informa-
are needed to decrease the gulf between roles carried out tion technology that drives it, has become an increasingly
by both IT professionals and non-IT professionals in busi- important part of the modern organization. Many CIOs
nesses in order to set up eective and working relation- are adding additional c-level titles to reect the growing
ships. importance of technology in successfully running com-
panies; this trend is referred to as the CIO-plus. The
CIO may be a member of the executive committee of
11.9.2 Roles and responsibilities an organization, and/or may often be required to engage
at board level depending on the nature of the organi-
The Chief Information Ocer of an organization is re- zation and its operating structure and governance envi-
sponsible for a number of roles. First and most impor- ronment. No specic qualications are intrinsic to the
tantly, the CIO must fulll the role of business leader.[6] CIO position, though the typical candidate may have ex-
As a CIO must make executive decisions regarding things pertise in a number of technological elds - computer
such as the purchase of IT equipment from suppliers or science, software engineering, or information systems.
the creation of new systems, they are therefore responsi- Many candidates have Master of Business Administration
ble for leading and directing the workforce of their spe- or Master of Science in Management degrees.[10] More
cic organization. In addition, the CIO is required to recently, CIOs leadership capabilities, business acumen
have strong organizational skills.[7] This is particularly and strategic perspectives have taken precedence over
134 CHAPTER 11. COLLABORATION

technical skills. It is now quite common for CIOs to be More specically, CIOs manage a businesss IT systems
appointed from the business side of the organization, es- and functions, creates and delivers strategies and policies,
pecially if they have project management skills. and places great emphasis on internal customers. In con-
In 2012, Gartner Executive Programs conducted a global trast to this, CTOs place emphasis on the external cus-
CIO survey and received responses from 2,053 CIOs tomers to the organization and focus on how dierent [15]
from 41 countries and 36 industries.[11] Gartner reported technology can make the company more protable.
that survey results indicated that the top ten technol- The traditional denition of CTOs focused on using tech-
ogy priorities for CIOs for 2013 were analytics and nology as an external competitive advantage now includes
business intelligence, mobile technologies, cloud com- CDOs who use the power of modern technologies, online
puting, collaboration technologies, legacy moderniza- design and big data to digitalise a business.
tion, IT management, customer relationship manage-
ment, virtualization, security, and enterprise resource
planning. 11.9.6 See also
CIO magazines State of the CIO 2008 survey asked 558 Chief technology ocer
IT leaders whom they report to. The results were: CEO
(41%), CFO (23%), COO (16%), Corporate CIO (7%) Chief digital ocer
and Other (13%).[12]
Chief executive ocer
Typically, a CIO is involved with driving the analysis and
re-engineering of existing business processes, identifying Chief nancial ocer
and developing the capability to use new tools, reshaping
the enterprises physical infrastructure and network ac- Chief operating ocer
cess, and with identifying and exploiting the enterprises
knowledge resources. Many CIOs head the enterprises
eorts to integrate the Internet into both its long-term
11.9.7 References
strategy and its immediate business plans. CIOs are of- [1] http://www.williamgruber.com/newpage1.htm
ten tasked with either driving or heading up crucial IT
projects that are essential to the strategic and operational [2] Synnott W.R. and Gruber W.H. (1981) Information Re-
objectives of an organization. A good example of this source Management: Opportunities and Strategies for the
would be the implementation of an Enterprise Resource 1980s. New York: Wiley-Interscience.
Planning (ERP) system, which typically has wide-ranging
[3] von Simson, Ernest. The new role of the CIO.
implications for most organizations. ww.businessweek.com. Retrieved 26 October 2014.
Another way that the CIO role is changing is an increased
[4] University of Nottingham. The role of a Chief Informa-
focus on service management.[13] As SaaS, IaaS, BPO
tion Ocers (CIO) or equivalent Senior ICT Manager.
and other more exible value delivery techniques are www.nottingham.ac.uk. Retrieved 26 October 2014.
brought into organizations the CIO usually functions as
a 3rd party manager for the organization. In essence, a [5] Manwani, Sharm; Flint, David. From manager to chief
CIO in the modern organization is required to possess information ocer. www.computerweekly.com. Re-
business skills and the ability to relate to the organization trieved 26 October 2014.
as a whole, as opposed to being a technological expert
[6] Peppard, Joe (August 2010). Unlocking the Perfor-
with limited functional business expertise. The CIO po- mance of the Chief Information Ocer (CIO)". Califor-
sition is as much about anticipating trends in the market nia Management Review. 52 (4): 5. Retrieved 26 October
place with regard to technology as it is about ensuring that 2014.
the business navigates these trends through expert guid-
ance and proper strategic IT planning that is aligned to [7] Lawry, Rachel; Waddell, Dianne; Singh, Mohini (2007).
the corporate strategy of the organization. Roles, Responsibilities and Futures of Chief Information
Ocers (CIOs) in the Public Sector (PDF): 3. Retrieved
26 October 2014.
11.9.5 Distinction between CIO, CDO and [8] Computer Weekly. What exactly does a chief informa-
CTO tion ocer do?". www.computerweekly.com. Retrieved
26 October 2014.
The roles of Chief Information Ocer, Chief Digital
Ocer and Chief Technology Ocer are commonly [9] Vaas, Lisa. Target CIO Beth Jacob resigns in breach af-
blurred. Tom Silver, the North American senior vice termath. www.nakedsecurity.sophos.com. Retrieved 27
October 2014.
president for Dice, states that CTOs are concerned with
technology itself, whereas CIOs are much more con- [10] Meridith Levinson (2007-07-05). Should You Get an
cerned with its applications in the business and how this MBA? - CIO.com - Business Technology Leadership.
can be managed.[14] CIO.com. Retrieved 2012-03-28.
11.9. CHIEF INFORMATION OFFICER 135

[11] Gartner Executive Program Survey of More Than 2,000

CIOs Shows Digital Technologies Are Top Priorities in
2013. Gartner. Retrieved 12 July 2013.

[12] State of the CIO 2008 Data Shows CIO Salaries, Inu-
ence Rising. CIO. Retrieved 27 February 2010.

[13] CIO Magazine: Recession Shifts IT Service Manage-

ment into Fast Lane. Cio.com. 2010-02-26. Retrieved
2012-03-28.

[14] Zetlin, Minda. CIO or CTO- Whats in a Title?". www.

oracle.com. Retrieved 27 October 2014.

[15] Hiner, Jason. Sanity check: Whats the dierence be-

tween CIO and CTO?". www.techrepublic.com. Re-
trieved 27 October 2014.

11.9.8 External links

El CIO y la ayuda a la produccin El papel de CIO
en una compaa
a summary of CIO competencies based on the
Clinger-Cohen competencies for CIOs, 2010.
Chapter 12

Text and image sources, contributors, and

licenses

12.1 Text
Enterprise architecture Source: https://en.wikipedia.org/wiki/Enterprise_architecture?oldid=774589954 Contributors: Edward, Michael
Hardy, Kku, Rfoard, Ronz, Geirem, Nickg, EricStephens, Khalid hassani, Alexf, Kustere, Mormegil, Rich Farmbrough, Mike Schwartz,
MaxHund, Mdd, Poweroid, Sutch, Ringbang, Dr Gangrene, Boothy443, Poppafuze, Tschirl, Kjenks, Dmccreary, Fred Bradstadt, Jpom,
Bgwhite, YurikBot, Gardar Rurak, YoavShapira, Lijealso, Yahya Abdal-Aziz, Jpbowen, Larry laptop, Pkearney, Tribaal, Deville,
Richard@lbrc.org, Leebrian, Bihal, Modify, Petko, Veinor, SmackBot, KAtremer, Gletiecq, Tbyrne, Svtveld, Ohnoitsjamie, Hmains, Chris
the speller, UdayanBanerjee, Colonies Chris, Sct72, Can't sleep, clown will eat me, Mahanchian, Etu, JonHarder, Rrburke, Wen D House,
Cybercobra, Colinwheeler, FlyHigh, DearMyrah, Moejorris, Kuru, RfHilliard, Roypittman, H.meligy@ieee.org, Evmako, ScottWAmbler,
Mudgen, Charles T. Betz, Razi chaudhry, AGK, Andy.k.chang, JForget, PhillyPartTwo, Johngt, CmdrObot, Daljitbanger, IanDBailey,
SeanFromIT, David Waters, DumbBOT, Lewisskinner, Horatio Huxham, Thijs!bot, Hervegirod, Headbomb, Dubtank, Picus viridis,
RichardVeryard, EdJohnston, VivekRaman, Dawnseeker2000, Gizmoeti, Jayron32, JEH, MER-C, Michig, Roleplayer, Creacon, VoABot
II, Ff1959, Indon, Saccland, SunSw0rd, Samhiggins1973, Jstehlin, Oicumayberight, DGG, Saigeethamn, Nickmalik, Jmgendron, R'n'B,
David.t.bath, Erkan Yilmaz, Athaenara, Sri1968, MatthewFordKern, Tonyshan, 0mark0, Keithstagner, Yogishpai, Heppelle, Inwind, Lar-
sonk, Jcs2006, Signalhead, VolkovBot, Shajela, TXiKiBoT, EnterprisePlanner, Arpabr, Lradrama, Factician, Ylvabarker, Kpellegrino,
Graham Berrisford, Id027411, SieBot, EAIG, Malcolmxl5, Lucasbfrbot, Dvanberg, Flyer22 Reborn, Jroschella, Leowashere, Momo san,
Pm master, Antonio Lopez, Faradayplank, Senright, Alienjim, Ncw0617, Noru66, Per.foldager, Eaguru, Billaronson, Sthubbar, Brandguru,
Qartman, SWA2, Vicpulido~enwiki, Mild Bill Hiccup, Niceguyedc, Trivialist, Vandvik, Catof, M4gnum0n, Qatestdev, Toheller, Sun
Creator, Eustress, Metaframe, Ricardus64, Vdmeraj, Lakeworks, XLinkBot, Dwbrockway, Petersleep, Lockezachman, Brandy Downs,
Rriverapadilla, Richard.McGuire88, Ron Gaba, Tom Corn, Addbot, Nocontributionsever, Mabdul, Hazarbx, AntonioVallecillo, Fort-
myers, EAPRACTICE, VishalVPatil, MrOllie, AndersBot, Manishpk, BlackKnight, Richard R White, Jarble, Luckas-bot, Yobot, Eis-
saf, Guy1890, AnomieBOT, DemocraticLuntz, Rubinbot, Emahdizargar, Eddiexx77, Nazrani, Citation bot, MithrasPriest, ArthurBot,
Xqbot, Osorin, Emrekenci, GrouchoBot, Marklane0913, Omnipaedista, SassoBot, Je Zhuk, In fact, Anna Roy, Mark Renier, W Now-
icki, Mikeyboysan, Raju bhupesh, Winterst, Rapsar, Troy.frericks, Foobarnix, Mirkoki, Lotje, 0tsa0, Darp-a-parp, ErikvanB, Svesterli,
Raholijaona, Mean as custard, Atifmkhan, EmausBot, WikitanvirBot, Ian Glossop, Primefac, Marcoprez, Sightreadernow, Somerwind,
Eamteam, Nav102, Kvoges, Wayne Slam, Erianna, Enoril~enwiki, ISresearcher, Architectchao, Cfoglia, Jlapalme, , Rudytheman,
ChuispastonBot, Gricehead, Scottlawrencelawson, Mjbmrbot, ClueBot NG, Ontist, Turnb345, Carl presscott, Eateacher, Sonyasunshine,
Neln, BG19bot, Monash123, Anubhab91, Compfreak7, ChrisGualtieri, Mediran, Mmalotau, Clapstick77, JD Beckingham, Rupert loup,
OhioGuy814, Phamnhatkhanh, Maya.lincoln, MaryEFreeman, Kjas1970, Comp.arch, Mandar.vanarse1974, Sbond01, Thewikiguru1,
Ftak, Mosaati, Entarchtools, Farleyortiz, Ed Gives, Rcmola, Voywiki, Haloedscape, Paulfaran, Sqjdiu Entaidia, JussiSiltanen, KasparBot,
Knife-in-the-drawer, MaxxPhase, Spbarrows, NB665, 665NB, Paulesco, Jacksonlukar, Georey Manning, Michael page23, Clintonandre,
Fmadd, Csnikoletta, LauraMauersberg, JohnPaulSmith, GratefulLearner and Anonymous: 289
Enterprise architect Source: https://en.wikipedia.org/wiki/Enterprise_architect?oldid=743758856 Contributors: Kku, Ronz, Cobalt-
bluetony, Mboverload, Rich Farmbrough, MBisanz, Mdd, RoySmith, Ruud Koot, Rjwilmsi, IceCreamAntisocial, Dariopy, SmackBot,
Svtveld, Hmains, JorgePeixoto, Peter Campbell, JonHarder, Kuru, Nux, JHunterJ, CBM, Ensa, Headbomb, Phronko, RichardVeryard,
Bwesche, Roleplayer, Appraiser, ICloche, DGG, Drm310, Aleksander.adamowski, Nickmalik, Pravin Gupta, Kimleonard, Yogishpai,
Rharner, King Lopez, Jclouse, ClueBot, The Thing That Should Not Be, Niceguyedc, Catof, M4gnum0n, Lockezachman, Brandy Downs,
Ron Gaba, Greg Zorne, EAPRACTICE, OceanKiwi, Moringadan, AnomieBOT, Maxis ftw, Marklane0913, Sn2000, Ace of Spades,
Berny68, Simple Bob, GardmanVS, Ian Glossop, Biolekk, Architectchao, ClueBot NG, Sonyasunshine, BG19bot, Happyuk, Epischel,
Entarchtools, Bender the Bot and Anonymous: 52
Enterprise Architecture Assessment Framework Source: https://en.wikipedia.org/wiki/Enterprise_Architecture_Assessment_
Framework?oldid=772643703 Contributors: Mdd, Jpbowen, Leebrian, Headbomb, TAnthony, DGG, ShelleyAdams, UnCatBot, Matthew-
Vanitas, Yobot, MerlLinkBot, Cat4567nip, GreenC bot and Anonymous: 4
Enterprise architecture planning Source: https://en.wikipedia.org/wiki/Enterprise_architecture_planning?oldid=768298169 Contribu-
tors: Kjkolb, Mdd, Woohookitty, Bgwhite, Vprajkumar, JForget, Headbomb, Denisarona, AnomieBOT, FrescoBot, Mirkoki, Nav102,
BG19bot, ChrisGualtieri, JohnPaulSmith and Anonymous: 8
Enterprise Architecture Management Source: https://en.wikipedia.org/wiki/Enterprise_architecture_management?oldid=756008797
Contributors: Edward, Chowbok, Mdd, Van der Hoorn, SmackBot, Kuru, Ehheh, Headbomb, RichardVeryard, Saccland, R'n'B, Yogishpai,

136
12.1. TEXT 137

Brandguru, DianaNier, Dinishare, MrOllie, Manishpk, Yobot, Redrose64, ClaretAsh, Helpful Pixie Bot, Smid12, Magnolia677, Voywiki,
LauraMauersberg and Anonymous: 5
Architectural pattern (computer science) Source: https://en.wikipedia.org/wiki/Architectural_pattern?oldid=771749576 Contributors:
Codeczero, Pnm, Kku, MartinSpamer, Andrewman327, Greenrd, Topbanana, Rursus, Wlievens, Beland, Vinsci, Bobo192, Kenyon, Jen-
rzzz, Davidfstr, BD2412, Bgwhite, Jpbowen, Rwwww, SmackBot, Jjalexand, LtPowers, Kuru, Rory O'Kane, Spdegabrielle, Yaris678,
Ephillipe, Christian75, Katjah, Honette, Archknight, TAnthony, Magioladitis, Avicennasis, Christian Storm, Vinod.pahuja, VolkovBot,
Thedjatclubrock, AlastairIrvine, A4bot, BenjaminHeitmann, McM.bot, SieBot, Janggeom, Martarius, Rpawson, Sandeep ubs, Shaded0,
M4gnum0n, Sbywater, MystBot, Tomrbj, Addbot, Jafeluv, Jarble, KamikazeBot, 4th-otaku, AnomieBOT, Citation bot, Thehelpfulbot,
Sae1962, Citation bot 1, Trappist the monk, CamilleLM, Madmikey, Naveen607, EmausBot, WikitanvirBot, Nav102, Demonkoryu, Sci-
entic29, Ptrb, Susanpadura, BattyBot, RandomLittleHelper, Mohsen Sadeghi Hasanabadi, Piecioshka, Softzen, Gorohoroh, Rod.bishti,
Wikishovel, Aone1988 and Anonymous: 56
Enterprise Architecture framework Source: https://en.wikipedia.org/wiki/Enterprise_architecture_framework?oldid=776261929 Con-
tributors: Ronz, M1ss1ontomars2k4, Coherers, Mdd, Woohookitty, Tabletop, BD2412, Rjwilmsi, AJackl, Bgwhite, RussBot, Gaius
Cornelius, Tony1, Drstrangeluv25, SmackBot, Miljoshi, JonHarder, Colinwheeler, RfHilliard, JForget, JohnCD, IanDBailey, Thijs!bot,
Roebuckr, Hervegirod, Sprhodes, Headbomb, RichardVeryard, Isometric, Nick Number, Pinaghosh, Appraiser, SunSw0rd, Samhig-
gins1973, Nickmalik, R'n'B, David.t.bath, Erkan Yilmaz, J.delanoy, STBotD, Izno, Squids and Chips, UnitedStatesian, Graham Berris-
ford, Malcolmxl5, Leowashere, Boppet, Wikitect, SWA2, S650588, Iohannes Animosus, SchreiberBike, Rriverapadilla, MystBot, Addbot,
Conrad Hughes, AntonioVallecillo, Grin700, Luckas-bot, Yobot, AnomieBOT, LilHelpa, Xqbot, Drilnoth, Dcannin, Omnipaedista,
Nkemp2010, Marc Schade~enwiki, MerlLinkBot, FrescoBot, Kevinleesmith, LucienBOT, Mishras99, Nav102, Dynamicedge, Archi-
tectchao, Ufoldager, , ChuispastonBot, Krohorl, 28bot, Widr, ChanochWiggers, BG19bot, Frze, Wikimpan, Compfreak7, Grlarose,
Mark Paauwe, Entarchtools, Ed Gives, Samuelholcman, Spbarrows, GratefulLearner and Anonymous: 73
Enterprise Architecture Body of Knowledge Source: https://en.wikipedia.org/wiki/Enterprise_Architecture_Body_of_Knowledge?
oldid=755838238 Contributors: Kku, Ronz, Khalid hassani, Tabletop, Jpbowen, SmackBot, Chris the speller, Cydebot, RichardVeryard,
Davidjcmorris, Nickmalik, David.t.bath, David.T.Bath, Bew TN, Olea, Jackfork, Skiwi~enwiki, Randy Kryn, Robomanx, Addbot, ,
Quarilari23, ArmbrustBot, EoRdE6 and Anonymous: 8
Generalised Enterprise Reference Architecture and Methodology Source: https://en.wikipedia.org/wiki/Generalised_Enterprise_
Reference_Architecture_and_Methodology?oldid=746814524 Contributors: Mdd, Estienne, Bgwhite, The Transhumanist, R'n'B, Wik-
Head, J04n, W Nowicki, Cat4567nip, KTachyon, BG19bot, Me, Myself, and I are Here and Anonymous: 3
IDEAS Group Source: https://en.wikipedia.org/wiki/IDEAS_Group?oldid=670015868 Contributors: The Anome, Aecis, Mdd, Smack-
Bot, Folajimi, JHunterJ, IanDBailey, Richard R White, Yobot, FrescoBot, Merlion444, AvicAWB, Theopolisme, Leggattst and Anony-
mous: 8
RM-ODP Source: https://en.wikipedia.org/wiki/RM-ODP?oldid=761823874 Contributors: Edward, Nickg, Mdd, Odalet~enwiki,
SmackBot, CmdrObot, Mblumber, RichardVeryard, Husond, .anacondabot, TXiKiBoT, Hardistyar, Ivarru, Addbot, AntonioVallecillo,
AnomieBOT, EdMcMahon, Miym, Nasa-verve, FrescoBot, Cat4567nip, Kaluzman, BG19bot, The s0rc3r, Me, Myself, and I are Here,
LauraALo and Anonymous: 9
The Open Group Architecture Framework Source: https://en.wikipedia.org/wiki/The_Open_Group_Architecture_Framework?oldid=
776264380 Contributors: Rp, Ronz, Nurg, Decoy, Chowbok, Discospinster, Rvodden, John Vandenberg, Mdd, Dominik Kuropka~enwiki,
Stephen, Stuartyeates, Hojimachong, Bobrayner, Zanaq, RHaworth, Apokrif, CiTrusD, Markphahn, Phantom309, Utuado, FlaBot, Juliank,
Kmorozov, FireballDWF2, Pittspilot, Spike Wilbury, Georgewilliamherbert, SmackBot, Mauls, Bluebot, Mahanchian, Colinwheeler, Kuru,
Yan Kuligin, Dl2000, IvanLanin, Prof 7, JForget, IanDBailey, Dwelliott, Thijs!bot, Hervegirod, IP 84.5, RichardVeryard, Nick Number,
QuiteUnusual, Sgryphon, SunSw0rd, Davidjcmorris, Nickmalik, Elpecek, Larsonk, GrahamHardy, Kyle the bot, Kronix1986, Graham
Berrisford, Jamelan, SieBot, Cirdan747, Timdwilliams, Laoyao99, TechnoMorphWiki, Jdbarras, Vdmeraj, Addbot, Ghettoblaster, Maria
C Mosak, Faramir4, Richard R White, ToolPioneer, Luckas-bot, Yobot, Bunnyhop11, AnomieBOT, Mgl795, Obersachsebot, Maurits-
Bot, Hassan210360, Je Zhuk, Desphi, Mohamad Hani ELJAMAL, FrescoBot, Airon90, Craigrmartin, Jonste, Uppalj, Lineslarge, Dou-
glasBeattieJr, ErikvanB, EmausBot, Varghesejac, John of Reading, Tdubendorf, Cat4567nip, BatesyM, Lokpest, Gmjohnston, Damian
Gawlowski, Turnb345, Helpful Pixie Bot, BG19bot, Edhgoose, Mark Paauwe, Editor0071, S. Stephane, Haloedscape, Babymissfortune
and Anonymous: 118
Integrated Architecture Framework Source: https://en.wikipedia.org/wiki/Integrated_Architecture_Framework?oldid=689508953
Contributors: Skysmith, Iznogoud~enwiki, Mdd, SmackBot, T@nn, Rpearlman, R'n'B, Addbot, Mtaksrud, Cat4567nip, Ontist and Anony-
mous: 6
OBASHI Source: https://en.wikipedia.org/wiki/OBASHI?oldid=759282384 Contributors: Jason Quinn, Chowbok, Mdd, Gary, Rjwilmsi,
MZMcBride, Rjjm, SmackBot, Chris the speller, Kuru, Alaibot, Reedy Bot, Lucasbfrbot, Fergus Cloughley, AnomieBOT, LilHelpa,
Dadadi, FrescoBot, Lotje, Adi4094, John of Reading, GoingBatty, Cat4567nip, DanielV UK, Miroslaw dabrowski, The Quixotic Potato
and Anonymous: 7
Information Framework Source: https://en.wikipedia.org/wiki/Information_Framework?oldid=730516192 Contributors: Giraedata,
Mdd, Bgwhite, Malcolma, MaximvsDecimvs, Magioladitis, Adrianrgcampbell, Infotect, Addbot, Yobot, AnomieBOT, Erik9bot, Fres-
coBot, DocYako, Onel5969, Mean as custard, John of Reading, Cat4567nip, Raja Angamuthu, BG19bot, BattyBot, The squaw on the
hippopotamus, Daithi.o.ciaran, Jordanni1972, Paulfaran and Anonymous: 14
Zachman Framework Source: https://en.wikipedia.org/wiki/Zachman_Framework?oldid=768421947 Contributors: Lousyd, Kku, Ronz,
Gzornenplatz, Chowbok, GoodStu, Bender235, Mike Schwartz, Mdd, Next2u, Ynhockey, HGB, Blaxthos, Dismas, Natalya, Woohookitty,
Mandarax, BD2412, MZMcBride, Ian Pitchford, Kmorozov, Gaius Cornelius, Zwobot, Gadget850, Deville, CQ, Knowlengr, Adnan-
mukhtar, Mlibby, SmackBot, AngelovdS, Mauls, Duke Ganote, Tennekis, Sct72, Mahanchian, JonHarder, BryanG, Louv, Aarktica,
Hu12, ScottWAmbler, Skapur, DEddy, CmdrObot, Larsonbennett, Gregbard, Grgarza, Paddles, Hagge, RichardVeryard, EdJohnston,
Dawkeye, AntiVandalBot, Darklilac, Magioladitis, EagleFan, SunSw0rd, Fang 23, DGG, Davidjcmorris, Nickmalik, R'n'B, Commons-
Delinker, GrWikiMan, Mhavila, Reedy Bot, MatthewFordKern, Elpecek, STBotD, Larrygoldberg, Fredrick day, PaulTanenbaum, Wiae,
Graham Berrisford, Metaman1, Rcbapb, Sbowers3, Boppet, ImageRemovalBot, CasperGoodwood, AnneBoleyn1536, Phogg2, Muhandes,
Metaframe, SchreiberBike, Thehelpfulone, Lockezachman, Len Morrow, Ron Gaba, Tom Corn, Addbot, Maria C Mosak, Tcrowley7,
Yobot, AnomieBOT, ChristopheS, Gark08, LilHelpa, Phwedh, J04n, Timp21337, FrescoBot, RonaldKunenborg, John of Reading, Go-
ingBatty, Cat4567nip, Arvigtall, Sgasson, , ClueBot NG, Ontist, Paulalbinson, Helpful Pixie Bot, Wikimpan, Jpzachman, BattyBot,
Ideasintegration, Entarchtools, Vivekkush1983, Sajadtorkamani, GoneWilde, Coghillcort and Anonymous: 95
138 CHAPTER 12. TEXT AND IMAGE SOURCES, CONTRIBUTORS, AND LICENSES

Department of Defense Architecture Framework Source: https://en.wikipedia.org/wiki/Department_of_Defense_Architecture_

Framework?oldid=775367187 Contributors: Skysmith, Ronz, PeterGerstbach, Thomas Willerich, Robertbowerman, ESkog, Jaber-
wocky6669, CanisRufus, Brons, Mdd, PaulHanson, Tabletop, Starsman, Aldryd, 5994995, Mjchonoles, Zwobot, Garion96, Cask05,
SmackBot, Gletiecq, Bluebot, Pglehmann, Frap, TheKMan, Louv, Doug Bell, Hu12, Markbassett, IanDBailey, Hervegirod, Deemery,
RichardVeryard, Nick Number, MME, Kitdaddio, Buckshot06, AlephGamma, Jstehlin, STBot, Atpco, Adavidb, Athaenara, LordAnubis-
BOT, Izno, Sauzuk, Igfrace, Juniorj1967, Senright, Mygerardromance, TechBuzz28, MRqtH2, SWA2, Pshoman, Wikiste, Mwilmshurst,
Sun Creator, SoxBot, Metaframe, MystBot, Addbot, Maria C Mosak, Richard R White, Yobot, Bunnyhop11, Ptbotgourou, John.szucs,
5cnts, Galoubet, Tremnai55, Mark Renier, DexDor, Rikenmyer, Cat4567nip, Sethhmorgan, Harryt99, Donner60, , MerlIwBot, Help-
ful Pixie Bot, Leggattst, Mark Arsten, UpdateMiller, Jean-Philippe LERAT, Mechthold54, Rg348, JoeB335, Eliz11, Ivankabel, Enter-
prisedesign, CAPTAIN RAJU, Caseyjsmith806 and Anonymous: 93
MODAF Source: https://en.wikipedia.org/wiki/MODAF?oldid=749404173 Contributors: PeterGerstbach, Kwekubo, Bearcat, Isopropyl,
Adeio, Robertbowerman, Pearle, Mdd, Rjwilmsi, Welsh, Mjchonoles, Saberwyn, Rayc, Esprit15d, SmackBot, Roypittman, JHunterJ, Cm-
drObot, Bigglescat, IanDBailey, Adam-griths, Hervegirod, RichardVeryard, Porqin, DavidOrme, Hammersoft, WOSlinker, Dormskirk,
Wikitect, Huku-chan, EoGuy, Niceguyedc, WolfgangFahl, Addbot, Maria C Mosak, MrOllie, Yobot, Helen Peacop, AnomieBOT, Visvais,
Locobot, Mark Renier, Branedancearj, Louperibot, Josee Bourdage, Carlbarck-holst, Cat4567nip, CIO-MODAF, BG19bot, Leggattst, Cy-
berbot II, Voywiki, GreenC bot and Anonymous: 27
NATO Architecture Framework Source: https://en.wikipedia.org/wiki/NATO_Architecture_Framework?oldid=741880167 Contribu-
tors: Mdd, GregorB, IanDBailey, Fabrictramp, Wikitect, WolfgangFahl, Yobot, Sarahnortonviolin, Marc Schade~enwiki, Cat4567nip,
Tonsnoei and Anonymous: 3
AGATE (architecture framework) Source: https://en.wikipedia.org/wiki/AGATE_(architecture_framework)?oldid=699195759 Con-
tributors: Premeditated Chaos, Rich Farmbrough, Mdd, Mais oui!, Switchercat, CmdrObot, Hervegirod, Bobblehead, RichardVeryard,
Nickmalik, The Evil Spartan, Dekart, Addbot, Maria C Mosak, Yobot, Ptbotgourou, FaleBot, Cat4567nip, BattyBot and Anonymous: 1
Government Enterprise Architecture Source: https://en.wikipedia.org/wiki/Queensland_Government_Enterprise_Architecture?oldid=
542618878 Contributors: Bkonrad, Shiftchange, Jpbowen, Tony1, Seattlenow, RichardVeryard, Samhiggins1973, VanessaDS, Yobot, Lil-
Helpa and Anonymous: 3
FDIC Enterprise Architecture Framework Source: https://en.wikipedia.org/wiki/FDIC_Enterprise_Architecture_Framework?oldid=
749567356 Contributors: Edward, Chowbok, Mdd, Ground Zero, Psantora, Sandstein, Whaledad, Tiptoety, ClueBot, XLinkBot, 5 albert
square, Yobot, AnomieBOT, Cat4567nip, Gregg 84102, ClueBot NG, Will20036, Technical 13, BG19bot, Cyberbot II, GreenC bot and
Anonymous: 2
Federal Enterprise Architecture Source: https://en.wikipedia.org/wiki/Federal_enterprise_architecture?oldid=772094655 Contributors:
Ronz, Cmholm, Piels, Chowbok, GoodStu, Giraedata, Mdd, PaulHanson, Ironwolf, BD2412, JubalHarshaw, Dmccreary, Epolk, Jp-
bowen, Tony1, Ihuxley, SmackBot, Gletiecq, Bluebot, DoctorW, Lantrix, Louv, Kuru, Lanma726, Krauss, RichardVeryard, Kitdaddio,
David.t.bath, Tericee, Daveshawley, Crkey, Snidhi22, Synthebot, Senright, ShelleyAdams, Brandguru, The Horst Mann, Kalai545, Trav-
eler23380, Lockezachman, Maria C Mosak, ToolPioneer, Yobot, Omnipaedista, Nageh, Mark Renier, DrilBot, Pinethicket, Adi4094,
John of Reading, Cat4567nip, , Nisteditor2, Sheardsheard, Mark Arsten, Compfreak7, Dexbot, Asmallteapot, Larsenjs, Dbrownpm,
GreenC bot, Omprakashbhart and Anonymous: 35
NIST Enterprise Architecture Model Source: https://en.wikipedia.org/wiki/NIST_Enterprise_Architecture_Model?oldid=766303002
Contributors: Neutrality, Mdd, Apoc2400, Finell, Vprajkumar, CmdrObot, Marek69, Citation bot, Cat4567nip, BG19bot, MartinZwirlein
and Anonymous: 4
Treasury Enterprise Architecture Framework Source: https://en.wikipedia.org/wiki/Treasury_Enterprise_Architecture_Framework?
oldid=729797045 Contributors: Mike Schwartz, Mdd, Bgwhite, Euchiasmus, CmdrObot, Jameboy, Rossj81, Saeed.Darya, MerlLinkBot,
Cat4567nip, SporkBot, Wikimpan and Anonymous: 4
Enterprise life cycle Source: https://en.wikipedia.org/wiki/Enterprise_life_cycle?oldid=737245939 Contributors: Kjkolb, Mdd,
Woohookitty, Josh Parris, CmdrObot, Mr pand, VolkovBot, Wiae, Pm master, Sfan00 IMG, Niceguyedc, Addbot, Yobot, Jean.julius,
Materialscientist, FrescoBot, ClueBot NG, BG19bot, Scmbwis, Me, Myself, and I are Here, Anniehovh, ShalokShalom, Emitri Daz and
Anonymous: 9
ISO 12207 Source: https://en.wikipedia.org/wiki/ISO/IEC_12207?oldid=774131882 Contributors: Vikebo, Mxn, Vargenau, Phil Boswell,
Robbot, Herbee, Mavetx, Khalid hassani, M.e, Limbo socrates, Pearle, Mdd, Lmatt, Chobot, Gdrbot, NTBot~enwiki, Deeday-UK, Ninly,
SmackBot, BenAveling, Kazov, Radagast83, Thijs!bot, Nick Number, Escarbot, JAnDbot, Siliconshells, Magioladitis, Dekimasu, Ale-
phGamma, VolkovBot, Rei-bot, UnitedStatesian, Jamelan, Jax 0677, Pichpich, Mitch Ames, Thebestofall007, Addbot, Fieldday-sunday,
Luckas-bot, TaBOT-zerem, AnomieBOT, Rubinbot, Alainr345, FrescoBot, Tim1357, Alopex0, ChuispastonBot, Italinux, ClueBot NG,
Taibah U, Cyberbot II, Kaizen nagoya, LauraALo, GreenC bot and Anonymous: 39
Systems Development Life Cycle Source: https://en.wikipedia.org/wiki/Systems_development_life_cycle?oldid=776273796 Contribu-
tors: The Anome, Jinian, Mrwojo, Michael Hardy, Pnm, Lousyd, Kku, Liftarn, Ahoerstemeier, Ronz, Angela, Andrewman327, Bearcat,
Chris 73, Pingveno, SchmuckyTheCat, Seth Ilys, Alan Liefting, Graeme Bartlett, Meisterexer, Pascal666, Khalid hassani, Beland, Zon-
dor, Mike Rosoft, Rich Farmbrough, Pluke, ESkog, Neurophyre, Bobo192, John Vandenberg, TheProject, Mdd, Alansohn, Walter Grlitz,
DrKranium, Lectonar, Redfarmer, Sir Joseph, Wtmitchell, Yogi de, Djsasso, Kenyon, Xphile2868, Woohookitty, Dandv, Teohhanhui,
Cbdorsett, Allen3, Paxsimius, Kesla, OMouse, Ketiltrout, Rjwilmsi, Koavf, Mikesc86, Croepha, Latka, Chsh, Tedder, King of Hearts,
Albanaco, Pip2andahalf, RussBot, Ansell, RadioFan2 (usurped), Stephenb, Wimt, Wiki alf, Grafen, Jpbowen, Tony1, Natkeeran, Syrthiss,
DGJM, DeadEyeArrow, Jeremy Visser, Closedmouth, Kevin, Allens, Rwwww, SmackBot, KnowledgeOfSelf, Hydrogen Iodide, MeiS-
tone, Ga, Gilliam, Oliverclews, Ohnoitsjamie, Sam Hobbs, Octahedron80, Pikajedi3, Allan McInnes, Madman2001, TheTallOne, Sigma
7, BrownHairedGirl, Kuru, Bilby, FiRe, Optakeover, Tee Owe, Vashtihorvat, David.alex.lamb, Hu12, ScottWAmbler, Xsmith, Daniel-
phin, JoeBot, IvanLanin, DEddy, AGK, Markbassett, Wspencer11, John.stark, Eastlaw, CalebNoble, Jonathan A Jones, Kushal one,
Ibadibam, Dgw, Yaris678, CFMWiki1, Chrislk02, Omicronpersei8, Epbr123, Eastmain, Mojo Hand, Headbomb, Marek69, Kathovo,
Supran, AntiVandalBot, Gioto, Luna Santin, Widefox, Seaphoto, Nkattari, JAnDbot, Niaz, DuncanHill, ThomasO1989, Geniac, Gert7,
Bongwarrior, VoABot II, Transcendence, JamesBWatson, AlephGamma, PIrish, Ensign beedrill, Allstarecho, JaGa, MartinBot, Arjun01,
Kr suraesh, R'n'B, Erkan Yilmaz, J.delanoy, SteveChervitzTrutane, AntiSpamBot, Tonyshan, NewEnglandYankee, Natl1, ThePointblank,
ABF, Je G., Maghnus, Philip Trueman, TXiKiBoT, Oshwah, Eiku, Anonymous Dissident, TwilligToves, Adamgibb, Raymondwinn, Aus-
traliss, ShwetaCool, BrianY, SieBot, Steelchain, Srushe, Happysailor, Flyer22 Reborn, Jojalozzo, TheseusXav, Allmightyduck, BasilBoom,
12.1. TEXT 139

Tanvir Ahmmed, GarbagEcol, ClueBot, LAX, Hutcher, Mick1990, Unbuttered Parsnip, Shaded0, Torqtorqtorq, Niceguyedc, Ajbrulez,
SigmaJargon, Arunsingh16, Kurumban, Veryprettysh, Kalai545, M4gnum0n, NuclearWarfare, Cory Donnelly, Aitias, Jonverve, Ran-
jithsutari, Versus22, Apparition11, Ordoon, XLinkBot, Stickee, Little Mountain 5, Avoided, WikHead, Addbot, Howartthou, Andaryj,
Jncraton, GD 6041, MrOllie, Tide rolls, Bguras puppy, Teles, Informatwr, RT Carpenter, Yobot, Jdg12345, Ptbotgourou, Fraggle81,
Merlin, Sarloth, Joe4210, Josephedouard, Evaders99, AnomieBOT, Cochiloco, Jim1138, Piano non troppo, 90, Kingpin13, Materialscien-
tist, , Michael Chidester, Xqbot, Jerey Mall, MikeEcho, Coretheapple, J04n, GrouchoBot, Shadowjams, Ebessman,
Mummy34, FalconL, Mark Renier, Recognizance, Wandering-teacher, Pinethicket, I dream of horses, Timo395, Thomasjereyanderson-
twin, Swep01, Twistor96, Hughiki, Throwaway85, Seahorseruler, Specs112, Suneelkushwaha, Yeng-Wang-Yeh, Sideways713, DARTH
SIDIOUS 2, Strawny02, VectorThorn, Salvio giuliano, Enauspeaker, CanadianPenguin, EmausBot, Avenue X at Cicero, BillyPreset,
Satishshah123, RA0808, RenamedUser01302013, Qrsdogg, Tommy2010, Wikipelli, Dcirovic, K6ka, Copyeditor22, Devarishi, PS., Al-
pha Quadrant (alt), HyperSonic X, Rooseveltavi, SporkBot, Ocaasi, Coasterlover1994, L Kensington, Qaiassist, Orange Suede Sofa, NTox,
Flyerwolf, AbbasSarfraz, Beiber the justin, ClueBot NG, Cwmhiraeth, Smtchahal, MelbourneStar, Widr, Chillllls, Gamcall, SentientSys-
tem, Kdridder, Oddbodz, Harsha.nagaraju, Omkar1234, Compfreak7, Herwin.a, Avi Harel, RscprinterBot, Johnjeric, BattyBot, Pratyya
Ghosh, Hghyux, MahdiBot, ChrisGualtieri, Holsen266, Ekren, Can357, Cliydcw, FoCuSandLeArN, Lugia2453, SFK2, Matt.sigs, Pabba
naresh, Michipedian, Sue Mars, Tentinator, Vizzy135, ITECStudent01, Zenibus, Ginsuloft, , Gmmahinya, Elon-
Phoenix, 12tl21, Patient Zero, 13EvilCows, Deecee59, Michaelrham, Sanjaya r 1985, Psycho rajput, Kamayani thakur, Johaardanish,
Agasthya1992, Tedy Beor, CAPTAIN RAJU, Shqiptar1234, Bungai2015, Ozoudemartins540, Invisible Guy, KATMAKROFAN, Bender
the Bot, Kavyakumari, Sssatyam patel, Yana.gusti, Pujakedar and Anonymous: 899
Technology Life Cycle Source: https://en.wikipedia.org/wiki/Technology_life_cycle?oldid=747930465 Contributors: Markhurd, Edcol-
ins, Giraedata, Mdd, Woohookitty, Sylvainremy, BD2412, Rjwilmsi, Phantomsteve, DragonHawk, Bachrach44, Tony1, EEMIV, Smack-
Bot, McGeddon, Chris the speller, Iridescent, Hermitage17, Ipsofacto, Nick Number, Widefox, Froid, JaGa, Hbent, Nickmalik, R'n'B,
Rlsheehan, Oshwah, Flyer22 Reborn, Nopetro, Swferrier, Sbolat, Auntof6, Yobot, AnomieBOT, Eumolpo, LittleWink, Skyerise, Clue-
Bot NG, BG19bot, Marcocapelle, BattyBot, Me, Myself, and I are Here, Randykitty, Biogeographist, XW42, Aeroid, Ghannam Wasif,
Dasari12, Chinmaynandy, MattBishop5, Mynameisjulious123456 and Anonymous: 15
Whole-life cost Source: https://en.wikipedia.org/wiki/Whole-life_cost?oldid=764791995 Contributors: Mrwojo, Kku, Paul W, Quarl,
Mdd, Velella, Woohookitty, RussBot, SmackBot, Hmains, Beetstra, Motorworld~enwiki, Future Perfect at Sunrise, Gnfnrf, Nick Num-
ber, Fayenatic london, DASonnenfeld, VolkovBot, Helenalex, Pm master, Martarius, Addbot, MrOllie, OceanKiwi, JonathanBentz,
AnomieBOT, LilHelpa, Mthrandir, Robtrob, EmausBot, Smobbl Bobbl, Widr, Helpful Pixie Bot, NukeofEarl, Scmbwis, ProjMngt,
Jeremy112233, Kkumaresan26, KasparBot and Anonymous: 15
Enterprise modelling Source: https://en.wikipedia.org/wiki/Enterprise_modelling?oldid=761813695 Contributors: Giraedata, Mdd,
ReyBrujo, Woohookitty, RussBot, SmackBot, Chris the speller, ScottWAmbler, Cnbrb, TheTito, Keithh, AndrewHowse, Hazmat2,
RichardVeryard, MarshBot, EagleFan, Davidjcmorris, Nickmalik, R'n'B, GrWikiMan, KvanHaperen, Telecomtom, Banana Concoction,
Equilibrioception, EwokiWiki, Flyer22 Reborn, Stanio, Berean Hunter, PongoPrint, Addbot, Jncraton, Yobot, Ptbotgourou, Legobot II,
LilHelpa, J04n, Some standardized rigour, FrescoBot, Noble Krypton, DrilBot, EnterpriseModeller, Purge me, , Petrb, Wbm1058,
Razorbliss, Sebastian-aus-Berlin, Quinto Simmaco and Anonymous: 27
Business analyst Source: https://en.wikipedia.org/wiki/Business_analyst?oldid=773950803 Contributors: Michael Hardy, Ronz, Grom-
lakh, Goethean, Wjhonson, Kpalion, Khalid hassani, VampWillow, 9ign, The Land, AndrewTheLott, Humblefool, Dr.frog, Discospin-
ster, Notinasnaid, ESkog, Kx1186, Ociallyover, Mdd, Gary, MarkGallagher, Saxifrage, Mindmatrix, Kgrr, SCEhardt, Kbdank71,
Harro5, Gurch, TheDJ, DVdm, The Rambling Man, Cpuwhiz11, NawlinWiki, Matthew0028, BOT-Superzerocool, Jeh, Gadly, Zzuuzz,
Closedmouth, Daugustine, SmackBot, MeiStone, Brick Thrower, Gilliam, Ohnoitsjamie, Choalbaton, Josbald1975, Jjalexand, Vdavis-
son, Freek Verkerk, Radagast83, Mion, Rklawton, Rodney Boyd, Kuru, Terzett, Stupid Corn, Andrew Kay, Mathewssh, Scratz, Cnbrb,
Albattar, Randhirreddy, Rambam rashi, RobinGoldsmith, Thumbarger, Outriggr (2006-2009), Cydebot, Odie5533, Bmitchelf, Hitrish,
JonathanWeaver, 2KT, Nick Number, Mactin, Widefox, QuiteUnusual, Movses, Alphachimpbot, Arvalarva, Edwardmking, Fusionmix,
Tedickey, Avicennasis, Irmtraining, DerHexer, Davidjcmorris, R'n'B, Kateshortforbob, Justaba500, J.delanoy, 02design, Siegfried1, Fre-
quencydip, Anagha dhumal, Kevin Brennan, Benglish11, Jackofwiki, Geeteshjain, Stuartlachlan, 3ta, R, Oshwah, GDonato, Amol pharate,
Dwandelt, Ghaag, Yintan, Oli2007, Kathode raytube11, Kinkyy, Flyer22 Reborn, The-sloans, GeoWingChun, Deereav, Boing! said
Zebedee, Davidovic, M4gnum0n, NuclearWarfare, JulianSammy, Wacko39, Thingg, Akshat59, Genmel, Oli.ahad, XLinkBot, Jytdog,
Dthomsen8, Strings28, Addbot, Maria C Mosak, Wikicsb, CanadianLinuxUser, MrOllie, Tassedethe, Tide rolls, Dave601, Evans1982, Az-
contributor, Rubinbot, Pendse pradeep, Sunshinedaydream95, Wenat, Materialscientist, Citation bot, LilHelpa, XZeroBot, Santosh kumar
g, Locobot, FrescoBot, LucienBOT, Taliped, Davidvilson2009, Jcampsall, I dream of horses, Tra, Petergjansen, Serols, Dfarnham, Light-
lowemon, Monymirza, Jaychowrocksmysocks, Slon02, Vwtinfo, Dcirovic, Cobaltcigs, L Kensington, Donner60, Wesmith4, Kalpanatikoo,
Baspecialist, Manytexts, AbbasSarfraz, ClueBot NG, Baanalyst, Jasper432, Widr, Oklahoma3477, BG19bot, MusikAnimal, Marcocapelle,
Mark Arsten, Elainarufs, Dexbot, Indexed card, Jacobnav, Frosty, Mhailstone, Wywin, Cadillac000, Me, Myself, and I are Here, MrLink-
inPark333, Drchriswilliams, Inphynite, Monkbot, Greedo8, Rogerborges, Contributorauthor, Some Gadget Geek, Oycps2014, Fico2015,
Ira Leviton, RashiRastogi2, AshokShauryaSingh and Anonymous: 350
Systems analysis Source: https://en.wikipedia.org/wiki/Systems_analysis?oldid=764277582 Contributors: Tbackstr, Stevertigo, Kku,
Ronz, Kingturtle, Mydogategodshat, Bearcat, Goethean, Bobbyanalog, Sverdrup, BigHaz, Beowulph, Discospinster, Rich Farmbrough,
Bender235, El C, Bobo192, Remuel, Maurreen, Rajah, Mdd, Riana, Velella, Jheald, Albamuth, Versageek, Kenyon, Fooziex, Btyner, Ted
Wilkes, Tawker, Yamamoto Ichiro, Authalic, Strangnet, DVdm, Straker, The Rambling Man, YurikBot, RussBot, NawlinWiki, Shreshth91,
RattleMan, Grafen, Toxickore, Malcolma, Jpbowen, Larsobrien, Cyrus Grisham, Rwwww, Cask05, SmackBot, Impaciente, Gjs238,
Gilliam, Bigs slb, Octahedron80, Nbarth, JonHarder, RJBurkhart, Nick Green, Kuru, Mr Stephen, The Missing Hour, Charleenmerced,
CMG, Jac16888, Cydebot, Mblumber, Skittleys, SimonClinch, Deipnosophista, AntiVandalBot, Luna Santin, Brian48, VictorAnyakin,
AllTheCoolNamesAreAlreadyTaken, EagleFan, Irmtraining, Johnbrownsbody, Mrten Berglund, Wylve, R'n'B, Nono64, Thirdright, Erkan
Yilmaz, Philosopher06, Zoara, Mcsharry, KylieTastic, Burzmali, X!, Psheld, Philip Trueman, Jemartincg, Ask123, Wpociengel, An-
drewaskew, SieBot, WereSpielChequers, Malcolmxl5, BotMultichill, Flyer22 Reborn, Qst, OKBot, ClueBot, Ian Tabi, Jesgab, Excirial,
Tyler, Stypex, 1ForTheMoney, Aitias, Aardila, AlanM1, Srikant.sharma, Addbot, Willking1979, Freakmighty, Maria C Mosak, MrOllie,
Tide rolls, Luckas-bot, Yobot, Ptbotgourou, Al.Ragsdale, KamikazeBot, Wiki Roxor, AnomieBOT, Soresumakashi, Piano non troppo, Ma-
terialscientist, Xqbot, S0aasdf2sf, Omnipaedista, RibotBOT, Mnent, Liridon, Mark Renier, Social Norm, Pinethicket, MastiBot, Serols,
Jandalhandler, FoxBot, Alph Bot, EmausBot, WikitanvirBot, Primefac, ZroBot, Donner60, Architectchao, Logicalgregory, ClueBot NG,
Widr, Theopolisme, MerlIwBot, BG19bot, ElphiBot, HusiGeza, Millennium bug, M Preston Sparks, Oreileao, Khazar2, Mr. Guye, Ankit
Neo Ghz, GabeIglesia, Phamnhatkhanh, Biogeographist, Drscarlat, Melody Lavender, My name is not dave, Aldishopper92, Nikolaiho,
140 CHAPTER 12. TEXT AND IMAGE SOURCES, CONTRIBUTORS, AND LICENSES

P1971, DissidentAggressor, Dhiraj.j.shetty, Hoornsma, Cherdchai Iamwongsrikul, Ibijoke, Hashi15, Grub98, FYD Ripper and Anony-
mous: 193
Information architecture Source: https://en.wikipedia.org/wiki/Information_architecture?oldid=771512051 Contributors: Deb, Edward,
TeunSpaans, Michael Hardy, Ronz, Angela, Pema~enwiki, Nickg, Phoebe, Mbria, Masao, Tea2min, LLarson, LockeShocke, Macrakis,
Urhixidur, KeyStroke, Dobrien, LeeHunter, Pavel Vozenilek, S.K., Fenice, Lycurgus, Marcok, Aaronbrick, Spalding, Enric Naval, Ka-
ganer, SeanGustafson, Jakew, Pinar, Mduvekot, Mattbrundage, Burkinaboy, Skeejay, Velvetsmog, JimmycurN, Burkhard~enwiki, BD2412,
Koavf, Captmondo, Aapo Laitinen, FlaBot, Timo Kouwenhoven, PhilipR, Insydney, Jpbowen, Speedoight, Parham, Veinor, SmackBot,
Brick Thrower, Ohnoitsjamie, JonathanHart~enwiki, Infophiliac, Kostmo, Mahanchian, Smoken Flames, Flyguy649, Lus Felipe Braga,
SashatoBot, RichMorin, Scetoaux, Ehheh, Quarty~enwiki, IvanLanin, DEddy, Atomiq, Timber92, Prof 7, Bill.albing, Outriggr (2006-
2009), Clayoquot, Horatio Huxham, A3RO, Jmelody, JustAGal, Salvadorious, Kauczuk, Asist, Creacon, Swpb, Lutzv, Ajcheng, Mets-
Bot, Havanafreestone, DerHexer, Hbent, Oicumayberight, Harvardnet, Nickmalik, Keith D, Craigb81, R'n'B, Captain panda, Chrisfur-
niss, Icseaturtles, Frequencydip, Orangewarp, Steel1943, VolkovBot, Mymarpie, Erliptac, JhsBot, Broadbot, PaulTanenbaum, Graham
Berrisford, Justin2007, Simon.raistrick, GlassFET, SieBot, BotMultichill, Of.information.architecture, KPH2293, Hobartimus, Abialek,
Sethlilly, Sfermigier, Martarius, ClueBot, Pucciar, The Thing That Should Not Be, CounterVandalismBot, Pboersma, BirgerH, Studip101,
XLinkBot, Danimovski, Addbot, Jomackiewicz, Willking1979, Whbenjaminjones, Emorrogh, Bevcorwin, CanadianLinuxUser, MrOllie,
Luckas-bot, Yobot, AmeliorationBot, Lostnumber747, AnomieBOT, Rubinbot, Eddiexx77, Oconar, DanimovIA, Materialscientist, Cita-
tion bot, LilHelpa, Xqbot, Capricorn42, Socrates32, Onepd, Martijnd, J04n, Greenmtncville, SassoBot, Smallman12q, FrescoBot, Ekillaby,
Pinethicket, Jonesey95, Skyerise, MondalorBot, Novacough, Lotje, Tankgrrl2000, Mandolinface, EmausBot, John of Reading, Wikitan-
virBot, Super48paul, Kellylautt, UXjam, , Mentibot, Nighthawk2050, ClueBot NG, Resmini, 10k, NicHB7, Ekphraster, Saluki2001,
PatHadley, Helpful Pixie Bot, BG19bot, DigitalWikiMan, SilvrWings, Brad7777, Rcunderw, Marty computerscientist, David.moreno72,
MarkTraceur, Kruchkamgar, IGeoy, LibrarianAnnie, MaryEFreeman, Znacznik, Biogeographist, Mcio, Jakedtc, Star767, Isabelgrob-
ler, Alad19, Zissou7, Nwhysel, Okpaulmecom, BethNaught, Aresmini, Maee10, Bigwavephoto, XamieA, Ks-M9, Tthompso spiritof76,
Bender the Bot, Mariasheler, Wikishovel, MalSol, JueLinLi, G.london, Gracezhang15m and Anonymous: 215
Solutions Architect Source: https://en.wikipedia.org/wiki/Solution_architect?oldid=774758039 Contributors: Ronz, RedWolf, Icairns,
Mdd, Rsrikanth05, SmackBot, Jamesont, Kuru, Alaibot, MER-C, Graham Berrisford, Enviroboy, Bentogoa, Michael.W.Meissner, Yobot,
AnomieBOT, Dplt, Jonathanchaitow, Super48paul, Jenks24, ClueBot NG, TruPepitoM, Fyrftd, Paulhussein, Glacialfox, Holsen266,
Dexbot, Aaadonai, Bw57899, Paul2520, Voywiki, Frankbybuc, Chekv and Anonymous: 69
Software architect Source: https://en.wikipedia.org/wiki/Software_architect?oldid=776502898 Contributors: Ronz, Boson, Willpeavy,
EricStephens, Antandrus, Andreas Kaufmann, Hydrox, Max Terry, RoyBoy, Mdd, Espoo, Masums, Nightscream, XLerate, GnniX, Gam3,
Roboto de Ajvol, Pinecar, Arado, Bhny, Bovineone, SamJohnston, Mtze, Deville, K.Nevelsteen, Drable, SmackBot, Bigbluesh, Anwar
saadat, Wigren, Robth, JonHarder, Allan McInnes, Normxxx, Cybercobra, MichaelBillington, Ryan Roos, Doug Bell, Kuru, Kompere, Dab-
Machine, Hetar, Longshot14, Wspencer11, Koe, Ervinn, Tlatoani, Alucard (Dr.), .anacondabot, Jatkins, Aladdin Sane, Nickmalik, R'n'B,
Doryexmachina, KylieTastic, HiEv, Vipinhari, UnitedStatesian, Sapphic, Laoris, MikelZap, ClueBot, DukeyToo, Java4food, Muro Bot, Ap-
parition11, Xtremeways, Neuralwarp, Addbot, Mr4tastic, BrianFennell, Maria C Mosak, Lightbot, Gail, Poosari, LuK3, Luckas-bot, Yobot,
AnomieBOT, Xqbot, JimVC3, Leoluz, RibotBOT, Drheaton, Edderso, RandomStringOfCharacters, Swampdaddy87, RichardAlexan-
derGreen, Dolovis, Erianna, Erget2005, ClueBot NG, Alex.shafran, Widr, Helpful Pixie Bot, Techmage, Daewoochong, Wikilobbyist,
David.moreno72, Fuebar, SFK2, Ginsuloft, Mike Schwartz SF, Melcous, Cherdchai Iamwongsrikul, Bazlul1, Rraheja, Frodothehobo and
Anonymous: 96
Systems architect Source: https://en.wikipedia.org/wiki/Systems_architect?oldid=774987080 Contributors: Ronz, Furrykef, Jnc, Sempf,
Andreas Kaufmann, D6, Mdd, Carbon Caryatid, Woohookitty, BD2412, Kmorozov, Vonkje, RussBot, Toxickore, Tony1, CLW, Deville,
K.Nevelsteen, Open2universe, SmackBot, Bigbluesh, Gilliam, Robth, Sct72, Allan McInnes, Normxxx, MichaelBillington, Ryan Roos,
Lus Felipe Braga, Louv, Drieux, Soap, DabMachine, Hetar, Iridescent, Longshot14, Markhu, Cydebot, Thijs!bot, Bobblehead, Richard-
Veryard, Ablqadir, Psychohistorian, EagleFan, Aleksander.adamowski, Chris Pickett, CardinalDan, Zac Gochenour, Sapphic, Philip Sut-
ton, Drmies, JustinClarkCasey, SchreiberBike, 9Nak, WikHead, Kbdankbot, Addbot, Yousou, Maria C Mosak, SEI Publications, Jarble,
AnomieBOT, J04n, Omnipaedista, Thehelpfulbot, DrilBot, Texclayton, DonFiresmith, Architectchao, ClueBot NG, Satellizer, Mrgates,
Calabe1992, Wbm1058, JoanZehrt, CarnivorousGnomeCatuse, HMSLavender, Jonathanarpith, David O Sampson and Anonymous: 59
Project manager Source: https://en.wikipedia.org/wiki/Project_manager?oldid=769057630 Contributors: Heron, Edward, Kku, Ping-
PongBoy, Ellywa, Mkoval, MQuinn, Wik, Cleduc, Hubertus~enwiki, Chris Roy, Ploums, Graeme Bartlett, Zigger, Chowbok, Antan-
drus, Hgfernan, Discospinster, Guanabot, S.K., Shanes, Richi, Kjkolb, Mdd, Carbon Caryatid, Wtmitchell, RJFJR, Digitric, Wiktoria,
Blair Azzopardi, Wdyoung, Rillian, YurikBot, Richieman, Mtcedar, Deville, David Biddulph, SmackBot, Od Mishehu, Chris the speller,
Bluebot, Stevenmitchell, Hoof Hearted, Dogears, Ojophoyimbo, Kuru, Gobonobo, Minna Sora no Shita, Rundquist, Travis99, Bhalchan-
dratk, Flaviohmg~enwiki, Beetstra, Ehheh, Ft1~enwiki, Iridescent, JensenDied, Dlohcierekim, CmdrObot, Cydebot, Voldemortuet, PKT,
Thijs!bot, Sisalto, James086, Matthew Proctor, Mentisto, Luna Santin, QuiteUnusual, Vincehk, .anacondabot, Bencherlite, Ff1959, Glob-
alprofessor, Oicumayberight, MartinBot, R'n'B, Akalanaki, Bendhoward, Bonadea, Synique, Dandriani, VolkovBot, Keith Richards UK,
TXiKiBoT, Saber girl08, BotKung, MADe, Haikon, Enviroboy, C45207, SieBot, Flyer22 Reborn, Pm master, Jagra, Silver Master, Ferdilo,
ClueBot, The Thing That Should Not Be, Karmona, Eeekster, BOTarate, Chiefmanzzz, XLinkBot, Jytdog, Dthomsen8, Alexolson, Myst-
Bot, Addbot, Co1Spain, MrOllie, Keith Biglin, Glane23, Mfo321, OlEnglish, LeonMichaelSmith, Waltloc, Luckas-bot, Yobot, Evans1982,
Michelle2mmb, AnomieBOT, DemocraticLuntz, Nankivel, Piano non troppo, A123a, ArthurBot, Obersachsebot, Xqbot, Capricorn42,
Mechanic1c, Kokcharov, FrescoBot, Hury94, Nazmanager, Vavilen, Jcampsall, Wndola, Banej, IMsupersmith, Muazen, Theblueman-
ager, Lordbrocket, Dineshasewwandi, Cloud10pm, WikitanvirBot, Jazzy Diva, RA0808, KimBecker, ZroBot, Cymru.lass, Sean Whitaker,
Donner60, Jsiraj, ClueBot NG, Artemis Fowl Rules, Nan-bread666, Stoborrobots, BG19bot, Jacobsharps, Juro2351, Axelberube, KGun10,
Fernandocastor, Vanmarcus, 2Flows, Pjganon, SFK2, Epicgenius, Eyesnore, Geza.molnar, NottNott, Behug, John Gaziano, Tom Hayhoe,
PMinformation, Stevebrown164, Liance, Dbayom, MasterRainbow, AyelitaBose, Libragagan, Djtizalami, Doumaio000, Jdbingham, An-
driy.nykytyuk and Anonymous: 207
Project management oce Source: https://en.wikipedia.org/wiki/Project_management_office?oldid=759052466 Contributors: The
Epopt, Kku, Donalmc, Boudewijn~enwiki, Pascal666, Khalid hassani, Stesmo, Kjkolb, Pearle, Rodii, SDC, FlaBot, TheDJ, Jar-
rahTree, RussBot, Stephenb, BirgitteSB, NickelShoe, SmackBot, Paraparam Bigot, SmartGuy Old, DemolitionMan, OrphanBot, Kuru,
Ashrafhashem, TastyPoutine, Hu12, Akbradford, Cespa, Asamawal, Darrentcook, Cydebot, CharlotteWebb, JamesBWatson, Chris0427,
DerHexer, Jwestland, Davidjcmorris, YUiCiUS, Nickmalik, J.delanoy, Tagus, VolkovBot, TXiKiBoT, Willit63, Pm master, KathrynLy-
barger, Lightfair, Flashart1, DickieTruncheon, PipepBot, Kokilads, Pakaraki, Alexbot, BOTarate, Eduardo6028, Vanished User 1004,
Addbot, Xp54321, Mapador, MrOllie, Download, SpBot, Waltloc, Yobot, Lindsayascott, AnomieBOT, Materialscientist, Citation bot,
12.2. IMAGES 141

Xqbot, Mattg82, FrescoBot, Fortdj33, Jonesey95, Lineslarge, Karateguyindc, Mean as custard, DavidAndres, Nick Moyes, GoingBatty,
U+003F, Qaiassist, Chasep2010, ChuispastonBot, ClueBot NG, Scmbwis, DanReedPMP, Drullewatz, Khorramirad, Moonowerdragon,
EPRNYC, BigJolly9, Ralfjnr, Ginsuloft, Pmi, Nitinmadhvani, Prem 9718270951 and Anonymous: 63
Chief information ocer Source: https://en.wikipedia.org/wiki/Chief_information_officer?oldid=772343389 Contributors: Robert
Merkel, Aldie, Kku, Egil, Ronz, Schneelocke, David Shay, Greyengine5, Gadum, LiDaobing, Iznogoud~enwiki, Neutrality, Zondor,
Lacrimosus, Rich Farmbrough, Rhobite, Aecis, Mairi, Mpeisenbr, Mdd, Mote, Poweroid, PaulHanson, Dismas, Woohookitty, Mindmatrix,
Dandv, Rjwilmsi, Davidp, Dmccreary, FlaBot, Ian Pitchford, Leslie Mateus, Alphachimp, Diza, YurikBot, Hede2000, OneGyT, Curtis
Clark, Zwobot, Rwalker, Katieh5584, SmackBot, Sebesta, Yamaguchi , Gilliam, Ohnoitsjamie, Bluebot, Jazmatician, Scwlong, Jon-
Harder, Benjamin Mako Hill, Cebess, Cybercobra, Nslonim, Kuru, Robosh, Comfychaos, Ehheh, InedibleHulk, Thiagoeh, Djharrity,
JForget, Yarnalgo, Mitchello, WeggeBot, Cydebot, Pdxuser, Odie5533, SusanLesch, Sorenriise, AntiVandalBot, Sadchild, ChristianBk,
Gatemansgc, Mrip, Pan Dan, Svetovid, 72Dino, VolkovBot, OminousSkitter, Shajela, Hqb, Yesha.sivan, Jvlock, Doc James, Iswive,
Rock2e, Ddmishra, Flyer22 Reborn, CIOGuru, Fbarw, Millstream3, ClueBot, Daniel73480, The Thing That Should Not Be, Gaia Octavia
Agrippa, Jaysee21, Ottawahitech, Zelig123456, Nuiloa, SoxBot III, DumZiBoT, MystBot, Johnloia2112, Addbot, MrOllie, Buster7, ,
Joseph.strunz, Legobot, Yobot, Vague, Themfromspace, Jamalystic, Bruce404, Nurtsio, Tempodivalse, AnomieBOT, Thomasjl, Materi-
alscientist, Laran.evans, Xqbot, C172rg, Andrewmin, Nasa-verve, Groverxv, Omnipaedista, Pravin.taskseveryday, Thehelpfulbot, Dub617,
Wiki3 1415, Swineinuenza, Dukeofgaming, EFormsBlogger, OnceAlpha, Lotje, Diannaa, Rollins83, Primefac, Julsssark, Thecheesykid,
Smpclient, Jplarkin, ClueBot NG, Tellmewhy1, Jmilestaylor, MerlIwBot, BlueSkyNoRain, BG19bot, MusikAnimal, Mark Arsten, Aranea
Mortem, Rrastin, Me, Myself, and I are Here, Phamnhatkhanh, John Jacobson367, Ugog Nizdast, Caliburn, DavidWestT, WB 96, Hectics,
HelpUsStopSpam, GeneralizationsAreBad, KasparBot, Whgruber, MateMaticMatan, Bishoptom, GregoryPence, Rantemario and Anony-
mous: 152

12.2 Images
File:4+1_Architectural_View_Model.svg Source: https://upload.wikimedia.org/wikipedia/commons/e/e6/4%2B1_Architectural_
View_Model.svg License: CC BY-SA 3.0 Contributors: Based on File:4+1 Architectural View Model.jpg by User:Mdd Original artist:
mpan
File:4-2_ANSI-SPARC_three_level_architecture.svg Source: https://upload.wikimedia.org/wikipedia/commons/8/84/4-2_
ANSI-SPARC_three_level_architecture.svg License: CC BY-SA 3.0 Contributors: Developing High Quality Data Models. The
European Process Industries STEP Technical Liaison Executive (EPISTLE).
Original artist: 4-2_ANSI-SPARC_three_level_architecture.jpg: Matthew West and Julian Fowler
File:4-3_Data_Modelling_Today.svg Source: https://upload.wikimedia.org/wikipedia/commons/5/5d/4-3_Data_Modelling_Today.svg
License: CC BY-SA 3.0 Contributors: Developing High Quality Data Models. The European Process Industries STEP Technical Liaison
Executive (EPISTLE).
Original artist: 4-3_Data_Modelling_Today.jpg: Matthew West and Julian Fowler
File:A_Tutorial_on_the_Zachman_Architecture_Framework.jpg Source: https://upload.wikimedia.org/wikipedia/commons/0/0c/
A_Tutorial_on_the_Zachman_Architecture_Framework.jpg License: Public domain Contributors: A Tutorial on the Zachman Architec-
ture Framework Original artist: va.gov
File:Air_Force_Ensign_of_the_United_Kingdom.svg Source: https://upload.wikimedia.org/wikipedia/commons/c/cc/Air_Force_
Ensign_of_the_United_Kingdom.svg License: Public domain Contributors: ? Original artist: ?
File:Ambox_current_red.svg Source: https://upload.wikimedia.org/wikipedia/commons/9/98/Ambox_current_red.svg License: CC0
Contributors: self-made, inspired by Gnome globe current event.svg, using Information icon3.svg and Earth clip art.svg Original artist:
Vipersnake151, penubag, Tkgd2007 (clock)
File:Ambox_important.svg Source: https://upload.wikimedia.org/wikipedia/commons/b/b4/Ambox_important.svg License: Public do-
main Contributors: Own work, based o of Image:Ambox scales.svg Original artist: Dsmurat (talk contribs)
File:Architectural_Levels_and_Attributes.jpg Source: https://upload.wikimedia.org/wikipedia/commons/1/14/Architectural_Levels_
and_Attributes.jpg License: Public domain Contributors: FEA Practice Guidance Original artist: Federal Enterprise Architecture Program
Management Oce, OMB
File:Architecture_framework.jpg Source: https://upload.wikimedia.org/wikipedia/commons/2/27/Architecture_framework.jpg Li-
cense: Public domain Contributors: Building an Enterprise Architecture framework Original artist: Rob Thomas, Director and Phil Cullen,
Policy Analyst, Technology and Architecture Group, Oce of Information and Technology
File:BPMN-AProcesswithNormalFlow.svg Source: https://upload.wikimedia.org/wikipedia/commons/b/b8/
BPMN-AProcesswithNormalFlow.svg License: Public domain Contributors: This le was derived from BPMN-
AProcesswithNormalFlow.jpg: <a href='//commons.wikimedia.org/wiki/File:BPMN-AProcesswithNormalFlow.jpg'
class='image'><img alt='BPMN-AProcesswithNormalFlow.jpg' src='https://upload.wikimedia.org/wikipedia/commons/thumb/3/
36/BPMN-AProcesswithNormalFlow.jpg/50px-BPMN-AProcesswithNormalFlow.jpg' width='50' height='28' srcset='https://upload.
wikimedia.org/wikipedia/commons/thumb/3/36/BPMN-AProcesswithNormalFlow.jpg/75px-BPMN-AProcesswithNormalFlow.
jpg 1.5x, https://upload.wikimedia.org/wikipedia/commons/thumb/3/36/BPMN-AProcesswithNormalFlow.jpg/
100px-BPMN-AProcesswithNormalFlow.jpg 2x' data-le-width='556' data-le-height='306' /></a>
Original artist: BPMN-AProcesswithNormalFlow.jpg: Tttt1234
File:BRM_Overview.jpg Source: https://upload.wikimedia.org/wikipedia/commons/1/1d/BRM_Overview.jpg License: Public domain
Contributors: FEA Consolidated Reference Model Document Original artist: FEA
File:Blueprint_Roadmap_to_Treasury_IT_Modernization.jpg Source: https://upload.wikimedia.org/wikipedia/commons/d/da/
Blueprint_Roadmap_to_Treasury_IT_Modernization.jpg License: Public domain Contributors: Treasury Technical Standards Prole
Original artist: Standards and Conguration Management Team (SCMT) of the Treasury Enterprise Architecture Sub-Council (TEAC)
File:Capabilities_Described_with_Architectures.jpg Source: https://upload.wikimedia.org/wikipedia/commons/7/7c/Capabilities_
Described_with_Architectures.jpg License: Public domain Contributors: DoDAF 1.0 Deskbook Original artist: DoD Architecture Frame-
work Working Group
142 CHAPTER 12. TEXT AND IMAGE SOURCES, CONTRIBUTORS, AND LICENSES

File:Commons-logo.svg Source: https://upload.wikimedia.org/wikipedia/en/4/4a/Commons-logo.svg License: PD Contributors: ? Origi-

nal artist: ?
File:Copyright-problem_paste_2.svg Source: https://upload.wikimedia.org/wikipedia/en/4/43/Copyright-problem_paste_2.svg Li-
cense: CC-BY-SA-3.0 Contributors:
commons:File:Copyright-problem paste 2.svg Original artist:
Ilmari Karonen, Rugby471 and Cronholm144
File:DOD_C4ISR_Architecture_Framework_Products_Mapped.jpg Source: https://upload.wikimedia.org/wikipedia/commons/6/
62/DOD_C4ISR_Architecture_Framework_Products_Mapped.jpg License: Public domain Contributors: Civilian Application of the DOD
C4ISR Architecture Framework: A Treasury Department Case Study Original artist: Rob Thomas II
File:DOE_Information_Architecture_Conceptual_Model.jpg Source: https://upload.wikimedia.org/wikipedia/commons/6/67/
DOE_Information_Architecture_Conceptual_Model.jpg License: Public domain Contributors: US DOE Information Architecture
Volume IV: Visio, page 3.1 Original artist: US DOE
File:DRM_Collaboration_Process.jpg Source: https://upload.wikimedia.org/wikipedia/commons/c/cb/DRM_Collaboration_Process.
jpg License: Public domain Contributors: FEA Consolidated Reference Model Document Original artist: FEA
File:DiffusionOfInnovation.png Source: https://upload.wikimedia.org/wikipedia/en/4/45/DiffusionOfInnovation.png License: CC-
BY-2.5 Contributors: ? Original artist: ?
File:DoDAF-V2.0-Viewpoints.jpg Source: https://upload.wikimedia.org/wikipedia/en/2/2c/DoDAF-V2.0-Viewpoints.jpg License: PD
Contributors:
DoD Architecture Framework Version 2.0
Original artist:
DoD
File:DoDAF-V2.0-Viewpoints2.jpg Source: https://upload.wikimedia.org/wikipedia/en/e/e8/DoDAF-V2.0-Viewpoints2.jpg License:
PD Contributors:
DoD Architecture Framework Version 2.0
Original artist:
DoD
File:DoDAF-V2.0-Viewpoints3.jpg Source: https://upload.wikimedia.org/wikipedia/en/7/79/DoDAF-V2.0-Viewpoints3.jpg License:
PD Contributors:
DoD Architecture Framework Version 2.0
Original artist:
DoD
File:DoDAF_Architecture_Framework_Version_2.0.jpg Source: https://upload.wikimedia.org/wikipedia/commons/c/c1/DoDAF_
Architecture_Framework_Version_2.0.jpg License: Public domain Contributors: http://dodcio.defense.gov/Portals/0/Documents/
DODAF/DoDAF_v2-02_web.pdf Original artist: DOD
File:DoDAF_Evolution.jpg Source: https://upload.wikimedia.org/wikipedia/commons/9/96/DoDAF_Evolution.jpg License: Public do-
main Contributors: DoD Architecture Framework Version 1.5 Original artist: DoD
File:DoDAF_Linkages_Among_Views.jpg Source: https://upload.wikimedia.org/wikipedia/commons/5/54/DoDAF_Linkages_
Among_Views.jpg License: Public domain Contributors: DoD Architecture Framework Version 1.5 Original artist: DoD
File:DoDAF_Perspectives_and_Decomposition_Levels.jpg Source: https://upload.wikimedia.org/wikipedia/commons/5/57/
DoDAF_Perspectives_and_Decomposition_Levels.jpg License: Public domain Contributors: DoDAF 1.5 Volume 2 Original artist: DoD
Architecture Framework Working Group
File:DoDAF_Support_to_the_Builder.jpg Source: https://upload.wikimedia.org/wikipedia/commons/9/91/DoDAF_Support_to_the_
Builder.jpg License: Public domain Contributors: DoD Architecture Framework Deskbook, Figure 2.10-1. Original artist: DoD
File:DoD_Architecture_Framework.jpg Source: https://upload.wikimedia.org/wikipedia/commons/d/d5/DoD_Architecture_
Framework.jpg License: Public domain Contributors: DoD Architecture Framework Version 1.5 Original artist: DoD
File:DoD_Architecture_Life_Cycle.jpg Source: https://upload.wikimedia.org/wikipedia/commons/0/00/DoD_Architecture_Life_
Cycle.jpg License: Public domain Contributors: DoD Architecture Framework Version 1.0 Deskbook Original artist: DoD Architecture
Framework Working Group
File:DoD_C4ISR_Framework.jpg Source: https://upload.wikimedia.org/wikipedia/commons/0/0f/DoD_C4ISR_Framework.jpg Li-
cense: Public domain Contributors: A Practical Guide to Federal Enterprise Architecture Original artist: Chief Information Ocer Council
File:DoD_Products_Map_to_the_Zachman_Framework_Cells.jpg Source: https://upload.wikimedia.org/wikipedia/commons/2/26/
DoD_Products_Map_to_the_Zachman_Framework_Cells.jpg License: Public domain Contributors: Architectural Framework Original
artist: P.Kathleen Sowell, The MITRE Corporation (original author;slide has been publicly released & widely used throughout Govern-
ment)
File:DoD_Standards-Based_Architecture_Planning_Process.jpg Source: https://upload.wikimedia.org/wikipedia/commons/b/b4/
DoD_Standards-Based_Architecture_Planning_Process.jpg License: Public domain Contributors: Technical Architecture Framework for
Information Management. Vol. 4: Overview, ver. 2.0, 6/94. Figure 1 Original artist: Department of Defense
File:EAAF_Maturity_levels.jpg Source: https://upload.wikimedia.org/wikipedia/commons/4/4a/EAAF_Maturity_levels.jpg License:
Public domain Contributors: Federal Enterprise Architecture Program EA Assessment Framework 2.0 Original artist: US OBM
File:EAAF_assessment_table.jpg Source: https://upload.wikimedia.org/wikipedia/commons/8/80/EAAF_assessment_table.jpg Li-
cense: Public domain Contributors: http://www.whitehouse.gov/omb/assets/fea_docs/OMB_EA_Assessment_Framework_v3_1_June_
2009.pdf Original artist: US OMB
12.2. IMAGES 143

File:EAP_mapped_to_the_Zachman_Framework.jpg Source: https://upload.wikimedia.org/wikipedia/commons/a/a8/EAP_

mapped_to_the_Zachman_Framework.jpg License: Public domain Contributors: Federal Enterprise Architecture Framework Version 1.1
Original artist: The Chief Information Ocers Council
File:EA_Development_Environment.jpg Source: https://upload.wikimedia.org/wikipedia/commons/0/02/EA_Development_
Environment.jpg License: Public domain Contributors: Treasury Enterprise Architecture Framework. Version 1, July 2000 Original artist:
Department of the Treasury Chief Information Ocer Council
File:Edit-clear.svg Source: https://upload.wikimedia.org/wikipedia/en/f/f2/Edit-clear.svg License: Public domain Contributors: The
Tango! Desktop Project. Original artist:
The people from the Tango! project. And according to the meta-data in the le, specically: Andreas Nilsson, and Jakub Steiner (although
minimally).
File:Enterprise_Architecture_Domain_Reference_Architecture.JPG Source: https://upload.wikimedia.org/wikipedia/commons/f/
f8/Enterprise_Architecture_Domain_Reference_Architecture.JPG License: Public domain Contributors: Own work Original artist:
Naveen607
File:Enterprise_Architecture_Process.jpg Source: https://upload.wikimedia.org/wikipedia/commons/b/bf/Enterprise_Architecture_
Process.jpg License: Public domain Contributors: A Practical Guide to Federal Enterprise Architecture Original artist: Chief Informa-
tion Ocer Council
File:Enterprise_Architecture_frameworks_utilized_2011.jpg Source: https://upload.wikimedia.org/wikipedia/commons/5/58/
Enterprise_Architecture_frameworks_utilized_2011.jpg License: Public domain Contributors: Engineering Enterprise Architecture: Call
to Action Original artist: Dennis E. Wisnosky
File:Enterprise_Engineering_and_the_Life-Cycle_Concept.jpg Source: https://upload.wikimedia.org/wikipedia/commons/f/f2/
Enterprise_Engineering_and_the_Life-Cycle_Concept.jpg License: Public domain Contributors: An Overview of GERAM Original artist:
JG Nell, NIST (redrawn by Marcel Douwe Dekker
File:Enterprise_Life_Cycle.jpg Source: https://upload.wikimedia.org/wikipedia/commons/9/90/Enterprise_Life_Cycle.jpg License:
Public domain Contributors: A Practical Guide to Federal Enterprise Architecture Original artist: Chief Information Ocer Council
File:Enterprise_Life_Cycle_activities.jpg Source: https://upload.wikimedia.org/wikipedia/commons/5/51/Enterprise_Life_Cycle_
activities.jpg License: Public domain Contributors: Treasury Enterprise Architecture Framework. Version 1, July 2000 Original artist:
Department of the Treasury Chief Information Ocer Council
File:Enterprise_Performance_Life_Cycle.jpg Source: https://upload.wikimedia.org/wikipedia/commons/6/61/Enterprise_
Performance_Life_Cycle.jpg License: Public domain Contributors: HHS Enterprise Architecture Governance Plan FY2007 Origi-
nal artist: U.S. Department of Health & Human Services
File:Evolution_of_Enterprise_Architecture_Frameworks.jpg Source: https://upload.wikimedia.org/wikipedia/commons/0/03/
Evolution_of_Enterprise_Architecture_Frameworks.jpg License: Public domain Contributors: Own update of the File:Enterprise
Architecture Framework Evolution.jpg Original artist: Original by Stephen Marley, NASA /SCI, update by Marcel Douwe Dekker
File:Example_of_Zachman_Framework_Rules.JPG Source: https://upload.wikimedia.org/wikipedia/commons/0/0d/Example_of_
Zachman_Framework_Rules.JPG License: Public domain Contributors: VAs Enterprise Architecture Original artist: Al Zuech, Acting
Chief Architect
File:FDICs_Enterprise_Architecture_Framework.jpg Source: https://upload.wikimedia.org/wikipedia/commons/3/31/FDIC%E2%
80%99s_Enterprise_Architecture_Framework.jpg License: Public domain Contributors: Implementation of E-Government Principles
Original artist: OIG
File:FEA_Consolidated_Reference_Model.png Source: https://upload.wikimedia.org/wikipedia/en/2/2a/FEA_Consolidated_
Reference_Model.png License: PD Contributors:
Federal Enterprise Architecture Framework Version 2 Original artist:
CIO Council
File:FEA_Reference_Models.jpg Source: https://upload.wikimedia.org/wikipedia/commons/6/61/FEA_Reference_Models.jpg Li-
cense: Public domain Contributors: Opportunity to Update FEA Reference Models Original artist: CIO Councel
File:Five-Year_Technology_Roadmap.jpg Source: https://upload.wikimedia.org/wikipedia/commons/a/a1/Five-Year_Technology_
Roadmap.jpg License: Public domain Contributors: Information Technology Strategic Plan 2008 - 2013 Original artist: CIO Council
File:Flag_of_Queensland.svg Source: https://upload.wikimedia.org/wikipedia/commons/0/04/Flag_of_Queensland.svg License: Public
domain Contributors: ? Original artist: ?
File:Flag_of_the_British_Army.svg Source: https://upload.wikimedia.org/wikipedia/commons/2/27/Flag_of_the_British_Army.svg
License: Public domain Contributors: Image of the ag: Flags & Heraldy Committee. Flying Flags in the United Kingdom. Flag Insti-
tute: The United Kingdoms National Flag Charity. Retrieved on 14 November 2015. Original artist: Created in Adobe Illustrator CS2,
based o the above sources, by Philip Ronan
File:Folder_Hexagonal_Icon.svg Source: https://upload.wikimedia.org/wikipedia/en/4/48/Folder_Hexagonal_Icon.svg License: Cc-by-
sa-3.0 Contributors: ? Original artist: ?
File:Framework_for_EA_Direction,_Description,_and_Accomplishment_Overview.jpg Source: https://upload.wikimedia.org/
wikipedia/commons/a/a1/Framework_for_EA_Direction%2C_Description%2C_and_Accomplishment_Overview.jpg License: Public
domain Contributors: Treasury Enterprise Architecture Framework. Version 1, July 2000 Original artist: Department of the Treasury
Chief Information Ocer Council
File:GERAM_Framework.jpg Source: https://upload.wikimedia.org/wikipedia/commons/9/90/GERAM_Framework.jpg License:
Public domain Contributors: An Overview of GERAM Original artist: JG Nell, NIST (redrawn by Marcel Douwe Dekker)
File:GERA_Enterprise-Entity_Concept--Type_3.jpg Source: https://upload.wikimedia.org/wikipedia/commons/b/b8/GERA_
Enterprise-Entity_Concept--Type_3.jpg License: Public domain Contributors: An Overview of GERAM Original artist: JG Nell, NIST
(redrawn by Marcel Douwe Dekker
144 CHAPTER 12. TEXT AND IMAGE SOURCES, CONTRIBUTORS, AND LICENSES

File:GERA_Enterprise-Entity_Concept.jpg Source: https://upload.wikimedia.org/wikipedia/commons/a/a3/GERA_

Enterprise-Entity_Concept.jpg License: Public domain Contributors: An Overview of GERAM Original artist: JG Nell, NIST
(redrawn by Marcel Douwe Dekker)
File:GERA_Generic-Reference-Architecture_Concept.jpg Source: https://upload.wikimedia.org/wikipedia/commons/1/1d/GERA_
Generic-Reference-Architecture_Concept.jpg License: Public domain Contributors: An Overview of GERAM Original artist: JG Nell,
NIST (redrawn by Marcel Douwe Dekker)
File:GERA_Life-Cycle_Concept.jpg Source: https://upload.wikimedia.org/wikipedia/commons/6/60/GERA_Life-Cycle_Concept.jpg
License: Public domain Contributors: An Overview of GERAM Original artist: JG Nell, NIST (redrawn by marcel Douwe Dekker
File:Government_Business_Reference_Model.svg Source: https://upload.wikimedia.org/wikipedia/commons/0/05/Government_
Business_Reference_Model.svg License: Public domain Contributors: FEA Records Management Prole, Version 1.0 Original artist: FEA
File:IDEF_Diagram_Example.jpg Source: https://upload.wikimedia.org/wikipedia/commons/3/31/IDEF_Diagram_Example.jpg Li-
cense: Public domain Contributors: <a data-x-rel='nofollow' class='external text' href='http://www.dau.mil/pubs/pdf/SEFGuide%2001-01.
pdf'>Systems Engineering Fundamentals.</a> Defense Acquisition University Press, 2001 Original artist: Defense Acquisition University
File:Information_and_IT-Enabled_Performance_Improvement_Lifecycle.jpg Source: https://upload.wikimedia.org/wikipedia/
commons/d/de/Information_and_IT-Enabled_Performance_Improvement_Lifecycle.jpg License: Public domain Contributors: http://
www.whitehouse.gov/omb/assets/fea_docs/OMB_EA_Assessment_Framework_v3_1_June_2009.pdf Original artist: US OBM
File:Integrated_Architecture.jpg Source: https://upload.wikimedia.org/wikipedia/commons/9/92/Integrated_Architecture.jpg License:
Public domain Contributors: DoD Architecture Framework Version 1.5 Original artist: DoD
File:Integrated_Process_Flow_for_VA_IT_Projects.jpg Source: https://upload.wikimedia.org/wikipedia/commons/3/37/Integrated_
Process_Flow_for_VA_IT_Projects.jpg License: Public domain Contributors: Department of Veterans Aairs CIO Conference Original
artist: Dr. John A. Gauss, Assistant Secretary for Information and Technology, va.gov.
File:Islm.svg Source: https://upload.wikimedia.org/wikipedia/commons/b/b9/Islm.svg License: CC-BY-SA-3.0 Contributors: Inkscape,
myself,en:Image:Islm.png and Image:IS-LM-Kurve.JPG Original artist: Derivative: Thomas Steiner; Islm.png: Original uploader was
Vikingstad at en.wikipedia. Later version(s) were uploaded by Jdevine at en.wikipedia.
File:James_Webb_Primary_Mirror.jpg Source: https://upload.wikimedia.org/wikipedia/commons/1/10/James_Webb_Primary_
Mirror.jpg License: Public domain Contributors: NASA Image of the Day Original artist: NASA/MSFC/David Higginbotham
File:LISI_Reference_Model_1997.jpg Source: https://upload.wikimedia.org/wikipedia/commons/e/e5/LISI_Reference_Model_1997.
jpg License: Public domain Contributors: C4ISR Architecture Framework Version 2.0. Original artist: Department of Defense, the Inte-
grated Architectures Panel of the C4ISR Integration Task Force.
File:Layers_of_the_Enterprise_Architecture.jpg Source: https://upload.wikimedia.org/wikipedia/commons/3/3f/Layers_of_the_
Enterprise_Architecture.jpg License: Public domain Contributors: The USDA Enterprise Architecture Program Original artist: Niles E
Hewlett, PMP CEA, Enterprise Architecture Team, USDA-OCIO
File:Levels_of_Enterprise_Architecture_Planning.jpg Source: https://upload.wikimedia.org/wikipedia/commons/b/be/Levels_of_
Enterprise_Architecture_Planning.jpg License: Public domain Contributors: Federal Information Architecture Initiatives Original artist:
Federal Aviation Administration
File:Library-logo.svg Source: https://upload.wikimedia.org/wikipedia/commons/5/53/Library-logo.svg License: CC0 Contributors: Own
work Original artist: Mononomic
File:Merge-arrows.svg Source: https://upload.wikimedia.org/wikipedia/commons/5/52/Merge-arrows.svg License: Public domain Con-
tributors: ? Original artist: ?
File:NIST_AE_model_1989.jpg Source: https://upload.wikimedia.org/wikipedia/commons/4/4d/NIST_AE_model_1989.jpg License:
Public domain Contributors: Information Management Directions: The Integration Challenge Original artist: Elizabeth N. Fong and Alan
H. Goldne
File:NIST_Enterprise_Architecture_Model.jpg Source: https://upload.wikimedia.org/wikipedia/commons/d/d0/NIST_Enterprise_
Architecture_Model.jpg License: Public domain Contributors: Federal Enterprise Architecture Framework Version 1.1 Original artist:
The Chief Information Ocers Council
File:NR-KPP-ProductsMatrix.jpg Source: https://upload.wikimedia.org/wikipedia/commons/f/fe/NR-KPP-ProductsMatrix.jpg Li-
cense: Public domain Contributors: CJCSI 6212.01E Original artist: DoD
File:Naval_Ensign_of_the_United_Kingdom.svg Source: https://upload.wikimedia.org/wikipedia/commons/9/9c/Naval_Ensign_of_
the_United_Kingdom.svg License: Public domain Contributors: ? Original artist: ?
File:OBASHI_Application_Element.jpg Source: https://upload.wikimedia.org/wikipedia/commons/1/1c/OBASHI_Application_
Element.jpg License: CC BY-SA 3.0 Contributors: Own work Original artist: Fergus Cloughley
File:OBASHI_Business_Element.jpg Source: https://upload.wikimedia.org/wikipedia/commons/c/c7/OBASHI_Business_Element.
jpg License: CC BY-SA 3.0 Contributors: Own work Original artist: Fergus Cloughley
File:OBASHI_Business_and_IT_Diagram.jpg Source: https://upload.wikimedia.org/wikipedia/commons/6/61/OBASHI_Business_
and_IT_Diagram.jpg License: CC BY-SA 3.0 Contributors: Own work Original artist: Stroma Software (UK) Ltd.
File:OBASHI_Dataflow_Analysis_View.jpg Source: https://upload.wikimedia.org/wikipedia/commons/5/5f/OBASHI_Dataflow_
Analysis_View.jpg License: CC BY-SA 3.0 Contributors: Own work (Original text: self-made) Original artist: Stroma Software (UK)
Limited
File:OBASHI_Hardware_Element.jpg Source: https://upload.wikimedia.org/wikipedia/commons/c/c9/OBASHI_Hardware_Element.
jpg License: CC BY-SA 3.0 Contributors: Own work Original artist: Fergus Cloughley
File:OBASHI_Infrastructure_Element.jpg Source: https://upload.wikimedia.org/wikipedia/commons/e/e0/OBASHI_Infrastructure_
Element.jpg License: CC BY-SA 3.0 Contributors: Own work Original artist: Fergus Cloughley
File:OBASHI_Owner_element.jpg Source: https://upload.wikimedia.org/wikipedia/commons/5/5d/OBASHI_Owner_element.jpg Li-
cense: CC BY-SA 3.0 Contributors: Own work Original artist: Fergus Cloughley
12.2. IMAGES 145

File:OBASHI_System_Element.jpg Source: https://upload.wikimedia.org/wikipedia/commons/a/a2/OBASHI_System_Element.jpg

License: CC BY-SA 3.0 Contributors: Own work Original artist: Fergus Cloughley
File:Office-book.svg Source: https://upload.wikimedia.org/wikipedia/commons/a/a8/Office-book.svg License: Public domain Contribu-
tors: This and myself. Original artist: Chris Down/Tango project
File:OilCleanupAfterValdezSpill.jpg Source: https://upload.wikimedia.org/wikipedia/commons/5/52/OilCleanupAfterValdezSpill.jpg
License: Public domain Contributors: ? Original artist: ?
File:Performance_Reference_Model.jpg Source: https://upload.wikimedia.org/wikipedia/commons/2/2b/Performance_Reference_
Model.jpg License: Public domain Contributors: FEA Consolidated Reference Model Document Original artist: FEA
File:Portal-puzzle.svg Source: https://upload.wikimedia.org/wikipedia/en/f/fd/Portal-puzzle.svg License: Public domain Contributors: ?
Original artist: ?
File:Process_and_data_modeling.svg Source: https://upload.wikimedia.org/wikipedia/commons/0/01/Process_and_data_modeling.
svg License: Public domain Contributors:
Creating a strategic plan for conguration management using Computer Aided Software Engineering (CASE) tools. Original artist:
Process_and_data_modeling.jpg: Paul R. Smith. Redrawn by Marcel Douwe Dekker
File:Question_book-new.svg Source: https://upload.wikimedia.org/wikipedia/en/9/99/Question_book-new.svg License: Cc-by-sa-3.0
Contributors:
Created from scratch in Adobe Illustrator. Based on Image:Question book.png created by User:Equazcion Original artist:
Tkgd2007
File:RM-ODP_viewpoints.jpg Source: https://upload.wikimedia.org/wikipedia/commons/7/7b/RM-ODP_viewpoints.jpg License: CC
BY-SA 3.0 Contributors: Own work Original artist: Marcel Douwe Dekker
File:SDLC-Maintenance-Highlighted.png Source: https://upload.wikimedia.org/wikipedia/commons/7/7e/
SDLC-Maintenance-Highlighted.png License: CC BY-SA 3.0 Contributors: Own work Original artist: Dzonatas
File:SDLC_Phases_Related_to_Management_Controls.jpg Source: https://upload.wikimedia.org/wikipedia/commons/a/a2/SDLC_
Phases_Related_to_Management_Controls.jpg License: Public domain Contributors: Systems Development Life-Cycle Policy p.13 Origi-
nal artist: U.S. House of Representatives
File:SDLC_Work_Breakdown_Structure.jpg Source: https://upload.wikimedia.org/wikipedia/commons/8/82/SDLC_Work_
Breakdown_Structure.jpg License: Public domain Contributors: Systems Development Life-Cycle Policy p.13 Original artist: U.S. House
of Representatives
File:Sample_Elements_of_an_Enterprise_Architecture_(1989).jpg Source: https://upload.wikimedia.org/wikipedia/commons/1/17/
Sample_Elements_of_an_Enterprise_Architecture_%281989%29.jpg License: Public domain Contributors: Information Management Di-
rections: The Integration Challenge Original artist: Elizabeth N. Fong and Alan H. Goldne, 1989-09
File:Self-Funding_Model_for_Future_IT_Development.jpg Source: https://upload.wikimedia.org/wikipedia/commons/c/cc/
Self-Funding_Model_for_Future_IT_Development.jpg License: Public domain Contributors: Information Technology Strategic Plan
2008 - 2013 Original artist: CIO Council
File:Service_Component_Reference_Model.jpg Source: https://upload.wikimedia.org/wikipedia/commons/6/62/Service_
Component_Reference_Model.jpg License: Public domain Contributors: FEA Records Management Prole, Version 1.0 Original
artist: FEA
File:Simplification_Zachman_Enterprise_Framework.jpg Source: https://upload.wikimedia.org/wikipedia/commons/3/3e/
Simplification_Zachman_Enterprise_Framework.jpg License: Public domain Contributors: VAs Enterprise Architecture Original artist:
Al Zuech, Director, Enterprise Architecture Service at the US Department of Veterans Aairs.
File:Stroma_Business_and_IT_Diagram.jpg Source: https://upload.wikimedia.org/wikipedia/commons/2/24/Stroma_Business_and_
IT_Diagram.jpg License: CC BY-SA 3.0 Contributors: Own work Original artist: Stroma Software UK
File:Structure_of_the_FEAF_Components.jpg Source: https://upload.wikimedia.org/wikipedia/commons/1/11/Structure_of_the_
FEAF_Components.jpg License: Public domain Contributors: A Practical Guide to Federal Enterprise Architecture Original artist: Chief
Information Ocer Council
File:System_Interface_Description,_Levels_1,_2,_3,_4Generic_Examples.jpg Source: https://upload.wikimedia.org/wikipedia/
commons/4/4a/System_Interface_Description%2C_Levels_1%2C_2%2C_3%2C_4%E2%80%94Generic_Examples.jpg License: Pub-
lic domain Contributors: Treasury Enterprise Architecture Framework. Version 1, July 2000 Original artist: Department of the Treasury
Chief Information Ocer Council
File:Systems_Development_Life_Cycle.jpg Source: https://upload.wikimedia.org/wikipedia/commons/b/bb/Systems_Development_
Life_Cycle.jpg License: Public domain Contributors: INFORMATION RESOURCES MANAGEMENT Original artist: US Department
of Justice (redrawn by Eugene Vincent Tantog)
File:TEAF_Matrix_of_Views_and_Perspectives.svg Source: https://upload.wikimedia.org/wikipedia/commons/0/00/TEAF_Matrix_
of_Views_and_Perspectives.svg License: CC0 Contributors: Based on TEAF_Matrix_of_Views_and_Perspectives.jpg Original artist:
mpan
File:TEAF_Products.jpg Source: https://upload.wikimedia.org/wikipedia/commons/1/16/TEAF_Products.jpg License: Public domain
Contributors: A Practical Guide to Federal Enterprise Architecture Original artist: Chief Information Ocer Council
File:TEAF_Work_Products_for_EA_Direction,_Description,_and_Accomplishment.jpg Source: https://upload.wikimedia.org/
wikipedia/commons/c/c0/TEAF_Work_Products_for_EA_Direction%2C_Description%2C_and_Accomplishment.jpg License: Public
domain Contributors: A Practical Guide to Federal Enterprise Architecture Original artist: Chief Information Ocer Council
File:TOGAF_ADM.jpg Source: https://upload.wikimedia.org/wikipedia/commons/a/a1/TOGAF_ADM.jpg License: Public domain
Contributors: Architectural Framework Applied Sciences Program, Geosciences Interoperability Oce, Stephen Marley NASA /SCI. Orig-
inal artist: Stephen Marley, NASA /SCI
146 CHAPTER 12. TEXT AND IMAGE SOURCES, CONTRIBUTORS, AND LICENSES

File:Technical_Reference_Model.jpg Source: https://upload.wikimedia.org/wikipedia/commons/1/1b/Technical_Reference_Model.

jpg License: Public domain Contributors: FEA Consolidated Reference Model Document Original artist: FEA
File:Tecnology_Life_Cycle.png Source: https://upload.wikimedia.org/wikipedia/commons/d/db/Tecnology_Life_Cycle.png License:
CC-BY-SA-3.0 Contributors: ? Original artist: ?
File:The_Zachman_Framework_of_Enterprise_Architecture.jpg Source: https://upload.wikimedia.org/wikipedia/commons/5/5c/
The_Zachman_Framework_of_Enterprise_Architecture.jpg License: CC BY-SA 3.0 Contributors: Own work Original artist:
Ideasintegration(image) + SunSw0rd(text)
File:Treasury_Enterprise_Architecture_Framework_concept.jpg Source: https://upload.wikimedia.org/wikipedia/commons/a/a5/
Treasury_Enterprise_Architecture_Framework_concept.jpg License: Public domain Contributors: A Practical Guide to Federal Enterprise
Architecture Original artist: Chief Information Ocer Council
File:US_Navy_080111-N-8273J-033_Chief_of_Naval_Operations_(CNO)_Adm._Gary_Roughead_talks_with_project_
managers_while_touring_Pacific_Beacon,_the_Navy{}s_first_large-scale_housing_privatization_facility_for_single_Sailors.
jpg Source: https://upload.wikimedia.org/wikipedia/commons/2/2e/US_Navy_080111-N-8273J-033_Chief_of_Naval_Operations_
%28CNO%29_Adm._Gary_Roughead_talks_with_project_managers_while_touring_Pacific_Beacon%2C_the_Navy%27s_first_
large-scale_housing_privatization_facility_for_single_Sailors.jpg License: Public domain Contributors:
This Image was released by the United States Navy with the ID 080111-N-8273J-033 <a class='external text' href='//commons.wikimedia.
org/w/index.php?title=Category:Files_created_by_the_United_States_Navy_with_known_IDs,<span>,&,</span>,lefrom=080111-N-
8273J-033#mw-category-media'>(next)</a>.
This tag does not indicate the copyright status of the attached work. A normal copyright tag is still required. See Commons:Licensing for more information.
Original artist: U.S. Navy photo by Mass Communication Specialist 1st Class Tini M. Jones
File:Unbalanced_scales.svg Source: https://upload.wikimedia.org/wikipedia/commons/f/fe/Unbalanced_scales.svg License: Public do-
main Contributors: ? Original artist: ?
File:VA_EA_Meta-Model_Cell_Details_Enlarged.jpg Source: https://upload.wikimedia.org/wikipedia/commons/b/b1/VA_EA_
Meta-Model_Cell_Details_Enlarged.jpg License: Public domain Contributors: [This diagram is the exclusive work of Albin Martin Zuech
of Annapolis Maryland, who placed it in the public domain in 2001. Al Zuech maintains the original Visio Diagram in numerous stages
of its development between 2000 and present. Al Zuech was the Director, Enterprise Architecture Service at the Department of Veterans
Aairs from 2001 until 2007. He incorporated this diagram within the VA-EA to provide a symbolic representation of the Metamodel
that VA used, under his direction, to describe the One-VA Enterprise Architecture and to build an EA Repository without the use of
Commercial EA Repository Software.
The One-VA EA repository was developed using an object oriented database within the Caliber-RM Software Product. Caliber-RM is
intended to be used as a software conguration management tool; not as an EA repository. However this tool permitted dening entities
and relationships and for dening properties upon both entities and relationships, which made it sucient for building an EA repository,
considering the technology that was available in early 2003. Mr. Zuechs motivation in selecting this tool was two-fold: (1) none of the
commercial repository tools that were available at that time provided a true Zachman Framework representation of models and relationships;
and (2) the available commercial tools were highly proprietary and made it dicult to incorporate best-of-breed tools and representations
from other vendors or form open sources.
This diagram emphasizes several important interpretations of the Zachman Framework and its adaptation to Information technology In-
vestment Management. (1) Progressing through the rows from top to bottom, one can trace-out the System Development Lifecycle (SDLC)
which is a de facto standard across the Information Industry; (2) The diagram emphasizes the importance of the often-neglected Zachman
Row-Six (the Integrated, Operational Enterprise View). Representations in Mr. Zuechs interpretation of Zachman row-six consist, largely,
of measurable service improvements and cost savings/avoidance that result from the business process and technology innovations that were
developed across rows two through ve. Row-six provides measured Return on Investment for Individual Projects and, potentially, for the
entire investment portfolio. Without row-six the Zachman Framework only identies sunk-cost the row-six ROI permits the framework
to measure benets and to be used in a continuous improvement process, capturing best practices and applying them back through row-two.
Mr. Zuech lectures on these topics at the Federal Enterprise Architecture Certication Institute (FEAC) in Washington D.C. and may be
reached for comment at azuech@luxsci.net
] Original artist: Albin Martin Zuech, Director, VA Enterprise Architecture Service (Retired)
File:VA_EA_Repository_Introduction.jpg Source: https://upload.wikimedia.org/wikipedia/commons/e/eb/VA_EA_Repository_
Introduction.jpg License: Public domain Contributors: Process...Modeling...EA Repository Development Original artist: va.gov
File:VA_Zachman_Framework_Portal.jpg Source: https://upload.wikimedia.org/wikipedia/commons/e/e4/VA_Zachman_
Framework_Portal.jpg License: Public domain Contributors: VAs Enterprise Architecture Original artist: Al Zuech, Director,
Enterprise Architecture Service at the US Department of Veterans Aairs.
File:Wiktionary-logo-v2.svg Source: https://upload.wikimedia.org/wikipedia/commons/0/06/Wiktionary-logo-v2.svg License: CC BY-
SA 4.0 Contributors: Own work Original artist: Dan Polansky based on work currently attributed to Wikimedia Foundation but originally
created by Smurrayinchester
File:ZFArticlePages.jpg Source: https://upload.wikimedia.org/wikipedia/en/f/f1/ZFArticlePages.jpg License: Fair use Contributors:
"A Framework for Information Systems Architecture". In: IBM Systems Journal, vol. 38, no. 2&3, 1999. IBM Original artist: ?
File:Zachman_Framework_Detailed.jpg Source: https://upload.wikimedia.org/wikipedia/commons/d/da/Zachman_Framework_
Detailed.jpg License: CC-BY-SA-3.0 Contributors: self-made, combination of File:Zachman Framework Basics.jpg and File:Zachman
Framework.jpg Original artist: Marcel Douwe Dekker based on earlier work of Phogg2 et al.
File:Zachman_Frameworks_Collage.jpg Source: https://upload.wikimedia.org/wikipedia/commons/b/b5/Zachman_Frameworks_
Collage.jpg License: CC BY-SA 3.0 Contributors: self-made, based on multiple Zachman Framework representations:
1. James McGovern, Scott W. Ambler et al. (2003) in the A Practical Guide to Enterprise Architecture p. 127 are given
an example instance of the Zachman Framework with 5 rows and 6 columns
2. Marc Lankhorst (2005) in Enterprise Architecture at Work on page 24 gives an image of The Zachman Framework
(Zachman 1987)": A 5 rows and 6 column matrix with the cells empty
12.3. CONTENT LICENSE 147

3. William H. Inmon (2005). Building the Data Warehouse, on page 155: A 6 rows and 6 column matrix with the cells
empty
4. The Zachman Framework: An Introduction by David C. Hay. Published: June 1, 1997, see <a data-x-rel='nofollow'
class='external text' href='http://www.tdan.com/view-articles/4140/'>here</a>: A 6 rows and 6 column matrix with the cells
with text
5. A modied 1987 Framework by Paul Harmon (2003) in Business Process Change page 319: A 6 rows and 3 column
matrix with the cells with text
Original artist: Marcel Douwe Dekker

12.3 Content license

Creative Commons Attribution-Share Alike 3.0