Software Architecture and Agile

An answer for people who “make mountains out of molehills“.

First of all, what is Software Architecture and what is Agile. I need to provide a short and summary definition of both terms in order to avoid “Barking up the wrong tree“.

The term software architecture intuitively denotes the high level structures of a software system. It can be defined as the set of structures needed to reason about the software system, which comprise the software elements, the relations between them, and the properties of both elements and relations. The term software architecture also denotes the set of practices used to select, define or design a software architecture. Finally, the term often denotes the documentation of a system’s “software architecture”. Documenting software architecture facilitates communication between stakeholders, captures early decisions about the high-level design, and allows reuse of design components between projects.

Agile software development is a group of software development methods based on iterative and incremental development, where requirements and solutions evolve through collaboration between self-organizing, cross-functional teams. It promotes adaptive planning, evolutionary development and delivery, a time-boxed iterative approach, and encourages rapid and flexible response to change. It is a conceptual framework that promotes foreseen interactions throughout the development cycle. The Agile Manifesto introduced the term in 2001.

The first term refers to Software Architecture and the second one to Agile Development. I guess that before even starting to bark against each other, we should have a look at the key terms that represent each topic and see if there are any terms that clash between each other. So, where Software Architecture and Agile clashes?

Software Architecture Agile Development
Design set of practices used to select, define or design a software architecture requirements and solutions evolve through collaboration between self-organizing, cross-functional teams

Here I don’t see any problem with these terms. Even if your architecture is dynamic, which is quite common, you still need to decide and define the architectures and patterns that you are planning to use. For example, you should specify the SOLID principles, setup the Continuous Integration tool, define the Development process, for example SCRUM, and so on …

In Software Architecture, what has been mentioned in the previous paragraph is called planning and there is nothing wrong with that, even in an Agile environment. In fact, right now I work in a successful Agile company and we have a quite heavy planning system, which works pretty well.

If you are working in a real Agile team, you will probably have: standup meetings, grooming, plan-board, you name it … Those are all processes that requires at least a piece of paper in your hands, and usually Software Architecture blends quite well into this mechanism. It brings tools like: ViewPoints, Diagrams, Process description. They are visual tools, very useful to keep the communication between Stakeholders, Product Owners and Developers clear and constant.

Software Architecture Agile Development
Decision and management The term software architecture also denotes the set of practices used to select, define or design a software architecture evolutionary development and delivery, a time-boxed iterative approach, and encourages rapid and flexible response to change

Agile development requires an adaptive and flexible attitude, you need to be ready for changes and be responsive. How can you be ready for changes and responsive? Well, probably by learning new techniques, experimenting new patterns and new frameworks, reading books and working on different projects and teams.

That’s probably the easiest way to be adaptive and ready for changes. What’s the problem with Software Architecture? None. An Agile Architect, because that’s what we are talking about, will simply document and mentor the teams about new technologies and frameworks and keep their technical motivation high and productive. The urban legend that a Software Architect will take all the decisions upfront it’s related only to some architects that work on waterfall projects, but of course it does not and it cannot apply to an Agile Architect.

The little different between a geeky developer and an architect stays in the experience. Usually an architect will suggest the cheapest, fastest and more maintainable solution for the company (customer) while a geeky developer will always try to experiment new techniques and frameworks that may be only the latest trend or the latest fashion. You don’t believe so? Look at the current development platforms. We moved back to 10 years ago architectures where we have simple HTML clients and rich business models behind a server side technology. So, that’s it? What happened then to those architects that didn’t move to the fancy RIA platforms? They were right, that’s it. 😐

Anyway, if you want to read more about how software architecture blends into Agile development, these are some useful links: