Visit https://ebooknice.

com to download the full version and

explore more ebooks

(Ebook) Software architect bootcamp by Mowbray,

Thomas J.; Malveau, Raphael C.; Safari Tech Books
Online ISBN 9780131412279, 0131412272

_____ Click the link below to download _____

https://ebooknice.com/product/software-architect-
bootcamp-21347440

Explore and download more ebooks at ebooknice.com

Here are some recommended products that might interest you.
You can download now and explore!

(Ebook) Biota Grow 2C gather 2C cook by Loucas, Jason;

Viles, James ISBN 9781459699816, 9781743365571,
9781925268492, 1459699815, 1743365578, 1925268497
https://ebooknice.com/product/biota-grow-2c-gather-2c-cook-6661374

ebooknice.com

(Ebook) Matematik 5000+ Kurs 2c Lärobok by Lena

Alfredsson, Hans Heikne, Sanna Bodemyr ISBN 9789127456600,
9127456609
https://ebooknice.com/product/matematik-5000-kurs-2c-larobok-23848312

ebooknice.com

(Ebook) SAT II Success MATH 1C and 2C 2002 (Peterson's SAT

II Success) by Peterson's ISBN 9780768906677, 0768906679

https://ebooknice.com/product/sat-ii-success-
math-1c-and-2c-2002-peterson-s-sat-ii-success-1722018

ebooknice.com

(Ebook) C Interfaces and Implementations: Techniques for

Creating Reusable Software by Safari Books Online LLC

https://ebooknice.com/product/c-interfaces-and-implementations-
techniques-for-creating-reusable-software-58746878

ebooknice.com
(Ebook) Piano adventures Performance 3b by Nancy and
Randall Faber

https://ebooknice.com/product/piano-adventures-performance-3b-52393612

ebooknice.com

(Ebook) Master SAT II Math 1c and 2c 4th ed (Arco Master

the SAT Subject Test: Math Levels 1 & 2) by Arco ISBN
9780768923049, 0768923042
https://ebooknice.com/product/master-sat-ii-math-1c-and-2c-4th-ed-
arco-master-the-sat-subject-test-math-levels-1-2-2326094

ebooknice.com

(Ebook) Cambridge IGCSE and O Level History Workbook 2C -

Depth Study: the United States, 1919-41 2nd Edition by
Benjamin Harrison ISBN 9781398375147, 9781398375048,
1398375144, 1398375047
https://ebooknice.com/product/cambridge-igcse-and-o-level-history-
workbook-2c-depth-study-the-united-states-1919-41-2nd-edition-53538044

ebooknice.com

(Ebook) The Software Architect Elevator by Gregor Hohpe

https://ebooknice.com/product/the-software-architect-elevator-21809672

ebooknice.com

(Ebook) Monster Girl Safari Omnibus Edition: Books 1-3 by

Roland Carlsson ISBN B0BWNWYXSC

https://ebooknice.com/product/monster-girl-safari-omnibus-edition-
books-1-3-47888218

ebooknice.com
Software architect bootcamp 2nd ed Edition Mowbray
Digital Instant Download
Author(s): Mowbray, Thomas J.; Malveau, Raphael C.; Safari Tech Books
Online
ISBN(s): 9780131412279, 0131412272
Edition: 2nd ed
File Details: PDF, 2.33 MB
Year: 2003
Language: english
Software Architect
Bootcamp
Software Architect
Bootcamp

Second Edition

Raphael Malveau
Thomas J. Mowbray, Ph.D.

PRENTICE HALL
Professional Technical Reference
Upper Saddle River, NJ 07458
www.phptr.com
A CIP catalog record for this book can be obtained from the Library of Congress.

Editorial/production supervision: BooksCraft, Inc., Indianapolis, IN

Cover design director: Jerry Votta
Cover design: Talar A. Boorujy
Art director: Gail Cocker-Bogusz
Manufacturing manager: Alexis R. Heydt-Long
Executive editor: Paul Petralia
Editorial assistant: Michelle Vincenti
Marketing manager: Chris Guzikowski
Full-service production manager: Anne R. Garcia

© 2004 by Pearson Education, Inc.

Publishing as Prentice Hall Professional Technical Reference
Upper Saddle River, New Jersey 07458

Company and product names mentioned herein are the trademarks or registered trademarks of their respective owners.

Prentice Hall books are widely used by corporations and government agencies for training, marketing, and resale.

Prentice Hall PTR offers excellent discounts on this book when ordered in quantity for bulk purchases or special sales.
For more information,
please contact:
U.S. Corporate and Government Sales
1-800-382-3419
corpsales@pearsontechgroup.com

For sales outside of the U.S., please contact:

International Sales
1-317-581-3793
international@pearsontechgroup.com

All rights reserved. No part of this book may be reproduced, in any form or by any means, without permission in writing
from the publisher.

Printed in the United States of America

2nd printing

ISBN 0-13-141227-2

Pearson Education LTD.

Pearson Education Australia PTY, Limited
Pearson Education Singapore, Pte. Ltd.
Pearson Education North Asia Ltd.
Pearson Education Canada, Ltd.
Pearson Educación de Mexico, S.A. de C.V.
Pearson Education—Japan
Pearson Education Malaysia, Pte. Ltd.
 Contents

Preface xiii

ONE Introduction 1
1.1 Defining Software Architecture 2
1.2 The Need for the Software Architect 3
1.3 Goals 3
Industry Background and History 4
Technology Trends and Architectural Styles 4
Tactics 5
Strategies 5
Tools 6
Mindset 6

TWO Military History 7

2.1 Software Architecture Approaches 8
Architectural Approaches 8
Common Principles 9
Architectural Controversies 10

v
vi Contents

2.2 The Architectural Paradigm Shift 11

2.3 The Need for Software Architecture 14
2.4 Zachman Framework 15
2.5 Reference Model for Open Distributed Processing 17
2.6 Enterprise Architecture Standards 24
Federal Enterprise Architecture Framework 25
2.7 Design Patterns 27
2.8 AntiPatterns 35
2.9 Software Design-Level Model 37
2.10 Conclusions 40
Exercises 41

THREE Software Architecture:

Basic Training 45
3.1 Object-Oriented Technology 47
Databases and Objects 49
Object in the Mainstream 49
Scripting Languages 50
3.2 Component-Oriented Technology 50
Components versus Objects 50
Component Infrastructures 52
Component Software Design Patterns 53
Component Software Architecture 54
3.3 Technology Ownership 55
Proprietary Software 55
Open Systems Software 56
3.4 Client-Server Technology 59
History 61
Distributed Components 64
Contents vii

3.5 Internet Technology 70

eXtensible Markup Language (XML) 70
Sun Microsystems J2EE and Microsoft’s .Net 72
Web Services 73
3.6 Architectural Layers and When to Use Them 74
3.7 Software Application Experience 79
3.8 Technology and Application Architecture 81
3.9 Applying Standards to Application Systems 84
3.10 Distributed Infrastructures 88
3.11 Conclusions 98
Exercises 99

FOUR Software Architecture:

Going to War 103
4.1 Software Architecture Paradigm Shift 103
Traditional System Assumptions 104
Distribution Reverses Assumptions 104
Multiorganizational Systems 105
Making the Paradigm Shift 105
4.2 Doing Software Incorrectly 106
This Old Software 106
An Example: Doing Software Incorrectly 107
Enter the Knight: Heroic Programmers 108
4.3 Doing Software Correctly:
Enterprise Architecture Development 109
Architecture-Centered Process 110
Step 1: System Envisioning 112
Step 2: Requirements Analysis 112
Step 3: Mockup Prototype 113
Step 4: Architectural Planning 113
viii Contents

Step 5: Architectural Prototype 118

Step 6: Project Planning 118
Step 7: Parallel Development 119
Step 8: System Transition 120
Step 9: Operations and Maintenance 120
Step 10: System Migration 121
4.4 Bottom Line: Time, People, and Money 121
4.5 Conclusions 122
Exercises 123

FIVE Software Architecture:

Drill School 125
5.1 Architecture Versus Programming 126
The Fractal Model of Software 126
Major Design Forces 126
The Effect of Scale on Forces 127
Software Design Levels 127
Using Design Levels 128
5.2 Managing Complexity Using Architecture 128
Creating Complexity 128
Option 1: Sweep It under a Rug 129
Option 2: Hide It in a Crowd 130
Option 3: Ignore It 130
Option 4: Slice It 131
Option 5: Dice It 131
5.3 Systems Integration 131
5.4 Making the Business Case 137
5.5 Architectural Linkage to Software Development 141
5.6 Conclusions 147
Exercises 148
Contents ix

SIX Leadership Training 151

6.1 Leadership Is a Necessary, Learnable Skill 152
6.2 The Architect as Team Builder 153
6.3 Always Insist on Excellence in Deliverables 154
6.4 Architect’s Walkthrough 160
6.5 Project Management Basics 164
Planning Phase 165
Analysis Phase 165
Implementation Phase 165
6.6 Architect’s Role Versus Project Management 166
Planning Phase 168
Analysis Phase 168
Implementation Phase 168
6.7 Conclusions 169
Exercises 169

SEVEN Software Architecture:

Jump School 171
7.1 Process 171
Process Prerequisites 172
A Basic Component Framework Software Design Process 174
7.2 Creating New Processes 179
7.3 Teamwork 180
7.4 Conclusions 187
Exercises 187
x Contents

EIGHT Communications Training 195

8.1 Communications Challenges 196
8.2 Responsibility-Driven Development 197
8.3 Communication Responsibilities 198
8.4 Handling Feedback 199
8.5 Evolution of Software Design Notations 200
8.6 Unified Modeling Language Notation 202
8.7 Model-Driven Architecture 215
8.8 Conclusions 218
Exercises 218

NINE Software Architecture:

Intelligence Operations 221
9.1 Architectural Mining 222
Top Down and Bottom Up 222
Architectural Farming 223
Architectural Mining Process 223
Applicability of Mining 224
Mining for Success 225
Horizontal Versus Vertical 225
Horizontal Design Elements 228
What About Traceability? 230
Designing for Future Applications 230
9.2 Architectural Iteration 231
Software Process Background 232
The Role of the Architecture Process 234
The Macro Process: Architectural Iteration 236
Contents xi

Developer Reaction to Architecture 238

After Intelligence, Iterate the Design 240
The Micro Process: Architecture with Subprojects 242
Architecture in Chaos 244
9.3 Architectural Judgment 246
Problem Solving 247
Review and Inspection 249
9.4 Conclusions 251
Exercises 251

TEN Software Architecture:

Psychological Warfare 255
10.1 Alternative Learning 256
10.2 Internal Control 257
10.3 Expectation Management 257
10.4 Psychology of Truth 258
10.5 Software Envisioning 259
10.6 Reference Models and Human Psychology 261
Reference Models as Perception 263
Biological Response Model 264
Group Applications of Response 265
10.7 Example: Reference Selling 266
10.8 Psychology of Ownership 268
10.9 Psychological Akido 269
10.10 Conclusions 272
Exercises 272
xii Contents

ELEVEN Software Architecture:

Career Advice 277
11.1 Read, Read, Read 278
11.2 Word of Caution 279
Nascent Body of Knowledge 279
Confusion and Gurus 280
The Management Trap 280
11.3 Making a Name 281
11.4 Becoming an Expert 283
11.5 Conclusions 284
Exercises 284

Appendix A Architecture Example: Test Results Reporting System 287

Appendix B Design Templates and Examples 307

Appendix C Glossary of Software Architecture Terminology 325

Appendix D Acronyms 333

Appendix E Bibliography 335

Index 341
 Preface

Why have a second edition of Software Architecture Bootcamp? It is safe to

say that there have been sweeping changes in the IT industry since the release
of the first edition. The era of limitless demand for IT talent is over. The bal-
ance of power has shifted away from IT shops and back toward the business
and financial areas. No longer will a nifty technical idea spur large investments
without a sound business plan and proven management expertise.
Companies no longer race to make IT investments to gain competitive
edge. Such thinking has been replaced by the need to justify IT investments by
demonstrating how greater efficiencies and return on investments will be
achieved . Corporations are more willing now than ever to alter their business
processes in order to make better use of commercial products or outsourcing.
Few people will be successful in the current IT environment for very long
simply by developing software. Now, more than ever before, it is absolutely
imperative to create additional value. Corporations have also realized that
speed in developing software solutions is not beneficial to them if the software
does not meet their business needs and if it is not of sufficient quality to be de-
pendable. The business community has come to realize that quality matters,
planning matters, and technical leadership that incorporates both matters.
Rather than having business analysts and marketing departments rack their
brains to figure out how to use their IT group to achieve business advantage,
the burden has shifted to the IT group and the expectation that it will have the
business acumen to align its focus with that of the organization. While this is
not new for some organizations, it is very different than the way IT business
was conducted at the height of the IT boom when the “new economy” IT gurus
would advocate rushing something to market first in the hope that a market
could be identifed or developed for it down the road.
In addition to the business environment—the mainstream—most relevant
technologies have changed considerably. Interestingly, while it is a different
world, it is also, in many respects, a far simpler world than it was a few years
xiii
xiv Preface

ago. While there have been a number of new technologies introduced, they
have been offset by the rapid consolidation of technical approaches and sup-
porting products. Internet technologies are the undisputed king, especially for
interoperability between corporations. Microsoft has been wildly successful in
its efforts to develop an enterprise platform that rivals the developments occur-
ing in the Java community. During the lengthy recession at the start of this
century, IT companies either consolidated or they failed, leaving a more man-
agable number of solutions, most of which were interoperable with one or both
of the major enterprise platforms. To a large degree, innovative solutions es-
caped the middleware layer of the enterprise and focused more on meeting spe-
cific business needs where a larger financial payoff exists. In order to maintain
technical leadership, software architects need guidance on new technological
areas not addressed in the first edition, such as enterprise architecture and
model-driven development. The second edition also gives greater emphasis to
working with project management to satisfy business objectives.
Finally, we felt that there was an opportunity to do a better job with the
timeless topics by providing more specifics and introducing greater clarity to
the material presented. We were concerned that the first edition might have
been misperceived as focusing too much on career advancement. We hope this
new edition will make it clear that our primary purpose is to equip software ar-
chitects with the tools to deliver greater value to projects. Few people remem-
ber the architects of the cornerstones of civilization—Egypt, Rome, and New
York. However, all remember their creations. It is what gets created and built
that matters, not the architects or other team members behind them.
In summary, this book has been updated to better meet the needs of soft-
ware architects today. The second edition gives you the essential information
to succeed as a software architect with an emphasis on the specific needs of
projects in the current IT environment. Since the prosperous times that existed
when the first edition was released may not return for a long time, it is impor-
tant that software architects have a broad base of skills to meet challenges be-
yond the technical or organization areas. The new edition of Software
Architecture Bootcamp provides a crucial portion of the knowledge base soft-
ware professionals require in order to remain major contributors of value to or-
ganizations and customers.

RAPHAEL MALVEAU
THOMAS J. MOWBRAY, PH.D.
McLean, Virginia, U.S.A.
 O N E

Introduction

S
o you want to become a software architect? Or perhaps you are already a
software architect, and you want to expand your knowledge of the disci-
pline? This book is about achieving and maintaining success in your soft-
ware career. It is also about an important new software discipline and
technology, software architecture. It is not a book about getting rich in the soft-
ware business; the advice offered here is aimed at helping the reader achieve
professional fulfillment. Although the monetary rewards may be substantial,
many people in software architecture are motivated by being continuous tech-
nical contributors throughout their careers. In other words, most software archi-
tects want to do technically interesting work, no matter how successful and
experienced they become. So the goal of this book is to help readers achieve
career success as software architects and then to maintain their success.
In this book both heavyweight and lightweight approaches to software ar-
chitecture are covered. The software architect has many roles: part politician,
part technologist, part author, part evangelist, part mentor, part psychologist,
and more. At the apex of the software profession, the software architect must
understand the viewpoints and techniques of many players in the information
technology (IT) business. What many people would consider the bulk of soft-
ware architecture, the discipline and process of writing specifications, is de-
scribed, as are those human aspects of the practice that are most challenging to
architects, both new and experienced.

1
2 Chapter One Introduction

So what does a software architect do? A software architect both designs

software and guides others in the creation of software. The architect serves
both as a mentor and as the person who documents and codifies how tradeoffs
are to be made by other software designers and developers. It is common to see
the architect serve as a trainer, disciplinarian, and even counselor to other
members of the development team.

1.1 Defining Software Architecture

An increasing number of software professionals are claiming the title of soft-

ware architect; however, very few of these people understand what software ar-
chitecture is.
Few people have considered the question: “What is architecture?” The
term architecture is one of those most often misused. The following section
discusses one of the common misuses; then the question “What is architec-
ture?” is answered using a conceptual standard that is widely used today.
Too often, architectures are used as sales tools rather than technical blue-
prints. In a typical scenario, a fast-talking technical manager (the “architect”)
presents a few high-level viewgraphs (“architectures”) to convince his audi-
ence of the greatness of his product or system. This is a presentation of a mar-
keting architecture. A marketing architecture is a description of an architectural
solution at such a high and abstract level that its true feasibility cannot be de-
termined. Most marketing architectures are directed toward customers, not to-
ward software developers. Marketing architectures are fine for advertising the
features of commercial products, but they provide only limited technical infor-
mation for developers.
The problem with marketing architectures is that they are decoupled from
the development process. The so-called architect is a manager who delegates
most technical details to individual developers. Unless the architect manages
the computational model (including subsystem interfaces), the architecture is
unlikely to deliver any real technical benefits. Architectural benefits that are
easily compromised include system adaptability (for new business needs) and
system extensibility (for exploitation of new technologies).
Despite the many competing definitions, experts emphasize the impor-
tance of architecture, especially for component-based applications. As compo-
nent reuse and software complexity increase, architecture is growing
dramatically in importance. In subsequent sections, several architecture-
centered approaches that support business change, technology innovation, and
Goals 3

design reuse are discussed. Reuse of architectural designs benefits component

reuse because design reuse is often much more effective than software reuse
alone.

1.2 The Need for the Software Architect

In the previous edition of this text, much was made about the software crisis
and the failure of the industry to complete software projects as planned. Given
that Corporate America spends more than $275 billion each year on approxi-
mately 200,000 application software development projects [Standish 1999],
this was an alarming situation.
However, as the software industry has matured and the focus on software
architecture has increased, significant improvements in the success rate of soft-
ware projects have been made. According to the Standish Group, in 1994, only
16% of application development met the criteria for success—complete on
time, on budget, and with all the features originally specified. By 1998, twenty-
six percent of all software projects were successful. The cost of failed projects
decreased from $81 billion in 1995 to an estimated $75 billion in 1998. Even
more dramatic was a major shift in cost overruns from $59 billion in 1005 to an
estimated $22 billion in 1998. While the state of the software industry seems
to be on a positive upward trend, a high rate of failed projects could still benefit
from the improvements that educated, knowledgeable software architects bring
to the software development process.

1.3 Goals

The development of educated, knowledgeable architects is the primary focus of

this work. This book attempts to define a package of skills required to make the
successful transition from a skilled software developer into a skilled software
architect. This is not a technical book that presents the details of every facet of
software architecture in sufficient depth that no additional information is re-
quired for success. This book will not be the last book a prospective software
architect will ever need to read in order to be a software architect. Rather, it is a
starting point and provides a good solid background for many of the issues and
areas that will be essential for succeeding as a software architect.
4 Chapter One Introduction

In this book, several military analogies are used to present relevant topics
essential to the development of a software architect. This comparison recog-
nizes that many of the same preparations used by the armed forces in training
for battle have roughly equivalent activities in software development. Just as
the army invests heavily in its recruits in order to produce well-trained, well-
disciplined soldiers who are capable of succeeding in any situation, this text at-
tempts to direct the reader into the specific areas that will provide the
flexibility to succeed in most situations as a software architect in the industry.
At the end of most of the chapters are exercises that are intended to aid in
putting the principles discussed in this book to use as a precursor to using them
in actual practice. Taking the time to read and think through these exercises
will provide the reader with a valuable experience that will establish an excel-
lent foundation for performing the same activities on an actual project.
The book is organized in the following sections to convey specific cate-
gories of information:

Industry Background and History

The discussion of the current state of architectural approaches in Chapter 2
provides a common foundation of knowledge for new software architects and
those who have been practicing software architects for some time. Topics such
as the Zachman Framework, enterprise architecture, and architectural view-
points are essential for communicating expertise in the area of software archi-
tecture. While the text does not attempt a comprehensive explanation of each
of the major approaches in documenting software architecture, a general
overview of each is provided along with the best available references. In addi-
tion, one major architectural approach is covered in significantly greater detail
in order to provide a deeper understanding of the value such approaches pro-
vide and the level of effort they typically require on a project. In addition, such
major architectural movements as design patterns, AntiPatterns, and software
architecture reference models are also presented.

Technology Trends and Architectural Styles

The major influence of technology on software architecture shows no signs of
abating. In Chapter 3, object-oriented technologies and their benefits and
downsides are addressed, as is the growing movement toward component tech-
nologies that emphasizes application and data separation over the data encap-
sulation approach of the object-oriented systems of the past decades. The
influence of the Internet and the need for various incarnations of layered soft-
ware architectures is discussed in considerable detail, particularly with con-
Advice for Software Architects 5

crete principles of the applicability of different architectural approaches to var-

ious design problems. Some discussion of the issues inherent in open source
solutions versus the reliance on proprietary approaches is also covered because
the impact of open source is expected to continue its explosive growth.

Tactics
Chapters 4 and 5 are intended to emphasize the tactical elements required to be
successful as a software architect. Chapter 4, “Software Architecture: Going to
War,” presents an overall architecture-centric development process. This
process is intended to be a guide for software architects who must structure ac-
tivities within a specific software development methodology. In addition, the
new issues introduced by the development of distributed systems are covered
in some detail, given that most new projects involve a number of distributed
components, frequently over the Internet or other networking technologies
where concerns for latency, reliability, and security are fundamental to techni-
cal decision making regarding system boundaries, technologies, and design
principles.
The primary duty of the software architect is to manage the complexity of
the software development effort. Chapter 5, “Software Architecture: Drill
School,” presents a set of concrete heuristics to enable the software architect to
address issues related to complexity management on a small scale. The tech-
niques should be adequate for dealing with many of the short-term issues that
arise, although they are no substitute for the long-range planning and overall
leadership skills that are required for long-term success.

Strategies
Chapters 6 and 7 discuss skills that are highly strategic in nature and will be
useful for long-term success in emphasizing quality in software development.
The most powerful skill sets required are leadership and team building. Leader-
ship is needed to focus the team toward a common goal, and team building is
required to keep focus on the day-to-day activities required to ensure that a
quality product is delivered. Also discussed is a seldom-covered topic in the
software industry—the relationship between the project manager and the soft-
ware architect.
Chapter 7 discusses software processes and provides the tools necessary
to make ongoing incremental improvements in the software development
process. The information is applicable to all software methodologies and its
lessons are not limited to technical concerns. Rather, the discussion of process
6 Chapter One Introduction

improvement applies to general preparation and improvement and should be

invaluable throughout any professional’s career.

Tools
Successful software architects must have available some basic tools of the
trade. Chapter 8, “Communications Training,” focuses on team building, as
any successful architect will be required to be a unifying force for many soft-
ware developers, and on the Unified Modeling Language (UML), a standard
notation for describing software artifacts throughout the industry. This chapter
also discusses model-driven architecture that proposes methods to ensure that
software decisions are reflected throughout the design documentation and code
base. Chapter 9, “Software Architecture: Intelligence Operations,” discusses
methods of continually staying current on software industry developments, par-
ticularly in the areas of specific domains. It is intended to provide the tools
necessary for staying current with the rapidly changing software toolsets that
are available.

Mindset
Chapter 10, “Software Architecture: Psychological Warfare,” is one of the
softer chapters, focusing on the more intangible aspects of succeeding as a soft-
ware architect. Of all the chapters, this one is likely to be the most controver-
sial because the topics introduced are relatively new and somewhat less
developed than the materials in other sections of the text. Finally, Chapter 11,
“Software Architecture: Career Advice,” provides valuable insight into how to
manage a career as a software architect. The career path for a student of soft-
ware architecture to an industry expert is explored. The lessons presented en-
courage the sharing of information and insight gained on software projects with
the software community at large.
 T W O

Military History

M
ilitary history is an essential means of retaining the experience of
past battles and imparting it to recruits and less experienced soldiers.
Military historians incorporate various sources of historical docu-
mentation including reference books, interviews with military leaders and
planners, and scientific analyses of artifacts recovered from battlefields. A
thorough study of past battlefields provides valuable insight into strategies and
tactics that can be brought to bear in modern situations. Army leaders, com-
manders, and soldiers can all benefit from learning from the experience of their
predecessors.

“Those that forget the lessons of history are condemned to repeat

them.”–George Santayana

For a fairly youthful industry, there is a deep history of significant devel-

opments in the software industry. From the Computer-Assisted Software Engi-
neering techniques of the early 1980s to the various artificial intelligence
movements including rule bases and fuzzy logic to the more recent uses of
scripting languages and application server development techniques, there is
something that can be applied to the software development practices of today.

7
8 Chapter Two Military History

2.1 Software Architecture Approaches

As a professional discipline, software architecture has at least a dozen schools

of thought, including

† Zachman Framework [Zachman 1997]

† Open Distributed Processing (ODP) [ISO 1996]
† Domain Analysis [Rogers 1997]
† IBM Rational’s 4+1 View Model [Kruchten 1995]
† Academic Software Architecture

Alternative approaches to architecture share concepts and principles, but their

terminologies differ greatly. Each architecture school is relatively isolated from
the others. In the literature of any given school, perhaps one or two other
schools are acknowledged, however briefly. None of the schools appears to
make any significant use of the results of the others. Since the terminology be-
tween these groups varies significantly, communication is difficult, especially
between practitioners using different architectural approaches. Upon further
study, the goals of each school are quite similar, and each school has some
unique value to offer.
In addition to these schools, many vendor-driven approaches are tied to
specific product lines, such as Sun One, IBM Lotus Notes, and Microsoft .Net.
In fact, every vendor appears to have a unique architectural vision for the fu-
ture founded upon its own product lines. Here, the focus is on those architec-
tural approaches that consider key application drivers, with appropriate product
support for underlying capabilities.

Architectural Approaches
Here is a brief tour of the major schools of software architecture thought.

Zachman Framework
Derived from IBM research and practice, the Zachman Framework is a tradi-
tional architectural approach (i.e., it is decidedly non–object oriented). The
Zachman Framework is a reference model comprising thirty architectural
viewpoints. The reference model is a matrix, which intersects two paradigms:
journalism (who, what, when, why, where, and how) and construction (planner,
owner, builder, designer, subcontractor). Architects choose from among these
viewpoints to specify a system architecture.
Software Architecture Approaches 9

Open Distributed Processing

A formal standard from the International Standards Organization (ISO) and In-
ternational Telecommunications Union (ITU), Open Distributed Processing de-
fines a five-viewpoint reference model (enterprise, information, computation,
engineering, and technology). ODP defines a comprehensive set of terminol-
ogy, a conformance approach, and viewpoint correspondence rules for trace-
ability. The product of seven years of standards work, ODP is a recent adoption
that fully supports object-oriented (OO) and component-based architecture.
While ODP may not have the level of recognition that some of the other ap-
proaches have, there is significant concrete value in its framework and overall
approach to software architecture description. It will be discussed in greater de-
tail later in this chapter.

Domain Analysis
A process for the systematic management of software reuse, domain analysis
transforms project-specific requirements into more general domain require-
ments for families of systems. The requirements then enable the identification
of common capabilities, which are used as the basis for horizontal frameworks
and reusable software architectures. An important capability of this approach is
the definition of robust software designs, which are relatively resistant to re-
quirements and context changes.

4+1 View Model

IBM Rational uses a four-viewpoint approach in describing software architec-
ture as part of the Unified Process. The viewpoints include logical, implemen-
tation (formerly “component”), process (i.e., runtime), and deployment. The
“+1” denotes use case specifications supporting requirements capture.

Academic Software Architecture

Academic software architecture comprises a community of computer science
researchers and educators constituting an academic field. Their educational ef-
forts are focused on basics and fundamentals. In their research contributions,
this community avoids proven architectural standards and practices in order to
achieve originality, theoretical formality, and other academic goals.

Common Principles
It is often said that the principles of software are simple (e.g., simplicity and
consistency). Architects agree that managing complexity (i.e., achieving sim-
plicity) is a key goal because it leads to many architectural benefits, such as
10 Chapter Two Military History

system adaptability and reduced system cost. For example, a simpler system is
easier to test, document, integrate, extend, and so forth.

“Explore the situation from more than one point of view. A seemingly
impossible situation might become transparently simple” [Rechtin
1997].

Simplicity is most necessary in the specification of the architecture itself. Most

architectural approaches utilize multiple viewpoints to specify architecture.
Viewpoints separate concerns into a limited set of design forces, which can be
resolved in a straightforward and locally optimal manner.
Consistency enhances system understanding and transfer of design
knowledge among parts of the system and among developers. An emphasis on
consistency contributes to the discovery of commonality and opportunities for
reuse. Architects agree that unnecessary diversity in design and implementa-
tion leads to decidedly negative consequences, such as brittle system structure.
A more comprehensive treatment of the principles related to the chal-
lenges of being a software architect is the VRAPS model named for its princi-
ples of Vision, Rhythm Anticipation, Partnering, and Simplification. The
model was pioneered in Software Architecture: Organizational Principles and
Patterns [Dikel 2001]. The VRAPS principles can be used to make hidden
risks and opportunities of software development apparent.

Architectural Controversies
The principal disagreements among architecture schools include (1) terminol-
ogy, (2) completeness, and (3) a priori viewpoints.
Architects disagree on terminology based on their backgrounds or
schools of thought. For example, when discussing software interfaces, the con-
sistency principle is variously called standard interfaces, common interfaces,
horizontal interfaces, plug-and-play interfaces, and interface generalization. It
can also be argued that variation-centered design (from design patterns) and
component substitution are largely based upon consistent interface structure.
Unnecessary diversity of terminology leads to confusion and sometimes
to proprietary advantage. Some vendors and gurus change terminology so
frequently that keeping up with their latest expressions becomes a time-
consuming career.
Differences in terminology lead to miscommunication. In contrast, some
distinct areas of disagreement among architecture schools can’t be resolved
through improved communications alone.
The Architectural Paradigm Shift 11

The notion of complete models is promoted by legacy OO approaches

(e.g., Object Modeling Technique [OMT], the Zachman Framework, and vari-
ous other models). These groups have promoted a vision that complete models
(describing multiple phases of development) are a worthwhile goal of software
development projects. Other schools would argue that multiple models are not
maintainable, that unnecessarily detailed models are counterproductive, and
that architectural significance should be considered when selecting system fea-
tures for modeling.
The selection of architectural viewpoints is a key point of contention
among architecture schools. Some schools have preselected a priori view-
points. Some schools leave that decision to individual projects. The Zachman
Framework is an interesting case because it proposes thirty viewpoints, from
among which most projects select groups of viewpoints to specify.
Variable viewpoints have the advantage that they can be tailored to ad-
dress the concerns of particular system stakeholders. Predefined viewpoints
have the advantage that they can accompany a stable conceptual framework
and a well-defined terminology, as well as predefined approaches for resolving
viewpoint consistency and architectural conformance.
These contrary notions can be summarized in terms of the principle of
pragmatism. The pragmatists make a good case because of the preceding ad-
vantages as well as because most software systems are too complex to model
completely (e.g., multithreaded distributed computing systems). Pragmatism is
a key principle to apply in the transition from document-driven to architecture-
centered software process.
All the architectural approaches are being applied in practice. Software
architects should have a working knowledge of the software architectural ap-
proaches described here. In addition, they should utilize one of the product-
quality architectural frameworks in daily practice. Component architectural
development is a challenging area, requiring the best of stable conceptual
frameworks supporting sound architectural judgment.

2.2 The Architectural Paradigm Shift

The nature of information systems is changing from localized departmental ap-

plication to large-scale global and dynamic systems. This trend is following the
change in business environments toward globalization. The migration from rel-
atively static and local environments to highly dynamic information technol-
ogy environments presents substantial challenges to the software architect
(Figure 2.1).
12 Chapter Two Military History

Local/Static to Global/Dynamic:
Rapidly Changing Technologies and Business Requirements
Digital Video Architecture

The Digital Video Architecture

has been proposed by BELL
Servers: Labs and has currently been
modified by MITRE to
Application Integrated Network include the Header layer.
This layering is necessary to
Backup break the different
File development activities into
manageable pieces similar
DBMS to what OSI has done for
presentation Documentation Text Graphics communication
Image Processing storage Storage Search and Imagery
system System Service Search
(voice & Video) (Text, Imagery, Server
Graphics)

Voice and VIDEO Search Server

Integrated Network

presentation Documentation Text Graphics

storage Storage Search and Imagery
system System Service Search
(voice & Video) (Text, Imagery, Server
Graphics)

Virtual Enterprises
Voice and VIDEO Search Server

Multimedia
Imagery Report
To: Intelligence Officers
From Pacom & NPIC

Subject:
The subject of this image
is drug trafficking in a
South American country

Item A is one of the planes

used for transport

Item B is a processing
plant

FIGURE 2.1 Virtual Enterprise Paradigm Shift

A majority of information technology approaches are based upon a set of

traditional assumptions (Figure 2.2). In these assumptions, the system com-
prises a homogeneous set of hardware and software that is known at design
time. A configuration is relatively stable and is managed from a centralized
system management configuration. Communications in traditional systems are
relatively predictable, synchronous, and local. If the state of the system is well
known at all times and the concept of time is unified across all the activities,
another key assumption is that failures in the system are relatively infrequent
and, when they do occur, are monolithic. In other words, either the system is up
or the system is down.
In the building of distributed application systems, most of the assump-
tions are reversed. In a distributed multiorganizational system, it is fair to as-
sume that the hardware and software configuration is heterogeneous. The
reason is that different elements of the system are purchased during different
time frames by different organizations, and many of the decisions are made in-
dependently. Therefore, a typical configuration is a collection of heterogeneous
information technology. Additionally, hardware and software configurations
are evolving. Occurring within any organization is employee turnover and the
evolution of business processes. The architecture of the organization has an im-
pact on the architecture of the information technology. As time progresses, new
systems are installed, systems are moved, new software is acquired, and so on.
When multiple organizations are involved, these processes proceed relatively
The Architectural Paradigm Shift 13

TRADITIONAL SYSTEM ASSUMPTIONS

• Homogeneous hardware/software
• Stable, centrally managed configuration
• Synchronous and local: processing, state, time, and communications
• Infrequent, monolithic failures

DISTRIBUTED SYSTEM ASSUMPTIONS

• Homogeneous hardware/software – evolving configurations
• Remote, autonomous processing
• Distributed, replicated, nonuniform: state and time
• Asynchronous, insecure, variable: communications
• Frequent partial system failures
FIGURE 2.2 Traditional and Distributed Systems Assumptions

independently, and the architect must accommodate the diverse evolving set of
configurations.
In distributed systems, the assumption is that there is remote processing
at multiple locations. Some of this remote processing is on systems that were
developed independently and therefore have their own autonomous concept of
control flow. This reverses the assumption of localized and unified processing
resources. There are some interesting implications for the concepts of state and
time. The state of a distributed system is often distributed itself. The state in-
formation may need to be replicated in order to provide efficient reliable access
at multiple locations. It is possible for the distributed state to become nonuni-
form in order to get into error conditions where the replicated state does
not have the desired integrity and must be repaired. The concept of time-
distributed systems is affected by the physics of relativity and chaos theory.
Electrons are traveling near the speed of light in distributed communication
systems. In any large system, there is a disparity between the local concepts of
time, in that a system can only have an accurate representation of partial order-
ing of operations in the distributed environment. The total ordering of opera-
tions is not possible because of the distances between information processes. In
addition, distributed communications can get quite variable and complex. In a
distributed system, communications systems can provide various qualities of
service. The communications can vary by such factors as timeliness of deliv-
ery, throughput, levels of security and vulnerability to attack, and reliability of
communications. The communications architecture must be explicitly designed
and planned to account for the variability in services.
Finally, the distributed system has a unique model of failure modes. In
any large distributed system, components are failing all the time. Messages are
14 Chapter Two Military History

corrupted and lost, processes crash, and systems fail. These kinds of failures
happen frequently, and the system must be designed to accommodate them.

2.3 The Need for Software

Architecture

Distributed processing changes virtually all the traditional system assumptions

that are the basis for most software engineering methodologies, programming
languages, and notations. To accommodate this new level of system complex-
ity, architects have three new needs.
First, architects need the ability to separate complex concerns, in particu-
lar to separate concerns about business-application functionality, from con-
cerns about distributed-system complexity. Distributed computing is a
challenging and complex architectural environment unto itself. If systems are
built with traditional assumptions, architects and developers are likely to spend
most of their time combating the distributed nature of real-world applications.
Problems and challenges of distributed computing have nothing to do funda-
mentally with business-application functionality.
The purpose of information technology is to make business processes
more efficient. In a typical application, 70% of application code is infrastruc-
ture [Standish 1999]. Some of this code is unique to the application even
though it might not directly address business requirements. By separating con-
cerns, developers can focus on the business functionality that is the true pur-
pose of the information system. Ideally, architects would like to separate
distributed-system issues into categories of design, where the majority of com-
ponents are purchasable as commodity communication infrastructure.
Software architects also need the ability to future-proof the information
systems that they are planning. It is important to accommodate commercial
technology evolution, which is known to be accelerating and provides substan-
tial challenges for architects and developers. Future-proofing also requires the
ability to adapt to new user requirements, since requirements do change fre-
quently and account for a majority of system software costs over the life cycle.
It is important to plan information systems to support the likely and inevitable
changes that users will require in order to conduct business.
A third need for software architects is the ability to increase the likeli-
hood of system success. Corporate developers to date have had a very poor
track record of creating successful systems. The software architect is responsi-
Zachman Framework 15

OBJECT-ORIENTED STANDARDS Rational’s Rational’s

4+1 model 4+1 model
ISO open
RM-ODP view view

(not standards)
distributed
processing
Interface US DoD
Trader definition specialization
service language
C4ISR
framework
Commercial
specialization

OMG object ISO OSI

management Reuses 7-layer
architecture concepts reference
model

FIGURE 2.3 Software-Intensive Systems Architecture Reference Models

ble for planning systems with the maximum probability of delivering success
and key benefits for the business. Through proper information technology
planning, it is possible to increase the likelihood of system delivery on time
and on budget.
In confronting these three needs, authorities in software engineering and
computer science tend to agree that architecture is the key to system success.
Authorities in areas ranging from academia to commercial industry are declar-
ing that software architecture is essential to the success and management of in-
formation systems. The list of software authorities who have come to this
conclusion is long and growing. Unfortunately, not everyone always clearly
understands what software architecture truly is. In order to provide clarifica-
tion, it is necessary to examine some of the reference models that provide defi-
nitions of software and systems architecture (Figure 2.3).

2.4 Zachman Framework

Many authorities in the software industry have thoroughly considered the

needs discussed here. Two leading meta-architectural frameworks guide the
development of software system architecture. One of the popular frameworks
originated at IBM and is called the Zachman Framework. The Zachman
Framework predated the popularity of object orientation and took the perspec-
16 Chapter Two Military History

tive of separating data from process. The Zachman Framework includes six in-
formation system viewpoints as well as five levels of design abstraction. The
original Zachman Framework published in 1987 contained viewpoints for the
network, the data, and the process of the information system [Zachman 1997].
A subsequent revision introduced three additional viewpoints. The current
framework resembles the set of traditional journalistic questions, which include
who, what, when, why, where, and how. Each viewpoint in the Zachman
Framework answers a chief set of questions to ensure that a complete system
engineering architecture is created.
The Zachman Framework formed a matrix of architectural descriptions
that are also organized in terms of levels. There are five levels of description
above the information system implementation. They range from architectural
planning done by individual programmers at the finest grain to the overall en-
terprise requirements from the investors’ perspective of the information sys-
tem. In total, the Zachman Framework identifies thirty architectural
specifications, which provide a complete description of the information sys-
tem. In practice, no real-world project is capable of creating these thirty or
more detailed plans and keeping them all in synchronization. When the Zach-
man Framework is applied, systems architects partition the viewpoint into vari-
ous categories and create architectural specifications that cover some or all of
the different Zachman descriptions without having to create the large number
of individual specification documents that the Zachman Framework spans. One
example is a very successful architectural initiative by the U.S. Department of
Defense (DOD) called the C4ISR architectural framework, where C4ISR
stands for Command and Control, Computers, Communication, Intelligence
Surveillance, and Reconnaissance. The C4ISR architectural framework is used
to describe DOD information technology at the highest echelons of the organi-
zation. The primary benefit in this case is that different service organizations
and agencies can communicate their architectural plans through common-
viewpoint description.
Beyond the Zachman Framework, object-oriented architects have discov-
ered additional needs for defining computational architecture and other view-
points that are not obvious applications of the Zachman principles. The ISO has
also considered these architectural issues. The ISO reference model for open
distributed processing called RM-ODP was recently completed. This model be-
longs to a category of ISO standards called Open Distributed Processing. ODP
is an outgrowth of earlier work by ISO in open systems interoperability. The
Open Systems Interconnection (OSI) seven-layer reference model identified an
application layer that provided minimal structure and guidance for the develop-
ment of application systems. In fact, the seventh layer for application organizes
Reference Model for Open Distributed Processing 17

remote procedure calls, directory services, and all other forms of application-
level services within the same architectural category, without defining any par-
ticular structure or guidance for this significant category of functionality.

2.5 Reference Model for Open

Distributed Processing

Among the various architectural approaches, a useful international standard,

the Reference Model for Open Distributed Processing (RM-ODP), defines
what information systems architecture means [ISO 1996]. RM-ODP is a pow-
erful way to think about software architecture and will be discussed in some
detail for the purpose of illustrating the depth of material provided by the major
architecture school of thought. The ODP model is representative of any mature
software architecture practice, including the architecture schools previously
mentioned.
RM-ODP defines five essential viewpoints for modeling systems archi-
tecture:

† Enterprise viewpoint
† Information viewpoint
† Computational viewpoint
† Engineering viewpoint
† Technology viewpoint

The five viewpoints provide a comprehensive model of a single information

system, with each viewpoint being a perspective on a single information sys-
tem (Figure 2.4). The set of viewpoints is not closed, so that additional view-
points can be added as the needs arise. Another of their purposes is to provide
information descriptions that address the questions and needs of particular
stakeholders in the system. By standardizing five viewpoints, RM-ODP is
claiming that these five stakeholder perspectives are sufficient for resolving
both business functionality and distributed systems issues in the architecture
and design of information systems. RM-ODP is an elegant model in the sense
that it identifies the top priorities for architectural descriptions and provides a
minimal set of traceability requirements that are adequate to ensure system
integrity.
The enterprise viewpoint of the RM-ODP takes the perspective of a busi-
ness model. Managers and end users in the business environment should be
able to understand the enterprise models readily. The enterprise viewpoint en-
18 Chapter Two Military History

Enterprise
viewpoint

Information Computational
viewpoint viewpoint
Information
system

Engineering Technology
viewpoint viewpoint

FIGURE 2.4 Systems Architecture Viewpoint Perspectives

sures that business needs are satisfied through the architecture and provides a
description that enables validation of these assertions with the end users.
The information viewpoint defines the universe of discourse in the infor-
mation system. The perspective is similar to the design information generated
by a database modeler. The information viewpoint is a logical representation of
the data and processes on data in the information system.
Each of the five RM-ODP viewpoints is object oriented, and they provide
a complete model of the system from the given perspective. The information
viewpoint is an object-oriented logical model of the information assets in the
business and how these assets are processed and manipulated.
The computational viewpoint partitions the system into software compo-
nents that are capable of supporting distribution. It takes the perspective of a
designer of application program interfaces for componentware. The computa-
tional viewpoint defines the boundaries between the software elements in the
information system. Generally, these boundaries are the architectural controls
that ensure that the system structure will embody the qualities of adaptability in
management of complexity that are appropriate to meet changing business
needs and incorporate the evolving commercial technology.
The engineering viewpoint of RM-ODP exposes the distributed nature of
the system. Its perspective is similar to that of an operating system engineer
who is familiar with the protocol stacks and allocation issues necessary to de-
fine the distributed processing solutions for the information system.
Reference Model for Open Distributed Processing 19

The technology viewpoint defines the mappings between the engineering

objects and other objects designed to specific standards and technologies in-
cluding product selections. The viewpoint is similar to that of a network engi-
neer who is familiar with the commercially available protocol standards and
products that are appropriate selections to configure the information system.
All five RM-ODP viewpoints are co-equal in the sense that they do not
form levels of description; rather, each viewpoint provides a complete model
of the information system that is object-oriented and corresponds to the other
viewpoints. Each defines various constraints on the design of the information
system that provide various architectural benefits for each of the system’s
stakeholders. The RM-ODP viewpoints enable the separation of concerns that
divide the business and logical functionality of the system from the distributed
computing and commercial technology decisions of the architecture.
The first three viewpoints identify informational and computational char-
acteristics. The enterprise and information viewpoints are purely logical views
of the business, represented as object-oriented models (Figure 2.5). The com-
putational viewpoint is independent of the distribution of software modules,
but it must define computational boundaries that are enabled for distribution.
The CORBA IDL (Common Object Request Broker Architecture Interface De-
finition Language) notation for specifying computational interfaces is appro-
priate for this purpose. IDL provides a way to define computational interfaces
that are independent of the distribution and deployment issues in enterprise de-
velopment. The first four viewpoints—enterprise, information, computational,
and engineering—are independent of specific implementations. In other words,
the majority of the architectural design is independent of the specific product
selections that configure the system. This property of RM-ODP enables the
evolution of technology components without having an impact on the overall
Distribution transparent

Implementation independent

RM–ODP Viewpoints
1. Enterprise
–Business purpose, scope, and policies for system
2. Information
–Meaning of information and information processing
3. Computational
–Modules and interfaces enabling distribution
4. Engineering
–Mechanisms of distribution
5. Technology
–Choice of technology and component details

FIGURE 2.5 Characteristics of Architectural Viewpoints

20 Chapter Two Military History

architectural constraints defined in the first four viewpoints. The engineering

viewpoint defines qualities of service and distribution transparencies that
evolving technology selections must support. The terminology of RM-ODP as-
sists in providing concise descriptions of these technology requirements.

The 4+1 View Model is a viewpoint-based architectural approach supported

by OO tools such as Rational Rose. The viewpoints include
Use case view
Logical view
Process view
Implementation view
Deployment view
The use case view models enterprise objects through a set of scenarios.
The logical view includes object models of packages, classes, and relation-
ships. The process view represents control flows and their intercommunica-
tions. The implementation view defines the modular structure of the software.
The deployment view identifies the allocation of software onto hardware. An
architecture defined as a 4+1 View Model covers aspects of all five RM-ODP
viewpoints.

RM-ODP contains many terms that are useful concepts for software ar-
chitects. Some of the key definitions in RM-ODP are the distribution trans-
parencies. RM-ODP defines eight distribution transparencies that specify the
qualities provided by a distributed computing infrastructure (Figure 2.6). Cur-
rently available commercial infrastructures provide some subset of these, such
as the location, access persistence, and transaction transparencies provided in
Java 2 Platform, Enterprise Edition (J2EE)–compliant application servers. Ad-
ditional transparencies are sometimes available through niche-market products
and custom implementations. Technologies that failed to provide access trans-
parency, such as Microsoft COM+ and the distributed computing environment,
did not adapt well to the future evolution of distributed systems.
Open distributed processing and its reference model are the result of ten
years of formal standardization work at ISO. The reference model for open dis-
tributed processing is object oriented. RM-ODP provides a reference model
that addresses three fundamental goals: (1) to provide a standard framework for
further work and additional detailed standards under the open distributed pro-
cessing initiative, (2) to provide a set of common terminology and concepts
Reference Model for Open Distributed Processing 21

Distributed Transparency Architectural Guarantee

Access Masks platform-protocol difference in data
representation and invocation mechanisms
Failure Masks failures and recoveries of other objects
Location Masks the use of location information to find &
bind to objects
Migration Masks awareness of changes in location of the
object from itself
Relocation Masks changes in the location of an interface/service from clients
Replication Masks the existence of replicated objects that
support common states and services
Persistence Masks activation and deactivation of objects
(including the object itself)
Transaction Masks coordination of activities to achieve
consistency

FIGURE 2.6 Distribution Transparencies

that could be applied for the development of product and application systems
for open distributed processing, and (3) to provide a guideline for object-ori-
ented architects to specify software systems. This third purpose is directly rele-
vant to the day-to-day practices of systems architects.
Open distributed processing includes several other standards that are sig-
nificant. In particular, it has adopted the interface definition language from
CORBA as a notation for a specified computational architecture. It also has a
standard for the trader service, which is the key directory service supporting
the discovery of application functions in distributed systems. The trader service
has subsequently been adopted as a commercial standard through the object
management group. The group’s object management architecture is a commer-
cial specialization of open distributed processing.
All together, the consensus standards of the object management group
(OMG) and the ISO open distributed processing form a set of software archi-
tecture standards that are useful intellectual tools for most software architects
and developers.
RM-ODP has four completed standards documents (X.901 Overview,
X.902 Foundations, X.903 Architecture, X.904 Architectural Semantics). Part
one of the standards (X.901) is a non-normative overview and summary of the
overall concepts and terminology. All four parts of the adopted standard are
cosponsored by the International Telecommunications Union ITU-T through
their X.900 series. The cosponsorship of both ISO and ITU-T represents a
broad international consensus on this guideline for object-oriented architecture.
Part two of the standard is the foundations document, comprising a glossary of
22 Chapter Two Military History

standard terminology for object-oriented distributed systems. Part three of the

standards is the architecture document. It defines the various viewpoints for
object-oriented architecture along with their structuring rules and various ODP
functions that enable distributed computing.
Altogether, these four standards documents comprise fewer than 200
pages of documentation—with the normative parts, part two and part three,
comprising about 100 pages. Even though this is a relatively short standard, it
provides a great deal of valuable information. Many ISO standards are rela-
tively inscrutable to the practicing software engineer; this standard is no excep-
tion. However, the effort to understand it is very worthwhile, given the
challenges of distributed computing in business process change that need to be
resolved.
Who supports RM-ODP? RM-ODP is the product of formal standards
bodies including ISO and the Institute of Electrical and Electronics Engineers
(IEEE). The IEEE is an accredited standards organization reporting to ISO;
therefore, the IEEE is a voting participant and joint supporter of RM-ODP as
well. RM-ODP is the formal standards basis for OMG’s object management ar-
chitecture and all of the resulting technologies that the group has adopted that
form the basis for distributed object computing and technologies that are avail-
able commercially. RM-ODP is also accurately used in several mission-critical
industries that depend upon information technology for their income. In partic-
ular, RM-ODP is applied across the telecommunications industry through the
telecommunications information network architecture consortium, and RM-
ODP is actively used by telecommunication companies such as AT&T, Lucent,
and Nortel. In the telecommunications industry, information technology is their
business, and distributed information systems success is essential to maintain-
ing their competitive advantage.
Also applying ODP actively is the financial services industry. Companies
such as Merrill Lynch, Morgan Stanley, and various mortgage lending organi-
zations are applying RM-ODP to define new information systems concepts.
The deployment of new information technologies is becoming one of the key
competitive advantages that these companies have for creating new market
channels to distribute and transact new financial instruments and securities,
and to perform other financial services. For these industries, failure of informa-
tion systems directly affects bottom-line profitability and is usually not an op-
tion. If these influential companies accept this architectural approach and apply
it actively, can all other organizations afford not to consider its benefits?
RM-ODP provides standard definitions for distributed infrastructure ob-
jects that enable abstract descriptions of engineering constraints. Figure 2.7 is
an example of the engineering objects that RM-ODP defines. These engineer-
Reference Model for Open Distributed Processing 23

Client Server
object object

Client Server
stub stub
Control
Client interfaces Server
binder binder

Protocol Protocol
object object
Interceptor

FIGURE 2.7 Distribution Channel Model

ing objects are capable of defining the characteristics of all forms of distributed
infrastructure, including remote procedure calls, screening data interfaces, and
asynchronous interfaces for signaling. Among the most important features of
RM-ODP are its definitions supporting conformance assessment. After all,
what is the purpose of architectural documentation unless conformance can be
assessed (i.e., unless implementation of the system corresponds to the written
and intended architectural plans)?
RM-ODP defines four categories of conformance and proceeds to specify
how conformance is represented in an architectural plan. The first category is
called programmatic conformance. This is the usual notion of behavioral test-
ing of software interfaces. Many of the programmatic conformance points will
occur in the computational viewpoint specification of RM-ODP-based archi-
tectures.
Perceptual conformance includes testing at user interfaces in communi-
cations ports that represent external boundaries to the system. Usability and
user interface testing can be defined through perceptual conformance assess-
ment. Interworking conformance involves testing between systems implemen-
tations. It is not sufficient for individual systems to have programmatic
conformance in order to guarantee interoperability. Interworking conformance
includes interoperability testing between working implementations (i.e., an ad-
ditional requirement beyond programmatic conformance).
Interchange conformance involves testing the exchange of external
media, such as disks and tapes. It ensures that information that is stored on ex-
24 Chapter Two Military History

ternal media can be interpreted and assimilated in other systems that conform
to the same standards. RM-ODP also defines correspondence requirements be-
tween the various viewpoints of application architecture. In general, the objects
defined in each of the viewpoints do not have to correspond explicitly because
they represent an independent description of the system representing various
levels of granularity of descriptions and constraints.
For a more comprehensive explanation of RM-ODP including details
necessary for applying it to software development and enterprise architecture
efforts, see Architecting with RM-ODP [Putman 2000]. Specifically, it pro-
vides a best-practice approach to creating architectural specifications using
RM-ODP and current best practices. It also identifies industry tools, current
and under development, that can facilitate the creation and maintenance of
RM-ODP specifications and diagrams.

2.6 Enterprise Architecture

Standards

An enterprise architecture is a set of documents designed to communicate how

IT components fit together to satisfy the higher level business objectives. En-
terprise architecture has been under development for years. Attempts were
made to increase the formalism of the enterprise architecture process and to
provide simple, generic models of system components across entire classes of
systems; much work has been done between these two extremes. The primary
lesson learned from efforts to date is that any enterprise architecture needs to
be tailored toward the audience that will use it for business decision making. In
retrospect, this makes excellent sense because the decision makers are making
the investment in the system and need on-going education into the alternatives,
risks, and tradeoffs involved in how they make such decisions. Without either
an enterprise architecture to communicate this information in terms others can
understand or the people affected by their decisions, decision makers are
forced to rely on blind faith in their IT staff or risk undermining efforts that
may already be aligned to aid in accomplishing their business goals.
Natural languages such as English are adequate for planning discussions
and setting high-level priorities. However, because natural languages are im-
precise and can be interpreted in multiple ways, lower level models and share
design artifacts require more specialized notations. For example, a detailed dis-
cussion of the contents of a database would drive most of the organization from
the room in the first hour; however, defining the various data types, expected
Enterprise Architecture Standards 25

field lengths, and semantic meanings of the fields and relationships is ab-
solutely essential for database construction.
The enterprise architecture defines the roadmap and how the various
models at different levels of the enterprise are related. This description needs to
be understandable across the enterprise, even if the individual models them-
selves have a more limited audience. A balance needs to be struck in develop-
ing artifacts that can simultaneously be used to provide technical information
to business users and enough information to derive consistent technical guid-
ance for development teams. An immediate benefit from having an enterprise
architecture is that it allows everyone within an organization to communicate
using a common set of documents. This provides an organizational alignment
and allows everyone at different levels of the organization to understand the
impact of both IT decisions and investments. For example, if a business group
needed management information reports from different lines of business, then
it should be possible to use the enterprise architecture to trace through what
business areas generate the required data and what IT systems are impacted
and to perform a quick assessment of where additional analysis would be re-
quired to produce a feasibility study. Furthermore, if a project is scoped out
and approved, the technical people can use the same enterprise architecture as a
starting point for their high-level design. Having the same information avail-
able as input into business decision making and technical analysis increases the
chance for project success.
Regardless of the approach taken, the initial step in developing an enter-
prise architecture is obtaining and documenting the current business environ-
ment. It would be a mistake to adopt a “bottom up” approach, placing technical
artifacts before an understanding of how they are linked to strategic business
objectives. Also, when technical artifacts are included in the enterprise archi-
tect, they should be targeted to the business users. This does not mean that the
more technical documentation customized for system designers, coders, and
testers should not exist. It does, however, mean that some effort is needed to
package and convey some essential information to a wider audience.

Federal Enterprise Architecture Framework

The Federal Enterprise Architecture Framework (FEAF) [FEAF 1999] is tar-
geted at U. S. government agencies to assist them in complying with the 1996
Clinger-Cohen/Information Technology Reform Act, which required agencies
to develop an enterprise architecture. It is expected that the agency enterprise
architecture will be integrated into the organization’s Capital Planning and In-
vestment Control (CPIC) processes used to set priorities and make decisions
Exploring the Variety of Random
Documents with Different Content
 But no one loves the scenes of nature more than I. The first
sunset that I remember with enjoyment occurred when I was ten
years old; and how many I have seen since then! On an autumn day
in 1903, I saw the sun sink into the ocean off the coast of Normandy,
and, by the miracle of memory, I can see it again whenever I wish. I
thought of Browning’s lines:

“Than by slow, pallid sunsets in autumn, ye watch from the shore,

At their sad level gaze o’er the ocean—a sun’s slow decline.”

I have seen the Matterhorn from the Gorner Grat, Mont Blanc
from Chamonix, and the divine flush on the summit of the Jungfrau.
Forty years ago I heard for the first time the Ninth Symphony;
and while I have heard it often since then, the most memorable
occasion was in May 1912 when I heard it at Paris, played by a
magnificent orchestra, conducted by Felix Weingartner; I have heard
Die Meistersinger in Munich, conducted by Arthur Nikisch; I have
heard the Emperor Concerto, with Ossip Gabrilowitsch at the piano; I
have heard Tod und Verklärung with Stokowski and the Philadelphia
Orchestra; I have heard De Pachmann (in his prime) play Chopin’s B
flat minor sonata, Paderewski play Liszt’s Hungarian Rhapsody No.
2, Josef Hofmann play Beethoven’s Sonata 111. I have heard
Carmen sung by Emma Calvé, Emma Eames, Jean de Reszké and
Lassalle; Tristan und Isolde sung by Jean de Reszké and Lilli
Lehmann; Faust sung by Jean and Edouard de Reszké, Emma
Eames, Maurel, and Scalchi; Mignon sung by Mme. Lucrezia Bori; I
have repeatedly heard the three greatest bassos of modern times,
Edouard de Reszké, Pol Plançon, and Chaliapin.
In the theatre I have seen Edwin Booth as Shylock, Mansfield as
Richard III, Irving in The Lyons Mail, Possart as Mephistopheles,
Sarah Bernhardt as La Tosca, Duse as Francesca, Salvini as
Othello, and twice have I seen the Passion Play at Oberammergau.
All these are memorable experiences, and for fear I may not be
conscious when I am dying, I am recalling them now. But if I should
attempt to recall all the glorious things I have seen in nature and in
art, I should have no time for fresh experiences that await me.
As for social pleasures, one of the highest enjoyments is
agreeable company and good conversation; and I especially like
men, women and children.
 Transcriber’s Notes
Punctuation, hyphenation, and spelling were made
consistent when a predominant preference was found in the
original book; otherwise they were not changed.
Simple typographical errors were corrected; unbalanced
quotation marks were remedied when the change was
obvious, and otherwise left unbalanced.
Just for the curious: Chapter XVIII has four references to
“F. P. A.” but doesn’t give the full name. When this book was
written, he was a well-known columnist: Franklin P. Adams.
*** END OF THE PROJECT GUTENBERG EBOOK ESSAYS ON
THINGS ***

Updated editions will replace the previous one—the old editions

will be renamed.

Creating the works from print editions not protected by U.S.

copyright law means that no one owns a United States copyright
in these works, so the Foundation (and you!) can copy and
distribute it in the United States without permission and without
paying copyright royalties. Special rules, set forth in the General
Terms of Use part of this license, apply to copying and
distributing Project Gutenberg™ electronic works to protect the
PROJECT GUTENBERG™ concept and trademark. Project
Gutenberg is a registered trademark, and may not be used if
you charge for an eBook, except by following the terms of the
trademark license, including paying royalties for use of the
Project Gutenberg trademark. If you do not charge anything for
copies of this eBook, complying with the trademark license is
very easy. You may use this eBook for nearly any purpose such
as creation of derivative works, reports, performances and
research. Project Gutenberg eBooks may be modified and
printed and given away—you may do practically ANYTHING in
the United States with eBooks not protected by U.S. copyright
law. Redistribution is subject to the trademark license, especially
commercial redistribution.

START: FULL LICENSE

THE FULL PROJECT GUTENBERG LICENSE
 PLEASE READ THIS BEFORE YOU DISTRIBUTE OR USE THIS WORK

To protect the Project Gutenberg™ mission of promoting the

free distribution of electronic works, by using or distributing this
work (or any other work associated in any way with the phrase
“Project Gutenberg”), you agree to comply with all the terms of
the Full Project Gutenberg™ License available with this file or
online at www.gutenberg.org/license.

Section 1. General Terms of Use and

Redistributing Project Gutenberg™
electronic works
1.A. By reading or using any part of this Project Gutenberg™
electronic work, you indicate that you have read, understand,
agree to and accept all the terms of this license and intellectual
property (trademark/copyright) agreement. If you do not agree to
abide by all the terms of this agreement, you must cease using
and return or destroy all copies of Project Gutenberg™
electronic works in your possession. If you paid a fee for
obtaining a copy of or access to a Project Gutenberg™
electronic work and you do not agree to be bound by the terms
of this agreement, you may obtain a refund from the person or
entity to whom you paid the fee as set forth in paragraph 1.E.8.

1.B. “Project Gutenberg” is a registered trademark. It may only

be used on or associated in any way with an electronic work by
people who agree to be bound by the terms of this agreement.
There are a few things that you can do with most Project
Gutenberg™ electronic works even without complying with the
full terms of this agreement. See paragraph 1.C below. There
are a lot of things you can do with Project Gutenberg™
electronic works if you follow the terms of this agreement and
help preserve free future access to Project Gutenberg™
electronic works. See paragraph 1.E below.
1.C. The Project Gutenberg Literary Archive Foundation (“the
Foundation” or PGLAF), owns a compilation copyright in the
collection of Project Gutenberg™ electronic works. Nearly all the
individual works in the collection are in the public domain in the
United States. If an individual work is unprotected by copyright
law in the United States and you are located in the United
States, we do not claim a right to prevent you from copying,
distributing, performing, displaying or creating derivative works
based on the work as long as all references to Project
Gutenberg are removed. Of course, we hope that you will
support the Project Gutenberg™ mission of promoting free
access to electronic works by freely sharing Project
Gutenberg™ works in compliance with the terms of this
agreement for keeping the Project Gutenberg™ name
associated with the work. You can easily comply with the terms
of this agreement by keeping this work in the same format with
its attached full Project Gutenberg™ License when you share it
without charge with others.

1.D. The copyright laws of the place where you are located also
govern what you can do with this work. Copyright laws in most
countries are in a constant state of change. If you are outside
the United States, check the laws of your country in addition to
the terms of this agreement before downloading, copying,
displaying, performing, distributing or creating derivative works
based on this work or any other Project Gutenberg™ work. The
Foundation makes no representations concerning the copyright
status of any work in any country other than the United States.

1.E. Unless you have removed all references to Project

Gutenberg:

1.E.1. The following sentence, with active links to, or other

immediate access to, the full Project Gutenberg™ License must
appear prominently whenever any copy of a Project
Gutenberg™ work (any work on which the phrase “Project
Gutenberg” appears, or with which the phrase “Project
Gutenberg” is associated) is accessed, displayed, performed,
viewed, copied or distributed:

This eBook is for the use of anyone anywhere in the United

States and most other parts of the world at no cost and with
almost no restrictions whatsoever. You may copy it, give it
away or re-use it under the terms of the Project Gutenberg
License included with this eBook or online at
www.gutenberg.org. If you are not located in the United
States, you will have to check the laws of the country where
you are located before using this eBook.

1.E.2. If an individual Project Gutenberg™ electronic work is

derived from texts not protected by U.S. copyright law (does not
contain a notice indicating that it is posted with permission of the
copyright holder), the work can be copied and distributed to
anyone in the United States without paying any fees or charges.
If you are redistributing or providing access to a work with the
phrase “Project Gutenberg” associated with or appearing on the
work, you must comply either with the requirements of
paragraphs 1.E.1 through 1.E.7 or obtain permission for the use
of the work and the Project Gutenberg™ trademark as set forth
in paragraphs 1.E.8 or 1.E.9.

1.E.3. If an individual Project Gutenberg™ electronic work is

posted with the permission of the copyright holder, your use and
distribution must comply with both paragraphs 1.E.1 through
1.E.7 and any additional terms imposed by the copyright holder.
Additional terms will be linked to the Project Gutenberg™
License for all works posted with the permission of the copyright
holder found at the beginning of this work.

1.E.4. Do not unlink or detach or remove the full Project

Gutenberg™ License terms from this work, or any files
containing a part of this work or any other work associated with
Project Gutenberg™.
1.E.5. Do not copy, display, perform, distribute or redistribute
this electronic work, or any part of this electronic work, without
prominently displaying the sentence set forth in paragraph 1.E.1
with active links or immediate access to the full terms of the
Project Gutenberg™ License.

1.E.6. You may convert to and distribute this work in any binary,
compressed, marked up, nonproprietary or proprietary form,
including any word processing or hypertext form. However, if
you provide access to or distribute copies of a Project
Gutenberg™ work in a format other than “Plain Vanilla ASCII” or
other format used in the official version posted on the official
Project Gutenberg™ website (www.gutenberg.org), you must, at
no additional cost, fee or expense to the user, provide a copy, a
means of exporting a copy, or a means of obtaining a copy upon
request, of the work in its original “Plain Vanilla ASCII” or other
form. Any alternate format must include the full Project
Gutenberg™ License as specified in paragraph 1.E.1.

1.E.7. Do not charge a fee for access to, viewing, displaying,

performing, copying or distributing any Project Gutenberg™
works unless you comply with paragraph 1.E.8 or 1.E.9.

1.E.8. You may charge a reasonable fee for copies of or

providing access to or distributing Project Gutenberg™
electronic works provided that:

• You pay a royalty fee of 20% of the gross profits you

derive from the use of Project Gutenberg™ works
calculated using the method you already use to calculate
your applicable taxes. The fee is owed to the owner of
the Project Gutenberg™ trademark, but he has agreed to
donate royalties under this paragraph to the Project
Gutenberg Literary Archive Foundation. Royalty
payments must be paid within 60 days following each
date on which you prepare (or are legally required to
prepare) your periodic tax returns. Royalty payments
should be clearly marked as such and sent to the Project
 Gutenberg Literary Archive Foundation at the address
specified in Section 4, “Information about donations to the
Project Gutenberg Literary Archive Foundation.”

• You provide a full refund of any money paid by a user

who notifies you in writing (or by e-mail) within 30 days of
receipt that s/he does not agree to the terms of the full
Project Gutenberg™ License. You must require such a
user to return or destroy all copies of the works
possessed in a physical medium and discontinue all use
of and all access to other copies of Project Gutenberg™
works.

• You provide, in accordance with paragraph 1.F.3, a full

refund of any money paid for a work or a replacement
copy, if a defect in the electronic work is discovered and
reported to you within 90 days of receipt of the work.

• You comply with all other terms of this agreement for free
distribution of Project Gutenberg™ works.

1.E.9. If you wish to charge a fee or distribute a Project

Gutenberg™ electronic work or group of works on different
terms than are set forth in this agreement, you must obtain
permission in writing from the Project Gutenberg Literary
Archive Foundation, the manager of the Project Gutenberg™
trademark. Contact the Foundation as set forth in Section 3
below.

1.F.

1.F.1. Project Gutenberg volunteers and employees expend

considerable effort to identify, do copyright research on,
transcribe and proofread works not protected by U.S. copyright
law in creating the Project Gutenberg™ collection. Despite
these efforts, Project Gutenberg™ electronic works, and the
medium on which they may be stored, may contain “Defects,”
such as, but not limited to, incomplete, inaccurate or corrupt
data, transcription errors, a copyright or other intellectual
property infringement, a defective or damaged disk or other
medium, a computer virus, or computer codes that damage or
cannot be read by your equipment.

1.F.2. LIMITED WARRANTY, DISCLAIMER OF DAMAGES -

Except for the “Right of Replacement or Refund” described in
paragraph 1.F.3, the Project Gutenberg Literary Archive
Foundation, the owner of the Project Gutenberg™ trademark,
and any other party distributing a Project Gutenberg™ electronic
work under this agreement, disclaim all liability to you for
damages, costs and expenses, including legal fees. YOU
AGREE THAT YOU HAVE NO REMEDIES FOR NEGLIGENCE,
STRICT LIABILITY, BREACH OF WARRANTY OR BREACH
OF CONTRACT EXCEPT THOSE PROVIDED IN PARAGRAPH
1.F.3. YOU AGREE THAT THE FOUNDATION, THE
TRADEMARK OWNER, AND ANY DISTRIBUTOR UNDER
THIS AGREEMENT WILL NOT BE LIABLE TO YOU FOR
ACTUAL, DIRECT, INDIRECT, CONSEQUENTIAL, PUNITIVE
OR INCIDENTAL DAMAGES EVEN IF YOU GIVE NOTICE OF
THE POSSIBILITY OF SUCH DAMAGE.

1.F.3. LIMITED RIGHT OF REPLACEMENT OR REFUND - If

you discover a defect in this electronic work within 90 days of
receiving it, you can receive a refund of the money (if any) you
paid for it by sending a written explanation to the person you
received the work from. If you received the work on a physical
medium, you must return the medium with your written
explanation. The person or entity that provided you with the
defective work may elect to provide a replacement copy in lieu
of a refund. If you received the work electronically, the person or
entity providing it to you may choose to give you a second
opportunity to receive the work electronically in lieu of a refund.
If the second copy is also defective, you may demand a refund
in writing without further opportunities to fix the problem.
1.F.4. Except for the limited right of replacement or refund set
forth in paragraph 1.F.3, this work is provided to you ‘AS-IS’,
WITH NO OTHER WARRANTIES OF ANY KIND, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR
ANY PURPOSE.

1.F.5. Some states do not allow disclaimers of certain implied

warranties or the exclusion or limitation of certain types of
damages. If any disclaimer or limitation set forth in this
agreement violates the law of the state applicable to this
agreement, the agreement shall be interpreted to make the
maximum disclaimer or limitation permitted by the applicable
state law. The invalidity or unenforceability of any provision of
this agreement shall not void the remaining provisions.

1.F.6. INDEMNITY - You agree to indemnify and hold the

Foundation, the trademark owner, any agent or employee of the
Foundation, anyone providing copies of Project Gutenberg™
electronic works in accordance with this agreement, and any
volunteers associated with the production, promotion and
distribution of Project Gutenberg™ electronic works, harmless
from all liability, costs and expenses, including legal fees, that
arise directly or indirectly from any of the following which you do
or cause to occur: (a) distribution of this or any Project
Gutenberg™ work, (b) alteration, modification, or additions or
deletions to any Project Gutenberg™ work, and (c) any Defect
you cause.

Section 2. Information about the Mission of

Project Gutenberg™
Project Gutenberg™ is synonymous with the free distribution of
electronic works in formats readable by the widest variety of
computers including obsolete, old, middle-aged and new
computers. It exists because of the efforts of hundreds of
volunteers and donations from people in all walks of life.

Volunteers and financial support to provide volunteers with the

assistance they need are critical to reaching Project
Gutenberg™’s goals and ensuring that the Project Gutenberg™
collection will remain freely available for generations to come. In
2001, the Project Gutenberg Literary Archive Foundation was
created to provide a secure and permanent future for Project
Gutenberg™ and future generations. To learn more about the
Project Gutenberg Literary Archive Foundation and how your
efforts and donations can help, see Sections 3 and 4 and the
Foundation information page at www.gutenberg.org.

Section 3. Information about the Project

Gutenberg Literary Archive Foundation
The Project Gutenberg Literary Archive Foundation is a non-
profit 501(c)(3) educational corporation organized under the
laws of the state of Mississippi and granted tax exempt status by
the Internal Revenue Service. The Foundation’s EIN or federal
tax identification number is 64-6221541. Contributions to the
Project Gutenberg Literary Archive Foundation are tax
deductible to the full extent permitted by U.S. federal laws and
your state’s laws.

The Foundation’s business office is located at 809 North 1500

West, Salt Lake City, UT 84116, (801) 596-1887. Email contact
links and up to date contact information can be found at the
Foundation’s website and official page at
www.gutenberg.org/contact

Section 4. Information about Donations to

the Project Gutenberg Literary Archive
Foundation
Project Gutenberg™ depends upon and cannot survive without
widespread public support and donations to carry out its mission
of increasing the number of public domain and licensed works
that can be freely distributed in machine-readable form
accessible by the widest array of equipment including outdated
equipment. Many small donations ($1 to $5,000) are particularly
important to maintaining tax exempt status with the IRS.

The Foundation is committed to complying with the laws

regulating charities and charitable donations in all 50 states of
the United States. Compliance requirements are not uniform
and it takes a considerable effort, much paperwork and many
fees to meet and keep up with these requirements. We do not
solicit donations in locations where we have not received written
confirmation of compliance. To SEND DONATIONS or
determine the status of compliance for any particular state visit
www.gutenberg.org/donate.

While we cannot and do not solicit contributions from states

where we have not met the solicitation requirements, we know
of no prohibition against accepting unsolicited donations from
donors in such states who approach us with offers to donate.

International donations are gratefully accepted, but we cannot

make any statements concerning tax treatment of donations
received from outside the United States. U.S. laws alone swamp
our small staff.

Please check the Project Gutenberg web pages for current

donation methods and addresses. Donations are accepted in a
number of other ways including checks, online payments and
credit card donations. To donate, please visit:
www.gutenberg.org/donate.

Section 5. General Information About Project

Gutenberg™ electronic works
Professor Michael S. Hart was the originator of the Project
Gutenberg™ concept of a library of electronic works that could
be freely shared with anyone. For forty years, he produced and
distributed Project Gutenberg™ eBooks with only a loose
network of volunteer support.

Project Gutenberg™ eBooks are often created from several

printed editions, all of which are confirmed as not protected by
copyright in the U.S. unless a copyright notice is included. Thus,
we do not necessarily keep eBooks in compliance with any
particular paper edition.

Most people start at our website which has the main PG search
facility: www.gutenberg.org.

This website includes information about Project Gutenberg™,

including how to make donations to the Project Gutenberg
Literary Archive Foundation, how to help produce our new
eBooks, and how to subscribe to our email newsletter to hear
about new eBooks.
Welcome to our website – the ideal destination for book lovers and
knowledge seekers. With a mission to inspire endlessly, we offer a
vast collection of books, ranging from classic literary works to
specialized publications, self-development books, and children's
literature. Each book is a new journey of discovery, expanding
knowledge and enriching the soul of the reade

Our website is not just a platform for buying books, but a bridge
connecting readers to the timeless values of culture and wisdom. With
an elegant, user-friendly interface and an intelligent search system,
we are committed to providing a quick and convenient shopping
experience. Additionally, our special promotions and home delivery
services ensure that you save time and fully enjoy the joy of reading.

Let us accompany you on the journey of exploring knowledge and

personal growth!

ebooknice.com