Software Architecture: Organizational Principles and Patterns [Paperback]

David M. Dikel (Author), David Kane (Author), James R. Wilson (Author)

Book Description

ISBN-10: 0130290327 | ISBN-13: 978-0130290328 | Publication Date: January 7, 2001 | Edition: 1

This book offers the first complete roadmap for building software architectures that achieve the most demanding goals-now, and for years to come. Discover how to establish a product-line architechtural framework and vision that managers, administrators and developers can buy into.

Editorial Reviews

Review

The three authors do a good job of highlighting the dual aspect of the architect’s job. -- Alistair Cockburn, Humans and Technology, and author of Surviving Object-Oriented Projects

From the Inside Flap

Preface

Building software has almost always involved fitting together products and organizations as well as developing code. Software architecture is fundamental to both activities, especially today. For example, an ordinary business transaction will traverse many layers of software architecture, leveraging shared platforms such as the Internet, client browsers, Web servers, business logic components, security systems, and back-end databases. In this environment, many partners must not only agree on a core set of interfaces and standards, but they must also agree on how to use those standards. Partners must also agree on the value they will add and receive for their contribution. All these agreements must remain workable and stay in place in the face of rapid changes in technologies, re-alignments of partners, shifts in business goals and requirements, as well as the ever-present mergers and acquisitions. If these agreements do not remain in place, the product and its architecture may fail, causing pain for developers and customers, as well as their managers and sponsors.

This book focuses on the interrelationship between software architecture and the organization. Software architecture serves as a framework that defines and orders not only the technical interactions needed to develop and implement a product, but also group and personal interactions. The ability of software architecture to fulfill this role over time relies on organizational factors.

It has long been observed that the structures of architectures and the organizations that build and use them influence one another. A close look reveals an extensive and complex relationship. Real-life architecture often is far removed from the intended structure, including hidden chunks of software, odd connections, hard-coded Òshortcuts,Ó missing pieces, and other irregularities. The same types of surprises come from an organizationÕs culture, its people, their beliefs, abilities, and behaviors. In practice, architecture and organization form a sensitive and highly volatile matrix. Done right, organization and architecture can deliver great value; failure can melt the core of the enterprise.

We have written this book to help people who have a critical stake in the success of software architecture understand and overcome the challenges of architecture and organization. These stakeholders form a large interdependent group that is getting larger as software products cross more organizational boundaries in their development and use. This group includes people who manage, develop, implement, maintain, acquire, and use software architecture. Each stands to benefit from a better understanding of how software architecture and organization interact. For example, partnering skills can decrease the time it takes for developers to find out about changes to a release of an architecture or platform, and increase the chances that they can negotiate to restore features that are critical to their continuing use of the architecture. Without these skills, the architect would soon lose customers; the customers would soon be maintaining a lot more code and creating a lot less product.

Our book is based on more than five years of research within some of the countryÕs best-known large-scale software development organizations and numerous workshops, as well as our work architecting product lines and implementing architectures for small, medium, and very large organizations. We also drew on work in other disciplines, especially organizational development. Our research yielded a model composed of five organizational principles that affect software architecture successÑVision, Rhythm, Anticipation, Partnering, and Simplification (VRAPS). We call this the VRAPS Model.

Together, the VRAPS principles provide a model you can use to get your arms around what to do and to improve your personal and corporate ability to get lasting value from products and ventures that depend on software architecture. The VRAPS model will help you to organize and interpret your observations and relate them to practices and patterns that others have used successfully. You can also use the model and principles to identify strengths and weaknesses, to communicate insights, and to encourage actions across roles, boundaries, and levels within and external to your organization.

You can take several paths through our book:

You can get a quick overview of the book in Chapter 1. Then go to Chapter 8 to find a case study that illustrates how the VRAPS principles worked within Allaire Corporation, as it grew from a small startup to become a leading provider of tools for building Internet applications.

You can find out more about each VRAPS principle in Chapters 3 through 7. After defining and describing the principle, these chapters provide criteria to help you gauge how well your organization applies the principle. Patterns, stories, and antipatterns provide practical guidance about what to do and what not to do to benefit from the principle.

You can get a detailed understanding of the VRAPS model and how it relates to other work in Chapter 2. Chapter 9 provides a real-world illustration of how to use the model, along with nine specific templates, tools, and guidance you can use to assess your organization and compare it with others. We describe how the templates were used in a commercial benchmark.

We invite you to read on and visit our Web site at VRAPS.David M. Dikel
David Kane
James R. Wilson

See all Editorial Reviews

Product Details

• Paperback: 320 pages
• Publisher: Prentice Hall; 1 edition (January 7, 2001)
• Language: English
• ISBN-10: 0130290327
• ISBN-13: 978-0130290328
• Product Dimensions: 9.3 x 7 x 0.8 inches
• Shipping Weight: 1.1 pounds (View shipping rates and policies)
• Average Customer Review: 4.7 out of 5 stars  See all reviews (6 customer reviews)
• Amazon Best Sellers Rank: #1,798,463 in Books (See Top 100 in Books)

More About the Author

Discover books, learn about writers, read author blogs, and more.

Customer Reviews

Most Helpful Customer Reviews

15 of 16 people found the following review helpful:

3.0 out of 5 stars Object-Oriented Psychology?, December 17, 2002

By 

David Lawrence (Cambridge, MA) - See all my reviews
(REAL NAME)   

This review is from: Software Architecture: Organizational Principles and Patterns (Paperback)

This book attempts to provide a unified theory of software architecture, their VRAPS (Vision, Rhythm, Anticipation, Partnering, Simplification) methodology. While the basic approach is reasonably sound, in order to prove their case, the authors delve into the highly speculative field of organizational patterns and antipatterns to provide justification for their model.

The book is divided into three parts. The first deals with and overview of the VRAPS model and the last deals with a presentation of its application in the context of the situation at Allaire. Both of these sections are fine. It is the middle portion, which attempts to "prove" the validity of their model with reference to object-oriented patterns, which stretches the credulity of the reader. The authors even admit that you can skip the chapters where these patterns are presented. Putting them in only serves to detract from the other meaningful chapters of their work.

Object-oriented analysis was developed to solve abstract problems in reusable code paradigms. Previously unknown to me, a group of eager souls has tried to extend this metaphor into the realm of individual and group psychology, with no attempts to provide an empirical basis for their efforts. Whimsical patterns such as "Antigravity Module," "Drop Pass," and "Loan Shark" are relied upon to produce a catalog of objectivist modes of development behavior.

Why a methodology with no basis in psychology is supposed to answer complex issues of organizational behavior is beyond me. Could anyone conceivably apply theories of database normalization or compiler design and hope that they would help you to manage your employees better? There is a vast body serious material in the business literature which deals with these issues in the proper context, and I see no evidence why adding a layer pseudo-scientific organizational patterns to the analysis can do anything but to add confusion to the problems.

If you want a pop psychology approach to managing behavior in a development environment, a book such as "Dynamics of Software Development," by Jim McCarthy provides a very entertaining and enlightening approach to the problem. If you want an exposure to serious software architecture methods, a tome such as "Software Architecture in Practice," By Len Bass, et al, from the Software Engineering Institute can provide deep insight.

The authors of "Software Architecture" are highly seasoned professionals with impressive experience. I find it difficult to understand why they would take a reasonable approach and burden it with a false sense of analytical rigor based on the patterns literature. They would have had a much better book had they simply focused on the case study of Allaire in the context of the VRAPS model.

21 of 24 people found the following review helpful:

5.0 out of 5 stars A systematic approach to architecture, February 1, 2002

By 

Christo "montxsuz" (Vancouver, Canada) - See all my reviews

This review is from: Software Architecture: Organizational Principles and Patterns (Paperback)

Not quite sure what to expect when I started the book, I was pleasantly surprised. The book explores 5 principles behind Software Architecture; namely Vision, Rhythm, Anticipation, Partnering, and Simplification; or VRAPS for short. Not only will you learn these principles, but you'll get an introduction to patterns and antipatterns as well. Yet it is not a "How To" on Software Architecture.

Much of the book is devoted to VRAPS. After a few introductory chapters, each principle is defined, explained, and then illuminated with criteria, antipatterns and patterns.

Chapter 8 introduces a case study, based upon a well known Internet company. Allaire's jouney through each principle is discussed, including successful practices and warning signs.

Chapter 9 is added for completeness. It presents a case study about building and implementing a benchmark framework for VRAPS. The authors surveyed many organisations in compiling this book, and their results are published here in a summary form.

The book is rounded off with useful Appendixes. One provides a quick reference principles, criteria, antipatterns and patterns, the other is an index of patterns and antipatterns cross-referenced to principles. Overall I found the book to be well structured and well organised - and not too hard too read.

This is the third book I've read from the Software Architecture Series, and the most practical and useful so far. This book should go far in establishing a basic process for Software Architecture that is both theoretical and practical.

14 of 17 people found the following review helpful:

5.0 out of 5 stars A Systems Approach to Software Architecture, August 16, 2001

By 

Amedee Friestedt (Takoma Park, MD United States) - See all my reviews

This review is from: Software Architecture: Organizational Principles and Patterns (Paperback)

Anyone who is caught up in the real world of software development knows that most books on the subject talk about what should happen and not so much what could and most likely will happen. That is, real people work in real organizations and, for example, dependencies between groups of people can slow things down or in other ways hamper the development progress. Dikel, et al, do a great job defining patterns and anti-patterns and their overiding principles. This book is a great guide for software development Project Managers who could use guidance when planning a project and when the going gets rough.