Making Architecture Matter - Martin Fowler Keynote

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: goo.gl/vD6vda
Find out more about OSCON: oscon.com/open-source-2015
Don't miss an upload! Subscribe! goo.gl/szEauh
Stay Connected to O'Reilly Media by Email - goo.gl/YZSWbO
Follow O'Reilly Media:
plus.google.com/+oreillymedia
/ oreilly
/ oreillymedia

[@armorsmith43]

I love that he was able to give an important lesson on the “How?” of software architecture at the very end: delegate decisions to those with the time to focus on them.

[@thelonearchitect]

Bringing Martin Fowler only to talk 15 minutes. Poor man. Excellent presentation as always :)

[@Equilibrier]

I think this is a sign of a genius: he can make more value from a 15 mins presentation than others in hours of presentation. And for me at least, it's very good, as I can listen to a super condensed info and inspiration giving speech, for just 15 mins. It's a real condensed experience he is giving free in here !

[@catgirl8202]

CSCI 4/5448 OOAD Quiz 9: Right answers: One part of an application is good modular design, which is internal quality, not visible to users Architecture is… The decisions that you wish you could get right early One part of an application is a pleasant UI, which is a measure of external quality and is visible to users

[@shrutitanwar1114]

Having read couple of books by Martin Fowler, but seeing him for the first time here, don't know why it surprised me to find what a great speaker he is. So articulative and smart!

[@tibordigana2551]

All managers should see this video before they would crash their company.

[@Nemcoification]

He makes the best case for why this stuff matters.

[@Ankushkushwahachd]

Very nice and straight-forward talk about the value of software architecture

[@lematindesmagiciens8764]

For me, architecture is the distribution of complexity in a system. And also, how subsystems communicate with each other.

[@georgeobada7531]

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.

[@vimalneha]

I love his enormous skill.

[@vaporizer08]

He is already a legend.

[@baggiowong1332]

It's amazing when you rewind the talk at 1.5 the normal speed and still hear the conference speaker hit home with razor sharp precision and clarity. Well said!!

[@AliRazaSaleem-dl9xg]

Haha same experience

[@ManojTyagi2006]

Very useful explanation about architecture. Amazing thoughts by Martin as always.

[@wh264]

Software Architecture + Ask what things are hard to change later on + The "Important Stuff" - what is the most important thing about code base I have to be mindful about, each time I'm working on this + Good software architecture is a long term ECONOMIC investment. New features being added later on can take longer and longer, which will put our customers at a disadvantage + Good architecture can keep our customers competitive because we can create new features later on that takes WEEKS instead of MONTHS, which happens in a badly architected project

[@kaypakaipa8559]

Powerful points delivered in a clean way for mere mortals like myself.

[@Equilibrier]

A super smart man. It's a pleasure to listen to him. Ok, he's a huge weight in software developing, but as a man it's a pleasure to listen.

[@maverickmusic101]

Only 275,435 people got lucky to stumble upon this wonderful video. Thanks OReilly for sharing this video !!

[@Marius-vw9hp]

Just found out about Martin, and I must say he is a very good speaker.

[@Hasi29347]

You should also check his website, lots of good articles there

[@Oswee]

Totally agree!!!

[@kaypakaipa8559]

Jesus, this is amazing. These old guys do speak wisdom.

[@christian.mar.garcia]

Fantastic talk.

[@maopuerta3430]

Mis respetos para el señor Fowler

[@elizabethakpan979]

This is such an engaging presentation!

[@AI-xi4jk]

These shirt 👚 pockets are designed to hold 3.5” hard drives each. Love it.

[@joaopedrogoncalves3783]

Monstro sagrado! Always brilliant and elegant.

[@TheFremenChick]

The moral is the practical.

[@firasabughazaleh5512]

I would really like to see a commercial measure or a sort of customer-facing indicator that can help: 1. Vouch towards actually preferring to buy the $100-more software get more preference over the other 2. Promotes good architecture practices among software teams and organizations towards creating better quality products/features knowing that their products will be profitable given their hard work and future vision My 2cents!

[@jonathanmantello3974]

Great talk.

[@sayalijoshi2731]

great talk

[@rameshchandran]

Very nice presentation... 👍

[@3nikki]

I once worked for a company that built an entire data staging layer just for their project because they had no confidence in the enterprise staging layer. The decision reverberated for months during status update meetings to explain delays, challenges, etc. Internal quality matters! Architects should not be treated like pariahs by project teams.

[@pietrotavares1731]

The Design Stamina Hypothesis reminds me of the Change-Cost Curve to an extent which I, myself, frankly can't spot the precise difference between them. I do see, however, that whenever some "thing" has more than one name.. then that thing must be pretty darn important. Nonetheless, the presentation was astoundingly informative for it's shortness of time. Who'd expect less than that from this man, anyways?

[@yellowrice8633]

OK where is the how part? I need it...

[@saeidbabaei7897]

Good explanation

[@bartoszp817]

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) ;)

[@mehdimohammadi1623]

I really did not get what do you mean. Could you please rephrase it.

[@nisimjoseph]

great lecture! as usual, thank you!

[@canayavargas6805]

Hola! Me interesó este tema, no soy buena con el inglés, tendrán alguna canal en español?

[@kumaranand1924]

Brilliant .....

[@socrattt]

I like seeing that some programmers know something. Apparently, you need to be old enough and experienced.

[@ahmedalhallag3338]

I can't believe someone like the great Martin Fowler is given only 15 mins to talk ..

[@rambo4014]

Unfortunately even today people think that architecture and code are mutually exclusive

[@wcuribe]

1:44 an architect should be programming.

[@ivonnealdanal]

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.

[@rothbardfreedom]

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.

[@tibordigana2551]

>>at some point it will all be chaotic This really happens in my current company with ala agile dev but big company, which is why I tried to convince the company that technical architect is a must to have.

[@RawPeds]

I usually think, if software architecture is yet so difficult to define, software engineering has to be still in its early days. Can't make much progress without solid fundamentals.

[@noeangelodelafuente8640]

Statement Is Right Okay

[@eldathray9703]

ah, is there related slide...? like the talk so much ;-)

[@123TeeMee]

While good quality code does feel right, I'd like to see a more in depth case study on how modularity and other improvements have actually increased long term value for some code, and some insight into where exactly the limits lie between economical quality and excessive code improvement, and an example of an acceptable mix of standards compared to an example of having toomany individual standards stuffed in that make code too complex, or standards that didn't work on the project at hand

[@KelvinMeeks]

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

[@hemant-sathe]

What he really talking about is software architecture. I have worked at different levels of architecture including Enterprise Architecture and in that parlance the value of an application is that of one of the components. Enterprises work on business capability as integration of multiple applications, systems and not a single application. What Martin is talking about is about something that can be considered as an application or a single system. However, the concept of quality in architecture is much more applicable across and choice of technology, COTS products do determine the ability to deliver features as well. For an enterprise architect, may be Visio Diagrams or any similar set of artifacts can be called as code. There also having good engineering practices and prescribing components to allow loose coupling, well defined scope for the components etc. are important. My understanding is that there are different levels of architecture and what Martin is talking about may not be directly applicable just because he is talking from code perspective. But you should consider the principles involved and see if they can be applied at higher altitude. The ambiguity about definition of architecture is still there. The dynamic nature of business requirements is there. The shared understanding across the application teams, networking and IT support teams and enterprise architects is what will finally be called as architecture. So at lower altitude, the architects must understand coding, at higher level, they need to understand integration technologies, networking, infrastructure etc. If an enterprise architect doesn't understand the nature of cloud computing and underlying technical stack, he is likely to design the systems wrong.

[@PetrGladkikh]

For any long-standing effort build shared understanding that Martin talks about here. And yes that means talking, shuffling ideas with people implementing stuff, overseeing actual progress, and, yes, chatting again. People do not read documentation, neither they have mind readers (and I would avoid those who have, because normally these devices are faulty ones). What about greener pastures, bus factor, family matters, burnout? If everything in a major effort relies on single person, and requires years to take effect, that is not going to happen. In my experience business code is usually worthless outside of organization's context, one might want to keep it secret for security reasons though. So, no, give third parties specs instead, and setup integration testing procedures. I'd prefer specs that can potentially be made executable, e.g. OpenAPI, test cases - writing those also might count as coding. No one has said that you should not write documentation at all (just keep it concise, and ensure people read it). No one has said that primary activity should be coding. But it is arrogant to dismiss some facet of a project as not deserving attention beforehand. One does not know in advance which areas may require most attention (and that might be the coding). If we are talking of "hundreds of applications", and one is a lone architect in an org with 1200 developers, then yes, architect might not have much time to dig details. But this is an extreme case that's true for, say, 0.1% percent of cases so is irrelevant for effectively everyone. On the other hand the talk above is a must-see for everyone developing software. No, and neither should software architect because you have "build system" (Maven, CMake, whatever) in your project to pour concrete. As an architect, one should have hands on experience with your code, not necessarily write lots of it. That is the only cure from becoming "architecture astronaut" and inevitably ruining the project by unnecessary complexity. There is no way to know your ideas are fleshed out as you expect, that you are not misunderstood if you do not look at the code. Thinking that writing lots of documentation gets one there is delusional - and I would not trust an architect if they do not know that already. How can one speak with developers the language they understand without looking at actual code? On and on and on. Good development pace facilitates everything else, so, yes it is worthwhile to spend some time coding. E.g. if it takes hours to setup project, make small changes and release then then you know first hand that this is an area for improvement. Your conjecture is true, indeed.

[@mikefenn2451]

7:55 The moral responsibility of creating high quality systems vs economics

[@lordoftherings6591]

Guys - pin that talk on the history calendar 👏👌👍

[@GerryLowry]

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.

[@martinfowlercom]

Gerry Lowry I agree that "architecture" is an inappropriate metaphor (see martinfowler.com/bliki/BuildingArchitect.html)

[@FrankKrasicki]

+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.

[@promost4024]

Woo.... very inspiring video jasa-desain-interior.com/

[@andik70]

11:55 the important decision is, if the features on the right of the intersection point are ever needed (yagni...)

[@endofgreen145]

andik70 you wouldn’t put so much time, sweat and effort into building a feature that nobody ordered.

[@ruixue6955]

7:55 why

[@lepidoptera9337]

Architecture is when you think for ten minutes before you start chopping. Most people just then have that kind of patience when they see an axe and a tree.

[@edgeeffect]

Martin.... you're from considerably further east than The East Coast! ;)

[@adnanhashem98]

After ~7 minutes Fowler defines software architecture as "the important stuff" and then goes ahead to "argue" why should we care about "software architecture". This clip is a good exercise for students studying logical fallacies 🤣

[@szlaci8383]

Good talk, on the other hand problem comes when you try to over engineer a simple program for 1 specific task which needs 10 lines of code with all your reusable and modular handler, orchestrator etc modules....

[@JonesDTaylor]

yeah this is mainly for commercial applications, not your side project from school :)

[@azatakhunov6061]

👍👍👍

[@alxkub]

That intersection point may never happen. Project may die long before that.

[@blueberret]

I respectfully disagree. A house however badly architected might work - but be a pain the backside for people living in it. A common understanding of how things work might constitute what is the current architecture which might or might not be good. From my point of view a good architecture, is something that makes it easy to use, easy to extend, easy to maintain and make the developer's life easy as well (again extend/maintain). An Architect needs to know the what need to go where and the flow of things. - if he/she get's that wrong, then it will be a really pain to maintain and make changes to it.

[@Rtzoor]

why is it hard to always show the presentation??!?!?!?! ALWAYS SHOW THE PRESENTATION

[@classical-bit]

[@SemiMono]

That definition of architecture assumes that the designers always understand their product's architecture. I like the IEEE definition, taken with a warning that NO ONE will EVER know the architecture of a sufficiently complex system, similar to a sufficiently complex system NEVER being bug-free. The only way to have good architects is if they realize they are never right, just like any truly good software developer accepts that their code will always have bugs. If you declare there is no objectively correct definition possible for a given snapshot of a software system, you stop trying to improve the accuracy of your understanding. It's there, you'll just never find it. It's disappointing, but it's ok. Keep calm and carry on.

[@SemiMono]

All of the above said, I absolutely agree with him on the importance of architecture.

[@paull373]

IMHO If your system's 'architecture' is so complicated 'that no one will ever' know it, it is - by definition - bad architecture.

[@thecloudtherapist]

I'm sorry but which part of this presentation was revelatory?

[@DasSuper]

Revelatory is a silly word - stop it.

[@dr.Ali.Aburas]

I hate the camera man as much as I like the talk. S/he kept foucsing on Martin and left the slides out.

[@Filip-ci3ng]

Are you not aware what the word architect means ? It’s a designer of the whole thing on high level, not a boring admin control as you describe it

[@alimahdi6379]

With respect to Martin Fowler but you can't mix design and architecture. At 10:40 he talks about the Design Stamina Hypothesis but that hardly has anything to do with architecture. Architecture is concerned more with scaling and size and less with quality and speed of development.

[@okerror1451]

A group of people's common understanding of how a thing works, is absolutely not "the architecture". I present my counter case: Flat-earth "architecture".

[@guptaranjana76]

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

[@Calphool222]

+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.

[@postblitz]

pubg vs fortnite in a nutshell.

[@BryonLape]

Unfortunately, Linux cannot keep up with Windows.

[@migueljimenezZ]

How's that?

[@JesusGomezOrtiz]

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.

[@migueljimenezZ]

Would be helpful for all of us if your comment includes those weak arguments and lots of fallacies.

[@UGPepe]

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?

[@UGPepe]

woodsmailbox1 Martin, show us your code.

[@shreyas.kulkarni]

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?

[@SirvanAlmasi]

Very confusing presentation. Choosing good quality engineering is not a morality question (very lazy method of communication). Everything is always built to a specification; now cutting corners within that specification is then quality of execution choice.

[@shimtest]

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

[@Calphool222]

+Bill Westfall Fowler knows exactly what he's talking about, and he is using the words he uses on purpose. He's not a dumb man.

[@shimtest]

+J R a straw man argument is a logical fallacy irregardless of the speaker's background

[@Calphool222]

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.

[@shimtest]

+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

[@Calphool222]

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".

[@FrankKrasicki]

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.

[@Calphool222]

+Frank Krasicki Somebody need to go learn more about Lean (Theory of Constraints, Six Sigma, Agile, Systems Thinking, etc.) What Fowler's saying (and I agree with him on this) is that everything that goes into producing a software system needs to be incorporated into the FLOW of building the system and SERVE that purpose. Architecture divorced from the reality of writing code does not generally produce a system design that SERVES the purpose of delivering working software. It serves some other purpose (simply feeding the egos of senior staff in the worst cases). Ignorance of bottlenecks, or over optimizing without regard to throughput bottlenecks slows down software development (or really any production process as Goldratt demonstrated in "The Goal"). What he and the other Agile signatories are advocating is the reduction of specialization in software development, because specialization inherently creates bottlenecks. So yes, they've reduced the definition of architecture to be "system design", and then they've advocated for democratizing that definition as much as possible. This is not a "wrong headed" goal, but it might be more-or-less applicable to a given context. For example, let us say that you work in an organization in which architects are more like enterprise-architects. These people might help a business unit take ideas they value and orchestrate them into a series of projects and programs that maximize business value at the macro-level. That's not the kind of architect Fowler et al. are talking about. They're basically silent on that kind of architect, because in effect that's a business-side strategy role. It's not a software related role at all, and they're only concerned with maximizing the value throughput of software engineering -- once those kinds of decisions are already made. Fowler and the other signatories aren't being deceptive, it's just that what they're advocating may or may not apply well to your organization, depending on the relationship between your architects and your business units.

[@FrankKrasicki]

+J R FYI, I've been a Lean advocate and Software Architect for many, many years now so please stop the dismissive rhetoric. What Fowler says is what Fowler sells. That is the idea that Software Architects (the whole range of titles and roles) are the problem with building software therefore they are consequently responsible for systems costs and failures largely because... wait for it... they (presumably) aren't in the trenches writing code. What his paying audience ((victims all) who are underpaid, under-appreciated, and ever-so-wise) hear is that THEY could be, would be and should be in charge to make it all better (e.g., the crab mentality (en.wikipedia.org/wiki/Crab_mentality). On your part, to assume or characterize the role of Software Architect is a matter of ego or, worse, senior most vicious developer (I'm talking to you, George and Phil) is just part of the Thoughtworks playbook. And business has been good. The agile crowd has been relabeling common problems and solutions for years all the while lining their pockets and doing little to improve the development process itself. Real progress comes from the abstraction of systems not the sing-song generalizations. As a contractor I have worked in real environments and seen first hand the wake of agile and lean adoptions. It ain't pretty and there is nowhere that can afford to eliminate the need for abstract tinkers in favor of religious zealots. In fact some of the most costly and unforgivable tragic environments have promoted programmers as their architects and create intellectually leaking, directionless organizations whose chances of sustainability are less than zero. The mantra that Architects "must know how to code" is odd given the roles and responsibilities Architects assume. Why is coding of paramount importance? Can't developers do the coding? When I think of things an Architect "must know", there is a litany of things far more important than coding and many of those things require personal abilities that very few coders possess (eg, abstract thinking, communication skills, good writing skills, visual organization skills, vision, and so on). Yet kicking Architects in the groin about coding is THE ONLY thing that is repeated ad nausea by Fowler and his fine feathered friends. So if what you and Fowler are saying is that a Software Architect isn't the program manager role who is a person who knows some coding lingo and ramrods the project for personal ambition then I agree with both of you. That's NOT a Software Architect's role, not a program management role, but a Technical Lead role (note the "Technical" qualifier to "Lead" - lead what? - Developers.

[@Calphool222]

Frank Krasicki I'm not being dismissive. I've been an architect for 22 years in a Fortune 100 company where we transformed our entire app dev practice to agile over a 10 year period -- over 1000 developers, testers, and analysts, so I'm not going to just agree with a grizzled consultant who has been unfortunate to never see agile work at scale. Try going to one of the companies near the bottom of the Fortune 100 headquartered in Columbus Ohio. You'll find a very interesting example of how it all works quite well at scale. I suspect you know that there is no "received definition" of architecture or architects, much less things like "Technical Leads". Every consulting company has their own flavor of where the boundaries are and thinks their method is the best. At least the agilists are collaborating across industry.... and as far as "religion" goes, most religions don't last long if they don't solve a problem... this one must be solving a problem -- its origins go back into the 1980s. What the agilists are doing is starting from the bottom and working up. They're basically saying that the "architect" in their mind is a system designer, and just like everybody else who contributes to the end product, they need to be focused *heavily* on delivery. Abstract thinking is great -- but it can't be tied to things with money and delivery deadlines. It's too unpredictable. So the alternative is to look for ways to make it less painful when you have less of it -- make as much as you can reversible. Anything that's not reversible is a candidate for making it so. It's Toyota Production System thinking applied to software construction (p.249, The Modern Theory of the Toyota Production System). It's an attack on entropy in software production, and like it or not "abstract thinking" that doesn't go into production is entropy -- it's stuff the customer paid for which he received no usable benefit from. We can dance around and say "we learned what NOT to do", but we all know our customers aren't paying for that. Our industry is rife with this failed delivery problem -- enough so that the agilists could gain traction at least. They're still figuring out how to best integrate architectural thinking into value stream flows, and they've started with the parts that are most applicable to what they're concerned with -- application and integration architecture. Fowler calls it "design", but obviously (to those of us who've been architects for a while) there's more to it than that. He and others aren't quite there yet. It's not surprising to me at all that they haven't figured out how to integrate the other architecture domains yet, but I wouldn't bet against them. These are some very smart people, and they've already upturned our industry, for the better in my opinion. I disagree that they're selling snake oil. I've seen dramatic benefits and cost reductions at scale.

[@JeremyAndersonBoise]

Ultimately, in a software product, there is one single point of truth, and that is the source code. This supports his claim that some non-coding architects can become divorced from the reality of what is produced by the developers if they are not familiar with the source itself, does it not?

[@JeremyAndersonBoise]

+Frank Krasicki I think you must have a personal bias that makes you so bent with Fowler, he has certainly contributed more to the evolution of software development writ large than I have, what about you? I'm going to guess you are a competing consultant who lost a client to Thoughtworks. I don't agree with everything the man says, but given your disrespect for him, I have to ask; you mad bro?