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 and yet still has management completely fooled
"á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
"--ities": Integrity, Simplicity, Reliability, Extensibility, Maintainability, Modularity, Recoverability, Composability, Parsimony, Scalability, Security, Performability, Longevity
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"
"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
Architects ...
understand
reassess
explore
lead
... we need a new metaphor?
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?
Why do we need this guy, exactly? ("Isn't the orchestra doing all the work?")
A conductor ...
... "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 a guy at the front waving a stick
... and that's OK, because his responsibilities are shared across the rest of the members of the band, in an intuitive or explicit fashion
The architect's role can also be seen as a parallel to that of a movie or stage director
... she sets the background
... she puts the tools in place
... she offers a vision
... she turns the actors loose
... she ensures the overall effect is a good one
absolutely, yes
how else is the architect going to get feedback about their decisions?
depends, but... usually not
but, 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
Alternatively, 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
architects need to figure out the context of the system
best way to do this is to talk to the stakeholders
... 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