ted.neward@newardassociates.com | Blog: http://blogs.newardassociates.com | Github: tedneward | LinkedIn: tedneward
... but you're not sure what architecture means
... but you're not sure what an architect does
... but you don't want to lose the respect of your developer friends & teammates (who are convinced that "architect" is Latin for "cannot code anymore")
... defines architecture
... gets paid more than "real" developers do
... focuses on issues that have nothing to do with real-world problems
... thinks in terms of clouds, not code
... speaks with big words and Powerpoint slides
... has no real idea what they're doing yet has management completely fooled
"The thing done by the team that tells me 'No' all the time"
"Something the CTO keeps referencing but can never define"
"A bunch of PowerPoints and Visio diagrams"
"That thing we always pretend to be doing"
"áarki tèkchər", noun
building design: the art and science of designing and constructing buildings
building style: a style or fashion of building, especially one that is typical of a period of history or of a particular place
structure of computer system: the design, structure, and behavior of a computer system, microprocessor, or system program, including the characteristics of individual components and how they interact
"Tell me your definition of 'software architecture'"
(it thought about this for a long time)
Software architecture is the set of fundamental decisions about the structure and behavior of a software system, along with the rationale behind them.
More specifically:
It defines the high-level organization of code, components, services, data flow, and interactions.
It addresses cross-cutting concerns like scalability, performance, security, maintainability, and deployment.
It identifies key abstractions, boundaries, and protocols between subsystems or teams.
It is concerned with trade-offs—every architectural choice involves balancing competing forces (e.g., speed vs. flexibility, cost vs. robustness).
It's not just a diagram or documentation—it's often reflected in code structure, interfaces, and system behavior.
Good architecture:
Enables change: It makes future changes easier rather than harder.
Aligns with business goals: It's shaped by what the system needs to do, not just what’s technically elegant.
Survives over time: Code can be rewritten; architecture should evolve gracefully.
Guides implementation: It provides a shared mental model for developers, even as teams scale.
(Not bad, for a machine!)
"--ities": Integrity, Simplicity, Reliability, Extensibility, Maintainability, Modularity, Recoverability, Composability, Parsimony, Scalability, Security, Performability, Longevity, ....
this list varies with company, department, team, individual, presenter, ....
as such it is really not a great definition
where "right" => "right for this project or system"
in other words, enable "correctness by default"
developers using our architecture "fall naturally into the pit of success"
credit: Rico Mariani (https://www.linkedin.com/in/ricomariani/)
Architecture is a set of answers to the questions developers will ask every day
"The core of strategy work is always the same: discovering the critical factors in a situation and designing a way of coordinating and focusing actions to deal with those factors. ... A good strategy honestly acknowledges the challenges being faced and provides an approach to overcoming them. ... bad strategy covers up its failure to guide by embracing the language of broad goals, ambition, vision, and values."
vision
what is our desired end state?
mission
what gets us there?
execution
how do we get there?
vision
what is our desired end state?
mission
what gets us there?
execution
how do we get there?
technology choices
structure choices
runtime choices
a set of principles that the developers will follow (most of the time)
should be extensive, but not comprehensive (cover the "80" in 80/20)
nothing is set in stone (heuristics, not algorithms)
prescriptive, not descriptive (focus on what to do, not what it looks like)
provide signposts, not guard rails
decision-making tools
heuristics to govern behavior
expression of intent and direction
limited to a handful in number
keeping them few in number forces you to focus on what matters most
tailored specifically to the problem at hand
and to the people who will need them
apply to well-defined activity or decisions
so as to avoid being too broad, general or abstract
provide clear guidance but allow for deviation
leaves room to exercise creativity and handle unanticipated situations
an architectural style
evolved by Roy Fielding
https://www.ics.uci.edu/~fielding/pubs/dissertation/fielding_dissertation.pdf
https://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm
architectural breakdown of the Web
Ian Jacobs, Norman Walsh
https://www.w3.org/TR/webarch/
URIs are used to identify resources
Agents communicate using standard protocols
Agents do not incur obligations by retrieving a representation
Delivery is in the form of a sequence of one or more messages, which taken together constitute a payload of representation data and metadata
Identification, interaction, and representation are orthogonal concepts
The information in the Web (and the techs used to represent it) change over time
Agents that recover from error by making a choice without the user's consent are not acting on the user's behalf
Be strict in what you send, liberal in what you accept
Understand
Reassess
Explore
Lead
Goals
domain
business
technical (see all the "ities" again)
Constraints
money
time
resources (developers, machines, etc)
domain
team member abilities
Outcomes
competitive advantage
productivity
costs/benefits
potential ROI
A journey of a thousand miles always begins with a single step." (Ancient Chinese proverb)
A journey of a thousand miles doesn't begin with a single step; it begins with the damn map." (Ted Neward)
Goals
changing business climate changes goals
Constraints
changing business climate changes constraints
Project's progress against those goals
"Are we winning? Losing? In the same ballpark?"
The changing landscape
New technologies (languages, databases, *aaS, etc)
New methodologies (microservices! modular monolith! AOP!)
New "isms" (functional! object! realism! absurdism!)
... to determine the viability of any of them to fit our needs
what changes would be necessary
prototype/research/spike new technologies
analyze new techs' impact within existing systems
NOTE: Beware of "The Coolness Trap"
it can be cool and useless at the same time
it can be boring and exactly the right thing simultaneously as well
To be "out in front"
To make decisions when one is required
To be willing to be wrong
... and to know when that is
... and accept the consequences
To articulate, mentor, and educate
... we need a new metaphor?
What if, instead of thinking of architecting software like architecting buildings...
What if we think of developing software like ...
... an orchestra?
And the architect is thus...
... a conductor?
"Isn't the orchestra doing all the work?"
... "directs rehearsals and performances"
... "shape(s) a musical interpretation"
... "has many specific responsibilities: accuracy, ensemble, tempo and dynamics, phrasing, balance, style"
(Source: http://www.cso.org/main.taf?p=1,1,4,8)
Sometimes the band is small enough ...
... you don't need somebody at the front waving a stick
... and that's OK, because conductor architect responsibilities get shared across the rest of the band, in an intuitive or explicit fashion
... she sets the background
... she puts the tools in place
... she offers a vision
... she turns the actors loose
... she edits the results, iterating as necessary
... she ensures the overall effect is a good one
absolutely, yes
how else is the architect going to get feedback about their decisions?
but also, no
an architect should never be on the critical path of any coding
their time is too deeply divided across too many activities
depends, but... usually not
it is reasonable to ask who is that enforcer
and if the architect is the team lead, it may fall to them
never enforce standards without consideration/thought
be warned: this is a dangerous path
it is entirely too easy to become "The Team Who Says 'No!' All The Time"
and who created those standards in the first place?
Or, should the team lead be the architect?
architect is a role; team lead is a title
never confuse the two
some good reasons to do this
enforcement of standards/decisions
familiarity with the dev team
some bad reasons to do this
time commitments; architect needs time coding (to get that feedback)
puts a great deal of power in the hands of one person
architects are not "system analysts" or "project managers"
any more than they are "developers"
architects need to figure out the context of the system
best way to do this is to talk to the stakeholders
they will weigh in on the requirements ...
... and will have input into what's necessary to specify
... but they should not be "responsible" for them
absolutely, if the company views architect as a role
this is generally a great litmus test over role/title
juniors can:
pair with seniors to learn the ropes
do some (guided) research to "scout" possibilities
build PoCs/research spikes
juniors will fail if:
they are tossed out on their own/not paired
they have zero programming experience at all
they are asked more than they can deliver
in other words, they are just like junior developers!
Cons:
serious "ivory tower" risk here
lack of access to stakeholders/customers
lack of day-to-day engagement potentially hampers domain learning
becomes an easy target for cost-cutting measures
Pros:
wider view of all the nearby efforts
easier concentration of brainpower
key question: how will this team get its feedback?
... a set of answers to questions developers ask on a daily basis
... a set of "simple rules" for developers to follow
... simply a role; not a title
... a developer with "broader scope"
... the person responsible for the vision
... understand, reassess, explore, and lead
Simple Rules: How to Thrive in a Complex World (Sull, Eisenhardt)
https://www.amazon.com/Simple-Rules-Thrive-Complex-World/dp/0544705203
Good Strategy, Bad Strategy: The Difference and Why It Matters (Rumelt)
https://www.amazon.com/Good-Strategy-Bad-Difference-Matters-ebook/dp/B004J4WKEC
Beautiful Architecture (Spinellis, Gousios)
https://www.amazon.com/Beautiful-Architecture-Leading-Thinkers-Software-ebook/dp/B0043GXMRA
Software Architecture: The Hard Parts (Ford, Richards)
https://www.amazon.com/Software-Architecture-Parts-Neal-Ford-ebook/dp/B09H2H5QKC
The Software Architect Elevator (Hohpe)
https://www.amazon.com/Software-Architect-Elevator-Redefining-Architects-ebook/dp/B086WQ9XL1