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):
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…
Comments
Post a Comment