Active Architecture for Agile Projects

I had previously blogged about how I felt that "System User Stories" were required and filled an important gap. I now believe that extending User Stories to create these System User Stories is not the best solution. You find that blog post at this link.

I still believe that there is a gap in Agile techniques that needs to be addressed for certain types of applications. For simple CRUD applications it is very possible that you will not require these additional techniques. This discussion is meant to address those non-trivial CRUD applications. I think my error was in trying to extend the brilliant User Story concept to cover System Stories. I now see that it was a bit of a forced fit. What I would propose instead is something I refer to as Active Architecture documentation.

The argument for Active Architecture

Too frequently in Agile, the focus on Requirements is only on User Stories. Sometimes the focus is on User Stories and Technical Tasks, but not on any architecture or holistic system design requirements. While this may be acceptable for Web applications that are simple, trivial, and primarily event-driven, it certainly does not suffice for applications that may have complex back-end components such as:

• Portfolio Rebalancing Engines
• Payroll Engines
• Network Optimization
• Scheduling or Matching Engines
• Really any application that has an engine. :)

Unfortunately, the amount of Architectural and Design Documentation has been greatly reduced by Agile due to the enormity of it and the waste. I agree 100% that there is waste, but I would suggest that the correct response was to create a new, leaner type of Architecture document. Instead of the traditional voluminous passive Architecture document, I recommend a new Active Architecture document that is composed of Component Conversations as illustrated below:

(Click on the image to enlarge it)

The issue with the traditional architecture documents are that they defined what the architecture was in a passive and distant way. Somewhat like a road map. What I am proposing is to define the architecture in an active way. Rather than just defining the map of roads, the documentation needs to define how the routes will be driven and in that active way, describe the road map. The traditional way of architecture documentation was too far removed from the actual act of system use to be relevant and effective. Architecture documents need to define what actions the architecture support, just like User stories did for user functions.

User stories capture interactions between the user and the system efficiently, and technical tasks capture lower level tasks that the system is required to do. But where in the Lean documentation do we define at a High level the interactions between system components?

The types of Agile Requirements I recommend are:

1. User Stories - Stories of how the User interacts with the application or manual processes
2. Component Conversations - Conversations between components of the application
3. Technical Tasks - Technical tasks that the applications needs to perform within a component.

Creating these component conversations and thinking them through for the entire system will ensure the following:

• That our User Stories are consistent in how functionality is handled across components
• That our User Stories do not create an undue amount of rework when an original story is encountered in a later iteration
  • Ensures that the entire solution has been thought through at a high level
  • Reduces the chance that a story will be discovered late that will require earlier stories to be revisited
• That our technical tasks are implemented consistently across components
• They will define the complex back-end high level requirements that would be inefficient and possibly inconsistent to define on a story by story basis
• They will define complex back-end high level requirements that may not be covered easily by user stories
• Components conversations can be reviewed to ensure we have all the system functionality covered and there are no gaps.
  • Ideally in a graphical way

These Component Conversations define the Active Architecture of the solution. One possible format of the Components Conversations are: (and you can customize to fit your particular requirement)

[#][Component A] does [primary action].[object].[additional action] by [Action].[Component B] when [event] 

Component Conversation Example

Perhaps an example would be beneficial to illustrate what these Component Conversations would look like. One important aspect is the timing as to when these Component Conversations should be created. Component Conversations should be created after User Stories have been created, and ideally after a User Story Mapping session has been held. These User Stories and a User Story Map provide inputs to the creation of Component Conversations.

Let’s use the FaceBook function of browsing suggested friends as a well-known example of a user event driven system that could benefit from Component Conversations.

Disclaimer: These stories are just a fictional representation of a well-known interface. They do not imply or propose actual Facebook functionality.

If we have the User Stories already defined, we could create the following Component Conversations to provide additional detail and context:

[1][SuggestedFriends] does
[create].[SuggestedFriendList] by
[filtering common connections across all friends].[Connection-DB] when
[user logs on]
[2][FacebookUser] does 
[Sends].[FriendInvitation] by 
[selectingconnectioninvitebutton].[SuggestedFriendList] when 
[User clicks on send friend request]
[3][FacebookUser] does
[Updates].[SuggestedFriendList] by
[selectingconnectionhidebutton].[SuggestedFriendList][HideFriendList] when
[User clicks on hide friend]
[4][FacebookUser] does
[Accept].[FriendInvitation] by
[selecting accept invitation].[PendingInvitations] when
[User clicks on accept invitation]

Now these four stories provide a very rudimentary example, but I hope it illustrates the level of information that are captured in the Component Conversations`. Even with these rudimentary examples, I think the following four ideas have been captured:

1. There is a process that creates these SuggestedFriendLists separate from the User interactions
2. There is a Connection-DB that is used to create this SuggestedFriendList and possibly the HideFriendList
3. There is an object that contains the Pending Invitations. (And possibly a similar concept for other pending objects)
4. There is the concept of a persisted HideFriendList to ensure suggestions that have been selected to be hidden will not appear again.

These ideas probably would have eventually been discussed when the stories are worked on in later iterations, but the real advantage of Component Conversations is to discuss them early, think them through, and ensure they are handled in a consistent way across the entire application. If these Component Conversations are discussed early they will also address the risk of potential rework when items are discovered after some development is complete. For example, the Pending Invitations object might be designed differently depending on all the objects it needs to support. If we can provide a process with Component Conversations where the high level requirements and behaviours are understood early, we should minimize these re-work situations occurring in later iterations.

The technical tasks would just be technical tasks that arise out of these Component Conversations, just like functional tasks are generated out of User Stories. (For example, a technical task might be “ensure Pending object is persisted and supports friends, events, and messages”). 

Summary

I've used these component conversations on my current project and they have greatly improved the understanding for both myself and team members. It is crucial that these component conversations should not be very involved and take a long time. I time box of 1-2 days should be sufficient to ensure a consistent understanding of the system exists. The component conversations can then be modified and changed as we proceed through iterations. The focus should be on Lean and what is enough to provide the required value.

The concept has provided great value for my current project.

About the Author

Terry Bunio is currently a Principal Consultant at Protegra. Terry never wanted to be a Project Manager. He started as a software developer and found his technical calling in Data Architecture. Along the way Terry discovered that he enjoys helping to build teams, grow client trust and encourage individual career growth, completing project deliverables, and helping to guide solutions.

It seems that some people like to call that Project Management. As a practical Project Manager, Terry is known to challenge assumptions and strive to strike the balance between the theoretical book agile and the real world approaches.

Terry considers himself a born again agilist as Agile implemented according to the Lean Principles has made him once again enjoy Software Development and believe in what can be accomplished.Terry is a fan of Agile implemented according to the Lean Principles, the Green Bay Packers, Winnipeg Jets, Data Architecture, XML databases, and asking why.