{"id":13829,"date":"2021-09-03T19:35:29","date_gmt":"2021-09-03T17:35:29","guid":{"rendered":"https:\/\/conferences.isaqb.org\/software-architecture-gathering\/?p=13829"},"modified":"2025-04-25T15:07:56","modified_gmt":"2025-04-25T13:07:56","slug":"blog-neal-ford","status":"publish","type":"post","link":"https:\/\/conferences.isaqb.org\/software-architecture-gathering\/blog-neal-ford\/","title":{"rendered":"Past, Present and Future of Software Architecture – Interview With Neal Ford"},"content":{"rendered":"\t\t
\n\t\t\t\t
\n\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t\t\t

Blog<\/h2>\n\t\t\t\t\t\t\t\t\t\t\t\t

iSAQB Software Architecture Gathering<\/p>\n\t\t\t\t\t\t\t\t\t\t<\/div>\n\t\t\t<\/section>\n\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t

\n\t\t\t\t\t\t
\n\t\t\t\t\t
\n\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\n\t\t\t\t\t\t\t\"Neal\t\t\t\t\t\t\t\t<\/a>\n\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t
Neal Ford<\/a><\/h6>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t
Director \/ Architect \/ Meme Wrangler @ ThoughtWorks<\/a><\/h6>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t
Published On<\/a><\/h6>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t
September 3, 2021<\/a><\/h6>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t
\n\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t

Past, Present and Future of Software Architecture - Interview With Neal Ford<\/h2>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

You refer to yourself as “meme wrangler.” What special activities and obligations do you associate with this role?<\/strong><\/p>

Neal Ford:<\/strong> For better or worse, ThoughtWorks allows people to choose their own titles for business cards, the only caveat being that you only get one set, meaning you have to live with your choice until you run out of that set, then you can get more. My first set of business cards at ThoughtWorks had my title as \u201cApplication Architect\u201d, which was what I was hired as. But I came to dislike that title for two reasons: first, at the time, \u201carchitect\u201d was a dirty word amongst many developers at ThoughtWorks, because of the second reason I\u2019ll posit in a bit. When I met someone in the hallway, he congenially asked my name and what I was hired for, to which I replied \u201cArchitect\u201d, which caused him to snort \u201cWe don\u2019t have Architects at ThoughtWorks\u201d and walk away. The second reason I came to dislike that title was because, over time, I came to realize that, in many organizations, \u201cApplication Architect\u201d actually means \u201cPost Useful\u201d – spends more time in Visio than an IDE.<\/p>

I wanted to more closely reflect what my job was becoming in my second set of business cards, so I chose the very abstract \u201cMeme Wrangler\u201d. From Wikipedia:<\/p>

A meme is a unit of social information. It is a relatively newly coined term and identifies ideas or beliefs that are transmitted from one person or group of people to another. The concept comes from an analogy: as genes transmit biological information, memes can be said to transmit idea and belief information.<\/i><\/p>

So, as genes are to DNA, memes are to thoughts.<\/p>

I love the meme meme, so I originally chose \u201cMeme Herder\u201d, and offered that to a mailing list I\u2019m on as a potential new title. Prag Dave Thomas, who\u2019s also on the same mailing list, suggested the much better \u201cWrangler\u201d, which is more visceral and has more layered meanings. \u201cWrangler\u201d has two meanings:<\/p>

a person in charge of horses or other livestock on a ranch. a person engaging in a lengthy and complicated quarrel or dispute.<\/em><\/p>

Both of which sound about right.<\/p>

A Meme Wrangler<\/em>: someone who herds ideas into thoughts, generally through lengthy and complicated discussions (not so much quarrels as \u201cimpassioned conversations\u201d). I once had a project manager complain to me, the Tech Lead, which is the true title at ThoughtWorks for someone who has architectural responsibilities, that the frequent arguments amongst the developers were annoying\/frightening the other people on the project. I asked \u201cWhat arguments? All I hear are impassioned conversations, which are like arguments, but with passion instead of anger\u201d).<\/p>

However cool the Meme Wrangler title is, it elicits one of two responses when I give people business cards: either \u201cOh, cool\u201d or \u201cWhat does this mean?\u201d<\/p>

So, as a Grand Compromise, in my most recent set of business cards, it lists my title as Software Architect \/ Meme Wrangler, which is probably as close to describing what I do as any short title can.<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t

\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

On your web page <\/a><\/em>you motivate your workshop and your upcoming book with the questions, \u201cHow do architects make decisions if no \u2018best practices\u2018 exist and no one has ever solved this problem before?\u201c Can your workshop be understood as a kind of \u201cmeta best practice” that helps to deal with this exact situation?<\/strong><\/p>

Neal Ford:<\/strong> Our workshop isn’t about canned solutions to problems, but rather how to do trade-off analysis for software architecture problems. We use some common problems in modern architectures to illustrate the process \u2013 namely, how to discover the best granularity and communication style for a microservices architecture \u2013 but the class is ultimately about how to apply our approach to solving problems in the real world. We teach architects how to objectively analyze problems so that they can find the least-worst set of trade-offs.<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t

\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

You propose evolutionary architecture to be guided by fitness functions. What do you think are some particularly good, useful, or helpful fitness functions you’ve encountered in your projects that might be worth considering in architectural design in general?<\/strong><\/p>

Neal Ford:<\/strong> One of the confusing aspects of fitness function as a verification mechanism is that developers have become accustomed to single tools to handle jobs. For example, for unit testing, find a unit testing library for this platform. However, architects must govern a wide variety of things, necessitating a wide variety of fitness function tools. Operational non-functional requirements such as performance and scalability should be governed by monitors, whereas structural quality requires code-level metrics tools for a particular platform. Fitness functions become useful because they force architects to create objective definitions for important characteristics. The answer to which is “particularly good, useful, or helpful” depend entirely on value added for a particular organization and\/or project. For example, if an automated security fitness function had prevented the zero-day exploit of Struts at Equifax back in 2017, the company would have avoided a billion dollars worth of litigation\u2013that seems like good value to me! Architects shouldn’t try to over specify, but rather find the ones that protect critically valuable architecture characteristics, and maintain them to provide automated governance.<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t

\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

IT education tends to teach the development of new systems, but in practice most of the work is done on existing systems. Do you have any ideas or suggestions on how to fill this gap? What do you think a good training program for architects should look like?<\/strong><\/p>

Neal Ford:<\/strong> Teaching a subject like software architecture only goes so far, then apprenticeship or something similar should kick in. Software architectures are too different, and we don’t the formal rigor of other engineering disciplines to allow objective analysis to the degree of more established engineering disciplines. Software architecture still relies on experience to make good trade-off analysis decisions, which is hard to teach.<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t

\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

AI tools such as OpenAI Codex, which powers GitHub Copilot, can help developers write code. What do you think about this trend and what impact does it have on the work of software architects? Could you imagine AI support for architectural design in the near future?<\/strong><\/p>

Neal Ford:<\/strong> It’s likely foolish to try to predict what AI won’t enable or supplant in the coming future :). However, coding ,especially on the scale of methods and classes, has pretty well established rules about what bad looks like\u2013overly long methods, use of too much global state, etc. However, we don’t have as firm a set of rules in software architecture, and architects find it more difficult to build rules that apply to something as big as architecture. Software architecture isn’t just a few decisions aggregated, it may be hundreds or thousands, each of which change the outcome. Like many fields, pattern matching and other aspects of AI and machine learning can assist architects to understand complex code bases or interactions, but I suspect the serious trade-off analysis will still be people for some time to come.

<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t

\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

Today, hardly anything works without the cloud. What future paradigm shifts for software architecture will be driven by this?<\/strong><\/p>

Neal Ford:<\/strong> This statement is true in any of the last 3 decades, where you can replace “cloud” with “X”, for many values of “X”. The point isn’t to believe that the cloud is the end state, but rather realize that we live and work in an extremely dynamic equilibrium. The software development ecosystem constantly iterates, as new capabilities appear and clever architects figure out ways to combine those capabilities to make new things. Think about what the software development ecosystem looked like 5 years ago\u2013you didn’t even know what a Kubernetes was!\u2013and then try to project 5 years into the future: no one has a working crystal ball. If the past couple of decades has taught us anything, it’s to build evolution into our architecture rather than try to predict the future. If we can adapt to the future, we don’t have to predict it. This goes back to good engineering practices and realizing there is no end state.

<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/section>\n\t\t\t\t

\n\t\t\t\t\t\t
\n\t\t\t\t\t
\n\t\t\t
\n\t\t\t\t\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t
\n\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t
Workshops by Neal Ford:<\/div>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t

Part 1 \/ Day 1 - Software Architecture: The Hard Parts<\/a><\/h3>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t

Part 2 \/ Day 2 - Software Architecture: The Hard Parts<\/a><\/h3>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/section>\n\t\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t\t
\n\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t
\n\t\t\t\t\t\n\t\t\t\t\t\t\n\t\t\t\t\t\t\t\t\tReturn to Blog Home Page<\/span>\n\t\t\t\t\t<\/span>\n\t\t\t\t\t<\/a>\n\t\t\t\t<\/div>\n\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/section>\n\t\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t\t
\n\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t
Stay up-to-date with the SAG newsletter<\/h5>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t
\n\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t
\n
\n
\n \n \n \n
<\/div>\n \n <\/div>\n<\/form>\n<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/section>\n\t\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t\t
\n\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t
Stay up-to-date with the SAG newsletter<\/h5>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t
\n\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\n
\n \n