One of the fundamental differences between traditional and Agile way of “making / doing architecture” is that in Agile / Scrum I don’t really make or define architecture.
As far as you can call anything “architecture”, this would be definition from Agile perspective:
These decisions are eventually visible in one or more software products. If not, then there is no architecture at all. There are only pointless decisions. Like fantastic wine, open in the air, they will be spoiled / outdated very fast. World, requirements and specially insights are simply changing too fast. The problem with word “architecture” in software is that it represents something tangible. Something that you might want to pay for and say that you have it or not. But, nobody really wants to pay for architecture. Architecture is not a product. Please don’t say it’s a document. :-). You do have form and structure, which emerges with each iteration. This can be called architecture during and after you built a system. Talking about architecture so extensively as we do now in traditional projects, before a system is delivered, is a sign of lot of waste creation.
On other hand, architecting or in more correct english: designing is, just like planning, one of the most important disciplines in Scrum cadence. Designing represents all decision making activities needed to deliver business value with a suitable product. Some of them are:
- Defining and continuously redefining with new insights overall product vision.
- Identifying and placing quality requirements on product backlog and Definition of Done (DoD).
- Making sure teams take design decisions just-on-time and just enough
- Making sure teams know constraints, possible technical solutions, and design limitations
- Dealing with technical debt and refactoring
- Involving stakeholders often overlooked by the Product Owner
- Measuring overall quality of the product or landscape
- Harvesting and documenting discovered guidelines, standards, services, and solutions that might be of interest to others in organization.
LeanArch.eu 
Hi Viktor,Specification and implementation are traditionally seperated, resulting in solutions were specification and implementation are not in sync.There are more and more methods/apps that support loosely coupling of specification and implementation. Visual Studio does it with the layer- and class diagram.Result: Change the specification once and implementation is also changed.Change the implementation once and specification is also changed.I think this is in line with your post.Regards,Johan Theunissen