The Evolutionary Architect

In the midst of tackling this guy:


I can’t even begin to express how encouraging and refreshing it is to have so many of my thoughts and concerns finally captured into written word and gaining momentum.  Things like domain boundaries, and the fact that data duplication is OK if done in the name of scalability and development team autonomy.

Not that I’m anywhere near Sam Newman’s experience and knowledge, mind you.  But my posts are fairly clear when it comes to my philosophy of design.  The database is not king, sharing a monolithic schema can and will kill your ability to scale in ALL of the following areas: product feature change, team delivery speed, reliability of the software, and uptake of new development talent.

“A good software design is easier to change than a bad software design.” – “Pragmatic” Dave Thomas.

(his blog)

One thing I truly admire about this book is Sam’s pragmatism.  He’s not trying to sell you microservices, he moreso does a thorough pro-con analysis.  The people that should appreciate this most are, indeed, software architects.

In chapter 2, The Evolutionary Architect, Sam goes through and does a deeper dive on what it means to be an architect, how we as a software development community have misunderstood the word over the years, and how a true definition is still up for grabs.  Honestly, I completely agree with him.  “Back in the day”, when I worked for Global Quality at a Fortune 500, I had the opportunity of a lifetime to study Six Sigma methodology with a true master of the craft.  This person not only knew the ins and outs of the methodology and the process, but they were responsible for managing a large global team.  It was under this person that I learned, by example, how an evolutionary leader can be both a master of a specific process, but also step back into a management role and empower their team to execute that process.  As team members (and myself as a junior member at the time), we can and will fail.  It is the architect’s (indeed – any manager) role to mitigate that failure, and manage the complexity involved.

It is an architect’s role to manage the complexity of a software product, not to increase it.

Unfortunately, since leaving that particular company, I have yet to meet another leader anywhere close to that magnitude of employee empowerment, mentorship, and expertise in both the “product” and the “people”.

So, back to Sam’s points (now that I’ve given you my background and why I agree), he states that the architect’s role is often that of a tech lead.  Based on my experience, alot of tech leads get less than 2 hours of coding per day, and are often caught up in meetings and company bureaucracy which prevents them from being directly or actively involved in the development. Sam states (and I agree) “More than any other role, architects can have a direct impact on quality of the systems built, on the working conditions of their colleagues, and on the organization’s ability to respond to change.”

This then, makes them such a strange hybrid of technical, but also leadership expertise.

Personally, I’ve seen both extremes – an architect who injects their opinion into code, without consulting the pragmatic ideas of the rest of the team (who in turn has to own the end result), and also the architect who is so hands off that their responsibility is configuring TFS and learning how to use Git so that they can tell the other team members to go Google it.

Neither of these scenarios capture the true essence of an architect – but Sam goes on to say we’ve actually borrowed terminology and not fully understood the impact – and that the role is very well defined in other industries, like engineering, where there is a specific, measurable goal.  By contrast, software engineering is less than a century old.

Trebuchet "is a" type of catapult - right?
Trebuchet “is a” type of catapult – right?

“Architects have a duty to ensure the system is habitable for developers, too”.  This is critical – tech turnover is still high.  Developers leave because they don’t like working with your codebase (yes, Mr. architect, you’re responsible for the overall quality of your codebase – go sit with your juniors now), or because benefits, culture, and environment is better at a different company.  In my experience, a company that invests wildly in the satisfaction of their employees retains better talent for longer.  Software is unique in the fact that you can invest in your developers with shiny tools and conferences, instead of being limited to “only” monetary compensation (like a sales team for example).

“If we are to ensure that the systems we create are habitable for our developers, then our architects need to understand the impact of their decisions.  At the very least, this means spending time with the team, and ideally it should mean that these developers actually spend time coding with the team too.”

This could be pair programming exercises, code reviews (you don’t get to complain about quality if you don’t put forth a concrete solution) or mentoring sessions.  If you’re an architect that only knows how to create stored procedures which end up creating multiple dependencies and breaking changes for more than one application, then you need to stop calling yourself an architect, and start doing your job – developers hate working in environments like this.  Stored procedures make for top-tier database performance, and the absolute lowest software agility (if misused) – since your dependencies cannot be managed from within your solution.  That “one guy” has to “remember” that “oh, when you change this sproc, these two applications will break”. Not fun.


Sam compares the architect to more of a town planner – they don’t get to decide which buildings go where, but they are actively involved in IT governance, and pragmatic decision making (read: data-driven) – i.e, they zone out areas where commercial and residential buildings will eventually go.

Anyone remember SimCity?

A town planner does not have the power to add and remove buildings or real estate developers from those zones.  Often times, it’s developers who are on the cutting edge of new tools that can achieve various outputs, and they should be empowered to deliver on the desired quality.  If you’re dictating who is consuming which stored procedures, you’re a town planner who is calling up Wal-Mart and asking them to move in.  If your development team has assessed the risks, and has pragmatically agreed on Costco or Meier, you need to let them do their job.
I’m also a big fan of governance through code, as this hearkens back to my Six Sigma days of mistake-proofing a process.  This can open up a whole new area of discussion, such as how Resharper, or architectural styles like DDD, REST, and CQRS can enforce best practices (as defined by you) at a code level.  Another discussion for another time!

For any fans of mainstream house, you may be interested in Deadmau5’s new album – W:/2016ALBUM/ (not a typo!)

Leave a Reply

Your email address will not be published. Required fields are marked *

Copyright Hi, I'm Andrew. 2017
Tech Nerd theme designed by Siteturner