As a software developer, software architect or anyone else who influences software, you’ll want to know about Ruth Malan. Ruth writes about software architecture and, particularly interesting, about visual design in the context of software architecture.
She runs renowned software architecture workshops with her husband Dana Bredemeyer.
Ruth has published tons of fabulous material. I think the links below make for a good start:
Ruth’s work is full of insights and — perhaps even more importantly — utterly enjoyable to read and work through.
I think you might be really interested in what Tom Graves (Tetradian) and Joseph Chittenden are doing on Patreon.
Their work is relevant for anyone involved in making change happen in organisations, i.e. you, me, regular people, and those in roles such as line managers, project managers, programme managers, product managers, product owners, system owners, business architects, enterprise architects, business analysts, software architects and so many others.
Brenda Michelson had this to say on Twitter yesterday…
..and all I had was a smartass response. Brenda shared a valuable idea.
Somehow “lead architects” rubbed me the wrong way…so let’s get rid off it:
All architecture is design… —Grady Booch
…we can just speak of “lead designers” who need to know all the questions…or at least many…or know folks who know questions.
Let’s also include “lead developers” and lead whatevers in that description and use this broad definition of designer:
Everyone designs who devises courses of action aimed at changing existing situations into preferred ones. –Herbert Simon
With that out of the way, why do we need lead designers when we’re all subscribing to collaborative design? What does leading design mean in the context of collaborative design?
What if we considered a lead designer to be an expert who then should be considered a knowledge manager as described by Andy Grove in High Output Management? From this perspective, leading (managing) is then much less about making (design) decisions than about gathering & distributing information and influencing decisions (nudging).
Leading design would then become facilitating and supporting collaborative design, i.e. helping the group design and designing with the group. Leading would then become helping the group figure out whom to follow with respect to different issues. Leading would then mean ensuring that all voice have a chance of being heard, especially the quieter ones.
Leading design would then be about helping the network make better (design) decisions (hat-tip Harold Jarche via Lisa Sieverts).
Leading design then wouldn’t rub me the wrong way.
“Courage is not the absence of fear; rather it is the strength to overcome fear.”
— Warfighting, United States Marine Corps
I’m about halfway through this little book. There is a lot of wisdom in there even for people like me whose profession is not war. In other words, if social interactions are your business, this book may well be worth reading.
Tom Graves writes about whole-of-enterprise architecture, where the enterprise is far greater than any single organisation or even individual markets. Similarly, whole-of-enterprise architecture concerns go far beyond the technology domain.
When working at the scope of individual systems, I have realised that we can benefit from taking a similarly whole perspective: I suggest thinking in terms of whole-of-system architecture can be useful and, in my work, necessary. Software systems certainly play an important role in my work, but people play vastly more important roles. As do relationships between people, groups of people and various forms of organisations. Furthermore, we need to talk about processes and data. The list goes on an on.
Even when thinking only about the technology aspects of such whole-of-system architectures, we usually have to consider runtime (or deployment) architecture concerns, development-time concerns (form, function and structure of code) as well as the tools and processes for helping us to build, deploy and manage the technology components of the system.
Thinking about this further, we might consider a system in this broad sense to be a fractal element of a larger enterprise, and therefore, perhaps, a small enterprise in itself. Consequently, whole-of-enterprise architecture insights may well apply. If so, whole-of-system architecture can then be understood as a specific type of whole-of-enterprise architecture (i.e. one tied to the system scope).
Having gotten the above out of my system, I can now start to sort it out. Would you care to help?
Bob Marshall “didn’t sign up for all this people shit“. Neither did I. But like Bob — and Tom and Stuart and Ruth and Chris and Dave and so many others before me — I’ve come to realise that talking about the architecture of software-intensive systems might be distracting me from the core of the problem of building and running effective systems (although they haven’t phrased it in exactly these terms). Focusing on people and their needs might be a more effective approach. This is tough, at least for me, and I can fail at this in the most spectacular ways.
If a classification seems necessary, thinking of the architecture of people-intensive systems might be more useful to me than thinking of the architecture of software-intensive systems.
I’ve been struggling with the architecture of people-intensive systems more concretely:
Fred Wilson‘s video of the week was “Simon Singh on Confirmation Bias“. I learnt about cognitive biases in formal education, read and heard about them on different occasions, and certainly experienced my share of them the hard way. I even knew about the specific example used by Simon Singh.
Despite all of this I was completely floored by the powerful experience delivered in this video…enough to make a hard man humble…
But what are practical implications of this? Say, for the next time we analyse anomalies in an information system? Or about the production problem we analysed last Friday, and the consequences we drew from that analysis?
Better stay away from that tool shed…
…but we do need to know the way home. All by ourselves.
Jeff Gothelf and Josh Seiden said it well in Lean UX:
Over the long haul, collaboration yields better results than hero-based design… Teams rarely learn or get better from working with heroes.
The same is true for any other discipline the hero might practice. And there isn’t really much to add to this.
Except, perhaps, for a little more context:
The most effective way I’ve found to rally a team around a design direction is through collaboration. Over the long haul, collaboration yields better results than hero-based design (the practices of calling in a designer or design team to drop in, come up with something beautiful, and take off to rescue the next project). Teams rarely learn or get better from working with heroes. Instead, designing together increases the design IQ of the entire team.
Just one more thing: Read Lean UX. Much of its content is applicable way beyond UX.
James Lawther discussed this from a broader perspective on SquawkPoint.
A few weeks ago I joined an up-and-running software development (and service operations) project together with a few other people. The team had already launched the first version of the product successfully. We had heard that huge effort had been put in to achieve this success and we had a hunch that the team would likely benefit from a renewed emphasis on certain lean & agile practices. We also had a hunch that the team wouldn’t benefit from us showing up and starting to lecture from the latest Scrum book or so.
I consider us extremely lucky to work in an environment in which we are free to choose our working practices (obviously within reason). I also consider us extremely lucky to work in a great team willing to own their work — and to put themselves on the line every day trying to improve our performance while at same time having to deliver against high expectations.
Listening to the team and the people around us, and establishing a shared understanding of our goals (including trade-off priorities; hat-tip to Alistair Cockburn) and the forces acting on us seems to be the essential foundation for our learning. After that, getting out of the way seems to be the best thing us management types can do. Every so often, we can provide some support and advice, or offer some re-assurance and confirmation. But mostly, it seems to be about getting out of the way and keeping the way clear of other obstacles as best as we can (we have way to go on that one).
Our work practices seem to become more lean & agile by the day, and I think our performance is improving. This post makes reality probably sound easier than it is, but I feel things are going so much better than whenever I’ve seen project teams being instructed to “be agile”.
We were discussing different ways of modelling information about two different concepts. One of my colleagues observed:
Concepts X and Y look very different to a human, but they don’t look all that different to a computer.
He suggested (looking further into) representing these two concepts using the same entity in the system.
A number of things struck me as noteworthy: I think it might be beneficial to more frequently distinguish conceptual models and implementation models (or conceptual and implementation concerns) in design discussions. I’m glad this happened here. Relevant concerns in a conceptual model don’t necessarily have the same relevance in an implementation model and vice versa.
We frequently still seem to draw on sub-classing as the mechanism of choice for distinguishing different types / categories / kinds of things in our models. Other mechanisms such as type attributes or type objects may yield much better results in many situations.
My colleague’s description of this thinking (looking different to a human but not that much to a computer) seems so much better than my ramblings about conceptual and implementation models.
Martin Fowler’s Analysis Patterns book contains a wealth of ideas on this and related topics — it’s highly valuable and relevant 15+ years after its first publishing. Get a first look here and here. Look for discussions of the knowledge level vs. the operational level in models.