A few days ago, I started reading "Semantic Software Design" by Eben Hewitt. I haven't finished it yet, but I believe I can already state that it won't become my favourite book on software architecture ever (more about that in the forthcoming review on Goodreads). Nevertheless, the book is worth mentioning here, because of a decent introduction - which covers the etymology & adequacy of using the term "architecture" (or "architect") in context of software development.
It's not the first time I get sucked into such considerations (whether the "borrowed" position names in software development make sense at all):
- how much do software "architects" & traditional architects have in common?
- is software "developer" some sort of an engineer, creative worker or just a skilled craftsman (/artisan)?
For the sake of this blog post, let's focus on the word "architect", its meaning and whether its usage in software crafting is truly justified.
A renaissance man
I've enjoyed how Hewitt has described traditional architects: people with broad thinking horizons, an insatiable curiosity, multidisciplinary interest. System thinkers, pattern seekers, problem solvers, master communicators (both verbally & visually), thought-space navigators who can use their architect "elevators" to momentarily switch from a high-level holistic overview to a "tactical" perspective of a single worker. Always looking for sources of inspiration & creative stimuli, yet still down to earth pragmatic, when it's time to get down into the trenches.
Architects' duty is supposed to be about finding a balance between function & form, purpose & convenience, opportunity & risk, present & tomorrow.
So what does an architect do on a daily basis?
Traverses, dissects & categorises the problem space. Frames & names the needs, expectations & constraints. Discovers the capabilities needed to fulfil them & comes up with the quality criteria so they can be assessed. Excavates the intertwined processes, responsibilities, functions. Crafts multi-dimensional maps, boundaries & interactions of functional areas around specific concerns.
Architects understand where's the potential value (its nature & source), how the solution will affect all its actors, what will be the consequences of particular changes, where are the most serious challenges & the most promising opportunities. They go far beyond their "industry" (e.g. construction) to understand how their solutions interoperate in the general universe. Their true domain isn't really steel, clay, glass or concrete - these are just basic means, needed to serve the purpose of executing the vision.
Software "architects"
Let's try to confront it with the typical understanding of who's a (self-declared) software "architect" nowadays:
- an indisputable expert within a certain software development platform (a language or two, bunch of frameworks/libraries, a corresponding tooling)
- familiar with all modern days software development patterns (microservices! event-sourcing! CQRS!)
- able to quickly craft a syntactically & idiomatically correct "architecture spike" (according to up-to-date architecture standards) that can be multiplicated to implement well-formed business requirements
- knowledgeable with various enterprise integration patterns & their most common implementations (RESTful services, Kafka topics, etc.)
Do you see where this is heading?
While the former section was all about the problem space & bridging between all kinds of stakeholders, this one is all about the technology & translating a precisely defined conceptual solution into well-shaped technical implementation. The first role is all about creativity, imagination, insights & vision; the second one is about masterful application of specific, technical knowledge to execute someone else's (the first guy's!) ideas.
Let's fix the naming
Is there any real common denominator between these two groups? Because apparently these two are clearly quite distant - require separate skill sets, address different concerns (both are needed, of course). It's entirely possible for a single individual to step into both those roles at the same time (it's a the best option to be honest), but it requires vast knowledge, deep practical experience & (at least but not last) a very open mind.
Based on my observations, the 1st role ("True" Architect or a "Functional" Architect) is rarely staffed. Partially because of a limited awareness (that such a role is needed) & partly because it barely exists in the wild (as the "Agile revolution" has led the Enterprise Architect profession to extinction, not w/o a reason ...). That's why in many cases the "functional" architecture of software is ... accidental (it just happens as a side effect of the rushed work).
The 2nd role is much more common, but it's very different to the "classical" definition of an architect profession, so I'd rather call it a "Technology Specialist", "Master Craftsman" or "Experienced Practitioner". When mapping that role onto construction industry, it's someone who knows his bricks, tools & material very, very well (it's his specialty after all), but doesn't care much about the bigger picture (domain problems his toys are supposed to solve) - his challenges/goals/priorities/motivations are purely technological.
It's not an accusation. Or an attempt to downsize anyone's experience or skill.
My point is that ... the successful product vision is never about how many layers will be created, how the services will be deployed or what kind of monitoring tool will be used. The "true" architecture is much less strict/formalised/reproducible than software crafting. In fact it's so ephemeral and hard to grasp, that we tend to forget it's needed and adequately value the rare ones who are capable of shaping it properly.
