Aligning Agile Processes and Software Architectures
By Ivan Mistrik, Muhammad Ali Babar, Alan W. Brown
Publisher: Elsevier / Morgan Kaufmann
Final Release Date: November 2013
Agile software development approaches have had significant impact on industrial software development practices. Today, agile software development has penetrated to most IT companies across the globe, with an intention to increase quality, productivity, and profitability. Comprehensive knowledge is needed to understand the architectural challenges involved in adopting and using agile approaches and industrial practices to deal with the development of large, architecturally challenging systems in an agile way.
Agile Software Architecture focuses on gaps in the requirements of applying architecture-centric approaches and principles of agile software development and demystifies the agile architecture paradox. Readers will learn how agile and architectural cultures can co-exist and support each other according to the context. Moreover, this book will also provide useful leads for future research in architecture and agile to bridge such gaps by developing appropriate approaches that incorporate architecturally sound practices in agile methods.
Presents a consolidated view of the state-of-art and state-of-practice as well as the newest research findings
Identifies gaps in the requirements of applying architecture-centric approaches and principles of agile software development and demystifies the agile architecture paradox
Explains whether or not and how agile and architectural cultures can co-exist and support each other depending upon the context
Provides useful leads for future research in both architecture and agile to bridge such gaps by developing appropriate approaches, which incorporate architecturally sound practices in agile methods
Comments about oreilly Agile Software Architecture:
If you like academic approach to the topic, that's something you are looking for - definitely. The book is a collection of articles from various authors. This is slightly misleading, because you don't expect that by cover. The point here is that book itself will not provide you with some solid, single minded idea of how to join architecture and agile based approaches. It's rather composition of ideas that circle around the topic. And you can tell that basing on writing style. Practically each chapter has different way of expressing topic.
Plus for the references. As for the academic style papers you will find loots of references to various sources. If you are really into the topic, this will help you find the information in other places.
Bottom Line No, I would not recommend this to a friend
Comments about oreilly Agile Software Architecture:
Review of chapter 15: "Architecture as a Key Driver for Agile Success: Experiences at Aviva UK"
My abbreviated contents of book's contents: Foreword by John Grundy Architecture vs Agile: competition or cooperation? Foreword by Rick Kazman Preface Chapter 1: Making architecture and agile approaches work together Part 1: Fundamentals of Agile Architecting Ch 2: DCI Paradigm: taking OO into Architecture world Ch 3: Refactoring Software Architectures Ch 4: Persona as a driver in architectural design and preservation Ch 5: Architecture decisions: Who, How & When Part 2: Managing Software Architecture in Agile Projects Ch 6: Adaptable architectures via agility to support variability Ch 7: Continuous software architecture analysis Ch 8: Lightweight Architecture Knowledge Management for Agile Ch 9: Tailored Scrum for Agile Architecting by bridging user stories with architecture Part 3: Agile Architecting in Specific Domains Ch 10: Security testing by architecture-centric approach Ch 11: Multitenant, multitarget architecture supporting agile development & deployment in the cloud Part 4: Industrial Viewpoints on Agile Architecting Ch 12: Agile Architecting: enabling delivery of complex agile systems Ch 13: Architecture and Agile = key innovation enablers Ch 14: Emergent Architecture's opportunities, threats and limitations Ch 15: Agile Success driven by architecture: Aviva UK case study. Extensive Author & Subject indexes
Chapter 15 review: This chapter brilliantly details the challenges and architectural-centric solutions for the transition to agile from a waterfall process in a big insurance organization, Aviva UK. The transition was caused by the rapid change (and on-going quality) demands under the restriction of not increasing risk & cost.
First part of the chapter lists the Challenges to agile adoption at Aviva UK, i.e. architectural / organizational characteristics (result of Conway's Law) and derived waterfall specific business practices (scheduled release processes, silo mentality, restricted integration testing, etc.).
Facing these, few lessons were learned: agile practices specific to small teams pose hurdles when adopted by big teams, requiring changes to pure Scrum practice; agile adoption by big businesses is achieved by focusing on impact and requirements of IT architecture ("in-sprint" design is not sufficient to guarantee success).
Next, the key architectural strategies for agile adoption success in big organizations are detailed and exemplified: 1. sufficient up-front architecture and design. An example is given where incrementally in-sprint design failed due to domain complexity and having too much uncertainty unresolved before starting the sprints. 2. what is "sufficient" up-front architecture / design and how uncertainties impact them. 3. the key points for continuing architecture and design during sprints (exemplified with Aviva UK agile development scenarios). 4. the layered architecture as enabler for independent change agility. Inspired from the buildings pace layering architectural pattern the layered architecture allows independent and different rate of change across loose coupled system software tiers.
The chapter ends with a testimony towards the benefits of incremental agile and architecture transformation of the business and IT. Aviva UK learned by experimentation a valuable lesson in gradually changing existing architecture towards a loosely coupled service-oriented tiers that accommodate easy system evolution. Paraphrasing authors lesson: it is permissible to change things later as long as the design facilitates these changes.
Bottom Line Yes, I would recommend this to a friend