In anticipation of Gregor Hohpe's keynote, The Architect Elevator: Connecting IT and Boardroom, Richard Wallintin (WPS - Workplace Solutions) had a number of questions for Gregor about his metaphor of the "architect elevator", software systems as sociotechnical systems, and the role of architects in them.
The fact that software systems are actually sociotechnical systems (or embedded in them) is being realized by more and more software people. Can you confirm this observation? Are you optimistic about mainstream awareness of the social dimension associated with every software project?
100% — one chapter in The Software Architect Elevator is aptly titled "Software is Collaboration", and collaboration is of course subject to social dimensions. I do notice a clear broadening of the horizon for architects from purely technical topics to building a bridge between technology and organization. Or, as I often put it: your technology strategy won't succeed if you don't also adjust the ways of working and the mindset within the organization.
On a strategic level, organizational structure cannot be separated from an architectural vision (in the sense of Conway’s Law). Is it part of an architect’s job role to advise on organizational change? Do the people in the boardroom expect that kind of advice from “technical” people and take it seriously?
Conway's Law is fundamental to understanding the impact team structures have on software structures and vice versa. But I am also worried when folks reduce all organizational aspects to this one single observation, proudly proclaiming "Conway's Law" whenever there's a discussion about organizational aspects. Our modern systems are more complex than the compiler that served as the prototypical example back in the 60ies (four groups will produce a 4-pass compiler), so we need to consider agile feedback loops, devops, complex run-time structures, platforms., etc. I spend a lot of my time having exactly those conversations with executives. And I routinely remind them that the "technical" label is way outdated: the most valuable architects in your organization are the ones who can span many levels, from engine room to boardroom.
Are there specific non-technical skills & methods that you consider essential for being an impactful software or systems architect, maybe even before entering the elevator?
Architects should expect to grow while riding the elevator — there's no substitute to actually having conversations at many different levels of the organization. That said, there are a few things that make for a better starting point. Empathy is likely number one — I see way too much arrogance from technical people towards executives who "don't understand". I don't believe those folks became senior leaders by not understanding things. So if they don't, it's your fault.
Sometimes people (in large organizations) perceive a divide between the “engine room” and “upper management”, due to lack of mutual understanding and not seldomly fueled by prejudices about what “management” does or does not understand. Should architects actively seek being seen and heard and try to narrow that divide? Which ways of doing so are most promising (and what would you avoid)?
Bridging this gap is the essence of riding the Architect Elevator. The biggest challenges are twofold: first, our engine room is complex, an auto-scaling and self-healing Kubernetes cluster may be normal for you, but requires careful explanation to folks on upper floors. Second, middle management occasionally benefits from the divide, becoming a gatekeeper and potential bottleneck. So, you need to be prepared to demystify our tech without watering it down. Focus on the decisions and trade-offs, for example, auto-scaling is great but how will you manage spend? Second, be prepared to face some resistance and remind folks that you're looking to improve the organization as a whole, not play favors.
Hypes and buzzwords are part of our work reality. How do you decide whether it is worthwhile looking into (“dissecting”) a topic? What do you think of the opportunistic practice of leveraging a buzzword to open a door or conversation in order to then pursue an agenda that is not related to that buzzword, but that one considers reasonable?
You might know that I am not a fan of buzzwords. 🙂 I often jest that all labels in our industry are initially useful but obscure before they become widespread and diluted to the point of being meaningless. The latter state is when we call them "buzzwords". The big danger is that relabeling things has never led to any sustainable improvement. However, relabeling is so much easier than actually changing people's mindsets. But architects need to be pragmatists and welcome all points of view. If a customer is looking to transform their traditional IT shop overnight into a loosely coupled, Agile, Lean, and DevOps "digital powerhouse", I'd still go and have the conversation. Helping them figure out what they're really after and laying out a possible path from here to there could be very valuable to them.
Sponsoring a conference is a terrific way to support and connect with our global community of software architects.
