This journal contains notes I take as I explore what it takes to be a
great software, systems and enterprise architect.
Until September entries accumulate, there are FORTY THREE months of
entries to pick from (left sidebar), and beneath those, I've linked
to many enterprise architecture and software architecture bloggers.
(Please let me know if I missed your architecture-focused blog, and
I'll add you to my blogroll and the blog list I maintain on
Resources for Architects website.)
the meantime, here's a description of my role in writing this journal, and here is a
sketch, Dilbert style. And
this Dilbert is a
nice complement to any discussion of the Agile Manifesto. Tomatoes?
Why tomatoes? I think the Agile Manifesto is a set of
dude. Still, "bias to x" sounds much like "we value x over y"...
which, when x=action and action=code, simplistically becomes "Just
do everything soon and perfectly"... and it's not just PHBs
that make this simplifying leap of faith or... Grin.
I love the clever visual metaphor for dependencies (and tight coupling) used in this
software rot post. I
was reading about JPL's trouble hiring engineers who are good system problem
solvers. They were hiring top engineering graduates from MIT and Stanford and so
forth, but finding that academic performance wasn't a good predictor of system
problem solving skill. They discovered that childhood hobbies like tearing down
a clock or engine to see how it works was (along with intellectual horsepower) a
better predictor of job performance in complex engineering design jobs. When
Ryan saw the gears in the picture, he immediately, without a blink, saw the
It is a great metaphor--some coupling (through minimalist, well-crafted
interfaces) is very productive and necessary to the design. Too much coupling,
and circular dependencies, and you freeze the system.
Metaphors are great learning and communicating tools. I'm not sure if you
could make out the categories on
The Grove visual
I collected for you, but they are: animals, living systems, physical/mechanical.
I'm not sure where rivers fall in that scheme... a living system? At any rate, I suppose it is meant more to
be suggestive (to help us come up with visual metaphors) than complete.
You know the IEEE 1471 mantra: design architecture documentation in terms of
stakeholder-concerns-views-models. I think that is better turned around. It is
not a matter of documentation; not first. It is a matter of design; first.
Make decisions, and make
If we could design the whole system all at once, that would be one thing. But
complex systems are, well, duh, complex--meaning it is hard to contain all that
complexity in our mind's eye, and manipulate it effectively. So we have to work a balancing act between separation of concerns and
system thinking covering multiple facets and concerns. Switching between views,
using abstraction, using patterns, etc. So, we are thinking about the aspect of the system under design,
and what decisions
we need to make, and what thinking tools to use to get ideas on the table,
and to express and "stress-test" those designs and
decisions. Yes, we're addressing stakeholders' concerns, and using models as a
critical individual and team thinking tool. And that is how we are picking the
models--to make, and then improve, the design decisions we need to make. As we iterate, we're thinking about how best to involve stakeholders
and get their input so we can improve and then begin to validate our
architectural approach. So we're thinking about communication style and
communication vehicles, but we're also thinking about what are these designs and
inherent decisions we're trying to make? What is the nature of the system
(facet) under design? What thinking tools give us a "lever" so we can do the
conceptual heavy lifting required when designing complex systems? How best do we
expose alternative approaches to "test"--to find flaws and discover
improvements. The same models that we use to help us think
alone, and in pairs and in larger groups, may well become the
foundation for the communication we do later to express, champion and defend the
architecture within the larger community. We almost certainly won't need to show
all models to all stakeholders. We will provide views on the specification, and
we will craft storylines for different stakeholders, depending on their
interests, concerns, and information needs. A la 1471. And we will tell our
story carefully, paying attention to how it builds and flows, informs and speaks
to the stakeholders concerned.
We need to see architecture models and their adequate description as vehicles
for creating sound architectural designs (and associated decisions), and
for recording them. Communicating these designs and decisions is obviously
essential, and communication isn't dictation. So we do need to take into account
how best to reach the community who will be impacted by the architectural
choices, and who need to create the designs and apply the decisions. Yes, we
need to target our communication to the concerns of a stakeholder group. Not
just in terms of what information and decisions we reveal but also the style of
the communication. The project's architecture wiki is probably not the best way to get the average business sponsor
excited... And so forth.
But the overall system design, architectural mechanism design, and
architectural decisions are the base we need to focus on. Of course,
communicating these designs and architectural choices are critical--if we don't
do that well, we may as well not make any decisions! But making the decisions is
what this is about--first. Making sound decisions, just in time--no sooner than
they need to be made. And no later. A tough call. A big decision in of itself.
On the question of software architecture documentation, though, I think we
need to reflect on what we, as architects, are trying to do. What decisions are
we trying to make? What techniques and tools are most useful to us in making
those decisions? This is what we need to document!!! Our decisions. As we weigh
the goals or concerns of various stakeholders, and balance that conjoint set of
demands on the system, we will assess what decisions are architecturally
significant. And for those that are, we need to document them, to aid our
thinking, and to record it for future reference. Our
reasoning, including the rationale but also experience and judgment, our
assertions and assumptions, and alternatives weighed. Yes we need to leave a
trail -- the architecture specification. This may be pretty ad hoc and rough
sketchy--for a small and quick project. And it may be more elaborate for a
complex project that needs more careful
engineering. At any rate, if
this architecture specification is the decision trail left only for the
architects, that is already important! But it isn't all, is it? It is the touchstone from which we draw the views we
share with other stakeholders. We don't expect every developer to read every
piece of the blueprint. Not necessarily. We may pull out the overall
context-setting views, the principles and other expressions of technical
strategy, and then more detail for the subsystem or service(s) the developer or
team in question will be responsible for. Etc. Tailored views, and additional help, conversation, examples, for the specific stakeholder group.
Communicate in terms that
If we've done a week's worth of thinking about architecture before we begin
development, we should have a week's worth of models (diagrams or informal
sketches, in some cases, and more fleshed out, formalized models in others) that
have been exposed to scrutiny and contrasted with alternatives and improved
(some tossed out), and explanations, discussion of context and assumptions, and
defense of the decisions against alternatives considered. Or two week's worth. Or three.
Well, ... I just wanted to say that the architecture helps us create better
systems, and do a better job of evolving these systems. So lets focus on
that--on how we get ideas that arrive in rough form in our mind's eye expressed
and "stress tested" by exposing them to
other eyes and experience of others and conducting "thought experiments" like
simulating the system behavior through interaction diagrams or activity diagrams
and so on. And as these models mature, keeping track of the thinking so that we
remember it, so that we are forced through the intellectual exercise of
expressing and challenging the decisions as we write them down and go through
the due diligence of writing an explanation and defense of the design (fragment)
and the decisions it encompasses. Just writing our assumptions down is a good
exercise because it makes us think explicitly about what they are, then we
become more self-aware and we discover new ones we've been implicitly making,
and become alert to uncovering assumptions as we go over the design
fragments with others, ferreting out the weaknesses and improving the design.
NOT necessarily all before coding begins. But more than many Agilists recommend.
And less than BDUF.
If some aspect of the design is architecturally significant, it is so because
it has systemic (diffuse) and strategic impact. Hence, by its nature, an
architectural flaw discovered early is generally cheaper to fix earlier than
later. Alternately put, architectural decisions are those that bear a high cost
of change (Booch). But the cost is lowest, when the change is to models and
thinking, rather than cemented in a big investment in code. Cemented, for the
most part, in our unwillingness to bear the high cost of change and in the
mutability we think code has, for it is apparently easy to make changes, but
easy changes have a creeping tendency to breed brittleness and rigidity. So we
live with the high cost of increasingly debilitating technical debt.
Which gets back again to using cheaper ways to expose the architecture, as
much as is reasonable, to tests: to models and thought experiments, modeling in
pairs and out loud, repeated and frequent discipline of finding alternatives and
ferreting out flaws, prototypes (from sketches and rough-mockups to working
prototypes of critical aspects of the system), to iteratively developing code.
These are the disciplines of architecture and engineering. Many of our systems
are as, or more, complex than (and put people, systems, and businesses at risk)
other rigorously engineered systems, and it is just as well to remain
intentional in our process, as we embrace evolutionary design. Not one or the
other, but both. Intentional. And evolutionary. And intentional in
our evolution! Once we have the models, we should use the models to think about
design evolution. That way we continue to have intellectual control over the
design. Rather than letting it rot in a reactionary trial-and-error approach
with more and more weight of code clouding the design, promoting more error with
Yes, we need an evolutionary design approach, not just an
evolutionary coding approach. We can argue that we can do all this design using
our programming language, but it is worth considering a broader slate of
thinking tools. And if code is still our preference, then we must maintain a
view of the code that expresses the design intent--the system view, the design decisions and
the rationale for them; the explanations, the justifications and the
alternatives considered but ruled out and why. This helps others understand the
architecture, to adhere to it, to build it out, to improve upon and evolve it.
Architecture documentation should support the architect, and support the
architect in accomplishing the architect's goals: designing, building and
evolving a system that has great fit to context and to purpose, and structural
integrity. To achieve fit to context and to purpose, the architect needs to
serve business and operational stakeholders, and customers and end users; this
service begs a dialog, a two-way set of conversations between the architect and
these stakeholders (and their proxies in marketing and business/requirements
analysis). Informal conversations, and also, as demanded by the context, more
formal communications via documents that put rigor into the expression, and also
preserve it for future communication. To achieve structural integrity, as well
as fit to other stakeholder's goals (subsumed in fit to purpose and to context),
the architect needs to help build not just understanding of the architecture,
but also commitment, enthusiasm and passion for the system goals and
This is not so much a radical departure from the
stakeholder-concerns-views-models mantra, as it is recognition that the
architect is a first order citizen among architecture stakeholders. And it is a
recognition that "the" architecture document needs to serve as the living record
of the technical strategy and architecturally significant design decisions.
Other views, composed out of selections from this record, potentially adding
stories and "spice" (humor, colorful illustrations, etc.), will be tailored to a
stakeholder group to draw their interest, and explain how the system addresses
If architecture documentation supports the architect in accomplishing the
architect's goals: designing, building and evolving a system that meets
the prioritized, balanced conjoint set of stakeholder needs, then the
architect (at least the role, if not the individual in it) needs to be around
for the long haul to keep the architecture alive--to intentionally evolve the
design, and also to draw learnings and design changes made in the medium of code
back into the architecture.
In short, let's acknowledge that architecture is first for architects! It is
for the architects to get the right design right--yes, to do this the architect
needs to involve others, and do so in terms they can and will mesh with. Yes,
yes, yes, architecture can fail in all sorts of ways. Failure to get and
maintain sponsorship. It could fail due to resistance or misunderstanding in the
development community. Etc. But it also fails if it is simply not a good, right
architecture. So the cornerstone architecture document needs to be whatever it
needs to be, to help the architect make sure that it is a good right
architecture. And to make sure that it stays that way. Enabling adaptive
evolution, not being sunk by it.
Then, the architect needs to remember that just because she did a good, right
job creating the architecture document (of record, or the blueprint), others are
not going to read it--all. It doesn't do to have the attitude that "I earned my
paycheck creating this beauty, now you earn yours by reading it," does it? No,
the architect has to take a very pragmatic stance, and help the various
communities along with just what they need of the architecture to make them
successful, and to make the architecture successful. Dialog/conversations.
Presentations, dog and pony shows, workshops, wikis, whatnot.
Remembering all the while, that a key principle architects (try to) live by
minimalist architecture principle. Keeping the architecture decision set as
small as it possibly can be, while meeting the key system objectives. We also
need to be pragmatic about the degree of detail we include in the architecture
documentation. During early iterations of VAP, we're moving fast and sketchy,
covering a lot of ground to find the big opportunities, uncertainties,
challenges and risks, so we can direct our attention and do targeted "deep
dives" and then pull back up to the higher levels of abstraction and decision
making (Dana Bredemeyer
calls this "forth and back"). So we are not adding precision to our models
unless we have to. I have seen these sketchy models called diagrams as opposed
to models, but I think that is just getting into terminology wars. The
discipline is to model the system as loosely as will pay off! Be willing to
accept that later will be good enough, when later will be good enough.
And allow the deep dives when later will not be good enough!
Which is not to say there's no guidance! There's the 4+1 view model (Krutchen)
or the VAP Decision Model, and the Visual Architecting Process (VAP) that
suggests views and models and guides decision making. There's architecture
document templates that architects put together for their organizations, and
there's TOGAF (now in its 9th version). So there is plenty of guidance.
But ultimately it comes down to the decisions that are relevant to the specific
project. What is architecturally significant? The architect decides. Yes, yes,
the architect decides taking stakeholder concerns into account, but it is not a
simple stakeholder-concern pairing, but a balancing act across stakeholders.
Various stakeholders care about security, in various ways. Or scalability. etc.
The architect is balancing across these stakeholders and their related and
unrelated concerns to figure out what really matters, and how to address what
matters. At least, whoever makes these calls (it may be management intentionally
or by the way, or it may be that during development these decisions are made in a spotty ad hoc manner,
etc.) is making architectural judgment calls whenever these decisions
have to do with what is strategic and what is cross-cutting and requires
balancing or tradeoffs or systemic approaches...
7/15/11: It is worth bearing in mind that creating the architecture is a
participative and evolutionary process and the purpose of architecture is to
enable the engagement of many minds to create a system with integrity of
identity and purpose (taking various and many stakeholder concerns into account
and determining what the system will be) and structural integrity (including
consistency). That is, our "system of record" is (or should be) a "system
Now, if we could explain architecture the way Benjamin Zander
explains classical music, we'd have mom, and everyone else, on board,
wouldn't we? It's not about thinking about every note (the parts), it's about
the long line of notes (the system; the vision). And the optimism of leaders.
Listen, too, to what he says about the conductor, and think about the architect!
No analogy is perfect (architect is something like a composer and not;
something like a conductor, and not; etc.). But does it help shed some light,
inspire a good, right behavior or illuminate an important concept? Etc.
Russ Ackoff does a great job explaining systems in "The
Nature of Systems," which is chapter 1 of Re-creating the Corporation.
Architecture is about the design of systems, but most definitions focus on the
parts and the relationships, and Russ Ackoff, and Bucky Fuller before him,
insist that system design is first about the system in its context. Whether we
like it or not, the system interacts with its context and will change its
context. This is not just a matter of dependency and constraint, unless we don't
take the context into account! Unless we think of the design problem as one that
has fuzzy edges--fuzzy and somewhat permeable, somewhat elastic edges. Which is
to say, if we think in ecosystem terms, we can partner with others in the
ecosystem to change the context, rather than warping the system to the context
and warping the context to the system.
I was struck by a billboard advertizing the Toyota Prius in Chicago today:
I love that! Self-deprecating humor in a commercial. (Reminds me of
commercials in South Africa!) But it is more too--right? Prius is being
identified with optimism. Optimism for the planet, optimism for the role of
technology in turning around the sorry trajectory we are on.
Anyway, I was thinking about
Zander's statement about leaders being optimists, and I have said something
similar, although I said enthusiastic, but it amounts to the same
sentiment--being positive about the vision and the community's ability to
achieve the vision. Of course, leaders aren't optimistic or enthusiastic about
everything under the sun, or even optimistic and enthusiastic about the vision
or the community's ability to achieve it 100% of the time... But they recognize
that if they have a dive in energy and enthusiasm, they set the tone of the
community and it will be harder to pull a community out of a dive...
Another way to put it would be: architects are either generally speaking
optimists and enthusiastic, or they can fake it when it matters. If they are
constant downers, depressing everyone's energy by constantly seeing the
downside, it is unlikely they will be picked to lead, or allowed to lead. This
is not the same as saying "cheerlead an empty, vacuous strategy," or
something equally unethical and unlikely to be swallowed in a pragmatic software
Well, as you know, I'm very into stories and pictures, especially pictures
that tell a good part of a story. Software is a human experience--a personal
human experience and a communal (tribal) experience. We need pictures and
stories so that the software design, the intent behind the code, will take on a
"life"--become technical memes (temes--Susan Blackmore coined this tem in a
TED talk) which self-replicate themselves in codified
expressions in the systems we build.
Wahoo! Charlie is back and he has written a
great article reflecting on experiences integrating explicit, intentional (EDUF)
architecture and SCRUM. Thank you, Charlie! It takes work and commitment to our
field to gather up and share the lessons from project experience, and it is a
great (and entertaining) read. Charlie is an artist-exemplar of (often humorous,
always insightful) analogy!
Back when I first came across Bono's U-Penn commencement address, I only
found a transcript--which I've read several times since. Today I stumbled across an
audio download of the address and listened to it. It is a great speech; it
is also great timing because it reminds us that there are defining moments in
history. Moments that are defined when a moral blindspot of an era is seen for
what it is and action is taken. Bono placed "Africa" in the top five of our age.
We urgently need to think about global warming and healthcare in the US, and ask
whether these belong in the top five too.
When I think about the innovation and the jobs we would create if we focus
our "yes we can" energy on global warming, essential universal healthcare and
the eradication of extreme poverty and hunger, I am dumbfounded that we don't!
We have to re-engineer our planet, fundamentally reshape how we produce, consume
and retire-into-new-use everything. Not all at once, but fast and soon! And if
we put our collective energy and passion into this, we address the economic
doldrums because we give people a reason to be excited about being people on
this planet at this point in history--and we create wave upon wave of regrooving
and retooling our lives, our homes, our schools, our businesses, our value
I don't want to live my life and die knowing that our generation wrecked this
planet and turned a blind eye out of indifference, self-interest and/or a
feeling of helplessness. We are the "yes we can" generation; yes we can face big
moral imperatives and together make a difference. We are not slaves except to
ideas that confine us.
This is the time for optimistic, energetic focus on setting things right!
For instance, what if instead of focusing all our energy on more fuel
efficient cars, we focused a good deal of it on weaning ourselves off our
over-dependence on cars? If we assumed less cars on the roads, we could devote
some of those roads to bicycles, to
create safe cycling arteries that enable
children and adults to get around our towns and cities safely by bicycle. "Share
the road" billboards don't exactly cut it when it comes to making roads safe for
children. We need alternatives to sharing roads (not safe; Bloomington keeps
track of deaths and we've had two, but I haven't seen stats on injuries) and
slowing down chains of motorists (turns a green intention upon itself). Make the
assumption that people would cycle to school and work if it was safe. Any "we
tried that" thinking has to be overturned, because we have a new sense of
urgency born of necessity and moral imperative. So make a self-fulfilling
assumption. And get Michelle Obama to promote it!
This environmental debt is building so quickly that it won't just be our
children who reap the consequences--we will too.
BASF identity statement is a nice example where the mission, values,
principles are expressed thematically and color is used to highlight the
thematic elements. They have a useful
statement/explanation of these elements of identity and their
BASF’s Vision describes the path that the
Company will take in the coming years. It clearly defines the goals that we set
out to achieve. All strategic decisions are based on this Vision.
BASF’s Values describe the approach and the
manner in which we want to work to achieve our goals.
Together, our Vision and Values form the
framework for all of our decisions and activities. They serve as both an
orientation and a guideline for leadership, and also define our corporate
BASF’s Principles formally state how we
want to conduct ourselves in day-to-day business.
You'll find our description of the role of identity in strategy in our
EA as Strategic
Differentiator executive report. Remember, architecture is the translation
of business strategy into technical strategy. The values of the technical team
need to be consistent with those of the business. And team values and
architectural principles are a key mechanism to align and focus the team. So the
discussion in the report, though most relevant to business leaders and
enterprise architects, is also quite relevant, just at a different scope, to
product architects. The stories we tell, underscoring the values we want to
promulgate in the team, help to create group identity. The name of the team.
Images associated with it. All these things help create a team that is a social
unit. If the project manager is leading in this area, work with her. If not,
you're missing something, and as the technical leader you have a role to play in
building a group culture that will adhere around values supporting structural
integrity as well as commitment to short term value delivery, for example.
Seth Godin pitches concepts and framing for tribal leadership. There's a
TED talk. And there's Seth Godin's
blog. All of which ...um... seem to inspire strong antipathy or strong
tribal followership... It might be tempting to dismiss the purple cow guy... but... insights
come in all kinds of guises. And there are some useful insights bundled up in
the various packaging of Godin's messages about "tribes" and, more to the point,
That is the title of Grady Booch's latest on
architecture column (IEEE Software). Defenestration?
Accoutrements? Superfluous? Yep, the title itself carries a payload of insight!
Very artful! The simplicity message is powerful.
For those of you who read what I
intended to say at the CAEAP
inaugural event (back on June 20th) in my "lightening round" topic on visualization in EA--if you
were worried that I'd be really, really horrible... you can verify your misgivings...
Goodness, Vimeo had to default to the (surely?)
worst momentary image on the video for the
cover still! I guess that's a
freeze-frame from the "I can't draw" bit... what an unflattering moment!
(What can I say, Q<= s are sensitive about unflattering moments!)
I watched the video and Sara came over and after just moments said: "you shouldn't
move so much." Nervous energy dear child. While
ywlaw would, in many contexts, be taken to be a compliment, ytlaw would be
rather damning; in my case, it would be, um, polite understatement! Indeed, I was
horrid... I was SO nervous, because,
while I am accustomed to talking to people in the room, it was the first time that I
was also talking to a camera... to people in the future on the internet who might be (some
probably will be) ...um... somewhat unedited in their reaction to me... To make
matters worse, someone mentioned she was tweeting out, and that
James McGovern was following the
tweets... OK, given how nervous I was, I was lucky I could string any
words together!!! Oh well, aside from the annoying pauses, the random vocal
volume setting, the self-corrections, the flickering movement, you'd never guess
my first incarnation was a shy farm girl in Africa who... still does better in
the company of a book than real live people.... would you? Ha! Well, at least I
smile... oh yeah, add that to my list of annoying qualities! (I'm susceptible to
South African sunshine, like on the faces of the kids in
clip. But...) Every cloud has a silver lining, and the silver lining to this
one is--now Dana understands why I tell him he has to do the conference circuit
thing! He couldn't even watch past the beginning of the video! He says he didn't
have time. Yeah, right! Grin.
One thing you don't see in the video is the audience. They were very kind and
attentive, even though this slot was around 4:30pm give or take 15 minutes and
we started at 8am, with big things during the day like the signing of the EA
Doctrine and award ceremony when John Zachman was honored with the Lifetime
Achievement Award, and Don Hirst with the Enterprise Architect Professional of
the Year Award.
Well, if you want to see how real ladies do it,
Nancy Wolff and
Pretty Newman's talks are also on the
CAEAP vimeo set. As for the gentlemen, I enjoyed
Beryl Bellman's talk, among others. I
need to go back to Beryl's talk (he made observations/asked good questions during my talk, but the
first one came before I had my nerves under control and I wasn't especially
graceful under fire...). Anyway, his talk came at the end of a long and very
thought-provoking and exciting day, so I do want to watch/listen to it
again--after my immediate deliverables are shipped. I liked
Jaap Teeuwen's presentation (the 80/20
reference in my presentation is harking back to Jaap's point from earlier in the
day) and Ervin's metaphors are a great add to our metaphorical toolkit. He gave
me his Matrix cut, so he did double-duty filling my toolbox with
Mark Lane and Mark Goetsch have made a huge contribution to the field,
founding the advocacy body for EA (CAEAP) and
the June 20th Summit was a unique landmark event. I got to shake John Zachman's
hand. Generally that would so not be a big deal to me (being an organizational
flatlander), but John is affable and smart and insightful. For these qualities
and his contribution,
not his status, I was honored to shake his hand. Mark Lane did a highly
commendable job all round, but I especially appreciated
his inclusion of women. Mark Lane sparkles with passion for the EA
field and he has just poured himself into CAEAP.
Dana rented a Prius on a recent trip. I asked him if he fitted 5 optimists in it, and he said
"I didn't fit any optimists in it. I was by myself." Ha! You know he's got to be
an optimist if you've met me, or seen that video! Grin. I guess I am too, or I'd
never show up to do a presentation again!
Why point you to it? Well, gosh, given what you think of me, it's probably
better than you expected!! Grin. I've said this before (but probably only I
remember that) -- I serve mankind by setting a low bar that bolsters everyone's
self-confidence. And that serves me too, because you have low expectations of me
that I can exceed... and still keep the bar low. It's really awfully
generous and public spirited of me. Of course there's no other message of merit
in the presentation... just... a lot of redundancy with this journal, but
perhaps somewhat novel for those who haven't been keeping me company these past
I had to "get over myself" because I couldn't help but notice that Manuel was
telling rather than inviting... but, oh well, not everyone would agree that
creating a "manifesto" for a field should be a
collaborative endeavor... I
think he's done a great job. Heroic. Grin. Actually, Manuel has single-handedly
pulled off some amazing stuff, so he gets to be a hero. In my estimation too.
Diego Rodriguez has a great list of innovation principles (right
column alongside his metacool blog posts). His
second principle (See
and hear with the mind of a child)
recalls to mind Kipling's Elephant's
Child. I love the way 'satiable mimics the process--the child asks "why?"
thinking that the thirst for the cause or the knowledge will be sated, but the
answer only begs a new question. So the seeming-satiable insatiable curiosity is
bound only by the adult's patience! And in that light, "curtiosity" is
Now, lots of people say we should have child-like curiosity and
wonder, but feel disquieted when that is put to the test... like when I read
from or tell the story from The Wheel. Many architects I've worked with
are very comfortable with the story. But there was one group who positively
squirmed--not to a man, but almost... like I'd put on my "Mom" hat in the wrong
context, gone crackers, something...
I get asked about (screening) assessments for architects. I push back strongly because I
believe that the most essential ingredient is
attitude rather than some cookbook
list of attributes (so I don't want to close people out of the field for some
cooked up reason that matters less than their passion for architecting). I said this in a phone conversation with a group of three
architects who were assessing whether to come to us for training. They said
thank you and goodbye. I think they will call back in a few years, when they've
had a chance to learn that the most essential ingredient is attitude! A facet of
that attitude is curiosity and a capacity for wonder (at least I think it is
wonder, but whatever it is that draws us to seek and explore).
But... Seth Godin put attitude at the
top of his list. I'm either going to have to revisit my list or redress my
attitude! Grin. Just teasing. There is a lot of intellectual/technical snobbery
in our field, and while I try to root it out when I find it in myself, I have to
joke because flaunting purple cows is kind of like flaunting child-like
hand-drawn sketches and lessons about innovation from children's stories. I
needle at the same kind of blinders in system development as Seth needles at in
marketing--and at our point of overlap, which is innovation and design. I think
Seth has key insights and an entertaining vibrant style.
Now, I was thinking about Sir Ken Robinson's presentation style, and
realizing that he is on to something. Take the 4 points you want to make.
(Generally, there's about 4; maybe 5 if you're an over-achiever.) And then just
wrap them in entertainment. Everyone wins. You light a fire under your 4 points.
And your audience gets a healthy dose of laughter that is good for their heart
and opens their mind to be lighted by the 4 points you were trying to fire up.
I'll have to try that... Just collect 15 minutes worth of jokes (they
don't even have to be relevant so long as you can weave them into the story!)
and 3 to 5 minutes of making and remaking the 4 points, and ...success! I say
that with absolute admiration and only a hint of a smile. I was sorely tempted
in that CAEAP presentation, to just play back (I mean act out, not show the
video) the first several minutes of
Sir Ken's TED talk--changing words here and there--like from "education" to
"software." I mean, just listen to it in that light--it'd work, wouldn't
it? And that really appeals to my (wicked) sense of humor. But I stopped at
"It's been great hasn't it?" (with a pause to consider "should I do it, should I
do it? Nah, I'm too @$# nervous") but followed up a bit later with one of his
Revenue drops by 20% and the margin halves. That says something about
economies at volume. I think that shipping is a good indicator of where things
are at in the economy, with discretionary spending slashed in most households.
It'd be great, though, if we used the down-turn to turn-around how we do things.
End-to-end. Cradle to cradle.
We look around. Trees still have leaves. Late season flowers are still
flowering. It was even a cool Summer. All the ills that threaten our world seem
to be nibbling at the edges... leaving us still complacent and inert... until it
is too late and we're facing a world thrown into spiraling climate change and
economic fall-out so far beyond anything we've seen that we can't even hold it
in our minds???
The only thing to do, is adapt. Now.
Montessori children around the world will be singing a
peace song on
September 21st--scheduled so that the song will be sung continuously for 24
Peace is something we deeply want for the world. Yet peace will not be
possible in a world devastated by all the untellable unfolding of climate change
impacts. Carpe diem has to be our motto--not in the wanton sense but rather in
the sense of making each day a big day for changing the way we conduct our lives
and our businesses. For the most dismissive skeptic:
even if the scientists are
wrong about the magnitude and speed of the escalating problem, even if they are
seriously wrong--it is a good thing to move quickly to lowering our
environmental footprint. There are so many of us on this planet, and the thing
we do know is that we are becoming
more all the time, and
each new human that enters life on this planet should have a life of learning
and sufficiency--food, shelter, healthcare and education to create opportunity
and fulfill our human need for intellectual growth. That's a lot to support. We
must do it while we reduce the burden we place on all the other life that shares
this unique, or at least rare, planet with us! And
we can do it if we put our minds to it:
The site I referenced for its population clock is worth highlighting: this
may be one of the most powerful visualizations of the
state of our mess and
it's just the numbers. Man, those are some knock you off your feet numbers!
Can Do is an
awesome piece of work! If Sir Ken gives me something to aspire to in terms of
presentation effectiveness, Maria Kalman gives me something to aspire to in
terms of making innovation and architecture points with great artistry! On both
fronts, I have a lot of room to grow. "That's a good thing." Grin.
from Lasqueti" vacation scrapblog has been viewed 895 times. My
sketchblog 821 times. Yesterday's stats reveal that this journal site has
already had more unique visitors in September than any month except August (and
it is within a day or so of surpassing August). But Google image searches send
more than 3 times as many new people to my site as phrase/word searches. In
fact, Google image searches have already sent as many people to my site this
month as in all of August.
All this is good and bad news. The good news is that visuals--even those that
are, like mine, rather sub-par--attract. The bad news is that they attract
one-stop hoppers and sometimes mis-users of my images...
But it also means that this stays a quiet backwaters place--with but a
handful of loyal optimists, as demonstrated in the
number of views of the ☼CAEAP
video. As for that presentation, before I do something like that I hope I'll be
great... for once!! There is nothing quite like before. And then reality
hits me in the face and hope dies a sputtering death. Not like zap-all-at-once.
No, there are moments of possibility, before it's over and hope's expired.
Still, in those moments of possibility, the seeds of hope for the next time are
consummated. And so it goes. Now, this surely doesn't happen only to me. Oh
goodness, maybe it does! Ok, that's all I had to say then. No need for you to
say anything. Really. I get it--you don't understand. You have
no way to relate to
Yes, I have a lot of experience facilitating workshops. And where the
workshop comes off looking good, my presentation skills always lag the rest of
my eval scores. Personally, I would rather facilitate a great workshop
experience and come off not looking so good myself, than the other way round.
Better still, though, would be getting to great on both. ... I suppose...
Goodness I hope not! That kind of thing takes practice! Couldn't a
fairy-godmother just transform me? Ok...
a genie perhaps?
Here's a nice companion piece to my "PICTURE IT" presentation:
Sketches and your brain. And, if you're resisting my ...um... unusual
presentation style, that's ok; Markman's article stands on its own well enough
without my help. :)
As for the misconception, this is what I wrote
back in June:
I should say, for those who are less susceptible to metaphor, that I did not
intend for the right brain/left brain allusions to be taken as unquestioned and
unquestionable fact; it is a research frontier that is interesting and the
intended take-away is that we need to allow that we use our detail-oriented,
pragmatic, logical "left brain" functions much of the time. And while that "left
brain" self is a bit suspicious of the "right brain" self (like it is wearing a
tie-dyed t-shirt and feels like a vestige of the 60's), there are times when
we need to be creative, think big-picture and holistically, and be comfortable
with ambiguity and uncertainty. Anyway,
helps us remind us that our understanding of the brain has come a long way, and
has a long way to go.
that does nothing to undermine the point--our education system and our reward
system helps to shape our experience, strengths and self concept, and we have to
take courage and invest some of our cycles in the set of "functions" that have
been associated (correctly, or not) with the "right brain." Walt Disney
recognized this, and purportedly created separate physical spaces to play out
the "dreamer," the "realist" and the "critic"--separating
in space and time the "right" brain functions from the "left," to ensure that
the right brain was not dominated into too early submission to practicality and
And, Disney, as Randy Pausch taught us, is a software engineer's hero!
Markman's article led me to Google Barbara Tversky, which led to the
work she is involved in.
I apparently have quite a thing about elephants. I suppose it is my South
African heritage. Back in 2005, I wrote this:
the dance of change is one thing, and it is hard enough. Teaching elephants to
dance  is quite another."
That is a reference to Rosabeth Moss Kanter*, who, by the way, has a
* her work, not her person! Goodness, the things you think! Grin.
(Well, at least I'm consistent. You have to give me that. Consistent? All the
"grins" I pepper my journal with. Oh right, you didn't watch the video, did you?
Grin. See, I'm as annoying when caught (I wouldn't have done it if Mark told me
upfront!) on camera as I am in this journal. You really have to ask yourself why
you're reading here!)
I generally follow Nick Malik's blog, but alas didn't for a spell and missed
requirements" post... Well, I like Nick's blog and he has developed a
style of "calling" the industry on controversial points. I just like it more
when I'm not the one in the spotlight! Grin.
I responded to Nick thus:
I didn't, in that context, explain VAP... the iteration... the role of the
architect in right systems built right... and all the other dimensions that
relate to why we coax and cajole architects to play a role in (just enough
upfront) requirements (or,
for those who do this, we reinforce and laud their insight and courage) -- but
not all requirements in their detail, but rather the architecturally significant
ones... the strategic, high impact ones. So the appellation has to do with the
focus of the architect; the decision of the architect as to where to place his
or her attention--during (just) enough design upfront, and throughout the system
evolution. In that light, perhaps Nick could be persuaded to dislike the
term a little less... Oh goodness I do hope so!
Otherwise... the lid!
Oh, come now, I'm kidding! I can take criticism. Sadly, I get a lot of it
(mostly from myself). That whack-a-mole sketch is not just about you and anyone
else who stands up/out and leads (can you imagine how President Obama feels?), but about
me! And I too generally pop back up... smiling enthusiastically... after
about... a month. ;-)
Not that I'd want to discourage a healthy discourse about
VAP, nor even the names we
chose for the facets we iterate through during the architecting process. I'd be
the first to criticize "architecture specification" -- it's not all about
blueprints, but also about strategy and it's hard for me to squish "strategy"
under a "specification" label. There's also our sketchy beginnings, that
we mature into specifications (sometimes, as in the case of agile, while we're
writing code); the appellation doesn't indicate those sketchy beginnings which I
not only embrace but emphasize.
And then there's "architecture validation" which
I also am uncomfortable with since the intent of that facet is to find gaps and
weaknesses and alternatives to improve the architecture, and only as it matures
does that facet focus on validating the decisions. So certainly there's lots of
room for improvement, and we have lots of willingness to enter into dialog about
it. With or without the hammer. Preferably without. Though I'm going to be
doubly cautious around
Darth-Don. I know
what he's packing these days.
I mean cautious in the blog-world death star sense... No, I don't work with,
and have never worked with, Darth Don. I fully expect I never will. I mean, he
already knows the
gun lesson. What could I do for him? Yes, I can say who I
haven't worked with (but I don't like to because it generally reflects badly on
those who haven't worked with us, now doesn't it? Wide grin!). And I can't and
don't say who we have worked with!
Leading up to the United Nation's International Day of Peace (9/21), I think
that piece of art and its message are worth some contemplation. Petros Gumbi has
used his art as a medium for increasing awareness. Hopefully you'll grant me
some forbearance in bringing his work to your attention. African mothers are not
the only ones whose hearts are ripped to shreds by the dogs of war and violence.
Other mothers. Fathers. Husbands. Wives. Brothers. Sisters. Friends. Anyone with a heart wide
I also found out that the
studio in the Drakensberg has been closed--that is disappointing news!
Referencing my excellence post reminds me--I've begun dipping into Steve's
Brain. The book, that is. You no doubt remember
the last time
I took Steve Jobs to bed--my husband asked "How
was that?" and I had to confess I slept through it...
Tonight we went to a performance of Inherit the Wind by our local theatre
company. It is an awesomely good play--a good, right play for these times we
live in! A reminder of the fragility of man and the traps our ego lays for us,
and the greatness. The greatness of those who defend what it is to be (the best
of being) human. In
essence, it is about "
the right to be wrong."
Defending the right to ideas. The right to question.
If one is going to take intellectual
risks--like, say, writing this journal--one feels pretty strongly about the
right to be wrong! Hypothetically speaking, of course. Grin.
Ryan was especially taken with:
DRUMMOND. (Honestly.) I’m sorry if I offend
you. But I don’t swear just for the hell of it. You see, I figure that language
is a poor enough means of communication as it is. So we ought to use all the
words we’ve got. Besides, there are damned few words that everybody understands.
— From Inherit the Wind, by Jerome Lawrence and Robert E. Lee.
Of course, Drummond was the lawyer in the landmark case, so he wasn't in the
pictures (sketches/diagrams/models) business.
We inherit the wind. And [the] UML. And we're at a great point in our field,
where we're learning the "and" lesson. Models and Agile make a handsome
couple. And they may give birth to some weak ideas, but we retain (or must
defend) the right to fail and learn. And that's the big idea isn't it? Making
failure fast and cheap, so that success is more resounding. Weeding out the weak
ideas that don't fit the context or purpose so well. Being free and able to hold
Darwinian ideas, to apply and adapt them to business and product ecosystems.
I've been reading around in Supercorp, Rosabeth Moss Kanter's latest
book. It makes a strong case for explicit, lived values and principles that form
a "strategic guidance system." Here's an excerpt from the excerpt:
Common vocabulary and guidance for consistent decisions.The
need for fast decisions and actions in far-flung or differentiated operations
makes principles an essential decision-making guide. Clear articulation of
values and principles helps employees choose among alternatives in a consistent
magnets and motivation machines. Talented people with many options are
increasingly attracted to companies and stay there because of compatible values.
control systems—peer review and a self-control system. In vanguard
companies, belief in the purpose and embrace of the values generate
self-guidance, self-policing, and peer responsibility for keeping one another
aligned with the core set of principles.
Leading teams is about creating not just the vision and sense of purpose, but
also the team culture (consistent with, but still unique within, the corporate
are just as important to technical strategic guidance systems, as they are to
the business's strategic guidance systems. The architect has to work primarily
through culture and influence rather than dominance-hierarchy-bestowed formal
authority. Values and principles are not fluff. They are tough core stuff that
we use to build the resilient technical compass of the team.
That makes "supercorp" (super-core) a nice play on words, doesn't it? I
haven't read enough to see if Moss Kanter intended that, but I'm sure she,
like I, would take the serendipity.
When I was an undergrad, I heard Athol Fugard (the South African playwright
who wrote Tsotsi) interviewed. He was asked if the meanings critics
construe from his works are intended, and he said many were "happy serendipity."
Funny the things that stick in the mind! But it's like that in software too;
some of the most elegant elements of design fall out as if either by dumb luck
or some genius in our subconscious that we'd like to be better acquainted with!
Which is why architecting--the part of the process that reflects the actual
design choices into the architecture decision set--needs to be an explicit and
appropriately resourced activity throughout the evolution of the system. Yeah,
yeah, some of these we may not recognize as architecturally significant at the
time, but the point is that when we do, we need to be explicit about updating
the architecture document--the system of record that must be just as alive and
actively nurtured as the code that implements it. Double duty? Unnecessary?
Well, just ask the folk who are "maintaining" (the under-appreciated art of
evolving the system in the context of technical debt) all the systems that
have no record like this!
9/22/09: Which raises the question--should we not explicitly make the case
that out-of-date architecture documentation is a type of technical debt? Just
like refactoring is an architectural and a local design tool, there are
different levels of technical debt. Systemic technical debt is much more dire
than isolated local technical debt (generally). And a debt-loving culture is a
very vulnerable culture over the long haul. In business, the long haul is about
5 years, but problems start to manifest earlier, of course.
Dan Roam (The Back of the Napkin) has taken a proactive lead-the-leader stance,
posting the talking points he'd like to prime President Obama to use (via
his chief speech-writer,
on healthcare. He winds up putting the onus on the individual to "take better
care of ourselves and our families."
It really is a
mess of a problem.
Dan Roam has laid out
salient issues in a crisp (and visual) way. The individual, the provider, and the
insurance companies all have a hand in the spiraling costs. And we do have to
do something! At all three points, we have to do something.
Walt Scacchi's classes look very synergist with ours. He even uses
(fortunately, our process dates to the 90's, so we have precedence; grin). He
has a great
pictures reference that I hadn't come across before, so thanks Walt!
Dana recently taught a class where the participants would not draw
rich pictures--unless they could just draw boxes. By contrast, in Brazil, one of
the architects revealed his amazing artist alter ego, but all were
creative and had fun exploring a systemic "system within the ecosystem" view.
I have been reading the architectural process blueprint created by one of our
clients (published as a company confidential book), and it is so
rewarding to see what they are doing with [the] VAP but more importantly what
else they have included and where they have adapted [the] VAP. In making it their own, they
maintained the simplicity that is so key. These are smart people I get to work
with, and it delights me to be challenged and stretched in so positive a way!
I do also want to say that the 15 men and 1 woman that I worked with in
Brazil were among the best architects I have worked with world-wide. They have
deep technical experience and are very smart, and they are fun, funny and they
laughed at my jokes! That gives you a good idea of their breadth of
talent and depth of character, and that combination along with technical smarts
and experience ranks them with a very select set of best of the best in my
experience! I have to tell you that usually a workshop has a handful of these
top-notch people, but this one was full of them. I told them I was utterly put
out, because I used to be smart and then I became wise (well, ok, somewhat
wise), but they are smart and wise! (Mark Zuckerberg and Tony Hsieh are
among those I look to as exemplars in the "smart and wise" department; the real
world teaches real fast when you're open to it!) No fair, I say.
(In case you're wondering, I can say this, because enough time has passed
that they have already submitted their evaluations. But... if you were
wondering, you're a skeptic and I welcome you. While your company surprises me, I'm sure I will benefit from
the challenges you put to me. Right, I'm an optimist. Generally. At least I am
when I get up in the morning... Grin.)
Marriott's carbon footprint of 3 million metric tons
of CO2 emissions annually — or .031 metric tons
(69.5 pounds) per available room — the company
measured its electricity and gas consumption in
guest rooms and public spaces at nearly 1,000
managed hotels worldwide, as well as at its
headquarters building and regional offices. The
calculation followed the World Resources Institute's
Greenhouse Gas Protocol and has been independently
certified by ICF International, a leader in climate
change consulting services.
Based on these
calculations, a $1 contribution will offset the
average carbon generated per occupied guest room per
night. Your $10 minimum contribution will help
offset up to 10 roomnights."
One thing I've noticed since the Mark Sanford scandal broke (and emails he
exchanged with his mistress were published), is that architects have been much
more careful about (not) emailing me their company confidential documents!
I was watching Peter Nygard's great presentation on "Stability
Antipatterns" on InfoQ, and it occurred
to me, I ought to mention InfoQ every once in a while--I generally assume anyone
who stumbles here already knows about InfoQ (videos from tech conferences,
articles and blogs). But then every workshop I teach, I have taken to saying
"Know about InfoQ? It is a stand-out great resource for architects..." (or
something enthusiastic like that)... Still today I find that quite a few people don't know
Ok, the pleading part is Hugh's own characterization ("I'm
not a loser. I just happen to like pleading..." Hugh McLeod). I was
torn about buying
Ignore Everybody. It definitely has more f-words than any other book I've
bought on the business expense account! Now, I told you Ryan liked Drummond's
line "I figure that language is a poor
enough means of communication as it is. So we ought to use all the words we’ve
got." But, need I remind you,
Ryan is eleven! Grin.
bought it because MacLeod is a genius at applying that hatchet not just to
others, but also himself--irony, and self-deprecating wit, rank high in
my estimation. And I bought it for
this cartoon which is at
the end of the book. The mind that created that, must surely have more to offer
than irony and a hunger not just for sex but for appeal... I guess I'll have to
read more than the cartoons in it! As for the cartoons, most of them are
Hugh-huge, clever, fun, remarkable.
On the back cover, Guy Kawasaki is quoted as saying: "Hugh's book will kick
your a$$ and push you out of your zone of mediocrity and stagnation." Is it just
me, or does that seem just a tad pompous? You speaking to me, Guy? Huh? Huh?
Oh! ... Sorry... I need to go
dig out of my zone of mediocrity and stagnation
now... The book will have to wait!
My link on "dig out"
is perhaps subtle enough it needs a little help... Jay Palat (a software
architect blogging on a peer challenge) explores (not intentionally, but while
he has been trying to find his theme, it found him) the tension between our
yearning to do great things that transcend us, and the tug of our delightful
immersion in relationships and their responsibilities, beset by the very tar pit
of chaotic disorder of our fast lives that accumulate too much muchness with too
little time (taken) to strip off the accumulation of muchness from years past!
The specific post I linked to, has all those elements. (It is my sensitivity to
those forces and choices that make me rail against Guy's words as arrogance and
lack of sensibility.) Jay's "hats"
post is delightful, and given that much of his theme has to do with finding and
clarifying identity and aligning action, I think it is perfect!
I love this line from Yeats:
"In dreams begins responsibility."
-- WB Yeats (attributed to Old Play)
[There's a variant in U2's
on Achtung Baby: "In dreams
Quoting Yeats of course segues right to:
"Education is not the filling of a pail,
but the lighting of a fire." -- WB Yeats
I like to do a goodly amount of filling, but my overshadowing priority is the
lighting! Daniel kindly noted, with respect to my workshop facilitation style,
'you can trick their expectations by
surprising them with a "satori"' -- Daniel Stroe, personal email, 9/23/09
That is a nice image; something (more)
to aspire to! I've tended to think of our workshops as crucibles where everyone
pitches in their talent and experience to create a rich and stasis-breaking
outcome for themselves and everyone else. I'm going to refer you back to
this post I did on Feynman.
I've said I'm only still doing this (15 years in one line-of-sight gig sets
me quaking!) because I'm still learning. One architect didn't miss a beat,
asking me what I learned from working with them. I wanted to say I learned never
to change meeting rooms during a workshop, because we didn't just lose time with
multiple room changes but we lost the deep context we create on the walls around
the team. Context is important, and physical manifestations of it have an effect
you aren't fully aware of until it is taken away from you. But I didn't want to
embarrass the architect who'd set up the logistics (that is a thankless and
time-sucking task as it is). I forget what I did say; the lesson about context
is so overshadowing. When we understand context, we understand:
"How can we know the dancer from the
This is a huge "ah ha" for technical people... who tend to think it is just
the steps. The steps. The patterns. I'll refer you back to my tongue-in-cheek
definition of architecture.
Think on it indeed!
Returning to Daniel:
"Think where mans glory most begins and
ends, and say my glory was I had such friends." --
We all traverse a unique path through life, each different
in where we explore, what we encounter and what we synthesize, and what makes me
special is a factor of the gifts of discoveries others bring to me. Some
directly, and some by what they write.
Dana made a point today that I want to share. He said (I'm
Einstein's thought experiments were
contextual, and he took care to take a variety of different perspectives on any
problem, integrating the perceptions gained from those different vantage points.
This came up in Bucky Fuller's tales about Einstein and
his encounter with him. Dana is still making his way through the 40 hours of
Bucky Fuller's core dump. What an amazing man! Dana yes, but I meant Bucky
Fuller. Einstein too. Apparently the word "operational" was invented to describe
Einstein's thinking process, and in particular the way he actively
repositioned his mind to shade new angles and perspectives
on the problem he was solving.
Out at lunch (it's been a long time since Dana and
I were both "in the office" together, and he's only just back from Virginia),
Dana was telling me about a wonderful architect he worked with this week and
said "he empties his cup before he enters the room" and I latched onto that (as
I'm want to do) as a compelling, vivid image of the person who readies him or
herself to take more in. So Dana told me
this Zen story:
I like that cup image. I told Dana about my crucible
image, and in the telling said, "and on occasion we create a mix that
bombs"--the chemistry just is wrong. Or the firing temperature is out of kilter
and our mix is volatile. Teaching by the crucible method has its risks, but when
it works, it is transformative. Fortunately, mostly the crucible works and I
have to say it's not me, except in so far as I create a place for the diverse
experience and insight of a talented group to mix and be warmed. I have worked
with so many great men, and a few great women (most workshops have no women, the
rare workshop might have up to 3)!
Now, don't go telling anyone who is interested in taking
the workshop (Chicago,
December 7-10, if you must know) that it is a crucible for transforming the
field of view from local technical concerns to cross-cutting,
future-operations-sensitive technical concerns that are embedded in business
contextual concerns! They'll run screaming from that notion, like that left
brain from my CAEAP presentation! Just kidding! It's a workshop,
and the harder everyone works the more everyone gets out: including during the
briefing sessions when we set up techniques and practices, during the practice
sessions when work is done and a lot of grounding happens, and during the
debriefs when the ah has have a chance to percolate.
Which leads me to another point that has been waiting in
the wings of my mind. We have so few women in leadership positions in technology
fields that the pre-eminent role models are men, and expectations for success
are set and shaped by men. I always feel bad when I encounter women who are
being more macho than the most machismo of our men (our field has many gentlemen,
but we also have our aggressors--I saw a game developer carrying a magazine with
violent images and wearing a t-shirt that said "I'm sorry I hurt your feelings;
let me call an ambulance"). It's a big world and there are many personalities
and I think diversity is wonderful (mostly). I also think it would be great if
we truly lived that belief, and let women succeed even when they don't smell and
sound and act like men!
That is not quite the whole story, because I also think
men have some advantages in their typical childhoods that place girls at a
disadvantage. Take Legos. When Sara was younger, I made sure to buy her
(girl-oriented) Lego (Belville) sets. Now, I have a story in my past that made
me do that. A professor at the University of Natal (where I did my undergrad
degree) told us that after apartheid was abolished and universities were opened
up, they found that the black engineering students were at a disadvantage
because they hadn't built things as kids. Simple wire-frame toys, perhaps, but
they hadn't worked a lot with manipulatives and simple to complex machines. So
they created a 1 week pre-university camp and had the freshman play with Legos!
Did you realize what an advantage your childhood gave you? Other boys, without
that childhood, also needed that tactile, hands-on build-stuff experience!
So what about girls? Ryan has returned to a Lego phase of
late, and is building all kinds of interesting space transport vehicles
(triggered by their recent introduction to the Star Wars trilogies)--some from
the sets but mostly of his own invention. I asked Sara why she didn't join in,
and told her that she would be at a disadvantage relative to boys. She brushed
me off, but lo and behold, over the last several days she has been building with
Lego blocks too. Interestingly, she is building social environments--starting
with a playground and building out from there. Lego Belville goes after some of
this, though it is targeted at about 5 year olds, and you don't find Belville at
mass outlets like Target. Besides, Sara is, of course, well past the "princess
and fairy and babies" stage. (Co-ed themes like Harry Potter and Percy Jackson
would be more inclusive and age-appropriate.)
Houston, we have a problem. Girls need to build stuff that
works but we need to take girls' interests into account. Not every parent is
going to realize this, but Lego could reach out to parents of girls, and
educators, through social nets. We want more women in technology. We need to
treat girls like they are technologists--but with a different set of interests.
Like, they're just, generally speaking, not into war-craft! This is market
segmentation speak, and there is a market segment we're not speaking to! History
may not have been too kind to girl-oriented Lego sets (in market penetration
terms), but we need to change the course of history!
So anyway, where's the Lego set to build a robot kitten or
puppy? And worlds of kittens and puppies who encounter and talk to each other...
What we're doing a really good job of, is
teaching girls to shop! Let's face
it, girls are pretty good at that. And marketers are getting clued in to the
budget clout of women in families and businesses. But we need to shape destiny a
little more pro-actively, don't we?
I stopped looking in on Dan Pritchett because I just
wasn't getting any positive reinforcement from visiting
his blog--yes, he'd gone silent. So
it was only today that I happened on his June post on
Intuition, Performance and Scale. And I have to say, it is a wonderful
example of the difference between design versus architectural thinking.
Alternately put, it is an example where the architect needs to understand the
business context and how it is likely to play out of over time.
designer/developer with local "now" responsibility can invoke "YAGNI" and focus
on algorithm tuning and tweaking to hit (today's) performance objectives
(unconstrained by tomorrow's need to compromise to meet conjoint objectives).
The architect, though, must juggle now and then. Grin.
It's a great post (and M.Maksin's comment is keen too).
Blogger-Dan, we want you back!
Dan's discussion illuminates why the architect's thinking
on critical choices like these must be written down--endeavoring at least to
make that intuition more self-conscious helps the architect become more aware
of, and hence more able to share, the complex of tradeoffs he or she is
juggling. When the architect moves on (simply gets too busy or walks the
architecture in his head out the door with him as he leaves) all these complex
interacting forces that the architect juggled are obfuscated unless the
architect has moved them out of his (or her) head into the heads and the
reference base of the team.
The great architect enables the team to do great work.
Demands greatness, yes, but also teaches, coaches and inspires greatness.
Our trees are starting to turn; a pretty hint of color to come for those who
are coming into town this weekend. Perhaps it will be a drawn out Fall, but this
is early! I love the Fall here, but not in September! That would
make for a very long brown winter! I feel an itch to get to mountains or sea any
time, but during our brown-earthed, grey-skied winter days I really get
restless! At least in New Hampshire we had lots of snow to ski and photograph!
A developer "heard" me telling that workshop group that architects need to
"take over from business analysts and marketing and do the customer visits."
This reminds me how communication gets warped and twisted when the receiver is
hostile to the message. It also reminds me that some people want simple, very
direct guidance laid out in clear binary terms. Yet architecting is the art and
engineering that deals with very messy interacting forces and the necessity of
making decisions under uncertainty and significant ambiguity!
So I was wondering if The Opposable Mind should be high on the
recommended reading list for architects in-transition--at least for those who
want to know if they have tolerance for the nature of architectural design
thinking. (If they don't have that, forget it, because it only gets worse from
there--remember, Rechtin said "If the
politics don't fly, the system never will.) Since the people in question
have deep technical backgrounds, that is not generally the area of concern. It
is the ability to transition from dealing with more discrete realms of
responsibility and intellectual traction to broadly scoped, messy, ambiguous
The Opposable Mind is a generally good treatment of integrative system
thinking, though I have
quibbles with it myself... (Roger Martin rails against tradeoffs and compromise,
but he is a man with a specific agenda.) Being able to handle that intellectual
tension itself is a good indicator... for we need to accept that system design
is like that--somewhat messy and certainly complex with so many dimensions of
uncertainty and tradeoff. Finding the integrative "and" solution is good, though
sometimes we accept a less-of-this-to-get-more-of-that solution. The thing is,
we have to get beyond the this-or-that binary thinking that would
break the system. Yes, system design, like life, has
high points and
beauty, and we
strive to achieve the purity of
but we also need to be able to accept compromise and suboptimal decisions
(especially when considered locally or from a different vantage point on
history) because expediency battles perfection at just too many turns... And we
need to be able to understand where we need to pull-push-pull to excellence, and
where we can give a little, or even a lot.
Of course there are patterns and practices that the developer transitioning
into the architect role needs to add into his or her toolkit. But the mindset is
now a system-in-(potentially shifting-)context mindset, and it is the mindset
shift that is more make-or-break than whether one is exposed to this pattern or
As for customer visits, I do advocate that architects have some direct
contact with customers/users. Architects bring a different lens to that
experience, but also we make so many decisions based on a gut-feel for the
system context and how it will be shaped, that aligning that gut-feel with the
actual customer and business context is useful. Strategy setters simply have to
understand the customer base. Mark Hurd (HP's CEO) makes time for customer
visits. So should we. That doesn't mean Mark Hurd replaces his marketing team,
nor does it diminish their role. It only enhances his! Technical strategy
setters are strategy setters. They set direction into the future, but the best
evidence we have for what the future will bring is grounded in today. Today's
customers and their aspirations and frustrations. Today's technology. And
Which brings me to another area of perpetual difficulty for many people.
Strategy is not only corporate strategy! Strategy applies at every level, even
the personal level. You can be strategic about your life, which means you think
from time to time about where you want to go, what value you will build or what
high-order contribution you want to make, and plan in broad brush-stroke terms
how you will get there. Projects that support business services or deliver
products, also need to have a strategy that lays out how the service or product
will be differentiated and what capabilities will enable this differentiation.
(And, if you're not differentiating, ask seriously whether you should go with
open source or buy off-the-shelf...)
When I talk about strategy with many architects, they dismiss what I'm saying
as irrelevant because they don't have a hope of talking to the CEO... Um, I'm
sorry, but a CEO that is driving product strategy is like the architect who is
designing an algorithm--it is done at her discretion, because only she can
decide what is strategic. Of course, the CEO that tries to drive the
product strategy for every product (in a big company context) is going to let a
lot of other important things fall off the table. So, if you're a product
architect, you probably won't talk to the CEO (other than about baseball at the
company picnic). Still, if you're the product architect and you don't talk to
the CEO, what I'm saying about strategy is also relevant to you. Relevant, but
at a different scope, and with concerns relevant to your scope. And your
interactions will be with the product or portfolio or solution or domain or
business unit strategy setter--as relevant to your scope of influence.
Companies have identity. That is strategic at the corporate level. Products
have identity. That is strategic at the product level. Is this relevant to the
architect? Absolutely! If the identity of a product is it crashes multiple times
a day, we have an extreme (counter) example of relevance. If the identity of a
product is end-to-end design excellence (albeit with an iconic individual's name
attached to driving that identity) that is relevant, because design excellence
is not just skin-deep. And so forth. Oh, don't worry, I'm not about to give
(more of) a strategy tutorial!
By starting to think in more strategic (how does this impact business
competitiveness) terms, your conversations with business leaders will be more
connected to their concerns, bringing what you see in technology terms into
their field of integrative thinking because you made it relevant to them. The
more you do that, the more you will be, and be viewed as, a contributor to
strategy and you will be drawn into more and more influential conversations.
Your role and your lens is technology. But technology is irrelevant if it
isn't made to be useful. Your role is to make it useful, but also to help people
see how it can be useful.
There's a great article in MIT's Technology Review titled
How Facebook Copes
with 300 Million Users--great because it is an example of deeply
technology-oriented issues articulated in terms that bridge business and
technology. It speaks to some of the gnarly problems of scale (often rooted in
the assumptions we make at the outset) without being condescending. And it
speaks to some of the business concerns--without being condescending. I loved
that "There was a long debate internally
about whether the "Like" feature was going to cannibalize commenting."
Why would they be concerned?
Tonight we took in
performances by The Stairwell Sisters (old time American music), Rahim AlHaj
(playing the oud, including his own compositions expressing the dreams of Iraqi
children to have a life--water, peace, electricity; and the tragedy of the
destruction of old Baghdad), and Kinobe and Soul Beat Africa (from Uganda). They
were all great, and of course very different. Kinobe and Soul Beat Africa were
outstanding and so much fun! They had a strikingly broad-spectrum
audience dancing to a sweat. Kinobe said music is the world's common ground, and
he's so right! Kinobe isn't just a consummate artist and performer, but
also very inventive, and he plays and has created unique instruments.
Kinobe and Soul Beat Africa will be in
Maryland and Ohio over
the next few weeks.
We saw the Horse Flies. They're awesome! Very inventive, intelligent,
folk-rooted, alternative rock. We had no preconceptions, though if I'd known they wrote
Sally Ann I'd have been excited. I'd previously only heard it
covered by Natalie Merchant, but now I see that Judy Hyman and
Richie Stearns of Horse
Flies played when Natalie Merchant sang ☼Sally Ann on the David Letterman
Show♫, and they play on Merchant's The House Carpenter's Daughter. (I just
wasn't paying attention; Natalie Merchant's rich contralto is like that though!)
Jeff Claus and Richie Stearns are wonderful vocalists too!
Horse Flies? Who'd have thought! Certainly you never thought to
tell me about them, now did you? No.
It is great seeing these artists using their platform for raising awareness
of the big social issues of our time--Richie Stearns in Baghdad Children,
and Jeff Claus dedicating their performance of Sally Ann last night to
those who help, and those who need help, in domestic violence cases. Kinobe also dedicates much of his time and music
to addressing the plight of children, and giving children hope in the world
we're bequeathing to them. Well, Richie Stearn's "I believe in love" message,
and the way he sings (warning note: the visuals on the
are disturbing and not appropriate for young children, nor criminal deviants)
Children♫, is haunting.
Meaningful--awful and awesome beautiful. I believe in love! The song is a great
example of holding opposing ideas in tension. You no doubt recall F. Scott
Fitzgerald's great line from The Crack Up:
"the test of a first-rate intelligence is
the ability to hold two opposed ideas in the mind at the same time, and still
retain the ability to function"
And does he function! A first rate mind, a talented and innovative musician,
and a good man! In a band of good men and one good woman. I wouldn't hesitate to rank Horse Flies' Baghdad Children the top song
of the decade! And we're nearing the end of the decade! It might be a recency
effect, but it is important and hauntingly chilling yet hopeful. Well,
again, don't tell me if you don't like it! I wouldn't want to know that
about you! Grin. But if you like it, please do tell people! This is an important
song for peace, written in
warning/protest as the rhetoric leading to the invasion of Iraq was building
and war was imminent. It is a song to hold in our memories always.
We also saw
and she's amazing too! She sings wonderful traditional Celtic songs (lovely
without being floaty-breathy). Her husband is a superb musician (backing her on piano and guitar).
With her husband accompanying her, and their twin little boys in the dressing
room, she sings mainly of unrequited love... Well, the messy hubbub of family
life may be what most makes us, but she has such a voice for tragic melodies!
So, better in her songs than in her life!
The only difficult thing about the Lotus World Music Festival is that there are
so many great bands playing in parallel! I don't regret seeing any we went to; I
only regret not being able to get to some of the others! (Some people duck in
and out, sampling the bands. We preferred to get the full immersion.)
"There's a right way of doing things and a
wrong way. If you've made up your mind to be different from everybody else, I
don't suppose I can stop you, but I really don't think it's very considerate."
-- F. Scott Fitzgerald,
The Curious Case of
“Reasonable people adapt
themselves to the world. Unreasonable people attempt to adapt
the world to themselves. All progress, therefore, depends on
unreasonable people.” -- George Bernard Shaw
So, I identify with xkcd's Dreams; only I
prefer to make my statement with FITZGERALD and SHAW. :-)
Oh I'm good. You've got to give me that. I'm good! Ok, I'll stop dancing on the
Uh, ...you did get that didn't you? No?! Oh, this is so embarrassing!
Hint: F-words and S-words... So, apparently you didn't read my MacLeod rant
before I ...edited it down ... not because I was in any way scared of Hugh
MacLeod (fans) coming after me for being prissy ... but because I was thinking
"wag more; wag more; wag more" ;-) ...
It would be interesting to explore what F. Scott Fitzgerald would see in our
culture now! It is a different age of elitism, to be sure. It doesn't seem right
to use as the emblem of unfettered creative and intellectual freedom, words
rooted in sexual aggression and domination. But that's just my ...prissy point
of view... I prefer to think of it as gentle and caring, but again, that's just
my ...point of view... I wouldn't want to stand up too boldly against the mean in
the tide that is flowing in... ;-)
I had to look up the letters top right to understand
this Indexed! I'm
rather backward in the "in" department... In our so-"sophisticated" modern
lives, it is fun to have our little band of boys watching and imitating Roy
Acuff's band doing ☼Wabash
Cannonball☼ (video from the 70's), learning the
mandolin rather than the electric guitar, and so forth. That lies ahead, no
it is nice that they can grow up in stages, rather than having the tsunami of
modern life blast over and through them...
Well, gosh, none of you told me about Google's
characterized as "a call for ideas to change the world by helping as many people
as possible." Did you also not know about it, or did you not think HelpMatch fit
the bill nicely??
Well, the ideas are all good, but innovation in public transportation gets my
vote. Of the list, number 4 has me most interested--me and David Byrne! I love
the company I keep! ;-) We have to regroove this world!
It is interesting to read about Curitiba and the transportation systems
pioneered by Jaime Lerner (and where they are at now, with social class
divisions driving more people back to cars for prestige and personal security).
It is a great case study because it is a unique case of a city that had an
"architect with an architecture team," who had considerable powers of
architectural governance (though by no means absolute power), but with political
changes and democracy the mayor doesn't have that kind of authority any more.
I was realizing that the time to read Charles Dickens Little Dorrit
has come around again! It is an exquisite novel, really delicate but also
socially important. Socially important then, and now, I think. It's not just in
the context of banks crashing, but Dickens point about the need to ensure that
people have a social safety net is timely. It is a long book, but it is
on audio if you have a commute or flight coming up. It is also on
books and Project Gutenberg,
though I like the book version especially when it comes to something that
becomes a part of me the way a book I really read does. My margin scrawl, like
my scrawl here, is my extended brain--a place to put thoughts so I can think
more of them!
Oh my, that's why I got into this! OOAD didn't have an explicit notion of
architecture, so we set about rectifying that in Team Fusion. But then the UML
started to happen, and again architecture was missing, so we focused on
architecture... and .history... here we are.
A lot of software visualization is about folding in detail to view the
abstractions or context, or traversing from abstraction to detail. Along those
lines, look what happens when we do this, factoring the
complexity of life. Puts us
in context, doesn't it? Grin.
Scott McCloud is into the "infinite
canvas" concept, and Microsoft Live Labs has a neat tool in
beta. Of course, for ages
cartoonists have played with parallel visualizations and flows. Here are some
still doing it the old way:
And this one's for me. And
this one's for... a whole bunch of unnamed
folk who don't read my journal... Grin.
Everybody's doing the Indexed thing, but why is it that I look for where
there is ☼no intersection☼
(but should be), and they all look for intersections (xkcd
and McLeod)? I mean, I can think of a good number of parenting Venn diagrams
with no intersection and if they didn't hurt so much they'd be pretty funny.
9/28/09 Wikipedia 'toon
I love this one! It's just
so... like any meeting these days!
9/29/09 Software Architecture Workshop
Software Architecture Workshop,
Chicago, IL, December 7-10. -- Early enrollment
discount ends tomorrow! Please tell someone! Thanks! Grin.
Consumers are struggling to regain hope, but floundering, and businesses are
following their lead. Remember Ryan--dropping
bombs and trying to take himself out. Well, that was Flight Simulator. Here
we have businesses doing that in real life! Now you can do something to reverse
the trend. Yes, recommend our workshop. Well, only if it is worthy of your
recommendation, that is. Just remember, we have an economy to stir up here. It
will take all your energetic enthusiasm, and mine. At least. Grin.
So your bosses boss will have it on his radar. This is the interesting part:
"Smart grid proponents call it the biggest
new technology since the Internet. They say that it will create huge wealth."
Relevant to IT? And product groups outside the grid space?
9/30/09: So, how did you do on that grad-level question? I'm sure you came up
with lots of creative answers. But you want mine? Ok, if nothing else, it is a
great case of architecting in larger ecosystem terms. Getting out of the box,
and working the bigger picture creates opportunity. There's a cost in
organizational complexity (working across organizations is even more fraught
with time sinking politics than working across business unit divides), but it is
worth doing when the opportunity it creates is huge!
10/6/09: I see that Daniel Stroe
took the challenge. Well, maybe not. :-) But his post is interesting and
relevant here--the ecosystem thread that stimulated "ah has" in the
business strategy community is being parlayed into technology terms. Two
decades ago, Garth Saloner at Stanford GSB was doing interesting work on network
effects in product or technology adoption terms. Thinking about the networking
effects in social systems is interesting too, especially in systems that an
outsider may not see as being especially social!
I write here to keep track of where I explore--what I stumble upon, what I
read, and where I try to knead a thought, let it rise, punch it down and knead it again, let
it rise, and become fully baked. But I also hope someone will find the thought
feast so leavened, heartening. Or something like that. Some metaphors are just
more perishable than others!
Of course, that's daft! I do know that! What I do for my own personal
cognitive growth isn't going to serve others nearly so well as something focused
on their cognitive growth.
The other thing is... that Bezos regret minimization framework... Doing this
is easy, natural. It informs me, and that's good. But it's not a big thing. It's
not a make a difference in this world thing. Don't get me wrong, I do think
system and software architecture is a "make a difference in this world" thing. I
just question the value of this journal. So, well, that's just a hint that other
quests beckon. It would be awful if it's no more than habit that keeps me here.
Habit and a ghosting whisper of hope that I serve more than myself.
But, while that little drama in the wings of my mind plays out, architecture
is still center-stage.
No, I'm not trying to pan-handle positive feedback out of you! It's more that I should put my shoulder to
a wheel that will change more lives for the better. Amplify such talent as I do
have. And I do have some. Maybe. At least, ... compared to a rock.
You see, writing crazed comedy would really be much more my style. And just
think how many people I could help with that!
You know, I have a question for you: What the FITZGERALD are you doing
Oh come now, I would never had said that if I wasn't teasing myself for my
prissy post. Like, I never dropped a brick on my toe? Ha! But that's life isn't
it? Principles wouldn't be worth holding if they were easy and a done deal! This
whole living thing is messy and hard and in my case more messy and more hard
because I have so many principles it's hard to serve all of them. (Oh, I should
add the minimalist principle to my list of principles, should I? Thanks for
following so closely!)
Humor in the afternoon... it must be because I have some real work I need to
do. The harder my left brain has to work, the more my right brain fights for a
release now and then. Well, back to the grind!
10/1/09: We went to see Cloudy With a Chance of Meatballs with the
kids. We did not share
Scott McCloud's experience. Ryan and Sara valiantly drew parallels to
Star Wars and thought it was ok... Maybe they're already too old for it.
Thinking back to what would target the same demographic, we remembered we all
liked Horton Hears a Who, and all it's clever references. There's funny,
and there's just weird. I need to edit down my Regret Minimization post further
in that light!
I expect you've seen the fridge magnet that says "She who has the most
quilting fabric wins." Ryan, of course, thinks it should be "He who has the most
fishing rods wins."
Well, I just came across this:
John D. Rockefeller once said, "He who has
the most information wins."
More is better... But information consumes attention.
Business intelligence goes after turning data into information that
monitors, directs and informs the business. There are lots of tricky questions
buried in this. Not just in terms of integration and ownership and those
perennial battles, but also questions about "invasive" monitoring versus more
Oh, and the Rockefeller quote also explains why you read here, right? Terror
lest some information you don't yet have will escape you. Ok, that's not it. Oh,
I get it! Its the charm thing. Or used to be. Now it's just... a bad habit...
that you're about to break!
Look, I'm about to bust through 2,000 unique visitors this month, so I have
to do something to sink this good ship enterprise again, don't I? Yes, most of
those are one-stop-hoppers. Good. But the return visitors are trickling up too.
Scary! I mean, yes it's a scary thought given what it implies for humanity, but
it's also scary to me. Remember--shy farm girl. Actually, I wasn't even much of
a farm girl. I was given some ducks, but I didn't know to clip their wings and
they flew away. I guess that was the start of my career in comedy. And the end.
In truth, I never saw myself having a career in comedy. Tragedy was more my
thing. But I recently read (in Gentle Action) that comedy is a far better
medium for social change than tragedy, so I'm trying that on. Sorry, I know it's
an awkward fit. But with a little practice...? Oh. Sigh...
How does architecture relate to social change?
Ahhh. Another grad-level question to leave you with!
Read this journal for a while, and we'll have to award you with a masters
degree in ... persistence. But--do remember, that's a
hallmark of an architect! See, you can read here to test and build your resilience. Or
Either way, UML should not have an article. ;-) So, it's not just that
I've given myself over to the convenience culture in the US. :-)
Oh, I know, I know, if you resurrect what it stands for, you have to use the
article: the Unified Modeling Language. But where's the sport in that?
Actually, when it comes to convenience, South Africa has one over us in
Bloomington, at any rate.
Woolworths (so not the US version) delivers really high quality
groceries and fresh prepared foods to homes in a number of SA cities! I wish!
And it is so much more convenient to say "VAP uses UML" than "the VAP uses
the UML." Why, it's like saving trip to the grocery store! [Oh, did you
trip on the missing article? Sorry!]
When I'm coaching people who are getting started with (some aspect of)
modeling, I don't correct them on notation. I noticed that when I did, it
distracted their attention from the reasoning that modeling supports. First, to model, then to get it right. Iteratively. Ultimately it
may be important to be pedantic about using the right notation--for all the
reasons that it is important that we have a standard modeling language
(understanding what we did today, tomorrow; others understanding what we did,
without needing us to be in the room to tell them; and enabling tool support for
model translation, tracing and code generation; etc.). The first thing though,
is to get people modeling, so they experience the benefits of that support for
reasoning and collaborating.
And ultimately, in formal settings, I might even go with the article.
But don't listen to me! I start paragraphs (not just sentences) with
conjunctives! I break the rules. Sometimes. It's colorful. I give editors headaches. You not doubt remember my
battle over the beasties, but in case you joined this party late and didn't go
back to the good stuff in the archives:
... I had
this paragraph in the Cutter report:
"We need to think in terms of
multifunctional teams who are innovation and design centers. Instead, we
typically have user interface folk who drive “user experience,” we have
requirements or business analysts who drive “requirements capture” (as if
they’re running around and we just have to corral them), and we have software
architects who wear beepers and are the second line of defense when the ops
people can’t put out on-the-line fires. Like these are all separable concerns.
Different beasts. For beasts we make them."
copy-editor didn't like "For beasts we make them."
so that line is zapped. I'm grief-stricken at the loss. One of the greatest
insights in software, killed. Dead. Gone.
I didn't give up though, and got the beasties back in--right under the wire,
as it was about to go to print.
You have to decide which beasties to fight for, I suppose. My battle?
beasts we make them." That is giving people power back. First, to see
them as beasts. Then to see them as beasts we created. Then to not do that!
System architecture is about the design not just of the parts but of the
relationship among the parts, for it is in the collaboration of the parts that
value is created. Or eroded. Alternately put, new value emerges from the
collaboration of the parts, that is not inherent in any of the parts alone or
even in uncoordinated conjunction. This is why "we must architect across the
interfaces," across the "seams" in the system.
But that's not all, is it? Value is also created or encumbered, even eroded,
in the relation of the system to it's context, or its various contexts. And the
architect must architect across the boundaries of the system--to the extent that
the degrees of freedom allow that. (More, usually, than architects are given to
think, because we have been shut out from that negotiation of the boundaries by
our waterfall processes and division of labor/role specialization.) And regardless, there's architecting the relationship
of the system to it's context, even if the context is ostensibly immutable.
So architecture encompasses decisions about the (architecturally significant)
parts and their relationships, and the relation of the system to its context.
Its technology environment as context. Its various use contexts. Its business
And when you turn that into a process, you have to reverse the order--first.
But then you play it "forth and back.'
At the other extreme from an (intentionally) architected system, is a fully
accidental architecture--emergent to the extent that pieces are agglomerated
over time. And even in such an accidental and emergent architecture, the value
that is created by the system (and all its collaborations among the parts) is
greater than the sum of the value of the parts. That is, some new, additional
value has been synthesized. Potential new costs and challenges too, but on
balance, greater value. At least, for a while. The thing is, the system becomes
embedded in its context. There is inertia and dependency in that embedding.
Whether intentionally designed by the human mind, or designed by the chances of
fate and the playing out of the web of interactions between the context and the
parts, architecture has to do with the parts (well-formed or eroded) and the
relationships between the parts (clean and simple, or messy, conflicting and
prone to error and surprise) and the relationships with the context (again,
clean and simple or promiscuous and sloppy).
Which is why we architect.
Oh yes, a note may be in order: when I say structural design I absolutely
structural and behavioral design for we must not, should not, cannot design
the structure without designing the behavior! And we would not--not unless we
have our heads in dug down deep in primordial ooze (or some such allusion to
being stuck in a prehistoric era of our field's evolution...)!
But here's a thought: might we say that architecting is about designing how
value will be created and delivered by the system? While keeping a strategic eye
on the horizon of other use contexts and the future.
Value lies not just in the parts, but in the relationships of the
parts to each other and to the context.
Architects design to create (and shore up) value. In its first incarnation, and through the
evolution of the system
Of course, the insight about the relationships among the parts and to context is not
new. Bucky Fuller was saying this way back when. Except not quite in these
terms. My terms, at least, are for the most part unique.
If you want to rave about my
journal, I can be reached using the obvious traceinthesand.com handle. If you
want to rant, its
firstname.lastname@example.org. Just kidding,
I welcome input,
discussion and feedback
on any of the topics in this
Trace in The Sand Journal,
my blog, and the
Resources for Architects
website, or, for that matter, anything relevant to architects, architecting and
architecture! I commit to using what you teach me, to convey it as best I can,
help your lessons reach as far as I can spread them. I try to do this ethically,
giving you credit whenever I can, but protecting confidentiality as a first
Topics from the current month are listed down the sidebar (after the archives
and before the blogroll). For those who decry my lack of permalinks because you
are desperate to share a quote on your blog or to point colleagues to a
particular section—just copy the shortcut from the topic link in the sidebar.
It's clunky, but it works. I did say the necessary condition was "desperate."
Restrictions on Use:
All original material (writing, photos, sketches) created by Ruth Malan on this
page is copyrighted by Ruth Malan. All other material is clearly quoted and
ascribed to its source. If you wish to quote or paraphrase fragments of material
copyrighted by Ruth Malan in another publication or web site, please properly
acknowledge Ruth Malan as the source, with appropriate reference to this web
page. If you wish to republish any of Ruth Malan's or Bredemeyer Consulting's
work, in any medium, you must get written permission from the lead author. Also,
any commercial use must be authorized in writing by Ruth Malan or
Bredemeyer Consulting. Thank you.