Lean Architecture II: 

Agile Feature Architecture


Agile Architecture is not Fragile Architecture 

A system not simple enough to understand can't work

In the 1960s, a programmer could translate requirements more or less directly into code that could be reviewed, verified, and approved in a desk check by a colleague knowledgeable in the field. As Trygve Reenskaug (inventor of Model-View-Controller) notes, we lost this ability in the 1980s. Why? Because of object-oriented programming. Objects have many advantages as discussed in Module 2, but they lose the ability to reason about what the system does by looking at the code. This means that desk checks have less value today than they did in the FORTRAN days and that we have resorted to testing for quality assurance. Yet testing cannot reason about the absence of bugs in code; it can detect only their presence. We need to do better.

Further, Agile has taken us away from requirements to User Stories that are a promise for a future discussion between a programmer and a customer. The tester never isn't mentioned in this perspective, and the fact that we now rely so heavily on testing for quality should be reason to worry. The fact that most Agile techniques put test writing in the hands of developers is even more reason to worry, and numerous formal studies have shown that TDD does not and cannot live up to its claims of supporting the architectural desiderata of decoupled and cohesive objects. 

In this course, we look at the process constructs for managing requirements in the software design and coding phase. Given that you have a base architecture or any base platform of pre-existing code, where do user scenarios fit? They are not objects; yet, in a good OO world, they are not functions. And they must be managed in a way that sustains a good interface, going beyond the Agile value of "working software" to "usable software." Lightweight Use Cases as advocated by Alistair Cockburn, co-signer of the Agile Manifesto, come to bear as a major enabler in customer collaboration and as a way to deal with change and to raise the chances of delivering working software. Again, minimizing the number of methodological artifacts and maximizing the expression of design concerns directly in code, these techniques contribute to high feature velocity. Using techniques developed by Trygve Reenskaug and popularized by the course's instructor, this course shows how to retain the structure of requirements directly in object-oriented code. The approach depends on a four-pronged approach to design that uses not only classes and objects, but also roles (and their implementation as interfaces), as well as context definitions that map roles onto objects at the beginning of every Use Case.


Target audience:

  • Designers;
  • Programmers;
  • System and software architects;
  • White-box /clear-box testers;
  • Line managers;
  • User experience folks (there is an important and surprising relationship between HCI and architecture in an Agile system);
  • Domain experts;
  • System Engineers;
  • To a lesser degree, ScrumMasters and Product Owners (wouldn't it be nice to know where architectural PBIs come from and where they go?)

Prerequisites:

  • 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++)
  • A helpful (but not absolutely necessary) prerequisite is the Lean Domain Architecture course.

You'll learn:

  • 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
  • When stories and use cases are the wrong tool
  • Why there are two different kinds of architecture for two different kinds of end user interaction: atomic interactions, and sequences of tasks in context
  • How to implement those architectures 
  • 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

Outline

  1. Introduction
  2.  The MVC-U Four-Layer Architecture
    1. Business Objects and Domain Modeling
    2. Business Objects as Tools
    3. Tools and MVC
  3. Architecture in Process
    1.  Incremental Architectural Slices
    2. How much architecture, and when?
  4. Capturing functionality in Code: Trygve Reenskaug's DCI architecture
    1. Code intentionality
    2. A model from the perspective of Aspects
    3. Class and object definitions of weavers
    4. Role definitions
    5. Capturing Use Cases
    6. Methodful roles
    7. Tieing it all together 
  5. Summary and Wrapup 

After attending "Lean 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 Lean 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 Lean Architecture. You really moved my perspective on software architecture in an agile world."