My current job title is Head of Architecture, though the word “architecture” means different things to different people in the world of software. So what does it mean to me, what do I do when I’m playing Head of Architecture?
I follow Perry and Wolf in Foundations for the Study of Software Architecture by drawing the analogy between software architecture and built environment architecture, not network or electronics architecture. The work of a built environment architect, particularly one who follows the path laid out by Christopher Alexander, combines elements, form and aesthetics by creating a system that complements and enhances its environment. Software systems are deployed into environments (with existing people, processes, cultural norms) and developed in environments, and should make those environments better for the people who are interacting with them, while also meeting the functionality, performance, security and other goals of the system.
But that doesn’t actually explain what I do, which is more about letting other people do things that are “architecture” than about “doing architecture” for them. Programmers, ops folks, QA people, product owners, and others frequently make decisions that have wide (and hence “architectural”) impact, and I think it’s better to enable that and follow up by asking how it impacts the rest of the system, to refine the choices made, than to stop people from making those decisions for them in the name of “being the architect”.
So playing software architect for me tends to be more about creating a forum in which people can present aspects of the problems they’re trying to solve, needing to solve soon, or the solutions they’re exploring, and getting a view from multiple teams and multiple functions about those problems and solutions. Making sure that ops know what devs are doing, that product team Alpha knows how product team Aleph are solving that issue, and so on.
Architecture is a new function within my organization, and I have exactly the same view as you of what our role is.
I’m wondering if you’ve found anything to be especially useful.
BTW, I will note that I’m also coming from the attitude that “documentation serves a purpose.” The most useful documentation, imho, is used once and created to solve a specific problem. But the generated/hand-augmented diagrams I mention above are the sort that I think people will refer to often (used to orient new employees, talk with management about where a failure was during an outage, etc.)
I mean that I actually deliver code that fulfils valuable user stories in our full-stack JS (Mongo (mostly), node, express, react) applications, rather than being an ‘architecture astronaut’. I currently don’t use reverse-engineered diagrams, mostly because I’m not sure what they add: by definition all of the information in them is available in the code but I might want to talk about an abstraction, or a desire, that isn’t present in the source.
In fact at the moment I tend to capture diagrams only at high level (so in the C4 model, at the Context and Container levels) and leave teams to discuss Container and Class levels themselves, in whatever form makes most sense to them.
Our “house standard” (i.e. I have a licence provided and know everybody else does) for diagrams is Lucidchart, I’d be happy with OmniGraffle or dia too, I don’t (currently) make code-generated diagrams.
That makes sense, and I’m also a fan of C4. Our code was recently refactored into a better collection of components with improved metadata about the connections between the components. That was the part I was thinking of generating.
I agree about the value of being involved with shipping user stories as well.
Thanks for the response!