Agile Architecture in 10 Steps

In my latest ten years, working as an IT consultant in the area of enterprise architecture, I got more and more questions about combination of the agile software engineering (not just only development) and the enterprise architecture which comprises business and software architecture.

Especially for the big organizations it is a challenging topic due to their internal culture and structure that doesn't really suit to the values and principles of "being agile" as defined by the Agile Manifesto. The main idea of the agile software engineering, besides the responsive, incremental and iterative development process, is to work in a *vertical* and not *horizontal* way. Only *vertical work*, defined e.g. in a form of a user story, can deliver business value as expected by the stakeholders. However this 90 degree turn in the way you work is the biggest problem especially in case of a big organization. It requires involvement of much more departments that work together *in parallel* comparing to the classical *horizontal work* with defined layers and responsibilities. This *vertical work* simply drill down your whole system thus affect many areas, especially architecture, which in this context has also *to be agile*, means that you have to think about agile architecture as a process of building a software system as well as a structure of it.

You can find plenty books about architecture. Most of them describe *what* architecture is and *why* you should architect it (yes, it sounds a little bit strange but you actually *architect architecture*). However there are just few books that say *how* to do it. That is exactly what this presentation and my upcoming book is about. This “HOW to architect agile architecture”, based on my experience and examples from my current project where I work as a lead architect in one of the biggest insurance companies in Germany.


Thinking "Beautiful" or "Agile" when Architecting Architecture

Working as the lead architect in my current project I decided to choose agile way of designing architecture. I decided to let architecture grow with the project. I decided to choose pragmatic approach making (as far as possible) architectural decisions that suit to the needs of the project. Decisions that align engineering benefits with the costs, thus reduce risks. And it works.

However focusing on the topics mentioned above causes admittedly the architecture to be agile (risk-driven, pragmatic etc.) but does not guarantee that the resulting architecture will be simply beautiful.

It is like designing a perfect house to live in, but possibly ugly when you look at it. And most probably a beautiful house will be more expensive as the "pragmatic" one, being however more attractive to the residents. Quite interesting trade-off that in my opinion should not be forgotten in case of a software architecture.

A perfect software architecture is agile and beautiful as well.