What's a Trace?
My Trace is a playground for developing ideas, for exploring architecture and the role of architects. It is a journal of discovery, and traces my active reflection. I've been journaling "out loud" here for over eight years. To get a sense of the span, calibre and contribution of this body of work, there's a selection of traces linked here. When reading a trace in isolation, it may feel like you've been dropped into a thought fray unprepared for the action that is already in progress. It's okay. You're smart, and my Trace assumes that. You'll get your bearing quickly. Just give it a chance.
Enterprise Architect -- Reprise?
Reprise? Well, this sounds like another swing around our block, doesn't it? But, if it doesn't sound familiar to you, it is high time you read The Art of Change: Fractal and Emergent. :-) Oh, Urquhart's post does take its own unique cut through the terrain and is well worth reading. But the ideas have been in play for a while, so there is other work worth tuning in on.
As ecosystems and ecology go, here are some traces:
More on the evolving identity of enterprise architects:
- Is Enterprise Architecture Completely Broken?, Forbes, Jason Bloomberg, 7/1/2014
- Can Enterprise Architecture Reinvent Itself for the Agile Movement? by Huw Morgan, July 11, 2014
- Re-Thinking Enterprise Architecture Using Systems and Complexity Approaches, Sally, Bean, JEA, 2010
- drEAmtime, Ivo Velitchkov
Of course, this trace is a tour de force:
As is this:
And there is this (via Sally Bean):
Fields, or disciplines, like people, need to keep learning, evolving, adapting.
8/4/14: Move over enterprise architects, Watson is here:
A Room Where Executives Go to Get Help from IBM’s Watson Researchers at IBM are testing a version of Watson designed to listen and contribute to business meetings. By Tom Simonite on August 4, 2014
8/8/14: Tour de force? Tongue in cheek. Sheesh! :-)
Wow, a client just sent me the participant list for the Software Architecture Workshop I'll be doing with them in late September -- two months out, and not only is the workshop full, but I can begin shaping... Mwhahaha... I mean... That's a wonderful degree of anticipation!
Dana Bredemeyer will be teaching our 4-day Software Architecture Workshop at the Embedded Systems Institute in The Netherlands on December 16-19. Enroll soon to ensure a spot in the workshop -- remember, Dana is awesome. I'm biased, but he is fully booked by existing clients through the end of the year (and into next year), so people who have worked with him think so too.
I will be facilitating a 1 day workshop on Software Architecture at the Software Architect Conference in London on October 14. Come too -- Richard West will be there, and it's going to be awesome.
I've been asked about dates for an open enrollment workshop in the US. The only week I have available this year, is the week of December 8. So, what's the level of interest in a Software Architecture or a Role of the Architect Workshop that week? In Chicago?
This, from an earlier trace, might be useful:
The Software Architecture and Role of the Architect Workshops do overlap somewhat – where we do both workshops with the same people, the Role Workshop draws on an additional set of material, but in either case, architects will get the core concepts, guidance and key models for architectural thinking/designing/communicating, and so forth.
That said, the design of the two workshops is different:
- The Software Architecture Workshop follows the Visual Architecting Process (informal)
- The Role of the Architect Workshop follows the Architect Competency Framework
However, a good part of architecting involves the “soft skills” of understanding what is strategically significant (hence what are the demands on the architecture and how are these shaped), and making and communicating decisions. These are technical decisions with business and organizational consequences, that need to be understood and embraced to be delivered on.
Often, clients who have teams of architects of different “flavors” (software, embedded, mechanical and electronic systems, infrastructure, test, domain, portfolio, solution, enterprise, etc., etc.) will go with the Role Workshop rather than the Software Architecture Workshop, for obvious reasons. But the essential skills of system thinking and modeling, strategic thinking (understanding what is shapingly important in the business space, so technical decisions support business intent), leadership, and so forth are going to come up in any of our architecture workshops. It is more a matter of what is primary and what is secondary. In the Software Architecture Workshop, the focus is on creating a draft (set of views of the) software architecture, and discussions of leadership and so forth are secondary, but very, very important. (There is no point to making decisions that are ineffective either in their focus or in organizational follow-through.)
Meetings don't get much love...
My imp wants to interject with something along the lines of that being a responsibility plate we need to step up to...
"The quality of your architecture can't be better than the quality of your meetings" -- Dana Bredemeyer
Your inner Conway is doing gleeful somersaults at that? :-) We work with forces -- compression, tension, gravity -- to design and construct viable structures. Conway's Law is like that -- something we have to balance and counterbalance, to resolve, to create ambitious systems.
Meetings are a mechanism we can use effectively or ineffectively. Relationships are conduits for understanding and influence, and informal and formal meetings are convening places. We need to take more responsibility for the effectiveness not just of our relationships, but the time we put into developing them, and what flows through them.
Alignment and shared understanding of context and priorities and what we're going to do and such, takes getting heads together somehow, somewhen. Call them working sessions if you prefer, but sometimes minds need to sync up, move understandings across the chasms between our craniums, and create new understandings out of the interaction between minds and in the wonderful generative space that opens when minds ignite and spark off one another. It is a privilege to try to convey something, because in that very act, we discover what we think! Getting it out there, in words and images, is important to moving understanding -- our own, and others. The big things we tackle, can't (generally) be done by one person alone; we need some common ground, some shared understanding of context, its forces and constraints and opportunities... shaping perception of "reality" and how we are going to interact with and intervene within that reality to create something together.
I suppose, in a sense, politics is about power and influence, shaping resource flows. It can work through informal, or formal, by soft influence or hard, command and control, authoritarian influence. Context and judgment factor. It's architecturally significant.
I like this point, and how it is put:
"You just look at the alternatives; analyze the merits vs. the problem at hand, and may the best option win. This works out well if you are the king (or work alone which makes you the king by default) -- otherwise there are other people and they won't necessarily agree with you."
Arnon Rotem-Gal-Oz, Architect Soft Skills, 10/26/08
There is a bit of an us vs them thing between strategy and execution, talk and action, theory and practice...
“In theory, theory and practice are the same. In practice, they are not.” ― Albert Einstein
"In theory there is no difference between theory and practice. In practice there is." -- Yogi Berra
"When you come to a fork in the road, take it" -- Yogi Berra
OH at Universal Studios (via Dana Bredemeyer): "Which way do we go to get somewhere else?"
Which recalls to mind:
"Would you tell me, please, which way I ought to go from here?"
"That depends a good deal on where you want to get to," said the Cat.
`I don't much care where--' said Alice.
`Then it doesn't matter which way you go,' said the Cat.
`--so long as I get somewhere,' Alice added as an explanation.
`Oh, you're sure to do that,' said the Cat, `if you only walk long enough.'
-- Lewis Carroll, Alice's Adventures in Wonderland
Alice looked round her in great surprise. 'Why, I do believe we've been under this tree the whole time! Everything's just as it was!'
'Of course it is,' said the Queen, 'what would you have it?'
'Well, in our country,' said Alice, still panting a little, 'you'd generally get to somewhere else — if you ran very fast for a long time, as we've been doing.'
'A slow sort of country!' said the Queen. 'Now, here, you see, it takes all the running you can do, to keep in the same place.
If you want to get somewhere else, you must run at least twice as fast as that!'
-- Lewis Carroll, Through the Looking Glass
So what is strategy? Here is Dana Bredemeyer's answer:
"Strategy is a process that asks, answers, and co-ordinates the interaction of these questions, and facilitates the evolution of this process over time:
- Who we are (identity, values, ethics, capabilities)
- What are our desired outcomes (mission, vision, objectives, goals and timeframes)
- What is our context, or situation (the world, trends, forces, resources, evolution...)
- What are the essential things we must do in order to realize our desired outcomes?"
Dana strongly advocates against pitting strategy and execution against one another in that "execution is more important than" kind of way. For those who insist on drawing out the distinction, Dana adds:
"If we divide the world up into strategy and execution, then I want to add a third component. I’ll call it achieving organizational coherence. This is the degree to which there is shared understanding and shared enthusiastic commitment to the desired outcomes and the strategy for achieving them. The ability of every organization, large or small, to do anything, is limited by what they can achieve organizational coherence around, regardless of how exquisite its planning or effective its execution."
- Bredemeyer Resources for Architects
- Trace In the Sand Blog
- Journal Map
- storylines tubemap by Peter Bakker