A Trace in the Sand
by Ruth Malan
This is where I keep a trace of thoughts on wanderings in the landscape of software and systems architecture and those that abut and have bearing on our field. I have been doing this for 10 years!
To get an idea of what this Trace is like, here are some traces from February:
To give further sense of the scope under the lens, here's a scattering of other traces:
Upcoming Open Enrollment Architecture Workshops
In an email this morning:
More about what we do:
There are a lot of things our field thinks are "obvious," yet we're still learning how to really grapple with the fundamentals. Take something as simple as "what is architecture?" We swerved to miss the BDUF pothole, and shot an axle* in the NDUF pothole? We're so focused on being Agile, we learn at microscales, and set the process up to focus on small increments and flow with its throughput metaphors and its own set of pressures. And... We become mired in "technical debt" ... or entropy... or tar-baby entanglements... that increasingly stymie attempts to respond to emerging understandings of what users and "the business" needs from our system, in the context of other changing systems and unfolding opportunity. We want to be able to "pivot" responsively, even once we've amassed code load, and the modularization approach du jour is seized upon to get us there. OO, CORBA/COM, SOA, microservices... We've learned through this evolution, but new challenges arise, and the fundamentals remain, well, challenging and fundamental. We're experimenting with grain or chunk size for our primary focus of modularization, as well as the interaction mechanism that allows us to compose these chunks. Hopefully into systems. But system design -- at all for complex systems, but especially where the system is inherently evolving under adaptation pressure given evolving contexts of use and operation -- remains hard.
Early characterizations of software architecture (and systems architecture for that matter), focused on the organizing structure of the system. So we have definitions that spotlight architectural elements and relationships among them, along with system properties. Elements, or components, are (still) the focus, for example, of Simon Brown's (context, containers, components) approach to architecture, and others. It is also where we spend a lot of our attention. As the excitement around microservices signals, chunking and composing is still a matter for hitching our bandwagon to the pony of hope that we have at last reached an approach and undergirding technologies that makes our software highly ... swap-in-and-out-able. Code is so malleable in the small, at the local level of lines and methods and classes or functions .... Yet becomes perversely less malleable over time, as code masses. And masses. We want a chunking mechanism that retains isolation of manageable units, yet coherence in composition -- not just static but dynamic composition, scaling, evolving, commissioning and decommissioning and more.
In other words, the problem of "organizing structure" -- of elements and relationships, of interactions among elements to yield system capabilities and properties, doesn't just automagically go away with the "right" technology stack and supporting deployment and operations infrastructure. When these things line up better, are more consonant with our system (de)composition, we have leverage, purchase. But decomposition and composition to create coherent systems is still important, and non-trivial. To say the least.
Obvious? Well, yes. And the blindingly obvious blinds. Most popular characterizations of software architecture -- including those of Grady Booch and Martin Fowler -- focus on decisions. Sure. And the organizing structure embodies decisions, so bases covered, right? Well. What we're paying attention to, shapes what we perceive and pay attention to. If we say "architecture is decisions" (architecturally significant ones, obviously -- wink), then we whip out an architecture decision template to document them -- put it on github. Walla. Done and dusted.
Not so fast.
Oh pfft, don't get me wrong! I'm not saying that it's not important to document architecturally significant decisions and it's a nice template, though it misses, for example, alternatives we considered but ruled out. More on that later. I just mean that a decision focus is a hammer looking for its own kind of nails, and moves attention away from the organizing structure -- that remains a crucial and central concern of architecting.
Why should we consider "the organizing structure" of the system, at all, and why architecturally? Why think about decomposition and composition, about system "chunks" which we then have to compose and orchestrate? Isn't it good enough to let structure emerge from (TDDed) classes (and micro-refactorings thereof) or functions and relationships among them?
Want to read some of my talk? I'm extranormously busy, so it can only unfold in bits here and there, but shall I get started? Yeah? Oh gosh, you're so nice! :) Here you go:
Dana Bredemeyer said "Architects have to have self-repairing egos" and I snatched it up and wrote it down because it's so true! We work across the system <Ruth makes an arc with her arms>. It's a defining characteristic of architectural decisions that they (are the decisions that) need to be made from a system -- not local (to a part) -- perspective. And they're about achieving something strategically or structurally significant, make or break, matters of structural integrity of the system, sustainability, resilience, ... So not only do they impact different people -- stakeholders (the ones with stakes, to quote Tom Graves) -- but they are things people care about, and have strong -- but varying -- opinions about. Are seen from different vantage points where there are different pressure points, by different teams and their people, responsible for different pieces of the system. We achitect across -- across the system. And across the turfs and charters of teams, and individuals, and functions. Well. All this means that people will see things differently. Care about them differently. And as architects we need to make decisions to meet system goals. Decisions that will sometimes look suboptimal from the perspective of local goals. Make things perhaps harder or just not be what someone with a local charter would prefer (but where their preferences impact others/the system substantively more, making it of archtiectural import). So, over time, various darts are going to be hurled the architect's way -- hence the need for self-repairing egos. Sure, we listen and empathize, try to build understanding, negotiate and coach teams in surfacing system issues and addressing them together, involve people so by participation they understand the bigger picture and the tradeoffs that have to be made. But there'll still be darts. People, you know? Ambitions. Agendas. Real heartfelt concern we're not doing things the "best way." Lots of reasons the darts come out. I have found myself saying "You have a point. You can take it out of my back now." So. Architects will take some scars for the system.
And surprise! SCARS is the mnemonic I saw in Grady Booch's "fundamentals of software architecture":
We'll consider each of these in turn.
More? What's that? I can't hear you... ;)
Psst -- this fits in well with one of my slides latish in the talk:
And this is loosely connected to the analogies slide:
Aside: When I read this paragraph (Oliver Sacks on Madame Curie by Evie Curie), I burst into tears:
A woman who influenced a man to science! And then there she was! And she signed his book. How lovely is that?!! If you don't tear up at that paragraph, don't tell me! I don't want to know!! :)
* well, sure, you're likely to take wheel or suspension damage hitting a pothole, but axle was a more vivid image right there (connecting, perhaps with the "don't get your axle too wrapped around" this image? ;-). Go with the feel of it, and you get more truth than nitpicking at the fact and probability level. :)
Slides: Design Visualization
Well, while you wait, you might want to see the slides from the talk I did in London? All the slides. And slides with notes for the first sections. Remember that if you like them, you need to Like them. That's the social contract, right? It's called reciprocity. You like. You social signal to others that it is worthwhile. Thank you. You're so wonderful! I know it's a pain to log in just to Like. But sheesh, people who Download and don't Like? What's that about? ;) Yes, yes. Even I need to develop some level of reputation. I need to fill workshops -- I earn my keep by delivering value companies pay for. Easy to overlook, I know.
Remind Me -- Never Again!
Yippy woo! I just got this in email:
It's an undeserved kindness, but having someone say that makes all the difference!
I also appreciated this tweet after the talk from another kind person:
I'm just not good at the conference talk thing, but it helps my spirit heal to have someone offer the salving grace of a positive reflection! I won't even look at the evals. I know there'll be good and bad, but the bad will just crush my tender spirit and what'd be the point? I'm not going to do it again.
Workshops are so incredibly different. I generally use flipcharts (not slides) because workshops are an unfolding collaborative learning experience. I have so much knowledge to share, it is at the tips of my fingers and markers are a great way to help get it out of me. And other architects participating also have so much insight and experiences to contribute to our shared learning too -- even their questions contribute to opening up avenues of learning, but the working sessions and mentoring through those sessions are where a lot of the magic happens.
Conferences have their place as a kind of buffet of access to emerging and interesting work. But lectures are "the educational equivalent of 19th-century bloodletting," so workshops ftw! Whoo!
Also, why I can't talk from behind a podium:
I'm going to take a twitter break (with the possible exception of some links here and there) for a while. Hold me to it!!! :)
I also write at:
- Bredemeyer Resources for Architects
- Software Architecture Workshop, Boston, MA, June 27-30, 2016
- Enterprise Architexture Workshop, Chicago/Schaumburg, IL, July 18-21, 2016