The importance of (agile) architecture and design
jl.marechaux 060001NWA6 Visits (1287)
Despite what dogmatic agile development coaches might say, I believe that there is no successful software development without architectural analysis.
I had a strange conversation with an IT professional last week. To preserve his anonymity, let's call him Oleg.
Oleg: Pretty well, JL. I joined a new project two months ago. It's an agile team and I like it very much.
JL: Glad to hear that. What kind of project is it?
Oleg: We are developing a new solution to enrich our existing internet banking application. Our new component will integrate services from several departments and even business partners.
JL: Sounds like an interesting challenge. Are you working on the architecture of this new solution?
Oleg: No, we don't do architecture, we are an agile team.
JL: ??!!?........ (speechless....)
Oleg: We focus on developing a set of services to enable the integration.
JL: Ok, I understand that your primary objective is to deliver working software but integration of services from different sources must not be easy. How do you define the structure of your component? How do you identify the different services needed? How to you mitigate risks?
Oleg: Well, it took two weeks before the project really started. Just the time to obtain the buy-in from the business sponsor and assemble the whole team. It was a great opportunity for me and some colleagues to start thinking about our new project. We addressed some of these questions at this time.
JL: I see... so you pictured the technical solution during the project warm-up. And how are you evolving your architecture during your sprints?
Oleg: Well, as I told you, it's an agile team. We do test-driven development and refactoring all the time, but we don't waste time on architecture.
JL: You mean that because you are an agile team, then you don't...THINK?
Oleg: Don't get me wrong. I work with brilliant people and we have brainstorming sessions all the time.
JL: Ok, so you are doing architectural activities, right?
Oleg: Well yes, but the client does not want to pay for architecture. So we don't really publicize this. We keep it secret in our war room and we bill our time on development tasks.
JL: I see. Architecture is really part of development sprints anyway, so you bill your time at the right place. Just curious, are you doing modeling at all?.
Oleg: Of course we do, because a picture is worth a thousand words. It helps us a lot during our brainstorming sessions. And we have a lot of short brainstorming sessions during the sprints to tackle new technical challenges uncovered. But again, this is not something we expose too much as the client does not pay for diagrams.
So what did Oleg tell me exactly? He stated that on his project, team members are not doing architecture because they are following an agile process. But then he explained that before their first development sprint, they spent some time to envision the architecture.So the good news is that Oleg's team is thinking about the new solution that they are developing (the bad news is that they seem ashamed of their architectural work).
Oleg also told me that his team is not officially doing architecture during sprints. But he also confessed that they are hiding to create models, as if it is some sort of perversion. Their models or sketches are considered helpful for their just-in-time modeling sessions during sprints. It is how they refine the architecture of their software-intensive system over time.
Of course, you can not deliver a system if you keep thinking about it forever. Architectural work must be integrated to the development lifecycle. Architecture is intentional because you make deliberate decisions based on what you know when you start a project.
Architecture is also emergent because you always uncover new technical challenges during development sprints.