HomeНаука и техникаRelated VideosMore From: O'Reilly

Making Architecture Matter - Martin Fowler Keynote

1460 ratings | 99226 views
From OSCON 2015 in Portland: In the software world, architecture often gets a bad reputation. I’ll talk about why it matters, and how we can pay attention to it without falling into traps. About Martin Fowler: Martin Fowler is an author, speaker, consultant, and self-described general loudmouth on software development. He concentrates on designing enterprise software – looking at what makes a good design and which 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, which he considers a “really rather good” system delivery and consulting firm. He writes at martinfowler.com. Watch more from OSCON 2015: https://goo.gl/vD6vda Find out more about OSCON: http://oscon.com/open-source-2015 Don't miss an upload! Subscribe! http://goo.gl/szEauh 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
Html code for embedding videos on your blog
Text Comments (43)
Dzintars Klavins (1 month ago)
Totally agree!!!
Martin (2 months ago)
All this knowledge and still can't pick a shirt that fits him.
Kelvin Meeks (2 months ago)
First, let me say that I greatly admire Martin Fowler - and have told him so, in person, during a QCon in San Francisco some years ago - and that he is a great inspiration to my own personal growth in this field. But, I do have a few questions - that I think are worth considering as a counter-point to his views expressed in this talk - which I do not think quite adequately consider the matter: The implicit view that architects who do not code (as their primary activity, or no more) are of no value - and that the code is the essential truth of 'The Architecture' seems to me to be ignoring the following concerns: 1. While AS-IS may very well be expressed in code, to a great extent - what of the TO-BE, which may well need to be charted and communicated over a multi-year arc of intent, effort, and funding by the business - in coordination with dozens, hundreds, or thousands of third-party partners? 2. What of communicating an understanding of those aspects of the design, which may need to be shared and communicated with third-parties - such as in the case of major (and complex) integration efforts? Will you just give those (potential competitors) the code? 3. What of communicating an understanding of those aspects of the overall system - some of which may not be implemented in your code - and which may rely upon other systems for which you do not have access to the source code (or which may be hosted by Cloud SaaS providers)? 4. What of communicating an understanding of those aspects of the overall system - some of which may not be implemented in code - and which may be implemented as manual processes - but are still critical elements to understanding the true scope of the overall system? 5. What of the oversight and governance functions that should be tended to - as systems must be managed through a life-cycle - which must include a clear understanding of the architectural implications when sun-setting, replacement, or rationalization choices must be considered, researched, choices evaluated, recommendations prepared, etc. - are architects who spend their time coding - and not keeping a weather eye on these concerns - really making the best use of their time for the business they are serving? 6. Whether an architect codes (as their primary activity, or no more) - and whether there is value in an architect who no longer codes - seems to me to be primarily a question of scale. In a multi-billion dollar business - in which an architect may be responsible for the oversight of dozens of applications, within one or more given business lines (of which there may well be dozens) - they are typically required to closely monitor, align, and coordinate the architectural road maps that span multiple business lines - usually involving multiple organizational units, external third-party partners, and impacting potentially hundreds of applications - over multi-year staged delivery planning of capabilities. Is it really feasible (or optimal to the business) to have someone in such an architect role - being buried in the minutiae of coding? 7. Does the architect of a major commercial building, a skyscraper, a new aircraft, a bridge, or a new automobile design spend their time pouring foundations, laying bricks, running wiring through conduit, riveting sheet metal, on the assembly line, etc.? Would any professional architect worth their salt sneer at the very thought of being expected to document the design of such endeavors? Or would they simply say, pop the hood and disassemble the engine if you want to understand how it works? What of the systems that approach (or exceed) 1M+ lines of code - and which may exist in an ecosystem of a multitude of other systems that are of similar size and complexity? Is it feasible to require people to just read the code to understand one of those systems - or the potentially intricate interactions between them? Does your advice of 'just a few diagrams' still hold? For these reasons, we should be open to embracing - across a continuum of diversity of possible manifestations - the possible interpretations of the role of Software Architect (or even, Enterprise Architect) - and not be disparaging - and certainly not promote the use of such derisive terms as 'Architecture Astronaut'. Meeks' Software Architecture Conjecture #1: The source code may (or may not) be a full implementation of the desired capability needed by the business - but is more likely just an approximation (constrained by permitted time, allocated budget, and available skills/talent of the team involved). Therefore, it should not be confused with the actual or desired (or envisioned) design - that may require multiple years to achieve - of which the current source code may only reflect a partial (and incomplete, or inaccurate) representation
Anthony Cyrille (4 months ago)
Bringing Martin Fowler only to talk 15 minutes. Poor man. Excellent presentation as always :)
Ankush kushwaha (5 months ago)
Very nice and straight-forward talk about the value of software architecture
Nisim Joseph (8 months ago)
great lecture! as usual, thank you!
Bartosz P (9 months ago)
Regarding the first part: It's easy to disparage a definition by interpreting it with a negative attitude. The sarcastic shooting at it is of course an interesting and valuable part of this presentation. However the term "important", being the point of this rhetorical endeavor, is covered by the initial term - "fundamental" (or even almost synonymous in this context) ;)
FremenChica (1 year ago)
The moral is the practical.
George Obada (1 year ago)
One can appreciate the point of this presentation when one's sense of code smell is trained, functional and utilized. Those controlling the budget as well as developer leads should understand the design stamina hypothesis, so that the appropriate focus and priority is given to internal quality - otherwise pay a high price soon.
Jesús Gómez (1 year ago)
I don't think this talk ended well for Martin. He used weak arguments. A lot of fallacies, maybe on purpose as a tool for rhetoric, but too much. Maybe those few 10 minutes played against him. We all know his trajectory. I would love to see this same subject developed by him in a talk of a lot more than 10 minutes.
Would be helpful for all of us if your comment includes those weak arguments and lots of fallacies.
Bryon Lape (2 years ago)
Unfortunately, Linux cannot keep up with Windows.
How's that?
Kumar Anand (2 years ago)
Brilliant .....
Ivonne Aldana (2 years ago)
I really like Martin Fowler, I love reading the stuff he writes, however I do believe that architecture is very much important and that architects are very important not just for the reasons he says, I know that agile says that architecture must emerge in development teams but this will cause entropy if you are dealing with a large product or a kind of business that changes constantly, at some point it will all be chaotic, so I think that if a baseline is established (Architecture Description, Architecture Guidelines and standards) for a project, you'll be able to react to change but have it managed and you'll be able to continue to grow your software product, that's my personal opinion.
João Farias (2 months ago)
Two cases: "large product" -> Its complexity itself demands evolving design - the larger a product is, the less people knew about it at the beginning (at most people in the future point are likely to even be in the project at the start). "kind of business that changes constantly" -> In this env, a "established baseline" (in the past) is even less useful, for, again, we don't know basically nothing about the future.
Bill Westfall (2 years ago)
Starts out with a painful straw man argument, "I picture an architect like.." Ugh, get out and meet a few instead of making these statements
Bill Westfall (2 years ago)
+J R I'm not an architect but I'll take it as a compliment to be mistaken for one :) To your point, I think it reinforces my previous analogy. There is, in your description, a one out of six chance that any given architect will be looped into Fowler's description. But even less than that because there will be (and I know some of these folks personally so I know for fact) a percentage of folks in that silo who are highly agile already. So again, what is the point of the initial description but to point out a small percentage of folks who meet this criteria?
J R (2 years ago)
+Bill Westfall As I'm sure you know, in our industry there isn't really a "standard" definition of architecture or architects.  Broadly speaking you can break us down into "architects who are really system designers" and "architects who help businesses organize programs, projects, and plans to be fed into IT in an optimized way." (Enterprise Architects)  Fowler et al. say absolutely nothing about the latter.  The former however they do say some things about, but it shouldn't be causing architects to shit their pants, as it seems to for some unknown reason. I prefer to use the "IT-inward" focus that IBM Global Services used to promote which breaks architecture into 8 domains (Informational/Usability, Functional/Requirements/QA, Integration, Systems Management/Governance, Operational, Security, Data, and Application) as a useful tool to help calm people down.  What Fowler et al. are saying is that "Application Architecture" and to a lesser extent "Integration Architecture" don't need to be extensively planned ahead of time.  They're mostly silent about those other domains (although the DevOps/Continuous Delivery practice creeps into Systems Management and Operations), and so, presumably if you're an architect charged with managing the quality of those 8 domains, only a couple of them change for you, so, relax.  Agile isn't doing anything that should threaten you if you're adding value in those other 5 or 6 domains, and you can safely ignore Fowler et al. when they call a dev lead an "architect", because they're talking about an "Application / Integration Architect" and nothing more.  And yes, they have an opinion about how that kind of "architect" works, and it's directed at throughput management, which is a good thing -- the only artifact that ultimately matters to our customers at the end of the day is something they can log into and DO something with, so ignoring the throughput of how we build such things is a long overdue correction to our "revealed practices".
Bill Westfall (2 years ago)
+J R what's the subset? If I say "Someone with a particular skin color committed a crime once" , is it valid to create a process for that experience? If Fowler ran into an architect who didn't listen to him that's not really a reason to create a new process
J R (2 years ago)
It's NOT a straw man if it's accurate for a particular subset of a problem.  You simply believe that it's not applicable for your context.
Bill Westfall (2 years ago)
+J R a straw man argument is a logical fallacy irregardless of the speaker's background
Frank Krasicki (3 years ago)
Brutally bad in more ways than not. This guy and his associates have been disparaging Software Architects for years with the same glib generalizations and nonsensical arguments he makes in presentations such as this. This floundering narrative resembles an alcoholic whose had too much to drink attempting to walk a straight line. There is no single worthwhile definition of a Software Architect, the role is relative to the organization and the product. when the primary duty of a Software Architect is to code then the title is little more than an obfuscation for a lead developer and has very little to do with Software Architecture and more to do with code design. Why the obfuscation? Developers critical to the enterprise demand richer sounding titles - ego flattery. The developer can be a Software Architect or a Cyber Genius Butterfly for that matter Nor is Fowler correct that Software Architecture plans are wrong because Software Architects are divorced from changes during the coding process. The coding process is the translation of a process specification into executable software application. A well-defined process will not have coding surprises and the desired outcome must be the desired outcome or its defective. A Software Architect is not responsible for coding and issues with coding the process to spec though code can expose an architectural issue of substance that requires re-examining the specifications. It should also be noted that Software Architects who were developers ten years ago and could ride a bike can still perform both things assuming no extenuating circumstances, not that riding the bike or coding read, write, loop in a given language is paramount to Software Architecture. And when Fowler waves his hands and says, "Sure there's a document here or a diagram there" he makes it sound like these are delivered by the Tooth Fairy from above as opposed to the flatulent pearls of wisdom that bubble up from poor coding practice. Fowler profits from the rhetoric associating poor quality to the Software Architects while the noble agile developers are keepers of the secret wisdom - forever more knowledgeable than the author of the book they are entrusted to accurately translate because like a bad word correction application only they know that the sentences are being indiscriminately reconstructed. Herein lies why Fowler and cohorts believe coding is necessary For Software Architects. They think the magic Pixie Dust of coding will either alert the Architects that the development process is flawed or make the Architects complicit in those defects. He can't imagine that a well-constructed postmortem could examine the quality of the code produced during the sprint or development cycle. Fowler should spend less time coding (just kidding - he hasn't coded in ten years (my guess)) and more time working with Software Architects. Just follow the Yellow Brick Road to the Ivory Tower.
Alec Whitehouse (10 months ago)
A pissing match that will never be resolved.
KhanSlayer (1 year ago)
+Frank Krasicki Good points about the definition of an architect being relative to the organization and the product. Although I agree with virtually everything Martin said in this presentation, you're right in that his critique applied to my situation; one in which we use to utilize "dictator engineers" that set standards and had a tough time understanding the new coding practices we we're using due to them being so distant from the codebase. But to your other point I've definitely seen the "emergent/organic" design approach that had no initial blue prints, no architects, and the codebase ended up much bigger than it needed to be and error prone, where an official "Architect and design structure" would have helped. Context seems to validate and invalidate all philosophies.
Jeremy Anderson (2 years ago)
Thank you for taking the time to make your position more clear. I don't feel it is quite as stark a contrast as you indicate, but I understand why you might feel the way you do, and I appreciate your contribution. The "Refactoring" book alone is enough of a contribution (despite having a price tag) for me to have respect for him, and GoCD is a pretty decent tool that Thoughtworks released under free Open Source product a couple years back, so I simply don't see it in the absolute terms you've described. Nonetheless, I appreciate your thoughtful and passionate criticism. Thanks again.
Frank Krasicki (2 years ago)
Fowler is a technician - he makes his money from developers. His "contributions" aren't free and they often require a closed, self-fulfilling ecosystem in which to thrive. Thoughtworks is a cash cow. Anyone practicing outside that universe is dismissed. Now, I'm not angry, I just think taking their best ideas id worthwhile and ignoring and pointing out the stench of their bad ideas is also a "contribution".
Frank Krasicki (2 years ago)
For the architect, code is not the source of truth. Code is expected to match specification and is tested to that end. The source of truth for an architect can be a multiplicity of things including the veracity of those specifications, the quality of components and so on. Obsessing about code as reality is like obsessing about molecules instead of the nature around you. Furthermore, knowing how to code doesn't make you a superior coder or one who writes bugless code. Why depend on an architect to code when developers get paid to do that?
Gerry Lowry (3 years ago)
To focus on internal quality is to break (refactor) the paradigm usurped from architecture as the lay person knows it. One might design a vertical slum low-income housing project that can shrug off a Richter 9.0 earthquake and can be maintained for the lowest cost of its class BUT is an eyesore to passers by and a depressing environment for the tenants. Architecture in terms of software must fulfil many criteria, first and foremost being that it meets the needs of its consumers, i.e., the end users; these needs include ease of use and the ability to be productive. Example:  web based forms of any degree of complexity when compared to desktop based equivalents tend to be limited with regards to using the keyboard to enter data quickly. FWIW, the badness of software architecture is likely to be inversely proportional to the extent to which the end users were involved in the creation of the end product.
Promo ST (2 years ago)
Woo.... very inspiring video http://jasa-desain-interior.com/
Frank Krasicki (3 years ago)
+Gerry Lowry The scope of Software Architectural problems exist in a multiplicity of technical layers and combinations thereof as well as within governance and methodological approaches. Unlike dwelling Architecture, Software architecture these days involves ecosystems and a far broader range of issues than simple user satisfaction. A recent Twitter post produced a very interesting observation that a substantial number of American marriages were the direct result of a computer matching service. It went on to say that this means that computers are modeling the next generation of humans assuming these marriages produce offspring. Likewise Software Architects are as responsible for creating the end user as satisfying an existing end user. Furthermore the architecture dictates the quality of individuals required to extend and maintain the ecosystem. All of this is non-trivial stuff, not the kind of thing you drop to fix someone's deep code bug.
Martin Fowler (3 years ago)
+Gerry Lowry I agree that "architecture" is an inappropriate metaphor (see http://martinfowler.com/bliki/BuildingArchitect.html)
UGP (3 years ago)
of course code is important, that's why you want to _stay away_ from architects as much as possible. What software is Martin actually known for?
Shreyas Kulkarni (6 months ago)
Ofcourse energy is important, that's why you want to stay away from scientists as much as possible, and just pump more oil. How much energy Einstein has generated himself?
UGP (3 years ago)
+woodsmailbox1 Martin, show us your code.
Ranjana Gupta (3 years ago)
Brilliant....Key takeaway is the pay less now for poor architecture and then end up paying more over long run for a poorly architected product
J R (2 years ago)
+Ranjana Gupta No, key takeaway SHOULD be, whenever you have a temptation to say "Ooooh, that's a difficult thing to change, let's make sure an architect agrees with it" you should instead say "Ooooh, that's a difficult thing to change, is there some way to make it NOT a difficult thing to change?" The answer is "Yes there is", about 80% of the time. Hence the reason he's advocating for the democratization of app design architecture into the team.

Would you like to comment?

Join YouTube for a free account, or sign in if you are already a member.