A Trace in the Sand
by Ruth Malan
This is a journal -- where I write traces or musing on topics I relate to architects architecting architecture. I have been writing this Trace for more than 10 years -- if you're just discovering my work, it's not because I am new to this!
To get an idea of what this Trace is like, here are some traces from February:
And the subsequent slides?
In slide 77, I make the point that right system built right isn't about getting "right system" right, and "built right" right, independently. And in slide 79, I riff on Lynn Langit's synopsis of Michael Feather's "Symbiosis" post (which is well worth (re-)reading), where she tweeted:
"Learning how to ask the question 'What does your code need?'"
These are not new questions for us, but simply a catchy way to sum up an important dimension of our approach to (ecosystem) context and strategy, and (system-in-context) design and requirements, and system architecture (and more granular, more narrowly scoped design of elements of the architecture, often in the medium of code) [see slide 75].
This is just to say... I like to think that these, like my other slides, are interesting for the understanding that is packed into them -- like vine-ripened fruit, yielding much to reflection.
Those several slides (73 to 80), are there to convene a discussion, and stimulate thinking, about design. When our different communities talk about design, they tend to do so from their frame of reference. User experience: business capabilities or features, customer journey and user stories, etc.. System architecture: looking inside the system, at elements and interface design, assigning responsibilities and designing element boundaries and inter-element relationships and interactions; design of mechanisms (elements and interactions to yield some system capability). Code: design of algorithms, functions, ... unit tests, ... But it is all design. And all design impacts and interacts with other (forms and scopes of) design. Whichever decisions are made and cast, shape (enable and constrain) subsequent decisions.
This is important to realize, because we think we can design in code incrementally, conducting value experiments through continuous delivery of working software -- without penalty. That is, without there being inherent tradeoffs. But any decisions we lay down, in whatever format, but including code, starts to shape. And then shapes more. And yes, yes, we can strive to lower the reversability cost -- do smaller things that are easier to roll back, for example. But we need to get it in our mindset that what is, shapes. For example, users who embrace (eagerly or with dragging heels in a "we'll see" mode) an increment of function, start to lay down tracks of habit and entanglement with other systems. We recognize the inertial forces of entanglement within our system, but our systems become entangled in their containing systems, too. Well, I'm not suggesting don't do that (continuous development/integration/deployment). Not at all. I am suggesting that we revisit all the ways we make design decisions, and not so glibly sweep visual models or sketch prototypes, and pretendotypes, and so forth off the table. But also don't turn code development into a new kind of waterfall (one-way flow) we're just not seeing as such. I'm also not suggesting all churn and back-tracking! It is helpful, though, to think of design as non-linear and highly interactive -- across the boundaries or scopes of design. Across traditional role cleavages and specializations. Not in a mad and maddening way. But just enough. We need to embrace the power of decisions and the constraints they place -- we can't enable, if we don't constrain. It's physics. ;-) But we need to do that, with our "heads up" to what we're doing, when we do that.
Oh, pfft, yeah. We don't have a crystal ball. We don't even have very good rear view mirrors!
But we're fooling ourselves if we think that building systems incrementally protects us automagically from missed and mis- direction. We can be more intentional about discovering and shaping value than that. So I'm going to address addressing (yes, intentional duplication) those questions in reverse order:
We (Dana Bredemeyer and myself) have been teaching software architecture workshops for 20 years (I have just this moment realized it was 20 years ago this summer that we prototyped our first architecture workshop in HP! OMGoodness! That's... devastating... but also awesome!), and much has its roots in that early work. Our visual architecting poster has columns for each of those questions. I only say that, because while I mention and generously point to other people's work, I don't want you to go assuming I wasn't there first. ;)
Elaborating a little to illuminate the scope of these questions (in this discussion):
In other words, I'll be focusing on Context for a while, catching you up just a little to what we have learned over more than 20 years! ;)
And if you're tempted to discount that experience with some ageist stereotyping... be my guest. You can take a short-cut to wisdom by learning from those of us who have wrestled hard with this space of concern and applied learning, or you can learn on the hazardously cutting edge of the lessons that complex systems will teach you. They don't call it the bleeding edge blindly. Oh, and if you want to see my code, you're asking for the wrong thing from me. My code will teach you very little, or nothing you don't know (assuming you have and do write a lot of code). What you need from me, is what (Dana Bredemeyer and) I have uniquely researched and applied and learned about strategy (business and technical) and leadership (in usual people sense, but also in the market/ecosystem sense) and system design and architecture. So you know. ;)
Just think of architecture as system design for complex systems -- starting with the complex of interacting complex systems within which a complex system is (or will be) embedded. So it makes sense that we could get more clued in? And that the code one writes at uni and as an entry-level programmer isn't exactly covering that base? Sure, we learn a lot on the job about complex systems and the design thereof, as we progress through our careers. We try things out, we learn through the empirical experiments of doing across time. But it is a haphazard and drawn out way to learn something vital to system integrity and business sustainability, and hence the lives and livelihoods of our team members, others in our business, and our users, and their businesses, and others they impact. And. Etc.
South Africa has exported some great innovations to the US: Elon Musk, Trevor Noah, and Ruth Malan. ;) Don't misunderestimate me (and George Bush Jr.; oh well... never said I was perfect). :)
Anyway, I'm going to explore context, but I want to reiterate and emphasize and reinforce (get what I'm doing?) the message that you must do as I say, not what I'm doing. ;) That is, I will talk about context, but when we are designing systems, we don't hole up on context, understand that real good, come up with a perfect strategy, then do system capability design by considering the system in its (system-of-system) context and get that all done and dusted. Etc. I have iterated my understanding across all these spaces, and you have too. So what we're doing here is simply organizing what we have learned into a context bucket. And later we can visit the system(-in-context) and capabilities design bucket. And the system architecture bucket. When we're designing systems, we do so messily, non-linearly, iteratively and incrementally -- we evolve the system and our understanding of what we want to shape it into, and how best to shape it internally. Sure, some things, we will be more intentional and rigorous about, proceeding in a more systematic way. Others, we will be more ad hoc about. We'll use judgment. And sometimes not. We're human. And complex novel problems are, well, complex and novel. So while our map of context, system-in-context and system, is not a prescription of a waterfall progression, it is a map of "places to put things" in terms of organizing our thinking and products thereof. And it is a reminder, that serves to prompt us to backfill, if we leave important things out. Etc. Got the idea? Good. I'm happy for you. Um. Could you explain it to me? ;)
Some traces on ecosystems:
Other resources you'd like to recommend?
Upcoming Open Enrollment Architecture Workshops
In a recent email:
More about what we do:
[7/7/16] Comments on student evaluations from a recent workshop (taught by Dana Bredemeyer), on the strengths of the course:
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