First, a bit of context..

For me, architecture and design is really important. Architecture is a deeply subjective thing in my opinion, but that doesn't make it less scientific. A good software architecture is one that the team understands, and that the team agrees upon. Therefore, when I am the architect in a software project, my job is to make everyone understand the architecture; to make everyone understand why the architecture is useful to the project. The architecture should guide code decisions.

For example, one architecture I often use is that I have a "model layer" and a "presentation layer". The model layer must not contain anything GUI-related. It must be written in a way that would make it easy to write a command line tool for the application, if we ever want to do so. (This is not just a decision I make, this is also something that I tell co-workers, so that we have a shared understanding. This is important!) And the presentation layer must not contain complex logic code or any algorithm that require a bachelor degree in computer science to understand. It can contain GUI code and it glues everything together.

Because software architecture is so subjective, everyone seems to have their own definition for it. This doesn't make it easier for a junior developer, right? I just don't want to give you another generic definition of "software architecture", because you can find that on Google.

Software architecture is certainly an advanced topic. You need to get experience as a professional software developer first. Maybe you need to see how software projects can fail because of bad architecture decisions. If you are lucky enough to not get into that situation, then there is certainly a good architect in your team, and you can ask him (or her) for advice.

Agile?

I often have the feeling that people think of Agile as the methodology that dumps all planning and thinking ahead.

"we don't need architecture. we just write the codez. we can always refactor it later. design is for dummies. we prefer working programs over huge specifications"

Of course, this doesn't do justice to agile software development in general. But I think it is important to know where this thinking comes from.

In ancient times there was the "V-model" and there was the waterfall-model. They produced huge amounts of documentation. They planned stuff for months before writing the first line of code. Then they started programming and everything fell apart. People realized that this kind of management is bad and leads to often undesirable project outcomes.

Then the agile manifesto was born. It says:

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

The developers that followed never learned about the V-model, or about the waterfall-model. They barely commented their code. They wrote almost no documentation. And then they read the agile manifesto. And they interpret it as saying:

it's okay that you don't write documentation. It's okay that you don't do any thinking before you start writing code. That is agile. That is the new way to go.

I'd like to add a quote by Joel Spolsky (one of the founders of Stack Overflow) here:

When Linus Torvalds bashes design, he’s talking about huge systems, which have to evolve, or they become Multics. He’s not talking about your File Copy code. And when you consider that he had a pretty clear road map of exactly where he was going, it’s no wonder Linus doesn’t see much value in design. Don’t fall for it. Chances are it doesn’t apply to you. And anyway, Linus is much smarter than we are, so things that work for him don’t work for us normal people.

So there is this misunderstanding that "agile" means that there should be no "architecture" and no "design", or that good architecture and some upfront design is incompatible with agile principles. This is not true, and it is not what the authors intended. You need to see "agile software development" within its historical context in order to make sense of it.

Conclusion

To sum it up: for me, agile software development and software architecture are connected. If you are responsible for the architecture of a software system, you need some way to communicate your architecture to your fellow team members. So everything you do will be embedded in some kind of process. As an architect, you have to actually read the code of other people and give feedback. So you cannot really be a software architect without also being a manager. (Otherwise, people may not follow the architecture that you invented, which may eventually break it.)

People have to like the architecture that you are proclaiming. If you create an architecture that everyone hates, it will not work out well, even if you can "prove" that it is technically optimal.

If you are a manager but don't do the architecture part, who gets to decide on architecture issues? Who takes the hard decisions? I know that there are managers that don't know anything about software architecture. There are two possible outcomes: 1) a disaster, 2) there is someone on the team who is the informal architect, and if the manager is smart, he knows he is dependent on him and has to delegate many technical decisions to the architect.

Furthermore, "agile" is more of a marketing terms nowadays than anything else. If you are saying that "your management method" follows "agile principles", no one will question you, and you can basically do whatever you want (as long as you don't introduce RUP or the V-model). This may sound a bit cynic, but it's not. The definition of "agile" is pretty broad.

I recommend "Just Enough Architecture" by Fairbanks for Architecture and "Domain Driven Design" by Evans for Design. These books will make you a better software developer.

If you want to be a manager, you also need to know about the whole development cycle, including deployment, configuration management, continuous integration, API development, etc. - but these things are really orthogonal to both architecture AND agile software development.

tl;dr: Some people seem to confuse the trait of a Software System having a good Architecture and a good Design with the activity of performing Architecture and Design explicitly up front and the role of an Architect and a Designer.

Most Agile Processes do not have a separate Architecture or Design phase, and they do not have specially designated Architects and Designers. Rather, Architecture and Design are emergent properties of the System and the team, and every member is equally responsible for good Architecture and Design. They do care about good Architecture and Design, which is precisely why everybody (not just one person) is responsible for it, and why they do it all the time (instead of just once at the beginning of the project).

This is like claiming that Test-Driven Development has no emphasis on tests, because there is no designated testing phase and no designated tester.

---

There is a common misconception that Agile means "never document your code, don't have processes, and never plan". This is wrong.

Here is what the Agile Manifesto actually says (bold emphasis mine):

Manifesto for Agile Software Development

We are uncovering better ways of developing software by doing it and helping others do it.
Through this work we have come to value:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

It does not say you shouldn't have processes. Quite the opposite: it says that there is value in processes. It only says that if you must choose, i.e. if you don't have enough resources to implement both comprehensive processes and have rich interactions between individuals, then you should prefer the latter. Or, in other words: you should have processes that don't constrain interactions and individuals.

Likewise, it does not say that you shouldn't have documentation. What it does say is that if you have only enough resources to either deliver working software or comprehensive documentation, then you should prefer delivering working software. Which, I mean, is kind of obvious … what good is perfectly documented software that doesn't work?

The Agile Manifesto is augmented with Twelve Principles behind the Agile Manifesto, some of which I will quote here (again, bold emphasis mine):

Principles behind the Agile Manifesto

We follow these principles:

[…]

• Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.

Requirements is another thing that Agile processes are often accused of ignoring. But as you can see, the authors of the Agile Manifesto and its Twelve Principles have explicitly thought about requirements. And moreso, they explicitly acknowledge a fact that lots of other, "traditional" processes deny: that requirements change over time.

• Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

This doesn't seem to have have anything to do with architecture and design directly, but think about it: if your development cycle is two weeks or even one (which a lot of agile companies actually do), then there is so little architecting and designing to do, that it may look from the outside as if you are doing none at all.

• Continuous attention to technical excellence and good design enhances agility.

Here you can see that design is definitely part of the agile mindset. Even more so: good design is important to stay agile! If you design yourself into a corner, where you can no longer change your code because it is so intertwined and brittle, then you can no longer move quickly (which is, after all, the definition of what the word "agile" means).

• The best architectures, requirements, and designs emerge from self-organizing teams.

Again, here you can see that the authors of the Agile Manifesto did not ignore architecture, requirements, and design, but explicitly included them in their considerations.

• At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

This is also a very important Principle that often gets overlooked. If you buy a book about Scrum / XP / Agile / whatever, and then strictly follow the book you are doing it wrong. If you discover that you could work better if you do a bit of architecture up front, then just do it.

Note also that Agile does not exist in isolation. In fact, several signatories of the Agile Manifesto are also signatories of the Manifesto for Software Craftsmanship, which is modeled after the Agile Manifesto and cleverly written as a sort-of "third column" added to the two columns of the Agile Manifesto (note that the first half of each sentence is directly from the Agile Manifesto):

Manifesto for Software Craftsmanship

Raising the bar.

As aspiring Software Craftsmen we are raising the bar of professional software development by practicing it and helping others learn the craft. Through this work we have come to value:

• Not only working software, but also well-crafted software
• Not only responding to change, but also steadily adding value
• Not only individuals and interactions, but also a community of professionals
• Not only customer collaboration, but also productive partnerships

That is, in pursuit of the items on the left we have found the items on the right to be indispensable.

I would argue that "well-crafted software" and to a lesser extent also being a "professional" includes good architecture and design.

Lastly, there is also the concept of Technical Debt and Refactoring.

The concept of Technical Debt means that, in theory, you know the most about how to correctly architect, design, and build your system, just after you have finished building it. As a consequence, this means that your system will not be perfect. It also means that if you want to build a perfect system, you are never allowed to start, because you don't have the knowledge how to build a perfect system.

Technical Debt, now, gives a way out of this dilemma: just like borrowing money to buy machines to make money to buy machines (financial debt allows you to move faster), Technical Debt allows you to start building your system with the best understanding you currently have. The difference between how you would have built the system if you had known from the beginning what you learned while building the system and how you actually built the system based on your limited understanding, that is Technical Debt.

However, just like financial debt, Technical Debt has to be paid back, otherwise you have to pay interest (in the form of more maintenance, harder to add features, slower innovation).

Refactoring is the tool we use to pay down that Technical Debt. Where Technical Debt is the difference between what you would have done if you had known everything you learned during the project from the start and what you actually did, Refactoring is the act of integrating that acquired knowledge back into the system, so that the system looks like you knew how to build it from the very beginning.

And that is where and when Architecture and Design actually, physically happens in Agile. Architecture and Design are discovered while building the system and integrated through Refactoring.