Lean Architecture: Form and Function
Agile Architecture is not Fragile Architecture
Agile Architecture is not Fragile Architecture!
There is a popular misconception that Agile development means not doing architecture, yet every major school of Agile practice advocates architecture. You can do a great Agile architecture in one week or in a single sprint, and overwhelming industry experience with Scrum bears out a return on investment before the end of your third sprint! In this course, designed as a one-day addendum to the Scrum course, we'll teach you how great projects do architecture the Agile way.
The first part of architecture is the form of what the system is. By focusing on form and delivering the architecture as code, instead of through a wasteful intermediate notation, a project can increase its velocity and prepare itself for just-in-time delivery. Features can be delivered faster by applying Lean principles.
The second part of architecture is the form of what the system does. This architecture several important end-user mental models. Architecture usually captures the end user's domain model, as we did above in "what the system is." Beyond that are four more mental models: the roles taken on by those domain objects; the mapping from those roles to the objects they wrap; the collaboration structure between the roles; and the algorithm encapsulated in the roles.
The course focuses in interactive systems and draws from a broad range of sources including Trygve Reenskaug's work on architectural underpinnings of MVC and his new work on the DCI architecture, Jim Coplien's lightweight domain analysis, dressed-down Use Cases, CRC cards, and role-basesd development. The course is for architects, designers, and programmers, and is programming-language neutral. This course is a compressed overview of Lean Architecture and Implementing Agile Requirements.
System and software architects;
White-box /clear-box testers;
User experience folks (there is an important and surprising relationship between HCI and architecture in an Agile system);
To a lesser degree, ScrumMasters and Product Owners (wouldn't it be nice to know where architectural PBIs come from and where they go?)
Familiarity with Agile vocabulary;
At least two years of professional experience in some domain;
Competence in a modern mainstream programming language (Java, C#, or C++)
Why architecture is perhaps more crucial to Agile development than to conventional development;
How to adapt Agile techniques so that they are supported by a good architecture, rather than doing damage to the architecture
How to sustain a business object architecture and domain object architecture that support each other
An overall development framework that reduces cost and has prospects for increasing revenues
How to reduce risk with eager decision-making strategies
Trygve Reenskaug's new framework for capturing requirements in code: Data, Context and Interaction (DCI)
Why User Stories are not enough, and what you need to understand the important relationships between requirements
How to implement two different kinds of architecture for two different kinds of end user interaction: atomic interactions, and sequences of tasks in context
How to reduce documentation needs by increasing code intentionality
How to package Use Case requirements into code that is as readable as the Use Case, instead of being spread across system classes
Time and Time to Market: Motivating Architecture's Value
Case studies and models of profitability with and without up-front work
Architecture and Technique
The Potential for TDD to erode architecture — and the remedy
Symbiosis between architecture and usability: MVC foundations and business objects
The link from architecture to functional requirements and Use Cases
Architecture and Maintainability
Lightweight Domain Modeling
How much architecture?
Commonality and Variability Analysis
Domain-Driven Design: Problem Domain Analysis
Commonality and Variation
Domain Starter Sets
Solution Domain Analysis
Positive and Negative Variation
Simple Domain Parititioning
Reducing to Code
The MVC-U Four-Layer Architecture
Business Objects and Domain Modeling
Business Objects as Tools
Tools and MVC
Architecture in Process
Incremental Architectural Slices
How much architecture, and when?
Capturing functionality in Code: Trygve Reenskaug's DCI architecture
A model from the perspective of Aspects
Class and object definitions of weavers
Capturing Use Cases
Tieing it all together
Summary and Wrapup
After attending "Agile Architecture", Ari Tanninen of European Game and Entertainment Technology, Ltd., said, "Learning is a struggle and often most painful, but with luck you get rewarded with one of those "aha!" moments. I have had about four of those in the past 24 hours or so. Isn't that something?"
Marko Taipale says, "I want to thank you for your inspiring course. You revealed something that I wouldn't probably ever get without your guidance. Now I know MVC. Now I understand OO(P). . . Thanks again for inspiring and proving that there is hope. Too often we feel that we care and think too much as we are having the pain; once again we see with the help of your insights that the problem is not us caring/thinking too much but the rest not caring/thinking enough."
Paolo Traverso of VisionWare Solutions, Inc. relates: "I attended your session on Agile Architecture and must say I was VERY impressed with your presentation. I would like to thank you for inspiring me with all of your stories and real world examples of Agile programming. It was so nice to hear about Agile from a developers perspective. For the most part I act as Architect, Business Analysis and Developer. Operating under these different roles is very difficult and I’m hoping the material you shared along with the Agile/Scrum fundamentals I will become more efficient as I manage and deliver projects."
Peter Anderson of TrueCon Aps says,"Thanks for a very mind-blowing course on Agile Architecture. You really moved my perspective on software architecture in an agile world."