The End of Software Architecture

Leonid Lezner, who does the wonderful Podcast “Firmenfunk”, and I recently had a discussion about whether a software architect was necessary. Building on this, Reinald Kirchner wrote an article where he shared the following observation: Software architecture is often compared to development plans which will never be followed. On the other hand, advancing to software architect was one of the most important career moves for software developers for a long time.

Emergent Architecture – discussed since 2005

Why did Leonid and I even wrestle with the topic of whether a software architect is necessary? I can tell you that the agile software development community already thoroughly discussed this question in 2005. Back then, the community came to the conclusion that the architecture would be done by the software developers in the teams and there should no longer a separate architect role. At conferences and in countless articles, we talked about what emergent architecture is and decided that we would only come to a meaningful answer if we used the metaphor of a gardener rather than an architect. In environments which are continuously changing, development can be improved if teams agree on using test-driven development and chose de-coupled construction for their software applications. This is called de-coupling and can – but is not required to – progress into, among other things, micro-service networks. Over time, there also was a realization that Conway’s Law really did apply. As such, it became clear that company architecture is always emergent and always aligns itself on the organization.

However, this repeating of what was already known can only be understood when you take into account that modern software development, as practiced by professional teams, had a long way to get to this point. In 2001, Extreme Programming began to take root as a new paradigm in the minds of developers as a robust development method with automatic testing. Fierce arguments took place over whether or not everything needed to be automated, and then the arguments were about who had to write the tests. Obviously, the testers felt empowered and wanted to do the job. When it became clear that the developers needed to write the tests, though, is when this movement progressed. Scrum and Extreme Programming techniques forced teams to think about emergent architectures because classical approaches were too slow, and protracted upfront planning proved to be ineffective. This wasn’t a few minor deliberations: The entire paradigm of software development needed to be tossed out and we needed to develop new mental models.

Have these models already manifested themselves across all organizations and in every developer’s mind? After 20 years of agile software development, are we all speaking the same language and do all software developers today do their development based on the modern paradigms that have been created in the last 20 years? Have they mastered development patterns or do they automatically write according to the motto “leave the code better than you found it – i.e. constantly rebuild the base code”? Certainly not.

In the agile developer scene, knowledge that was gained many years ago is still being ignored. Many developers, software architects and managers are lying to themselves when they say it can’t be done differently. They believe that an architect, or even an entire team, must do the thinking for the developer and dictate to them how they have to do things. Kirchner calls this development plans.

There is still this idea that you can build solidly and firmly in a world filled with unprecedented changes. Instead, we should think about how robustness and resilience – or better said, anti-fragility – can be integrated into the applications.

Stumbling Block Status

I think the reason for this is that in far too many projects and organizations it is still going about the issue of status. There is a social hierarchy in organizations: At the top is business, then come the project managers, then the software architects, then the developers, then the testers, and at the very bottom is operations. For this reason, backlogs are still written, technical user stories thought up and framework architectures imagined. Developers should then implement as quickly as possible what the others have imagined and estimated. And such that the testers in India are able to do the testing as simply and cheaply as possible.

We continue to dream because we all wrap ourselves up in an agile coat. We call operations DevOps, from requirements management we get Design Thinking and we have woven requirements specifications into backlogs. There we find user stories in a degree of detail that was unthinkable in the days of requirements specifications. We make deliveries with the help of release trains that suggest punctuality and predictability – although we know we should be doing continuous releases. However, at its core, this work is more expensive than before. Why? Because we haven’t resolved the status problem, i.e. the power relationships. Organizations remain political entities in which silos dominate and the focus is inwards rather than outwards. The sad thing is that incompetence and unprofessionalism is sold as state-of-the-art and “no other way possible” because regulations, legacy systems, existing technologies and who knows what allegedly make it necessary.

The Rule of Fractals

Agile development should – but does it far too little – be comprised of fractal teams that are comprised from various, diverse disciplines (this applies to agile working as well as agile organizations). In these teams, people should be able to use their abilities for the benefit of the team (now called Paint Drip People), creating truly diverse teams. Teams that complement the original ideas of cross-functional teams and become reality. In this way of thinking, there is no place for traditional fixed roles like software architects, lead developer, test leads or business analysts. These are the functional roles that always become bottlenecks. At the latest, when the person in that role wants to defend their position because of the money, the bonuses and the honor tied to it.

If you really want to change this and put fractal teams in place, you will be successful if you implement a few simple rules:

1. De-coupling as a principle
2. Teams remain small
3. Teams are responsible for their functionality end-to-end
4. Each team takes care of “their” user
5. The entire network has all the information
6. Things are allowed to be duplicated in development
7. Speed, not efficiency, is most important

Then a network is created that is able to continuously change and is ultimately able to work more effectively and efficiently.

If you don’t believe me or can’t imagine how this should work, you can read a precise description of how it can be done. It shouldn’t be too difficult to transfer this information and make it into reality in a software development organization. Enjoy reading “Team of Teams”!

#insightsborigloger #agilemanagement #agiletechniques #agileorganisation #softwaredevelopment #teamsDoes

Foto: pixabay license, andreasfuchs8732