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.
How about the stereotype that software architects program using Visio or Powerpoint? In my case, I program using JavaScript. I do make documentation, to make sure that decisions made in the forum are captured, that proposed or current approaches can be seen and understood. And yes, much of that documentation is diagrammatic. But ultimately I’m a programmer on a software team too, and that documentation has to reflect working, valuable software. That is, while there is value in comprehensive documentation, we value working software more.
Architecture is a new function within my organization, and I have exactly the same view as you of what our role is.
When you say “I program using JavaScript,” I’m curious about what your programming output is. We currently have a substantial lack of shared understanding of our system, and I’ve been thinking about using mxGraph (a JavaScript library) alongside draw.io to produce some (high-level, higher than class-level) diagrams from our code and other info about our system.
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.)
Sorry for the lengthy comment. I felt I needed to explain where I was coming from in order to make the question “what do you use JavaScript for in your architecture role” make sense.
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!