Watch more from the O'Reilly Software Architecture Conference: http://goo.gl/lXpXnG There is a common misconception that architecture is thrown out the window when a team or organization is developing software in an agile fashion, but where does this myth stem from? Surely, there is some truth behind this thinking. We’ll talk about some of the underlying assumptions that support this belief in order to build a common understanding of what it really means to be developing in an agile fashion. During the second half of this talk, we’ll move from the conceptual thinking into some practical suggestions from our experiences — what we’ve seen that works and highlight some practices to avoid. In the end, the audience will know how to bring architectural thinking into teams to support the higher level goals of application architecture. About Molly Dishman (ThoughtWorks): Molly Dishman is a Senior Consultant at ThoughtWorks Inc. a global IT Software Consultancy. During her ThoughtWorks career she has developed top quality software solutions for clients all over the world. She has been a trainer, developer, technical lead and coach during her time at ThoughtWorks. Molly is passionate about solving technical problems and helping others grow and learn software development. About Martin Fowler (ThoughtWorks): Martin is an author, speaker, consultant and self-described general loud-mouth on software development. He concentrates on designing enterprise software – looking at what makes a good design and what practices are needed to come up with good design. Fowler has been a pioneer of various topics around object-oriented technology and agile methods, and written several books including “Refactoring”, “UML Distilled”, “Patterns of Enterprise Application Architecture”, and “NoSQL Distilled”. For the last decade he’s worked at ThoughtWorks, what he considers a “really rather good” system delivery and consulting firm, and writes at http://martinfowler.com. For more information, visit: http://oreil.ly/1Cyt9nt Software architecture is a massive multidisciplinary subject, covering many roles and responsibilities, which makes it challenging to teach because so much context is required for every subject. It's also a fast-moving discipline, where entire suites of best practices become obsolete overnight. The O'Reilly Software Architecture Conference is a new event designed to provide the necessary professional training that software architects and aspiring software architects need to succeed. A unique event, it covers the full scope of a software architect's job, from IT to leadership and business skills. It also provides a forum for networking and hearing what other professionals have learned in real-world experiences. Stay Connected to O'Reilly Media by Email - http://goo.gl/YZSWbO Follow O'Reilly Media: http://plus.google.com/+oreillymedia https://www.facebook.com/OReilly https://twitter.com/OReillyMedia

Comments

1. Object-orientation is a failed paradigm, and agile is the scabbed-over bandage that keeps the patient from bleeding out entirely.
   
   Don't get me wrong, objects / interfaces can be great, such as when you need to build pluggable systems. But as your first choice for modeling a program, OOP carries in so much unnecessary complexity (mostly via mutation) that you'll never hope to get anything right the first time. Or the second. Or the third.
   
   Instead of admitting the failure of their programming paradigm, the OO 'sages' invented a methodology that punts on all of the problems that come out of it. Is your team bogged down because your system has become so complex that no one can figure out a coherent way forward? Get rid of code ownership so that any system invariant can be bulldozed in the name of short-term progress. Can't figure out how to design an OO system without falling into analysis paralysis? Skip the whole fucking design phase entirely and make it all up as you go along.
   
   We now know that around 90% of our systems can be built with significantly simpler and more lego-like (composable) pieces using functional programming. In the fewer cases where performance is top priority, we know that we can get the best performance by skipping the OO middleman entirely and going straight to data-orientation. Performant and well engineered systems tends to use both approaches in tandem.
   
   This whole agile methodology is the result of OO taken to its incoherent and pathological extreme. Throw that shit out of a moving bus, and learn to use mathematics like basic data abstraction and abstract algebra to solves your design problems.
2. don't know why they going back and forth ... hard to follow ... they shoulda just split the presentation up. A very non-agile presentation!
3. Does anyone else think Molly looks a bit like Ronda Rousey?
4. incoherent gobbledygook. This reason for architecture is to get out in front of coding so you can discover and correct design problems when you can do so quickly and cheaply. The goal is to fix architectural issues before they become hard and costly to change so you don't need to have 20 $100.00 an hr developers in a "mob refactoring" session to fix a blistering mess.
5. Agility without SOLID is a pure mess.
6. Molly seems very, very nervous.
7. I think of software architecture as that which is common across the whole solution and stand the test of time. Everyone desires everything to be easy to change but in some cases especially in a large enterprise, the "architecture" design/decision is not easy to change. For example, if an "architecture" decision was made to go with a particular vendor or platform and people/team who made that decision didn't think through all the important use cases, it could really suck later. What is the "agile" approach to such projects? In my experience, these type of "architecture" decision requires a lot of forward thinking and is not practical to say just "remove" the architecture (i.e. things that are hard to change). Thanks and enjoyed the video.
8. Can we have good design with zero documentation ?
   I'm very curious to know to how to do that. And what dos it mean by that.
   And how to keep a communication medium in team.
9. I really enjoyed the talk, and I really appreciate the idea that the architecture of a system should be easy to reverse, because once it does not do so it will likely add some constraints on some important quality attributes such as flexibility, adaptability and even on usability. Therefore, I myself learned that if you want to architecture a system which aims to attend the fast changes of the real world you'd better design something that is easy to change.
10. Martin, I have your books and read them too, cover to cover, I respect your opinion. I am having a huge amount of difficulty following you guys in this video. Architecture is concrete, its a plan, a design to elaborate on those items in a significant use case (importance) or hard to change fact (flexibility) as you've stated, but its also a movement towards detail, understanding and delivery.. Agile, CMMI, etc are processes for delivery. I architect and apply Agile methodology all the time. (I also apply CMMI) The issue is not Agile and Architecture (completely a red herring), the issue is simply about leadership in Agile teams. 
    
    I would encourage you to go back and read "A pattern language" Page 463 to 466. That was penned 20 yrs prior to Utah, yet it definitely puts forth 'how to' achieve results in an iterative process. Its about the Architect guiding the process, it applies to software well. The point being, structural changes to ongoing processes is not a new concept. Agile process is to produce working software, not to modify the architecture. I was a little shocked at what was being presented.
    
    Mostly, what irritates me with the video is you do not point out - "If the agile processes is modifying the Significant Use Case, then an error was made. If the process is modifying the importance of a foundation construct, then a mistake was made". BOTH by the Architect! No matter, what agile states, we can not change the underlying foundation of a <analogy> sports car, it will never be truck. Perhaps if you spoke about understanding using agile processes for feature delivery and to make such features flexible, then that conveys a better understanding of how to achieve architecture with agile. Collaboration is almost the anti-pattern to architectural leadership. I have no idea where you guys are going with that concept :) 
    
    Lastly, "Change" is not Agile, its Architecture. (case in point, CMMI Iterative approaches) I just wish to express if flexibility and change (with increased cost and complexity) are architectural constructs expressed in a project, then "Modularization" is the answer. Not some new-fanggled labels used to further confuse those who are learning around us. (i.e. Gof4 Chapter 1. Favor composition over inheritance to lower those dependencies) That point there is... Agile gives us a process to wrap composition in to achieve working software. I wish you'd said that.
11. Is she in love with him, or what's going on?
12. very good talk. gave me a foundation on where to start. I've been a developer in my company for 3 years, now my boss pushing me to become an architect, do less coding and manage the group of developers. i didnt even know what actually an architect do until i watch this,haha
13. Thoughtworks has been slandering Software Architects and misrepresenting Architecture for years and the get-out-of-accountability card that they have successfully cashed in on has been the Agile gobbledygook.  Like the child who finds a hammer, everything looks like a nail and so Agile has become a hammer for far too many of these zealots to perpetuate their false propositions.
    This talk is as bizarre as it gets. Software developers are doing "architecture" but not really, it's "design", it's "planning", it's not a meeting its a collaboration, it's not a kickoff planning, it's this synonym or another.
    It's Archi-tardation is what it really is. To disparage architecture and then pretend all the notes, whiteboard artifacts, cue cards, index cards, stickies, pen to palm of hand notations are not a self-inflicted, dysfunctional (sad) attempt at backfilling the absence of rational architecture is tragic.  To imply that developers (bricklayers), spreadsheet gurus, or  are knowledgeable architects is delusional. Yes, you can get away with calling the worst-case development  huts, lean-tos, and spider holes architecture but I'm pretty sure that's not what the customer had in mind - YNRG2ATRU - You're not really going to argue that are you?.
14. If you're interested in more of my talks, take a look at http://martinfowler.com/videos.html
15. Enjoyed this talk? Watch our interview with Molly Dishman, and browse other keynotes and interviews from the O'Reilly Software Architecture Conference: https://www.youtube.com/watch?v=cNIVPsL2PMs&index=6&list=PL055Epbe6d5aFJdvWNtTeg_UEHZEHdInE