Software Architecture: Organizational Principles and Patterns

Description

There's only one way to maximize the responsiveness and business value of all your products or enterprise systems: architect them. But implementing and managing software architecture across a value-chain, product-line, or enterprise can be tremendously difficult. Unless you understand that architecture will interact with your organization and unless you know what to do, even the most sensible architectures can quickly stagnate or lead to more unpleasant surprises.The authors, a team of leading architects, will show you exactly how to field resilient, long-lasting enterprise architectures. Software Architecture: Organizational Principles and Patterns introduces the breakthrough VRAPS (Vision, Rhythm, Anticipation, Partnering and Simplification) model for software architecture and demonstrates how to leverage it through real-world case studies and patterns.

Extras

Related Articles

Agile Development: Weed or Wildflower?

Conway's Law Revisited: Successfully Aligning Enterprise Architecture

Organizational Savvy: The Missing Piece in Software Architecture Education

Patterns: An Antidote for "Best" Practices Gone Bad

Sample Content

Online Sample Chapter

Rhythm in Software Architecture: Assuring Beat, Process, and Movement

Downloadable Sample Chapter

Click here for a sample chapter for this book: 0130290327.pdf

Table of Contents

1. What You Can't See Could Help You.

What This Book is About. Software Architecture's Growing Importance. For Some, the News They are Stakeholders Comes Too Late. Principles Reveal the Hidden. Vision. Rhythm. Anticipation. Partnering. Simplification. Taking Action With Principles. Organizational Principles at Work: The Architect's New Job. Rhythm. Vision. Simplification and Anticipation. Partnering. Principles on the Web. Summary.

Overview. Why Models are Important. The VRAPS Model. Context. Organizational Principles for Software Architecture. The Role of Principles. Vision. Rhythm. Anticipation. Partnering. Simplification. Principles Interact. Conceptual Framework. Criteria. Patterns. Antipatterns. Applying the VRAPS Model. VRAPS Evolution. Summary.

Overview. Vision Definition. Mapping Value to Architectural Constraints. Congruence and Flexibility. Vision Challenges. Limits of Architect Influence. Executive and Architect Cooperation. Product Lines Increase the Challenges to Architects and Executives. Recognizing Breakdown. Shaping a Vision. Will the Real Architect Please Stand Up? Vision and Leadership. No Respect. Putting Vision Into Practice: Criteria, Antipatterns, and Patterns. Criterion 1: The architect's vision aligns with what his or her sponsors, users, and end customers are trying to accomplish. Criterion 2: Practitioners trust and use the architecture. Criterion 3: Tacit knowledge about architecture and components is visible and accessible to users. Summary. Other Applicable Patterns and Antipatterns.

Overview. Tempo. Content. Quality. Rhythm Definition. Motivation. Rhythm Aids Transition Management. Rhythm Drives Closure. Putting Rhythm Into Practice: Criteria, Antipatterns, and Patterns. Criterion 1: Managers periodically reevaluate, synchronize, and adapt the architecture. Criterion 2: Architecture users have a high level of confidence in the timing and content of architecture releases. Criterion 3: Explicit activities are coordinated via rhythm. Summary. Other Applicable Patterns and Antipatterns.

Overview. Prediction. Validation. Adaptation. Anticipation Definition. Anticipation in Action. Pulling Architectures in Many Directions. The Architecture Customers and Their Customers. Aiming Too Far Into the Future. Aiming Too Close to the Present. Balancing the Needs of Today and the Future. Striking a Balance. Putting Anticipation Into Practice: Criteria, Antipatterns, and Patterns. Criterion 1: Architecture capability is regularly enhanced to respond to anticipated risks and requirements of architecture customers and their customers, market-driving standards and evolving technology, and changes in strategic business directions. Criterion 2: Technical and business risks and opportunities are evaluated through a quick cycle of review and development. Criterion 3: Features, budgets, plans, or schedules are adapted when it is recognized that critical estimates or assumptions are incorrect. Summary. Other Applicable Patterns and Antipatterns.

Overview. Cooperative Relationships. Partnering Definition. Architecture Stakeholders. Clear, Cooperative Roles. Maximizing Value. Industrial Roots. Contract Management. Networked Organizations. Value Chain. Trust. Putting Partnering Into Practice: Criteria, Antipatterns, and Patterns. Criterion 1: The architect continually seeks to understand who the most critical stakeholders are, how they contribute value, and what they want. Criterion 2: Clear, compelling agreements exist between stakeholders. Criterion 3: Both policies and informal rules of social conduct enforce cooperation. Summary. Other Applicable Patterns and Antipatterns.

Overview. But What is Essential? Simplification DeÞnition. Conway's Law. Clarification. Minimization. Putting SimpliÞcation Into Practice: Criteria, Antipatterns, and Patterns. Criterion 1: Developers continue to use the architecture over time, reducing cost and complexity. Criterion 2: The architecture group clearly understands the essential minimal requirements and builds them into core elements. Criterion 3: Long-term budget and action ensure that elements are removed from the core when 1) they are not shared, or add unnecessary complexity, and 2) there is a clear business case. Summary. Other Applicable Patterns and Antipatterns.

Introduction. Why Allaire? Five Organizational Principles. What was Our Approach? About the Results. Vision—Making a Good Vision Real. Definition and Description. Practices to Project Architecture Vision and Keep It Alive. Warning Signs Identified by Allaire Staff. Rhythm—The Beat Goes On. Definition and Description. Practices That Help an Architecture Organization Stay in Sync. Warning Signs Identified by Allaire Staff. Anticipation—Predict, Validate, and Adapt. Definition and Description. Practices to Maintain an Architecture's “Friction With the Future”. Warning Signs Identified by Allaire Staff. Partnering—Lifelines. Definition and Description. Practices That Support Partnering. Warning Signs Identified by Allaire Staff. Simplification—Finding the Essential. Definition and Description. Practices That Support Simplification. Warning Signs Identified by Allaire Staff. Summary.

Overview. Benchmarking Provided a Framework. Survey Template. Organization Background and Context Template. Architecture Overview and Return on Investment Template. Principle Template. Practice Template. How We Conducted the Benchmark. Getting to a Workable Vision. Conducting the Interviews. Benchmark Results and Lessons Learned. Principles Resonated. Principle Relationships. Lessons Learned. Summary.

References.

Preface

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 www.VRAPS.com.

David M. Dikel
David Kane
James R. Wilson

Updates

Submit Errata