Rethinking Software Architecture

From time to time everybody feels that the architecture of the software one develop is quite closer to a big bull of mud that the screaming architecture.

I give you plan of a workshop you may lead with your team. This is a part of my ArchitecturalKata for an Agile Team workshop.

What is the Goal

We want to achieve agreed and clear vision of the architecture. I am really pragmatic person. So I am not going to push you to introduce some sexy solutions as: DDD, Clean Architecture, CQRS, Event Sourcing and stuff. It may happen it may not.

There are many criteria to meet to achieve these architectures. Here, our goal is to move your architecture into a better place, even it mean a step forward. We want the architecture to be more testable, maintainable and more decoupled. That's all.

What We Need?

• a team who work on the system (recommend no more than 10 people)
  
• 1-2 days
  
• silent classroom
  
• space on the walls or on the floor
  
• quite big table or space on the floor
  
• couple blocks of sticky notes in many colors
  
• colored markers
  
• pair of scissor
  
• printer paper
  
• big flip-chart sheets
  
• paper tape
  
• a computer with a code baseline
  
• beamer (useful but not necessary)
  

See Responsibilities

Because flow of that workshop varies in some details depends on the software size and granulation, I give you an example for the quite big legacy system (developed from more than a decade, where primary building blocks are components containing many classes).

1. First, capture all your components. Write each on a sticky note. It may be hundred of them or more but not so much :)
   
2. Then look into the source code and try to name responsibilities. Responsibility is a role of the component and the way how it serve to others. So, you will find them looking at the public methods, events published, signals sent. Sometimes one strange method is one responsibility, other time group of related method define a responsibility.
   
3. That's important: name only those responsiblities you see in the code, not those you think they are
   
4. Don't be too detailed with the granulation of the responsibilities. Be ready to regroup and rename them any time you want
   
5. Probably you know that in a legacy code components have many responsibilities, so name them explicitly and write them on small stickies. Next put small stickies on components they come from
   
6. You will see than you have two to four components which looks like stars with its satellites :) These are components where single responsibility principle was really abused. There is much code inside
   

Redefine Responsibilities

Now its time to redefine responsibilities of the components. Organize your components obeying following rules:

• A component has exactly one coherent responsibility
  
• You are allowed to add new components
  
• You are allowed to remove components
  
• You are allowed to rename components
  

So now:

7. Add/Remove/Rename components and reorganize responsibilities stickies
   
8. Repeat until every single component have sort of small stickies and all of them describe one coherent responsibility
   

Redefine Communication Between Components

9. Now draw directed lines representing communication between components and note purposes of a communication just right above the lines. A line starts from a component which initiate communication.
   
10. There is one rule during this exercise: a line cannot cross an other line. I will explain why at moment.
    

11. Sometimes you will discover a cyclic dependency between components, so remove it, if needed.
    

Cluster Components

12. The rule "don't cross the line" caused that components which work closely are stuck closely.
    
13. Try to circle clusters of closely related components. But there is important rule: look for the clusters related to the functionality of the system. You may ask yourself: What is the core cluster where we have minimal deliverable functionality? How to cluster components to extract potentially optional functionalities?
    
14. Name these clusters
    

Define Clusters API

Now we want to see high-level view. We want to extract fine grained and decoupled clusters enclosed in modules, processes or separate applications.

15. First define an API for the clusters.Finally we want cluster-to-cluster communication instead of component-to-component. A component-to-component communication is fine inside the cluster, but not between them.
    
16. API receives communication from other clusters and distributes it inside of the cluster. It also translates the inside-cluster communication into outside one.Technically that translation layer will be some combination of facades and adapters.
    
17. Defining API remember that we have: exposed interfaces and required interfaces. Define both.
    
18. Also explain how the inside-cluster components talk to each other.
    
19. This is important: obey the encapsulation rules: nothing from inside of the cluster is seen to the outside world
    

Define Communication Between Clusters

20. Draw communication between clusters. It will be API-to-API communication, it mean exposed interface to required interface.
    

This is it. Artifacts and discussions during that workshop bring quite clear understanding of the current state and well defined vision were want to be if about architecture of our software.

How long it takes to refactor the code?

Wel, it depends ;). I know the cases (software of that size) where it took a year or so total. Remember that visioning is a one thing, but bringing the vision into reality is completely different story.

What Next?

One of the next steps is a really tricky stuff. We need to prepare plan how to communicate our technical objectives to managers and all those people who have an authority to say YES or NO to our refactoring work. On the end we want them to support our new architecture.

Working strategies to convincing sponsors are the key part of my ArchitecturalKata for an Agile Team workshop. If you want me to lead this workshop for your team, please contact me at the contact form.

Group Your Tasks by Context

I had really busy time last month, I did training and workshops week by week. Naturally I come up with an idea of optimizing my tasks and decided to arrange all that organisational stuff on the beginning of the month.
In my trello board the following card was created:

When working I checked task by task but realized that I wanted to update training materials before printing. Moreover I received a discount in the hotel but first I had pay it in cash. In consequence of that it was better to book hotel for third training in two weeks.

My task froze. In couple days I start feel myself frustrated because I couldn't move that stupid task to the 'DONE' column. Why? Because I did a mistake in grouping tasks by a type (organisational stuff) instead of context (a training).

Grouping them by a context is almost always better solution. It would generate more cards on the board, but at the same time they would move through the board faster. You improve the flow, boost your satisfaction and motivation - that's how it works.

So keep in mind: group your tasks by a context instead of a type.

Meet us at JDD 2016

This year you will see a special talk at JDD Conference.
Me and Łukasz Korczyński (Nordea Bank AB) prepared a summary of six months long work with pushing refactoring initiative at Nodea Bank AB (former Nordea IT Polska) in Gdynia. We are waiting for your attending!

Moving the blog

So, most of my time was recently consumed by books writing. It's time to reactive the blog, so I decided to move it into gettingthingsprogrammed.pl as a part of some changes related to my personal branding.

So, how do you find the gettingthingsprogrammed.pl?