Software Architect Bootcamp 2nd Ed Mowbray

Thomas J Malveau download

https://ebookbell.com/product/software-architect-bootcamp-2nd-ed-
mowbray-thomas-j-malveau-21347440

Explore and download more ebooks at ebookbell.com

Here are some recommended products that we believe you will be
interested in. You can click the link to download.

Software Architect Bootcamp Raphael Malveau Raphael C Malveau

https://ebookbell.com/product/software-architect-bootcamp-raphael-
malveau-raphael-c-malveau-979378

Software Architect Michael Bell

https://ebookbell.com/product/software-architect-michael-bell-47983716

Software Architects Handbook Become A Successful Software Architect By

Implementing Effective Architecture Concepts 1st Edition Joseph Ingeno

https://ebookbell.com/product/software-architects-handbook-become-a-
successful-software-architect-by-implementing-effective-architecture-
concepts-1st-edition-joseph-ingeno-10554992

Software Architects Handbook Become A Successful Software Architect By

Implementing Effective Architecture Concepts Ingeno

https://ebookbell.com/product/software-architects-handbook-become-a-
successful-software-architect-by-implementing-effective-architecture-
concepts-ingeno-11793456
The Software Architect Elevator Redefining The Architects Role In The
Digital Enterprise 1st Edition Gregor Hohpe

https://ebookbell.com/product/the-software-architect-elevator-
redefining-the-architects-role-in-the-digital-enterprise-1st-edition-
gregor-hohpe-44556590

The Software Architect Elevator 1 Converted Gregor Hohpe

https://ebookbell.com/product/the-software-architect-
elevator-1-converted-gregor-hohpe-21809672

Becoming An Agile Software Architect 1st Edition Rajesh R V

https://ebookbell.com/product/becoming-an-agile-software-
architect-1st-edition-rajesh-r-v-47823452

97 Things Every Software Architect Should Know Richard Monsonhaefel

https://ebookbell.com/product/97-things-every-software-architect-
should-know-richard-monsonhaefel-53601250

Software Architecture For Busy Developers Talk And Act Like A Software
Architect In One Weekend 1st Edition Anonymous

https://ebookbell.com/product/software-architecture-for-busy-
developers-talk-and-act-like-a-software-architect-in-one-weekend-1st-
edition-anonymous-55229804
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
[email protected]

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

International Sales
1-317-581-3793
[email protected]

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
26 Chapter Two Military History

about IT and other capital asset investments. The guidance is heavily based on
the Zachman Framework customized for implementation within the U.S. gov-
ernment.
The FEAF is focused on defining the required processes with the as-
sumption that agencies have the expertise to define additional standards for the
specific artifacts expected to be created by the processes. The FEAF defines
the structure for content after it is developed but does not go into the specifics
of standards and examples for developing content. While reasonable, it has, in
many agencies, produced artifacts that are not suitable for use in fulfilling their
intended purpose. This is partially the result of the lack of sophistication in
upper management, which has grown accustomed to making decisions about
IT investment without a wealth of information being available. Some manage-
ment may view the benefits of a unified view of IT and business as a hindrance
when compared to the relative ease of making decisions in the dark and dele-
gate the understanding, maintenance, and responsibility of the enterprise archi-
tecture to others while retaining the decision-making authority. Such a mindset
effectively dooms the optimal use of an enterprise architecture immediately,
relegating it to a lower level tool for the IT shop to use as an aid in their deci-
sion making. While this will result in some success, often it will not achieve
the large cost benefit that the FEAF authors and advocates intended.
After its initial development, the FEAF was supplemented with a much
needed guide, A Practical Guide to Federal Enterprise Architecture (PGFEA)
[PGFEA 2001], providing more detailed instructions on applying enterprise ar-
chitecture development and FEAF principles to agencies. This guide served the
purpose of bridging the gap between the FEAF guidance and practical use and
also aided in integrating other enterprise architecture approaches into the fed-
eral arena.
The first part of PGFEA outlines all the steps necessary to initiate an en-
terprise architecture program. This includes getting executive buy-in, clearly
defining roles and responsibilities, and establishing management structure and
control. Because the audience is federal government agencies, the PGFEA dis-
cusses how to integrate efforts with the structures of other agencies such as
CPIC and CIO. The hope is that these government agencies will have analo-
gous processes and organizations analogous to those of most large corpora-
tions. For example, the CPIC council that governs the financial investment in
IT systems serves a role similar to the budget organization in most Fortune 500
companies. Furthermore, many of the efforts that are driven by IT legislation
are considered industry-best practices and were created from them in an at-
tempt to have the government achieve the same success rates in IT investments
as those achieved by commercial organizations.
Design Patterns 27

The next part of the PGFEA discusses deciding and documenting the ap-
proach the organization intends to take in developing the enterprise architec-
ture. Making this determination is essential because it provides an opportunity
to scope the enterprise architecture and ensure that what is being developed has
a valid use within the organization. Unfortunately, it assumes that most agen-
cies already have a standard approach to developing the artifacts associated
with an enterprise architecture; this approach is seldom the reality in most or-
ganizations. It is expected that eventually additional guidance will be provided
to assist federal agencies with more limited experience in software architecture
development. The Department of Defense developed the Command, Control,
Communications, Computer, Intelligence, Surveillance and Reconnaissance
Architecture Framework [C4ISR 1997], which provides an example of the
level of guidance that is needed to bridge the gap from the FEAF processes to a
fully realized enterprise architecture. C4ISR takes a different approach to en-
terprise architecture development than FEAF by adopting a greater emphasis
on standards for artifacts; C4ISR has been successfully adopted in numerous
commercial and nonmilitary government enterprise efforts. The C4ISR archi-
tectural framework provides detailed rules, guidance, and product descriptions
for developing the documentation of an enterprise architecture. The products
are appropriately targeted to allow all participants to understand quickly and
then synthesize knowledge about IT systems throughout the enterprise.
Other sections define the development, maintenance, and use of enter-
prise architecture. The three parts of an enterprise architecture are the baseline
architecture, which depicts the enterprise environment as it currently is; the tar-
get architecture, which reflects the desired environment in the future; and the
transition plan, which outlines how to proceed from the baseline architecture to
the target architecture. Most environments are constantly changing so that both
the baseline and target architectures are moving targets. Therefore, there is a
real need to ensure that both architectures are updated regularly so that they
have value in supporting business-level decision making.

2.7 Design Patterns

Software architecture is an eclectic practice, combining ideas from many areas

of computer science and software engineering. Reusing these ideas and exist-
ing knowledge is paramount to the effective practice of the architectural disci-
pline. The popular movement of design patterns has codified and documented a
great deal of software knowledge for this purpose. The driving force behind the
28 Chapter Two Military History

success of design patterns in the software community has been the on-going
work of the Hillside Group, an organization dedicated to improving human
communication about computers by encouraging people to codify common
programming and design practice [Hillside 2003].
The design patterns community has made reusing lessons learned a popu-
lar, trendy approach. Patterns represent a rejection of originality as a technical
goal, including an active avoidance of the Not-Invented-Here syndrome. Soft-
ware architects should also be pattern literate.
Design patterns are a significant addition to software engineering in the object-
oriented software development community. Design patterns are documented
representations of software engineering knowledge. They are intended to cap-
ture expert-level knowledge and important lessons learned. Design patterns are
a departure from previous object-oriented guidance in several respects. Patterns
document essential design knowledge, transcending original object-oriented
notions. Originally, object orientation was based upon modeling the natural
world as objects. To design effective software systems, more sophisticated and
often abstract structures that are unique to software are needed.

Hillside Group Patterns Home Page

“Fundamental to any science or engineering discipline is a common vocabulary

for expressing its concepts and a language for relating them together. The goal
of patterns within the software community is to create a body of literature to
help software developers resolve recurring problems encountered throughout
all of software development. Patterns help create a shared language for com-
municating insight and experience about these problems and their solutions.
Formally codifying these solutions and their relationships lets us successfully
capture the body of knowledge which defines our understanding of good archi-
tectures that meet the needs of their users. Forming a common pattern language
for conveying the structures and mechanisms of our architectures allows us to
intelligibly reason about them. The primary focus is not so much on technology
as it is on creating a culture to document and support sound engineering archi-
tecture and design.” (Hillside Group—http://hillside.net/)

Design patterns have rigorous requirements for documenting knowledge.

Design patterns should represent proven solutions, not merely wishful thinking
Design Patterns 29

about how software should be done. This concept is embodied in the so-called
rule of three. Informally, the rule of three states that: “A single design occur-
rence is an event, two occurrences are a coincidence, and three occurrences are
a pattern.” To the design patterns authors, there is a more literal meaning: pat-
terns are proven solutions applied by one or more communities of experts on a
recurring basis.
Design patterns also introduce the notion of design force, also called is-
sues or concerns. Design patterns document these forces explicitly and elabo-
rate the solution in terms of resolving the design forces.
Design patterns represent a high-quality movement, focused on proven
approaches to development, which has its own conference series and substan-
tial visibility at technology events. The origin of design patterns comes from
actual bricks-and-mortar building architecture [Alexander 1977]. The original
vision for design patterns included a design-level model that was not observed
in other authors’ work. Design patterns represent a powerful approach for doc-
umenting guidance and solving technical problems in software architecture and
system development. Figure 2.8 shows an example of a popular design pattern,
called model-view-controller. This pattern applies at the framework level and
provides an approach for reusing software objects that contain data and pro-
cessing that must be viewed and controlled in many different ways.
The model-view-controller pattern includes model objects, view objects,
and controller objects. The model object is the reusable component. It repre-

Users

Synonymous uses:

Smalltalk–80:
model–view–controller
View Controller
Jacobsen’s reuse classes:
entity, interface, control

OMG business objects:

entity, interface, process
Model

FIGURE 2.8 Model-View-Controller Pattern

30 Chapter Two Military History

sents the data in the system and the encapsulating processes that need to be
represented and controlled in several ways. The view objects represent various
visualizations of that information, and many simultaneous views may be pre-
sented to groups of users. The controller objects represent various business
processes or mechanisms for controlling the processing of the data. The
model-view-controller pattern has been around at least since the creation of the
Smalltalk programming language and has been reapplied at several different
scales of software by various groups, including UML’s business classes and
the OMG business object task force that defines business objects in an analo-
gous set of categories [Mowbray 1997b]. Figure 2.9A shows the overall struc-
ture of design patterns. The essence of any design pattern is a
problem–solution pair. The problem is explained and expanded in terms of the
applicable design forces and any contextual forces that may be present. The
solution resolves the design forces in a particular manner. The selection of any
solution is a commitment, and a commitment provides some benefits as well
as consequences. In addition, selecting a solution may lead to additional prob-
lems where other patterns are appropriate.
Design patterns are distinguished from other forms of software literature
in that design patterns are presented in terms of a standard outline or template.
Several templates that meet the needs of various software design models have
been published. Figure 2.9B lists the template developed for the CORBA de-
sign patterns [Mowbray 1997a]. In this template, the solution description is

Problems

Applicable forces

Solutions

Benefits Consequences

Related patterns

FIGURE 2.9A Design Pattern Structure (right side)

Design Patterns 31

Pattern name
Intent
Primal forces
Applicability
Solution
Benefits/consequences
Variations
Scalability
Related solutions
Example
Background

FIGURE 2.9B An Example Pattern Template (left side)

separate from the variations of the solution, which may vary by structure and
by scale of application. Making this separation allowed the authors to clarify
the base solution at a particular scale and then to describe the variations and
nuances of applying the pattern in separate sections of the template. The design
pattern template is a rhetorical structure that ensures consistent coverage of the
key questions that people may need to answer in order to apply the design in-
formation. In particular, when justifying the application of a pattern, an under-
standing of the benefits and potential consequences of the pattern is important
if the real tradeoffs in design are to be understood. If the design pattern authors
have properly documented the pattern, they have identified those points of de-
bate explicitly so that the users of the pattern do not need to reinvent that infor-
mation.
Figure 2.10 is an example of a CORBA design pattern that applies in
general to technologies beyond CORBA for system building. The problem is
that most systems have vertical solutions, where each software module has a
unique interface corresponding to each software implementation. The vertical
solutions lead inevitably to stovepipe interdependencies between the modules
in the system. By adding the common interface pattern to a system, the com-
mon interoperability information can be captured so that the software modules
can interoperate without explicit dependencies upon particular implementa-
tions. The common interface pattern is a fundamental principle that is applied
in standardization work and in software architectures in general.
Figure 2.11 shows a related pattern that applies the common interface in
a more general and sophisticated context. In this pattern, called the horizontal
vertical metadata pattern, a static architecture for a system is defined in terms
of a common interface with vertical interface extensions; some dynamic
32 Chapter Two Military History

Vertical solutions

Common interfaces are

horizontal solutions

FIGURE 2.10 Common Interface Pattern

architectural elements are added represented as metadata. A key tradeoff de-

scribed in the pattern talks about how dynamic architecture and static architec-
ture can be varied to represent different portions of the design. Dynamic
architecture is one of the key solutions for implementing variability and adapt-
ability in software architectures.

Static Dynamic
architecture architecture

Vertical Vertical Vertical Vertical

Vertical API API API API Metadata
interfaces Change &
Functionality & resource
performance management

Horizontal interfaces
Change & complexity

FIGURE 2.11 Horizontal Vertical Metadata Pattern

Design Patterns 33

V
M System = application profile
H

V
M Enterprise = system profile
H

V
M Domain/industry = functional profile
H

V
M Global = a standard
H

FIGURE 2.12 Pattern Applicability at Multiple Scales

Figure 2.12 shows how the horizontal-vertical-metadata pattern is actu-

ally an instance of a more general concept that is applied across standards orga-
nizations and profiling entities all the way down to a system level of
deployment. This application of the horizontal-vertical-metadata pattern is di-
rectly analogous to the functional and system profiles described in Chapter 5,
where the functional profile is a vertical extension of a global standard. A sys-
tem profile is a vertical extension of a functional profile, and any particular ap-
plication system is a vertical instance of a system profile.
Figure 2.13A shows an application-level pattern and how it is applied.
This example provides a flavor of what is involved. In this case, a UML se-
quence diagram is shown. Before the pattern is applied, a simple request and
return transaction actually causes the client program, or thread, to block while
it is occurring. It turns out that this is the default behavior of most distributed
computing infrastructures such as remote procedure calls and CORBA. The
performance of this configuration can be improved by adding a moderate
amount of complexity and, after applying the pattern, returning a reference to
the result that will be computed in parallel and retrieved later (Figure 2.13B).
34 Chapter Two Military History

Before applying the pattern

Service
Client object

Unable to proceed Request()

Time

Return

FIGURE 2.13A Partial Processing Sequence Diagram (left side)—

Before Applying the Pattern

After applying the pattern

Service
Client object

Request()

Return Continue
Continue with partial
Time

Return

FIGURE 2.13B Partial Processing Sequence Diagram (right side)—

After Applying the Pattern
Antipatterns 35

Gamma Buschmann CORBA Fowler

Design Architecture Design Analysis
Patterns Patterns Patterns Patterns

Software Micro- Micro to Objects to

System
Scale Architecture System Micro

Most OO System System OO

Useful to Programmer Architect Architect Analyst

Key Change
Change Functionality
Horizontal Change Complexity
Complexity Change
Forces Performance

FIGURE 2.14 Comparison of Design Pattern Languages

Figure 2.14 shows a table of several examples of design pattern lan-

guages. Much of the available pattern documentation addresses a specific soft-
ware design level. More recent work on CORBA design patterns and
pattern-oriented software architectures has addressed several levels of abstrac-
tion where these levels are explicit. At the idiom level of design patterns, the
guidance is focused on improving individual objects. Idiom documentation has
been widely available in the form of programming language guidebooks. Id-
ioms represent expert programming techniques that one would rediscover after
substantial use of a language. If software engineers are maintaining software
written by other people, it is essential to understand idioms in order to under-
stand the intentions of the programmers applying these sophisticated ideas.
One of the first published design pattern languages described microarchi-
tecture patterns [Gamma 1994]. The goal of the gamma pattern language was
to invent a new discipline of variation-centered software design. The gamma
pattern language is organized in terms of several categories including cre-
ational patterns, structural patterns, and behavioral patterns. When applying the
gamma patterns, complexity of design is increased with the benefit of potential
support for potential modification of the software. Gamma patterns have be-
come very popular and are applied widely in software engineering organiza-
tions today.

2.8 AntiPatterns

Another development in the software development community that comple-

ments design patterns is called AntiPatterns. An AntiPattern is a literary form
that describes a solution to a commonly occurring problem that generates
Other documents randomly have
different content
 A DISCUSSION ABOUT CLOTHES

“You look first-rate, father, and a lot more comfortable than usual, I
can tell you.”
It was at Martyn’s suggestion that Horace had urged his father to
make a change in his attire.
“It would be a good thing if you could get him to put on sea-going
togs,” the sailor had said. “He is the owner of as smart a craft as ever
sailed out of British waters, and he will look a good deal more at home
on the deck of his own ship in regular yachtsman’s dress than he
would rigged up in his ruffles and boots.”
With this Horace had agreed heartily, for his father’s appearance on
occasions when he had gone out with him in the Surf had struck him
as being wholly incongruous with the surroundings.
At half-past eight they went down to the steps, two porters carrying
the luggage under the watchful eye of Zaimes. As they were seen, the
smart gig with its six rowers, which was lying a short distance off,
rowed in to the steps. Tarleton was steering. He stepped out to hand
Mr. Beveridge into the boat.
“This is Mr. Tarleton, father, our second lieutenant.”
“I am glad to meet you, sir,” Mr. Beveridge said, shaking hands with
the young officer. “I hope that we shall have a pleasant cruise
together.”
“I feel sure we shall, sir. If one couldn’t be comfortable on board the
Creole, one couldn’t be comfortable anywhere.”
Tarleton took his seat in the centre to steer, with Mr. Beveridge and
Horace on either side of him, Zaimes and the luggage were placed in
the bow. The bowman pushed the boat off with the boat-hook. The
oars, which had been tossed in man-of-war fashion, fell with a splash
into the water, and then with a long steady stroke the gig darted away
from the steps.
“This is certainly very pleasant,” Mr. Beveridge said as they threaded
through the anchored craft and made their way seaward. “I begin to
wish I had taken up yachting twenty years back.”
“Well, it is not too late, father. When we have done with Greece, you
can go in for amusement if you like.”
“I should never find time, Horace.”
“Oh, you could make time, father. You could spare three months in the
year and be all the better for it. When you have once had a break, you
will find how pleasant it is.”
Half an hour’s row and Horace said: “That is the Creole, father, lying in
there near the farther point.”
“She doesn’t look as large as I expected, Horace, though her masts
seem a great height.”
“She is heavily sparred for her length,” Tarleton said, “but she has
great beam; besides she is rather low in the water now, and of course
that makes the spars look big in proportion. She will be a bit higher by
the time we get out. Fifty men consume a considerable weight of
stores and water every week. You will be pleased with her, sir, when
we get alongside. We all think she is as handsome a craft as we ever
set eyes on. She will astonish the Turks, I warrant, when it comes to
sailing.”
Another twenty minutes they were alongside. According to naval
etiquette Horace mounted the ladder first, then Tarleton, and Mr.
Beveridge followed. Martyn and Miller received him at the gangway,
the former introducing the first officer and the surgeon to him.
“She is a fine-looking vessel,” Mr. Beveridge said, “and you have
certainly done marvels with her, Captain Martyn, for my son wrote me
that she had nothing but her lower masts in her when you took
possession, and now she is wonderfully bright and clean, and these
decks look almost too white to walk on.”
“I hope that we shall always keep her in equal order, sir. We have a
capital crew, and no one could wish for a better craft under his feet.”
Mr. Beveridge was now conducted round the ship, and expressed
himself highly gratified with everything.
“Is it your wish that we should make sail at once, sir?” Martyn asked.
“We have been expecting some heavy luggage on board, but it has
not arrived.”
“I changed my mind about it, and there is nothing coming, Captain
Martyn. I am perfectly ready to start if you have everything on board.”
“There is nothing to wait for, sir; we are perfectly ready.”
They returned to the quarter-deck, and as Martyn gave the orders
there was a general movement on the part of the crew. Some of the
men clustered round the capstan, while others prepared to make sail,
and Mr. Beveridge felt a keen sense of pleasure as he watched the
active fellows at their work. In five minutes the sails were set, the
anchor at the cat-head, and the Creole moving through the water
under the light breeze off shore.
They had favourable winds across the Bay and down the coast of
Portugal. Everything from the start had gone as smoothly as if the
Creole had been six months in commission—officers and men were
alike pleased with the ship; the provisions for the sailors were of the
best quality; the duties were very light, for the sails had not required
altering from the time they had been set, although each day the men
practised for an hour at lowering and setting them, in order to
accustom them to work smartly together.
There was half an hour’s cutlass drill, and for the rest of the day,
beyond cleaning and polishing, there was nothing to be done. Mr.
Beveridge spent the greater part of his time in a comfortable deck-
chair on the quarter-deck, for there was no poop, the deck being flush
from end to end. Horace attended to his duties as third officer
regularly, and the nights were so warm and pleasant that the watches
did not appear long to him. There was no stiffness in the cabin when
they gathered to their meals, or in the evening, and Mr. Beveridge
proved in no way a wet blanket on their fun, as the three officers had
rather anticipated he would be. He talked but little, but was
thoroughly amused at their yarns and jests, all of which were as
strange to him as if he had lived in another world.
“You will certainly have to cut off our rations a bit, Mr. Beveridge,” Will
Martyn said one day as they finished dinner. “We shall be getting as
fat as porpoises if we go on like this. I can feel my togs filling out
daily; and as for Tarleton, he will have to have all his things let out by
the time we arrive in the Levant. For the credit of the ship I shall have
to give orders for us to be supplied with the same rations as the men,
and go in for luxuries only on Sundays. We are not accustomed to be
tempted in this way at every meal. It is all very well for you who do
not eat much more than a sparrow to have such nice things always
put before you; but to us who have been accustomed to a steady diet
of salt junk, except when we put into port and are able to get fresh
meat for a change, these things are beyond our power of resistance.”
“I eat a great deal more than I did on shore,” Mr. Beveridge said. “I
find, indeed, a wonderful improvement in my appetite. It was quite an
infliction to Zaimes that I cared so little for the good things he
provided me with. I can assure you I really begin to look for my meals
now, and it is a pleasure for me to see you all eat with good healthy
appetites, and I am sure that it must be a great gratification to the
Greeks to see their efforts appreciated at last.”
“It is Tarleton I am thinking of principally, sir; as for Miller, nature
made him square, and it would be no disadvantage if he became
round; while as to the doctor, food is simply wasted on him, he will
never do credit to your cooks. But Tarleton, with those dark eyes of his
and his gentle sort of way, was what the ladies would consider an
interesting youth, and he would, I am sure, forfeit the good opinion of
the ladies altogether if he were to return looking like a mildly
animated sausage.”
Tarleton joined in the laugh. “I do think I have gained a lot in weight
the last week,” he said; “but we won’t always go on in this quiet sort
of way. As for what Martyn says, I believe it is only jealousy on his
part at seeing that my angles are filling out.”
On arriving at the Straits they put in at Ceuta and obtained a supply of
fresh meat and vegetables. In the Mediterranean they fell in with dead
calms and were a fortnight in getting to Gozo, where they again
replenished their stock. They abstained from putting in either at
Gibraltar or Malta in order to avoid being questioned as to the cargo
and destination of the Creole.
“Now, sir,” Will Martyn said when they were within two days’ sail of
Greece, “it is quite time to decide what port we shall make for, but we
can’t decide that until we know how matters are going on. When we
left England there were very conflicting accounts of the progress of
the revolution, and whether Corinth, Patras, Nauplia, or Athens are in
the hands of the Greeks or Turks. Well, I should say, sir, that our best
plan would be to put in at Zante, where, as it is English, and therefore
neutral ground, we shall learn all about the state of affairs, and may
meet some of our own people or foreigners who have been fighting by
the side of the Greeks. Half an hour’s talk with one of them would give
us a better idea how everything stands than a week’s talk with
Greeks.”
“I think that will be a very good plan,” Mr. Beveridge agreed. “Flying
the English flag we might go in or out of any of the harbours as
neutrals; but if by any chance it leaked out what our cargo is the Turks
would probably consider themselves justified in laying hands on us.”
“At any rate it is well not to run the risk, Mr. Beveridge, as there is no
object to be served by it. I will take the bearings of Zante and lay our
course for it.”
There was, indeed, no spot where they were more likely to obtain
accurate news of what was going on than Zante, lying as the island
does at a short distance from the mouth of the Gulf of Corinth, upon
which were three of the most important towns in Greece—Patras,
Corinth, and Missolonghi. Here, too, the fugitives from the Morea, of
either party, would naturally make their way.
It was the 8th of October when the Creole, flying the English flag at
her peak, dropped anchor in the port. As soon as she did so a custom-
house officer came on board.
“What ship is this?” he asked the first officer, who was on deck.
“This is the Creole, a private yacht belonging to Mr. Beveridge. The
owner is below if you wish to see him.”
“You have no merchandise on board?”
“I tell you that it is a yacht,” Miller said. “An English gentleman doesn’t
bring out merchandise for sale in his yacht. The captain will show you
her papers.”
Will Martyn came on deck.
“This is the captain,” Miller said. “You had better address him.”
On hearing what was required Martyn took the officer below and
showed him the ship’s papers.
“I see it is mentioned here that you were bound from England to
Lisbon,” the officer observed.
“Yes. We did not put in there, as Mr. Beveridge was anxious to get into
a warmer climate.”
“I see you are strongly armed,” the officer said when he came on to
deck again, for after leaving Malta the eight twelve-pounders and the
pivot-gun had been got up from the hold and mounted.
“Yes, we are armed, as you see. I imagine you would hardly
recommend anyone to be cruising about in these waters without
means of defence.”
“No, indeed,” the officer laughed. “The Greeks are pirates to the core.
You would be all right with the Turks, although from your appearance
I should not think they would ever get near enough to trouble you.”
Half an hour later Mr. Beveridge and Horace were rowed ashore. As,
except at Ceuta, Horace had never set foot ashore out of England, he
was much amused and interested by the varied population. Mingled
with the native population of the island were Greeks from the
mainland; Albanians in their white pleated petticoats, bristling with
arms mounted in gold and silver; a few English soldiers walking about
as unconcernedly as if in a garrison town at home; and sailors of
several nationalities from ships in harbour.
“I should think, father, the proper thing would be to call upon the
English officer in command here and invite him to dinner. We shall get
a general idea of the state of things from him.”
Asking a soldier, they found that the small detachment there was
under the command of Captain O’Grady, whose house, at the entrance
to the barrack, was pointed out to them. The officer was in, and on
Mr. Beveridge sending in his card they were at once shown in.
“I am the owner of a schooner-yacht, the Creole, that dropped anchor
an hour ago,” Mr. Beveridge said. “I know very little about the
etiquette of these things, but it seemed to me the proper thing was to
call at once upon His Majesty’s representative here.”
“A very right and proper thing to do, Mr. Beveridge. I have been
wondering what that craft could be, and where she had come from. If
it hadn’t been for the flag and the tidiness of her I should have put
her down as a Greek pirate, though they don’t often rig up their crafts
as schooners.”
“She has been something like a pirate in her time,” Mr. Beveridge said,
“for she was a slaver, captured and sent home as a prize. I bought her
at Plymouth and fitted her out.”
“And a mighty nice way of spending money too, Mr. Beveridge. She is
the biggest thing in the way of yachts I ever saw. I don’t at all see
why a gentleman shouldn’t buy a big ship and cruise about the world
in her if he can afford it.”
“Well, Captain O’Grady, I won’t occupy your time now, but shall be
glad if you will come off and dine with me at six o’clock to-day. I have
come straight from England, and have heard nothing as to how
matters stand out here. If you will bring any of your officers off with
you I shall be very glad to see them.”
“I have only two here. Mr. Lester, my lieutenant, will be on duty, and I
have no doubt that Plunket will be very glad to come off with me if he
has no special engagement, which is not likely, for it is a mighty dull
life here, I can tell you, and it is glad I shall be when the order comes
to rejoin the regiment at Corfu.”
Mr. Beveridge and Horace walked about for some time, and then
returned on board. They met their two Greeks in the town shopping,
and told them that there would be guests at dinner. They met also Will
Martyn and Tarleton, who had come ashore a short time after them,
Miller remaining on board in charge; a good many of the men were
also ashore.
“I have warned them solemnly,” Martyn said, “against drink and
quarrels, but I am afraid that to-night and to-morrow night we shall
have a good many of them coming off noisy. Wine is cheap, and as
they haven’t set foot ashore for five weeks it is not in the nature of an
English sailor to resist temptation. I don’t care much as long as they
don’t get into rows with the Greeks. I have told them the boats will be
ashore at nine o’clock to fetch them, and that any who are not down
there by that hour will have their allowance of grog stopped for a
fortnight.”
It had been arranged with Captain O’Grady that the boat should be at
the steps for him at a quarter to six. Horace went in charge of it, and
brought off the two officers.
“You have comfortable quarters here, indeed,” Captain O’Grady said
when Mr. Beveridge had introduced his officers to him and his
companion. “Sure I would like nothing better than to travel about in a
craft like this. It is like taking a floating palace about with you.” But if
the officers were surprised at the fittings of the cabin they were still
more so at the excellence of the dinner. Up to the time the dessert
was placed on the table they chatted as to the incidents of the
voyage; but when the wine had gone round Mr. Beveridge began
questioning them.
“Of course you hear everything that goes on on the mainland, Captain
O’Grady.”
“Everything, do you say? It is well content I would be if that was all I
heard; but the thundering lies that are told by those Greek rapscallions
are enough to take one’s breath away. To hear them talk you would
not think that such valiant men had ever lived since the days of Noah;
and yet, with the exception of a little skirmish, all that they have done
is to starve out those unfortunate heathens the Turks, and then after
they have surrendered on promise of good treatment, to murder them
in cold blood with their women and children.”
“I hope that there has not been much of that,” Mr. Beveridge said
gravely.
“It depends upon what you call much of it. At the very lowest estimate
there have been thirty thousand murdered in cold blood since the
troubles began; and some accounts put it much higher. There has not
been a single exception; nowhere have they spared a Mussulman. The
poor beggars of farmers and villagers were killed; man, woman, and
child, in hundreds of villages the whole of them were destroyed
without resistance; and it has been the same in all the large towns.
The Greeks began the work at Kalamata, which surrendered under a
solemn promise of their lives to the Turks; but every soul was slain.
And so it has been all along. In the district of Laconia there were
fifteen thousand Mussulmans, and of these two-thirds at least were
slain. At Missolonghi there are not twenty Turks alive.
“At Navarino every soul was murdered. Tripolitza surrendered only a
week ago, and I saw by a letter from Colonel Raybonde, a French
officer, who commanded the Greek artillery during the siege, that
forty-eight hours after they entered the city they collected about two
thousand persons, principally women and children, and drove them up
a ravine and murdered them there; and altogether eight thousand
Mussulmans were killed during the sack. I have heard of massacres till
I am sick of listening to the stories; and though at the beginning I
hoped that the Greeks would drive the old Turks out, faith I have
come to think that if I were to hear that the whole race were utterly
exterminated I should feel more comfortable in my mind than I have
been for some time. Not content with murdering the poor creatures, in
many cases the villains tortured them first. I have heard fellows who
came over here boast of it. One Albanian ruffian who told me that he
had done this, told me, sir, as if it were a thing to be proud of. I had
the satisfaction of taking him by the scruff of his neck and the tail of
his white petticoat and chucking him off the pier into the sea. When
he scrambled out I offered him the satisfaction of a gentleman, seeing
that he was a chief who thought no small beer of himself. There was a
deal of difficulty in explaining to him how the thing was managed in a
civilized country, and I never felt more satisfaction in my life than I did
next morning when I put a bullet into the scoundrel’s body.”
A wet blanket seemed suddenly to fall over the party in the cabin as
Captain O’Grady was speaking. Horace saw that Miller, who was sitting
opposite to him, was undergoing an internal convulsion in restraining
himself from bursting into a laugh; and Will Martyn, who was facing
Mr. Beveridge at the bottom of the table, looked so preternaturally
grave that Horace felt that he too was struggling to repress a smile.
The doctor nodded, as if to signify that it was exactly what he had
expected. Mr. Beveridge looked deeply concerned.
“I have heard something of this in England, Captain O’Grady, though
of course the Greek agents there suppress all news that would tell
against their countrymen, but I did not think it was as bad as this. Yet
although I do not for a moment attempt to defend such atrocities, you
must remember how long the Greeks have been oppressed by the
Turks. A people who have been in slavery for hundreds of years to
strangers, aliens in blood and in religion, and themselves in a very
primitive state of civilization, except in the cities, would be almost
certain in the first rising against their oppressors to commit horrible
excesses. The same thing happened, although, happily, on a much
smaller scale, in your own country, Captain O’Grady, in ’98, and that
without a hundredth part of the excuse that the Greeks had.”
“True for you, Mr. Beveridge,” Captain O’Grady admitted. “There’s no
denying that you have turned the tables on me there. It is mighty
difficult, as you say, to hold a savage peasantry in hand.”
“It was the same thing in the French Revolution. That again was
practically a revolt of slaves, and they behaved like fiends; and the
number of persons murdered—men of their own race and religion,
remember—was at least as great as that of those who have been
massacred here. The revolt called the Jacquerie, in the middle ages,
was equally ferocious, and the number of victims would probably have
been as great had not the revolt been nipped in the bud. I regret
deeply the conduct of the Greeks; but I think it was only what was to
be expected from a people naturally fierce and revengeful under the
circumstances.”
“Maybe you are right, Mr. Beveridge, though I did not look at it in that
light before.”
“And who are their leaders now?”
“Faith they are all leaders. One day one hears one man’s name
mentioned, that is hard enough to crack one’s jaw; the next day he is
upset and another has taken his place. Every dirty little chief of
brigands sets himself up as a leader, and as they are about the only
chaps who understand anything about fighting they come to the front.
If they only spent a twentieth part of the time in preparing for war
which they do in quarrelling among themselves as to their share of the
spoil, it seems to me they would make a much better fight than they
are likely to do. There is a fellow called Odysseus, which is their way
of pronouncing Ulysses; he used to command the Mohammedan
Albanians under Ali Pasha. Now he has turned round, and fights
against his old master. He is one of the chief of them. Then there are
Kolokotronis and Mavrocordatos. I should say they are the two
principal men just at present. Then there is a chap called Prince
Demetrius Hypsilantes. He is the brother of a fellow who got up the
rising up in the north of the Danube, and pretends to be the head of
all the Greeks. Demetrius says he is invested by his brother with a sort
of viceroyalty over Greece, and wants to have it all his own way. Then
there are the Greek bishops and priests. They are pretty well against
all the rest, and want to keep the peasantry under their thumb. Then
there are the primates; they have got a big lot of power.”
“Do you mean archbishops?” Captain Martyn asked.
“Not a bit of it. The primates are a sort of half-and-half officers. They
are supposed to be chosen by the people of their own district, and of
course they are always the big-wigs; the chaps with most power and
influence. Once chosen they became Turkish officers, collected the
taxes, and were each accountable for the money and for the doings of
their district. Nicely they ground the people down and feathered their
own nests. Naturally, when the Turks went they became the local
leaders. The people had no one else to look to but them and the
priests. In the Morea these two classes have all the power in their
hands. North of that we don’t hear much of the primates. I don’t think
they had any of them there. It’s the Albanians, and the Klephts, that is
the brigands, and some of the fighting clans, such as the Suliots and
the bands of armatoli, which are a sort of village militia, who are the
backbone of the rising.
“All the chiefs are jealous of each other, and if one fellow proposes a
plan all the others differ from him; or if there is one of the big leaders
there, and his plan is adopted, the others either march away to their
homes or do what they can to prevent it from succeeding. The great
thing with all the chiefs is to get spoil. The people are different; they
really want to fight the Turks and to win their freedom; and it is
because they see that not one of their leaders is honest, that their
jealousies keep them from any common actions, and that they will not
unite to form any central government, that the people have no
confidence in them, but just follow one man until they get disgusted
with him, and then go off to join another.
“Everything is wasted. The spoil they have taken has been enormous;
but the people are little the better for it; it is all divided among the
chiefs, and not a penny of it has gone to form a fund for defence.
They have captured enormous quantities of ammunition, but they
have fired it away like children, just to please themselves with the
noise. At one place I was told by an Englishman who was there that
the two million cartridges they captured were all wasted in what they
called rejoicings in the course of three days. What they want is a big
man—a fellow who will begin by hanging a hundred politicians, as
many chiefs, bishops, and primates; who would organize first a
government and then an army; and would insist that every halfpenny
taken as spoil from the Turks should be paid into the public treasury.
Then, sir, I believe that the Greeks would polish off these sleepy Turks
in no time, with the advantage they have in knowing every foot of the
mountains, in being as active as goats, and in possessing the idea that
they are fighting for freedom. Mind I don’t say that the Turks will beat
them even as they are. The Turkish pashas are as incapable as the
Greek leaders. Their soldiers are good, but as the Greeks have no
regular army, and no idea of standing up to fight fair, the Turks can’t
get at them, and the Greeks can move about quickly and fall upon
them at their own time; and besides they will bring them to a
standstill by starvation. They don’t care about attacking the Turkish
troops, but they are down like a pack of wolves on a baggage train,
and if the Turks venture any distance from the sea-coast they will be
harassed out of their lives.”
“Have the Turks still the command of the sea? There the Greeks ought
to be their match anyhow.”
“Yes, the Turks still send their store-ships escorted by their men-of-
war frigates and corvettes. The Greeks hover round them and among
them, but they take care to keep pretty well out of range of the
Turkish guns, and their only idea of fighting seems to be to launch
fire-ships at them. A man-of-war was burnt while at anchor a short
time back by Knaris, who is the best sailor the Greeks have got. Still,
at present the Turks are so far masters of the sea that they take their
convoys where they like and can revictual their fortresses whenever
they have the energy to do so. On the other hand, the Greeks scour
the seas in all directions, and not a single merchant ship flying the
Turkish flag dare show her nose outside the Dardanelles.”
“Is the cruelty all on one side?” Horace asked.
“Not a bit of it. Of course the Turks have not had much chance yet,
but when they have had they have naturally paid the Greeks in their
own coin. In Thessaly they have put down the rising ruthlessly. But
when the troops go into a place and find that the whole of their
people have been murdered it is not to be wondered at that they set
to to play the same game on those who began the work of massacre.
The Greeks hate the Turks, and their object is to root them out
altogether. The Turks despise the Greeks, but they don’t want to root
them out by any means, because if they did there would be no longer
any revenue to collect. The Turks seem to strike more at the leaders.
They have strung up a lot of Greeks living in Constantinople, and as
the whole affair was got up there, and the Greeks were, most of them,
taking the Sultan’s pay while they were plotting against him, it is only
just that if anyone was to suffer they should be the men. What I am
afraid of is that when the news of this horrible massacre of eight
thousand people at Tripolitza gets known, the Turks in Asia Minor will
everywhere retaliate upon the Greeks settled among them.
“They can’t do much in Greece, for most of the people can take to the
mountains; but there are almost as many of them settled in Asia Minor
as there are here, for they are the traders and shopkeepers in every
port, and I am afraid it will go mighty hard with them everywhere
when the Turks come to know the atrocities that have been
perpetrated over here. If the Greeks had thought for a moment when
they began they would have seen that it was a game two could play
at, and for every Turk they could murder the Turks had in their hands
three Greeks at least that they could put an end to. To my mind it is a
bad business altogether. Plunket will tell you that I have not put it a bit
too strongly.”
“Not in the least,” the young officer said. “The tales these fellows tell
are ghastly. We have them over here by dozens. A man is a leader one
day and a fugitive the next; and they run over here till they see a
chance of landing again and getting together a fresh band, and they
actually make a boast of the horrible massacres they have taken a
part in. If the islanders here saw their way to it they would rise
against us, and as it is, it has been as much as we can do more than
once to prevent their going on board neutral vessels that put into
harbour with a few wretched Turkish fugitives, and murdering them.
The fact is, the Greeks believe that they are Christians, but they are
just as much pagans as they were two thousand years ago. My
sympathies are altogether with them in their struggle for liberty, and I
try to make every allowance for their actions; and I do believe that if
what O’Grady says could be carried out and all their leaders, and
politicians, and bishops, and primates hung, the people themselves
would carry on the struggle with ten times the chances of success
they have at present, for they would then be forced to form a strong
central government and might find some honest man to put at its
head. They regard it in the light of a religious war rather than one for
national freedom, and I suppose that at least half the Mussulmans
who have fallen are of Greek blood, for, especially in the north, nearly
half the tribes have changed their religion and become Mohammedans
since their conquest.”
“Are there many Europeans fighting with them? You mentioned a
French colonel commanding the Greek artillery in the siege of
Tripolitza.”
“A good many. There are some Austrians, Frenchmen, Italians, and a
few of our own people. Among the last is a General Gordon and a
naval lieutenant; but although the Greeks know nothing whatever of
military matters, they are jealous in the extreme of any interference or
even advice from foreigners. I believe there are altogether thirty or
forty foreign officers who came over to fight for them, and only two or
three of these have got employment of any sort. As to any attempt to
introduce military discipline, or raise anything like a body of regular
soldiers, it seems impossible. They believe entirely in fighting in their
own way and dispersing when they choose, just as the Spanish
guerilla bands did during the Peninsular War. In fact it seems to me
that the Greek character resembles the Spanish very much, the
peasantry in both countries being brave and animated by a patriotic
hate of their enemies, while the upper class are equally vain, cowardly,
given to boasting, and absolutely faithless to their promises. If we had
the Duke of Wellington here with a couple of hundred good officers he
would make the Greeks into as good soldiers as he did some of the
Portuguese, and would as likely as not wind up the war by driving the
Turks out of Europe altogether.”
At half-past ten o’clock the officers went ashore. When they had left
the ship, the others returned to the cabin.
“I should not take it to heart, Mr. Beveridge,” Will Martyn said
cheerfully, seeing how depressed his employer looked at the news he
had heard. “Of course the Greeks have behaved badly—horribly badly;
but you see it is because the poor beggars are not much better than
savages, and never will be better as long as they are kept down by the
Turks. All these things will right themselves in time. As you said, they
are no worse than the French when they rose, or than the Spanish
peasantry whenever they got a chance, or the Irish peasantry, and we
must not look at it from our own standpoint; once they are free they
will get a settled government and become a nation again, and that is
what we have got to help them to do. We are not going to land and
take part in massacres. All we have got to do is to look out for a
Turkish ship of war, and pull down her colours whenever we get a
chance. But even more than that, what I want specially to do as soon
as we can is to get rid of some of that cargo in our hold. That is what
is bothering me at present.”
“Thank you, Martyn,” Mr. Beveridge said, holding out his hand to him.
“It is trying to hear of a glorious cause being disgraced by such
horrible atrocities, but the cause remains the same, and the atrocities
are, as you say, such as have occurred among other peoples when
their blood has been heated to boiling point. This will not shake my
determination to aid Greece in her struggle for freedom.”
 CHAPTER VII
A CHANGE OF NAME

T HE next two days Mr. Beveridge and Horace spent entirely on

shore. Speaking modern Greek fluently, they were able to converse
with people of all classes from the mainland, and they learned from
their reports that Captain O’Grady’s account of the utter confusion
existing from end to end of the country was in no way exaggerated.
As soon as the Greeks perceived that Mr. Beveridge was a well-wisher
to their cause, and judging him from his possession of a large yacht to
be a wealthy man, innumerable schemes were proposed to him, all
involving his placing himself in the hands of the proposer and
advancing him a considerable sum of money. These projects Mr.
Beveridge resolutely turned a deaf ear to, his resolution being greatly
strengthened by Horace, who distrusted all these plausible
adventurers profoundly.
“We must wait, father,” he said, “until we see something like a stable
government in power. When it has been at work a bit, and you find
that it makes its authority respected, restores order, and unites the
people in a common effort, it will be time enough for you to let them
have money. To give it now would simply be to waste it, and, indeed,
worse than waste it, for it would only add to the struggle for power on
which the Greeks are wasting their strength. From all we learn the
sailors of Hydra, Spetzas, and Psara are the only men who at present
are acting with any common object. As everything depends upon
crippling the Turks at sea, I should think we could not do better than
get rid of some of our guns and ammunition by giving them to them.
If we could get rid of twenty or thirty tons of our cargo it would put us
in first-rate sailing trim, and at any rate get something off our minds.
Then from there we could sail to Athens and get the papers we
require authorizing us to act as a Greek privateer. Of course that
would be no protection to us if we fell into the hands of the Turks; but
we could do nothing until we get them without acting as pirates and
rendering ourselves liable to be hung by any European man-of-war
that might overhaul us.”
This course was determined upon, to the great satisfaction of William
Martyn; and after a stay of three days at Zante sail was again set, and
the Creole left the anchorage. It was well that she did so, for the next
day all their Greek sympathies would have been insufficient to prevent
their fighting on the other side. An Algerine barque that had separated
from the Turkish fleet, which had just captured Galaxidhi and had
taken possession of thirty-four Greek brigs, was attacked by eighteen
Hydriot ships. She refused to surrender, and made such a gallant
resistance that the Hydriots did not venture to run alongside and carry
her by boarding. The Algerines, knowing that if their spars were shot
away they would all be killed, ran her ashore near the southern cape
of Zante.
The fight had been witnessed by thousands of refugee Moreots and
Zanteot peasants, who opened fire upon the Algerines when they
landed. Two English officers with twenty men had gone down from the
town to enforce obedience to the quarantine regulations, which were
very strict. They ordered the Greeks to retire, but these refused, and
continued to attack the Turks. The officer commanded his men to fire
over the heads of the crowd, when the Zanteots at once turned their
muskets against them. One soldier was killed, and the rest retired into
a house with the Turks and defended themselves until a stronger body
of English troops came down from the town and rescued them. For
firing upon the troops and killing one of them five Zanteots were
afterwards tried and executed, and the lord high-commissioner issued
a proclamation forbidding the entry of any Turk or Greek men-of-war
into any Ionian port.
The Greek commercial navy, before the outbreak of the revolution,
consisted to a large extent of the shipping of the four little islands
Hydra, Spetzas, Psara, and Cazos. These islands, which were small
and barren, had sprung into importance by the wise policy of the
sultans at the beginning of the eighteenth century. Seeing that the
exactions of their own officials rendered it impossible for the Greek
and Mussulman sailors to compete with those of other nations, they
had exempted from all taxes and other burdens persons settling on
these islands, and had allowed to them perfect self-government. The
result had answered their expectations. Colonies of Albanian sailors
had established themselves at Hydra and Spetzas, while Greek
seamen had settled in Psara and Cazos, and all four islands became
populous and flourishing, owning among them nearly three hundred
craft of from sixty to four hundred tons.
The contrast between the population and manners of the four islands
was very marked. The two Albanian islands were governed by twelve
primates, elected by the wealthy, while in the Greek islands the
government was purely democratic. The Albanians were by far the
more sincere and honest, while the people of the two Greek islands
were the more courteous. All had early thrown in their lot with the
revolution. The Peace of 1815 had caused a great reduction in the
price of grain on the Continent and a fall of freights. Consequently
many ships remained unemployed, the prosperity of the islands
diminished, and the sailors became discontented and clamorous for
employment. Spetzas had been the first to declare for the revolution,
and had at once sent off some ships, which had captured a Turkish
corvette of twenty-six guns and a brig of sixteen, which, with small
crews, were waiting at Milos to receive the contingent of sailors from
the Albanian islands. The Turks, expecting no attack, were taken by
surprise; but the first Greek naval success was dimmed by the
Mussulman prisoners being all carried to Spetzas, where some were at
once murdered and the rest put to death with horrible tortures.
Psara quickly followed the example of Spetzas, but Hydra was some
time before it raised the Greek flag. The people were in favour of the
revolution, but the wealthy ship-owners, who possessed all the power,
were averse to fitting out their vessels for unprofitable service, and
opposed the revolution until a popular insurrection broke out and their
authority was set aside. The united fleet of the three islands, instead
of attacking the Turkish fleet, which was occupied in conveying store-
ships to the besieged garrisons, swept the seas of merchantmen, and
attacked and plundered an Austrian vessel. Two Hydriot brigs captured
a Turkish ship, with a very valuable cargo, carrying, among other
passengers, a recently-deposed sheikh El-Islam, or Patriarch of the
Mussulmans, and all his family. These and all on board were murdered
by their captors; but the affair in the end benefited the Turks, for the
captors refused to conform to the regulation that had been laid down,
that all booty should be the common property of the fleet. Quarrels
began between the sailors of the different islands, so that the fleet
broke up, and was for a long time useless for any concerted action
against the Turks.
The Creole visited the three islands in succession, handing over to the
authorities in each ten guns, with a considerable amount of powder
and shot, a thousand muskets, and ten thousand rounds of
ammunition. There was a large amount of shipping in each of the
harbours, and Will Martyn had the Creole’s guns all loaded and double
shotted before entering.
“There is no saying what these fellows may be up to,” he remarked to
Horace. “Seeing us giving away so large a quantity of valuables, they
may think that we have got a gold mine on board. I don’t mean to
close an eye while we are in harbour, I can tell you.”
Mr. Beveridge, personally, was received with much honour at these
islands, and the guns, which Will Martyn had taken care should be the
largest of those in the hold, were dragged up by the people and
placed in the batteries.
The Creole then crossed to the Piræus. The Acropolis of Athens was
still held by the Turks, who were closely besieged there. Will Martyn
landed with Mr. Beveridge. Horace told his father that he would rather
not accompany him.
“You will be going about and seeing people, father,” he said, “and, as
you say, you may have to go to other places to find some of the
nominal authorities to sign documents, and so on, authorizing us to
hoist the Greek flag, and giving us the usual papers carried by
privateers. This may take time, for you and Martyn think that as the
Greeks themselves have no such formalities, but fight the Turks just as
they find them, it may be difficult for you to persuade them that
letters of marque are really required authorizing the vessel, as a Greek
ship, to capture, burn, and destroy all Turkish vessels she may meet.”
“It is a mere formality, Horace.”
“Well, father, I don’t think that Martyn or the others look at it at all in
that light, and I know they consider it absolutely necessary that we
should have papers of that sort. Even with such papers they say they
expect there will be a lot of difficulty, if they take any prizes, in
disposing of them, and that, unless they have papers signed by the
central government, the chances are that the moment a Turkish prize
is brought into port, the Greeks will seize it as public property, and
want to cut the throats of any Turks prisoners. Certainly we should not
stand that, and we should be in the position of having to fight the
Turks at sea and the Greeks in port. So I should not be surprised at all
if you are ten days, or a fortnight, before you can get all the papers
you want. Of course Martyn’s signature will be necessary to all sorts of
things, and as there is no humbugging him he will be wonderfully
useful to you in all sorts of ways.”
“But why should you not go with us too, Horace?”
“I would very much rather not, father. Of course I am quite with you in
wishing to see Greece independent, but I am so disgusted with all
these stories of the horrible atrocities they have been guilty of, and at
the way in which, instead of joining together to fight the Turks, they
are all bent only on getting power or spoil, and of behaving more like
a collection of bands of brigands than a united people, that I would
rather not see any more of them at present, or I shall get regularly to
hate them. In a short time, I have no doubt, we shall hear of a lot of
things done by the other side. We may be sure that the Turks will
avenge the eight thousand Mussulmans who were murdered at
Tripolitza. We heard at Zante that they had begun it, and then one
thing will balance the other and I may get enthusiastic about the
Greeks again; but at present, father, what I should like to see is this,
that the Creole should be employed as a rescue ship.”
“How do you mean, Horace?”
“I mean, father, that we should try to save as many of these wretched
Turks, and their women and children, from massacre as we can; and
on the other hand, that we should try to save as many Greeks as
possible from the vengeance of the Turks. There ought to be lots of
opportunities both ways. If we are with the Greeks when they capture
a Turkish vessel we can buy off the prisoners. The Greeks are fonder
of money than even of blood, and the money will be a deal better
spent that way than if wasted among the politicians, the captains of
brigands, or primates, and would do good to the cause of Greece by
saving it from dishonour. When the Greeks make a descent upon a
Turkish island we could send our boats ashore and take off a lot of the
inhabitants, and we could do the same thing when the Turks attack a
Greek place or island; and if either Greeks or Turks interfere with us at
the work, I should say let us thrash them whoever they are. I consider
that would be a glorious mission, and would be a credit to the flag we
fly whether it is Greek or English; and if I were you I should speak out
to Kolokotronis, or any other leader you may meet, and tell him
frankly that you have come out to help the Greeks with arms and
money, but that these massacres will turn all Europe against them;
and that unless you are provided with an authority to take and hold all
Turkish prisoners, and to protect them both from the populace and the
sailors, you will withdraw altogether, and will do your best to prevent
such atrocities, even if it comes to firing upon Greek vessels engaged
in them.”
“I will do so, Horace,” his father said in a tone of decision. “We are a
match, I fancy, for half a dozen of the Greek ships. They will find us a
very different vessel to deal with than those slow-sailing Turks. I quite
approve of what you say. For the first outburst of vengeance when
they rose I am willing to make every allowance; but the revenge taken
by the Turks at Kydonia should have reminded them that there are at
least a million of their fellow-countrymen in Asia Minor whose lives
have been endangered by their atrocities. Henceforth I will, as you
propose, devote myself to saving life, and part of the money that I
had intended for the Greeks shall go to make up to the crew for any
loss they may sustain by missing the chance of taking prizes. I will
hoist the Greek flag as I intended, and we, at least, will keep it
unsullied.”
Horace repeated the substance of the conversation to Will Martyn and
the other two officers, who cordially agreed; for although they had, of
course, heard less at Zante of the details of the massacres than their
employer and his son had done, they had heard enough to fill them
with indignation, and to disgust them with the cause that they had
come out to defend.
“That will be first-rate,” Martyn said, “and I can foresee we shall have
lots of fun, and are likely to end by fighting both parties. There will be
plenty for us to do. We will see if we can’t cut off some of the Turkish
vessels laden with Greek captives for sale as slaves in the markets of
Alexandria; while, as for the Greeks, if we slip in and save their
captives they will be like a pack of wolves after their prey. If I am to
go with your father, Horace, you may be sure I will take any
opportunity I may get of speaking out, and I reckon I will open the
eyes of some of these Greek swells by the way I will give it them. I tell
you what, Miller: While I am away do you get up eight of those
eighteen-pounders from the hold and mount them instead of the
twelves. Now that she has got so much of her weight out of her she
can carry them well enough, and I fancy we are likely to want as
heavy metal as we can mount before we have done.”
At dinner that day Horace said: “Are you thinking of changing her
name, father, when you change your nationality?”
“I wasn’t thinking of changing her name at all, Horace,” Mr. Beveridge
said in surprise.
“Well, I thought, father, the Greeks wouldn’t understand the name of
the Creole at all. It was a good name for a slaver and did well enough
for a yacht, and if we ever take her back to England I should like her
to be the Creole; but I think it would be better to have some name
that the Greeks will understand.”
“What name would you propose, Horace?”
“Well, father, I have been thinking of it, and if you have no objection I
should like to call her the Misericordia, ‘the Pity.’ We came out here
because we pitied the Greeks, and now we pity the unfortunate
people, both Turks and Greeks, and you have agreed that our mission
shall be to save both of them from slaughter.”
“I think it would be a very good name, Horace. The Misericordia it
shall be. What do you say, Captain Martyn?”
“I think it would be a capital name, Mr. Beveridge,” Martyn said, “and
the crew will fight all the better when they know what the name
means and what we intend to do. Sailors have no particular love for
the Greeks—they always regard them as treacherous beggars; and
they have no particular hostility against the Turks, who fought pluckily
enough on our side in Egypt, and have always been friendly with us. I
am sure that when our fellows understand that what we are going in
for is to save women and children from being murdered, whether they
happen to be Greeks or Turks, you will find them ready to do
anything.”
The next day Mr. Beveridge and Will Martyn landed, and Miller set the
crew at work to mount eighteen-pounders in place of the twelves, and
to get the ammunition for them into the fighting magazines in place of
that of lighter calibre. Zaimes had accompanied Mr. Beveridge. Marco
remained on board, but had leave every morning to go on shore the
first thing after breakfast, and to remain there until late in the
afternoon, when he came off in time for dinner. He brought news that
it was believed the Turks in the Acropolis could not hold out much
longer, as their provisions were running very short. After an absence
of ten days the party on shore returned, and an hour after they did so
the English flag was lowered and that of Greece was hoisted, while a
flag with the word Misericordia replaced that of Creole at the
masthead. Captain Martyn called the crew together.
“My lads,” he said, “you all knew that when we arrived here we were
going to hoist the Greek flag instead of our own, and that we were
going to act as a Greek privateer against the Turks. That, you see, is
done, and we are authorized by the Greek government to capture or
destroy any Turkish vessels we may meet. You see we have changed
her name, and I will tell you why Mr. Beveridge has done this. We are
going to fight for Greece, but at the same time, as British sailors, we
are not going to stand by and see men, women, and children
murdered in cold blood, whether they are Turks or anyone else. There
has been a great deal too much of this sort of thing done on both
sides, and we mean to stop it as much as we can. We are going to
prevent the massacre of Greeks by Turks, and I hope we shall manage
to lay hands on some of the Turkish vessels carrying Greek women
and children captive to sell them as slaves; but on the other hand we
intend to save as many Turks as we can from being massacred by the
Greeks, and that is the reason why Mr. Beveridge has renamed his
craft the Misericordia, which means ‘the Pity.’ I am sure, my lads, that
there is not a British sailor who would not risk his life to save those of
women and children, and that is what we mean to make our first
object, although we hope to lower some Turkish flags before we have
done with them; but in any case we mean to save life whether it is
Greek or Turk we have to fight in doing so. It is a work, my lads, in
which we may all be proud to take part, and in which, whether we
fight under the English flag or the Greek, we shall be doing a duty
dear to every British sailor. Now, my lads, we will give three cheers for
the Misericordia.”
Three hearty cheers rang out from the sailors. They had all been on
shore at Zante, and had heard enough from the soldiers they
fraternized with there to fill them with disgust and indignation at the
conduct of the Greeks, and this announcement that they would
henceforth put a stop to such cruelty, even if they had to fight for it,
filled them with satisfaction.
“We had hard work of it,” Martyn said to Horace, talking over his visit
ashore. “In the first place they wanted us to hand over all prisoners
we took, and half the plunder and value of the prizes, to their
miserable government. We told them that we would see them at the
bottom of the sea first. I was with your father at a meeting with the
fellows they call Kolokotronis and Odysseus, and half a dozen other of
their leaders, and you should have seen how your father spoke out.
He got upon his legs and he just poured it out. I did not know, of
course, what he was saying, but he told me a little about it afterwards,
and I could see by their faces that it was hot and strong.
“He told them that their countrymen had disgraced their cause by
conduct worthy only of the lowest savages, and that if they did not
give him the authority he demanded, to interpose to save Turks from
massacre, he would sail on to Constantinople, hoist the Turkish flag,
and fight against the ships that behaved like bloodthirsty pirates rather
than Greek patriots, and that they would find his ship a very different
opponent to the Turks. I did not think your father had it in him. It was
splendid, I can tell you, and the faces of those fellows were worth
seeing. I don’t expect they ever had such a straight talking to before. I
believe altogether he spent about a thousand pounds in bribing a
dozen of them; anyhow he got what he wanted. In the first place we
are authorized to hoist the Greek flag, and to capture and destroy
Turkish vessels; and in the second, to dispose as we please of all
prisoners. We may take on board Turkish fugitives and dispose of
them at our pleasure, free from all interference from any Greek
authorities or Greek ships. We are to pay a quarter of the value of all
prizes and booty into the treasury of the central government, and are
to send ashore to-morrow five thousand muskets and twenty rounds
of ammunition for each.
“Your father has had a hard time of it. I don’t believe there has been a
single Greek politician or leader who hasn’t called upon him privately,
to what they call borrow money from him. At last I had to regularly
mount guard over him and set Zaimes at his door to tell all comers
that he was too unwell to see anyone, which was not far from the
truth, for he was regularly upset at the meanness and trickery of the
people he had come to spend his fortune to assist. However, thank
goodness it is all over. I am precious glad that I am back, I can tell
you, for I believe if I had stayed there much longer I should not have
been able to have prevented myself from walking into some of them.
Your father has been trying to find out whether they have got any
general plan of defence; but they have no more plan than a lot of
children would have if they got up a rebellion. Everyone wants to be a
leader; everyone complains of everyone else. They scarcely seem to
give the Turks a thought. All their energies are occupied by their own
miserable squabbles and rivalry. Well, I don’t want to set foot on shore
again as long as we are out here, unless it is on some real expedition.”
“What about the Turks in the Acropolis, Martyn?”
“They are negotiating, but the poor beggars know there is no faith to
be placed in the Greeks, and that so far there is not a single instance
in which they have kept their promises for the safety of garrisons who
have surrendered. They want the guarantee of the European consuls
for their safety, but they can’t give it, as they have no force here to
protect them. I told our consul that we would lend him the whole of
our crew if he liked, and that I thought we could pretty well clear out
the town; but he said that that would be well enough if there was no
one to protect. But that as there are something like two thousand
men, women, and children up in the citadel, fifty men could never
protect them against the mob. However, I hope the Turks will be able
to hold out for some time yet. The Greeks only guess that their
provisions are running short, and if a man-of-war, French, or English,
or Austrian, comes into the harbour the consuls will ask its
commander to protect the Turks, and will then guarantee their safety.”
“When are we going to sail?” Horace asked.
“To-morrow. The two Greeks will go ashore the first thing in the
morning to lay in a fresh stock of meat and vegetables. As soon as all
are on board we will get up anchor. I have heard lots of shocking
stories on shore from Greeks who have escaped from Asia Minor and
the Turkish islands. There have been massacres in almost every city
where there were Greeks; at Smyrna, Adrianople, Salonika, Cos,
Rhodes, in Crete and Cyprus, and as far as I can hear the Turks have
altogether massacred nearly as many men, women, and children as
the Greeks have done. I saw General Gordon, who is a warm friend of
the Greeks, and he said that it was impossible to justify the ferocity of
the Greeks, or to deny that a comparison between them and the Turks
would give the latter the palm of humanity; that is, if the term
humanity could be employed to either.
“We went up and saw some of the troops, as they call them, active,
hardy-looking fellows. They seem in earnest enough, and are ready, as
a French officer said to me, to submit to anything but discipline. He
said that the Klephts and armatoli are as fine material for mountain
warfare as one could wish to see; one day honest, hard-working
peasants, the next engaged in partisan war, or in raids on their
neighbours; frugal, hardy, active, and in their way brave; men who
would never storm a position or stand against the attack of Turkish
infantry or cavalry, as the war has everywhere shown so far; but who
would defend a hillside or hold a ravine against good troops, and
when driven out, make another stand at the first position they came
to. Anyhow they are worth a lot more than the townspeople, who brag
and vapour and go about armed to the teeth, but who take precious
good care never to get within range of a Turkish musket.”
Early the next morning some large boats came off, and the muskets
and ammunition were transferred to them, and at noon the two
Greeks brought off a boat-load of fresh meat, vegetables, fowls, eggs,
fruit, and other stores. As soon as these were slung on board, the
anchor was got up, and the Misericordia, under a gentle breeze, stole
out to sea.
“That is better, Miller,” Will Martyn said as he looked over the side.
“She has not gone like that since we shook out our sails for the first
time. I should say she is just about in her right trim now, and is ready
to fight or sail anything of her size afloat. How easily she goes through
the water. There is scarcely a ripple in her wake. She is a beauty.”
“Which port now, Martyn?”
“I was talking it over last night with Mr. Beveridge, and as soon as we
get well off land I am going to shape a course that will take us down
between Cyprus and Alexandria. It is of no use cruising about here.
The Turks only move about under a convoy of their men-of-war, and it
would not be much better across on the other side, for the Greek
vessels are everywhere on the look-out. But they don’t like going far
from home, and if we cruise well to the south we shall have a good
chance of falling in with craft bound for Alexandria from Cyprus, Crete,
Welcome to our website – the perfect destination for book lovers and
knowledge seekers. We believe that every book holds a new world,
offering opportunities for learning, discovery, and personal growth.
That’s why we are dedicated to bringing you a diverse collection of
books, ranging from classic literature and specialized publications to
self-development guides and children's books.

More than just a book-buying platform, we strive to be a bridge

connecting you with timeless cultural and intellectual values. With an
elegant, user-friendly interface and a smart search system, you can
quickly find the books that best suit your interests. Additionally,
our special promotions and home delivery services help you save time
and fully enjoy the joy of reading.

Join us on a journey of knowledge exploration, passion nurturing, and

personal growth every day!

ebookbell.com