Don't Think in Dialogs, Interactions and Features! Use Models Instead!

For some days I read an article in ObjectSpektrum by Ralf Westphal about his understanding of an agile architecture. As we know, there is no clear definition for that term, so the interpretation field is quite big, from design process up to continuous delivery. I was interesting what Ralf would like to say about agile architecture as I knew some of his interesting projects before (e.g. http://www.clean-code-developer.de/).

He rightly claims that there is a gap between requirements and, what he calls, logic (understood as implementation). Agile architecture should help to reduce this gap. This requirements are defined with the help of User-Stories, that mostly do not have direct mapping in the software structure. They have to be transformed into containers with logic, called modules. He reasons that these modules exist in various forms, from small functions, throw-out classes and libraries, up to services. This is however a quite technical view on a software system, so Ralf created another model that is defined as follows (with respect to the first one):

• Software system
• Applications of a software system (map to services)
• Dialogs of an application (map to classes)
• Interactions of a dialog (map to functions)
• Features of a interaction (map to functions as well)

This second model is used to correlate User-Stories with its "module-oriented increments" which can be in turn, as described above, mapped into modules:

Pic. Correlation between User-Stories and module-oriented increments by Ralf Westphal

I have seen lot of systems built like this, and in my opinion it is not a proper way for designing a software system where an agile architecture is used in context of closing the gap between requirements and logic. 

Closing the gap is only possible if the project members get better understanding what should be done. This can be achieved only with the help of models that focus on the certain aspects of the business (see http://www.nativeagile.com/2015/02/architectural-way-of-catching-business.html for more):

• Business entity and process model
• Business rule model
• System state model

These models have to be created in their initial versions at the beginning of a project. Yes, it is a design upfront, but it is required to avoid a big risks of emergent architecture, when you can run with it into completely wrong direction (it is one of the biggest mistakes of many agile protagonists that say "we don't need any architecture" or similar). So the project starts with so called Little Design Up-Front (LDUF) as an opposite to Big Design Up-Front (BDUF) (see my slides about Agile Architecture in 10-Steps for details http://www.nativeagile.com/2014/12/agile-architecture-in-10-steps.html).

Thinking (following Ralf's suggestion) you can start a design of a software system with the questions how many applications you need and then follow with the definition of the dialogs for each is quite common, but very naive.  It results at the end with a technically split systems and the strong projection of  the business processes onto UI flows. As a result every process activity maps to individual dialogs, which causes every change in process flow an enormous challenge in development. You can forget flexibility, which is one of the main non-functional requirements solved by agile architecture. Having various types of clients with various UI flows (what is often the case when talking about web, desktop and mobile applications) is very difficult, because you have to reimplement most parts of the business process in every type of client.

We can however correct the Ralf's diagram by extending it in the following way:

Pic. Updated Model with use of various business models.

We correlate here user stories with the created models by answering following questions:

• What business domains an user story belongs to?
• What business entities are involved?
• What are the business process activities required?
• What business rules have to be involved?
• What is the state a case and how does is change?

Having this answers we can design implementation details or analyze our current implementation in case of an increment. We judge if the bounded contexts have right boundaries for the part of a business domain represented by the user story or if we need a new bounded context. Afterwards we can start designing or dialogs, interactions and features (if we stick to the Ralf's vocabulary). And this should be done for every user story in the agile's iterative and incremental way. Very important is however the "step back" after each increment "to see the whole" picture of the architecture as defined by one of the lean principles.

This is the right way doing agile architecture. Quite straightforward. The magic sits in the models…