View Larger Image	Nick Rozanski, Eoin Woods Addison-Wesley, Hardcover, Published April 2005, 546 pages, ISBN 0321112296
	List Price: $59.99 Our Price: $46.50 You Save: $13.49 (22% Off)
	Availability: Out-Of-Stock

People who purchase this book frequently purchase:

• Software Architecture in Practice; Len Bass, et al, $54.50, 22% Off!
• Patterns of Enterprise Application Architecture; Martin Fowler, $50.50, 22% Off!
• Service-Oriented Architecture: Concepts, Technology, and Design; Thomas Erl, $43.50, 21% Off!
• Head First Design Patterns; Eric Freeman, et al, $26.95, 40% Off!

• Programming : Software Development

• Addison-Wesley

• A thorough handbook for software architects that builds upon legacies of best practice
  
• A highly practical, practitioner-oriented guide that explains how to design and implement solid architectures
  
• Improves an organization's chance for software success by clearly defining the boundaries between requirements, architecture, and design

Preface

The authors of this book are both practicing software architects who have worked in this role together and separately on information system development projects for quite a few years. During that time, we have seen a significant increase in the software architect's visibility, and in the importance with which our role has been viewed by colleagues, management, and customers. No large software development project nowadays would expect to go ahead without an architect -- or small architectural group -- in the vanguard of the development team.

While there may be an emerging consensus that the role of the software architect is an important one, there seems to be little agreement on what the job actually involves. Who is our "client?" To whom are we accountable? What are we expected to deliver? What is our involvement once the architectural design has been completed? And, perhaps most fundamentally, where are the boundaries between requirements, architecture and design?

The absence of a clear definition of the role is all the more problematical because of the seriousness of the problems which today's software projects (and specifically, their architects) have to resolve.

• The expectations of users and other stakeholders in terms of functionality, capability, time to market, and flexibility have become much more demanding.
  
• Long system development times result in continual scope changes and consequent changes to the system's architecture and design.
  
• Today's systems are more functionally and structurally complex than ever, and are usually constructed from a mix of off-the-shelf and custom-built components.
  
• Few systems exist in isolation, but are expected to interoperate and exchange information with many other systems.
  
• Getting the functional structure -- the "design" -- of the system right is really only part of the problem: how the system behaves (i.e., its "quality properties") are just as critical to its effectiveness as what it does.
  
• Technology continues to change at a pace which makes it very hard to for architects to keep their technical expertise up-to-date.

When we first started to take on the role, we looked for some sort of software architecture "handbook" that would walk us through the process of developing an architectural design. After all, other architectural disciplines have behind them centuries of theory and established best practice:

In the first century AD, the Roman Marcus Vitruvius Pollio wrote the first ever architectural handbook, De architectura libri decem ("Ten Books on Architecture"), describing the building architect's role and required skills and providing a wealth of material on standard architectural structures.
In 1670, Anthony Deane, a friend of diarist Samuel Pepys, a former Mayor of the English town of Harwich and later a Member of Parliament, published a ground-breaking textbook, A Doctrine of Naval Architecture, which described in detail some the leading methods of the time for large ship design. Deane's ideas and principles helped to systematize the practice of naval architecture for many years.
In 1901, George E. Davis, a consulting engineer in the British chemical industry, created a new field of engineering when he published his text A Handbook of Chemical Engineering. This text was the first book to define the practical principles underpinning industrial chemical processes and guided the field for many years afterwards.

This has a very important consequence: If you were to give several architects and engineers a commission to design a building, a cruise liner, or a chemical plant, then although the designs they produced would probably differ, the processes they used, the way that they represented their designs on paper (or a computer screen), and the techniques they used to ensure the soundness of their designs, would be very similar.

Sadly, our profession of software architects has yet to build up any significant legacy of mainstream industrial best practice, and when we looked we found a dearth of introductory books to guide the practicing information systems architect in the details of doing their job.

Admittedly, we have an abundance of books on specific technologies, whether it's J2EE, CORBA, or .NET, and some on more general topics like Web services or object-orientation (although, because of the speed at which software technology changes, many of these become out of date within a few years). There are also a number of good general software architecture books, many of which we refer to in later chapters. But many of these books aim to lay down general principles that apply across all sorts of systems, and so are written in quite general terms, while most of the more specific texts are aimed at our colleagues in the real-time and embedded-systems community.

We feel that if you are a new software architect for an information system, the books that actually tell you how to do your job, the important things that you need to know, and how you make your architectural designs successful are few and far between. While we don't presume to replace the existing texts on software architecture, or place ourselves alongside the likes of Vitruvius, Deane, and Davis, addressing these needs was the driving force behind our decision to write this book.

Specifically, the book:

• Explains what software architecture is about, and why your role is vitally important to successful project delivery
  
• Shows you how to find out who is interested in your architecture (your stakeholders), understand what is important to them (their concerns), and design an architecture which reflects and balances their different needs
  
• Shows you how to communicate your architecture to your stakeholders in a way that they can understand, and which demonstrates that you have met their concerns (we call this the architectural description)
  
• Shows you how to focus on what is architecturally significant, safely leaving other aspects of the design to your designers, without neglecting issues like performance, resilience, or location
  
• Describes the most important activities you need to undertake as an architect, such as identifying and engaging stakeholders, using scenarios, creating models, and documenting and validating your architecture

Throughout the book we primarily focus on the development of large-scale information systems (by which we mean the computer systems used to automate the business operations of large organizations). However, we have tried to present all of this in a way that is independent of the type of information system you are designing, the technologies the developers will be using, and the software development lifecycle your project is following. (We've standardized on a few things, such as the use of UML in most of our diagrams, but we've only done that because UML is the most widely understood modeling language around. You don't have to be a UML expert to understand this book.)

We don't set out to be the definitive guide to developing "the architecture" of your information system -- such a book would probably never be finished, and would require the collaboration of a huge number of experts across a wide range of technical specializations. Also, we are not a prescriptive methods book. Although we present some activity diagrams which explain how to produce your deliverables, these are designed to be compatible with the wide range of software development approaches which are in use today.

What we hope to achieve is a practical, practitioner-oriented guide, which explains how to design successful architectures for information systems and to see these through to their successful implementation. This is the sort of book that we wish had been available when we started out as software architects, and one that we expect to refer to even now.

Table of Contents

Preface.

About the Authors.

1. Introduction.

I. ARCHITECTURE FUNDAMENTALS.

2. Software Architecture Concepts.

3. Architectural Viewpoints.

4. Architectural Perspectives.

5. The Role of the Architect.

II. THE PROCESS OF SOFTWARE ARCHITECTURE.

6. Introduction to the Software Architecture Process.

7. The Architecture Definition Process.

8. Scope, Context and Concerns.

9. Identifying Stakeholders.

10. Identifying and Using Scenarios.

11. Using Styles and Patterns.

12. Producing Architectural Models.

13. Creating the Architectural Description.

14. Validating the Architecture.

III. VIEWPOINT CATALOG.

15. Viewpoint Catalog.

16. Functional Viewpoint.

17. Information Viewpoint.

18. Concurrency Viewpoint.

19. Development Viewpoint.

20. Deployment Viewpoint.

21. Operational Viewpoint.

22. Achieving Consistency.

IV. PERSPECTIVE CATALOG.

23. Perspective Catalogue.

24. Security.

25. Performance and Scalability.

26. Availability and Resilience.

27. Evolution.

28. Other Perspectives.

V. PUTTING IT ALL TOGETHER.

29. Working as a Software Architect.

APPENDICES.

Other Viewpoint Taxonomies.

Bibliography.

Index.

Forgot your password? FAQs Shipping Options Returns Your Orders Your Account