A Trace in the Sand
Online Architecture Journal
by Ruth Malan

I also write at:

- Resources for Architects

- Architecture Action Guide

- Trace In the Sand Blog


- HelpMatch Wiki

- HelpMatch Google Group


Other Interests

Trace in the Sand
Architecture Journal

February 2008
Su Mo Tu We  Th  Fr Sa
  3    4    5    6    7    8   9
10  11  12  13  14  15 16
17  18  19  20  21  22 23
25  26  27  28  29

Print Feb08


- January

- February

- March

- April

- May

- June

- July

- August

- September

- October

- November

- Current


- January

- February

- March

- April

- May

- June

- July

- August

- September

- October

- November

- December


- January

- February
- March

- April

- May

- June

- July

- August

- September

- October

- November
- December

- January
- February
- March
- April

- May
- June
- July
- October
- December


- February
- March
- April
- May
- June
- July
- August

- September
- October
- November

- December

- March

- April
- May
- June
- July
- August
- September

- October
- November
- December

February Topics
- Trace Turns Two
- Conway's Law
- Structural Engineers
- Getting Past But
- Getting Past But: Take 2
- Getting Past But: Take 3
- Seeds in the Desert
- Intentional Architecture
- From Seeds to Levers
- Books and Green Things
- Books and Paper Things
- Taken Literally
- Happy Valentines Day
- Innovation Model
- Don't Go Big Bang
- Booch's Memoir
- Educate with Value
- Minimalism and Documentation
- Architect Jobs
- Einstein vs. Zen
- Update on Failed Projects
- Requirements as invention
- Kiva Widget
- Architects and Innovation
- Innovation Blogs
- Coupling
- Scaling

- Differentiate—or Imitate?
- Architect as Time Traveler
- My Influence Dashboard
- Tags and Google
- Herding Cats
- Coupling and Decomposition
- Idealized Design








Architecture trace in the sandFebruary 2008

2/3/08 This Trace in The Sand Turns Two!

Grady Booch's Handbook "blog" is to be credited with inspiring this Trace in the Sand two years ago today. It struck me that Booch's blog is really an online journal and the spark ignited: I could share my architecture journal notes online. Frankly, my notes, being shared, took on a rather different vein than notes in my private Lab notebook. Still, the medium has served me well, and as I look back over months of entries I am surprised by the writing that has amassed. I do have a tendency to bulldog a point to death, but by worrying at a notion from different angles, I've produced more clarity for myself.

Along those lines, I've been mulling over the relationship between organizational structure and system architecture, managers and architects. I've been heads down on a couple of assignments, but the ideas want to take expression, so that I can get a clearer handle on them.

2/3/08 Conway's Law

The Wikipedia community describes Conway's Law like this; I paraphrase it like this: if the architecture of the system and the architecture of the organization are at odds, the architecture of the organization wins. The organizational divides are going to drive the true seams in the system.

The architecture of the system gets cemented in the forms of the teams that develop it. The system decomposition is what typically drives work allocations. Then the organizational lines of communication become reflected in the interfaces, with cleaner, better preserved interfaces along the lines where organizational dissonance increases. In small, co-located teams, short-cuts can be taken to optimize within the team. But each short-cut that introduces a dependency is like rebar in concrete—structurally efficient, but rigid. If the environment changes, demanding new lines to be drawn, the cost becomes clear. The architecture is hard to adapt.

Power lines and Table Mountain at sunsetOne could say this is part of the innovator's dilemma. Sustaining innovations, that is, incremental improvements within the cast of the architecture, are what the organization is adapted to be good at. But when a breakthrough innovation demands a new architecture, a new organization (unencumbered by power trees that grew up around the old architecture) tends to be more fleet in bringing the innovation to market.

Another implication of Conway's Law is that if we have managers deciding on teams (what they'll do, who will be on them, and how they will relate), and deciding which services will be built, by which teams, we implicitly have managers deciding on the system architecture. They determine system chunks (services or components) and capabilities by deciding who will build what.

Conway's Law also kicks in if we take an initial guess at the system decomposition (a first-cut conceptual architecture), allocate subsystems to teams, and sally forth—the team boundaries will tend to become the boundaries within the system. Anything else will be a feat of architectural heroics; hard to accomplish, when architectural heroics have to compete with schedule heroics driven by the steady beat of integration clocks. Yet, architecture is where we address cross-cutting concerns, or at least those that needs-must be addressed with a system perspective so that when it comes time to compose the system it will have the properties stakeholders care about, rather than emergent properties that may or may not suffice.

Roles are defined by their responsibilities and associated decisions. Architect is a role. Any person may play one or more roles. That is, the architect role may be shared among a group of people (as in many agile project teams), or one person may hold more than one role (as in many small teams, especially in startups).  This may be overt and declared. And it may be the result of decisions that are actually effected. If management decisions determine the architecture of the system, they are in effect its architects. If developers determine the architectural decisions, they are in effect its architects.

"Duh!" you might well be saying. Yes, a lot of what is absolutely common sense when it is put plainly, is so obtuse in the face of perplexifying reality. Simply witness all the heated arguments and misunderstandings you get around the topic of the role of the architect.

But what does it mean? Architecture needs to happen across the interfaces, and this also means across the system/organization interfaces. It means that system architects (who we call architects) and business/organization architects (who we call managers) should not work as if one has no impact on the other.

[See also: Manuel E. Sosa, Steven D. Eppinger, and Craig M. Rowles, "The Misalignment of Product Architecture and Organizational Structure in Complex Product Development," Management Science, Volume 50 , Issue 12,  December 2004]

2/9/08 Seeking Inspiration: New Name for HelpMatch

Well, we need to find a new name for HelpMatch, since the .com version, previously innocuous, is now a "dating site" with quite the wrong associations!! The HelpMatch.net wiki is also a target for persistent and nasty (automated) spam attacks. Ideas?

2/9/08 Structural Engineers? 

In the building architecture space, for complex buildings with stringent structural requirements (such as hospitals, sky-rises, bridges, etc.), there is a further specialization of role (and associated skills) into architect and structural engineer. For a more simple structure, like a multi-level family home, the architect knows enough structural engineering to design a structure that meets the functional and quality requirements and structural forces. But for a complex or safety-critical structure, a structural engineer (or a team of structural engineers) is needed to make sure the architecture stands up. Many of Frank Gehry's designs, for example, are feats of structural engineering, and not only does Gehry partner closely with the architect-designers on his team who stimulate his creative thinking, but also with leading structural engineering companies who make his gravity-defying designs realizable.

It is being increasingly impressed upon me that we have some of that specialization happening in our domain where the systems (or systems of systems) are complex. It might be time for us to explicitly recognize that we are using the title "architect" in some cases where we really mean "structural engineer," perhaps to give these technical experts more prestige and put them in a different salary band. However, the title causes some level of mismatch in expectations. Technical experts, like integration experts, security experts, and so forth, may not be playing the role of the architect, unless we define the role as "solving hard problems."  Still, while architects surely do solve hard problems, we can't define the role that way; that would be saying software engineers don't solve hard problems, which obviously is not true!  Architects address a particular set of hard problems—yes, the architecturally significant ones. To do so, they partner with others, including "structural engineers" or technical experts, tech leads and developers.

2/9/08 Getting Past But

Getting past but! A guide for architectsFlying out to a workshop this past week, I was thinking about how many times I get told "Yes, but..." and I decided to write a book called "Getting Past But: An architect's guide to moving elephants." (I'll redraw the cover image idea some other time, but I expect you get the idea.)

Well, I was barely hours into the workshop when the first architect walked right into the "but" trap, and I flashed up my book cover idea for a cheap laugh. Then, when I was talking about innovation and the role of architects, I don't know what possessed me but I said "when we put architects in at the rear end" (indicating my elephant sketch) "we might as well give them a shovel because all they can do at that point is damage control." The next time I looked in the mirror, this is what I saw... 

Aren't you just so glad you stopped by???

Alright, it'd be better if you didn't answer that. I've already decided that confined to total introversion is where I definitely belong!

"Whether you think that you can, or that you can't, you are usually right." —Henry Ford

[Oh, yeah, thanks Scott—another "but" argument?]

2/10/08 Getting Past But: Take 2

Strategy and architectureJoking aside, the deeper issue I want to deal with, is the schism between strategy and architecture. Dana Bredemeyer and I have been making points about delivering on CEOs' call to growth through innovation by including architects in strategy formulation (value discovery) and fully enabling the architect role in strategy implementation (architecture is the translation of business or product strategy into technical strategy and leading design).

Naturally architects get that technology plays into innovation in all kinds of businesses, not just those readily identifiable as technology companies—including those for whom customer intimacy or customer experience is a driver of differentiation. And the response is "yes, but..." For the most part, "but" is along the lines that strategic management doesn't get it. And marketing doesn't get it. So architects are brought in at the rear end, and ... yes... damage control is then the relegated domain of architects. Well, it is not usually so bleak, because software people are creative. But they have to get creative about being creative, which is a misapplication of creativity, when you think about it.  

Visual strategy model from Bredemeyer ConsultingFrank Kelly gave our "Enterprise Architecture as Strategic Differentiator" paper a score of 3 out of 5.*** I'm still trying to remove the dagger from my chest! On the up-side, he gave our "What it takes to be Great" paper a rare 5, and our rather-in-need-of-an-update "Role of the Architect" paper a 4, so I have not pulled Frank from my Christmas card list. For those of you who are now wondering why you didn't get one, don't worry, I don't actually send out Christmas cards; I only plan not to. 

So, does this aside have any relevance at all? Well, though the "EA as Strategic Differentiator" paper focuses on EA and strategy, I expect that a software application/product architect could be persuaded to see the relevance. Architects translating business/product strategy to technical strategy need to understand strategy, and that's my quickie tutorial on business strategy for architects. Since no-one is out there saying this for me, I'll make so bold as to say it covers what is essential in strategy (see figure at right), and no architect should escape reading it. And no architect should allow their management team to escape reading it. And no architect creating a reading list for peers should escape recommending it—yes, Rob Daigneau, that includes you. Ok, so one could take this card list thing too far... Really, all I wanted to do was link to Rob (so we can all peek in on his SOA patterns book progress from time to time). Beside, his software architect link list is really first class, given that it gives Bredemeyer considerable emphasis. He doesn't recommend this journal, but, hey, unless you are Mark Mullin, you're not recommending it either!

[If you're just tuning in, this might help... I realize I take some risks showing up as myself, not just a dry professional projection of myself. I do this, because I like to work with people who believe that our work lives should be whole lives, playful and fun, yet seriously productive, creative and investigative yet focused and pragmatic.]

[*** To put that in perspective, we get do get high-fives on that paper from enterprise architects.]

2/11/08 Getting Past But: Take 3

Charlie Alfred walked right into my carefully laid "but trap."

"In my experience, the “business strategy vs. architecture” dilemma is pretty much as you describe it.  Architects should participate earlier than they do, but I think there are several factors which contribute to why they don’t: 

  1. Strategy, like authority, equals power.  Those who have it tend to be reticent to relinquish it.  Loosely translated: “Decision X is good for my career (or position), don’t try to dissuade me with the facts…”  The “pointy-haired” boss in Dilbert is a humorous archetype for this statement, but sadly, this archetype seems all too prevalent in the business world.  Recently, I had the opportunity to evaluate an excellent static code analysis tool.  The vendor’s proposal was for unlimited use for one project (~15 people) for 2 years for about a $50K license fee.  At the time, this product was a month from going to beta, and had over 2000 defects, with over 300 P-1’s.  And yet, the $50,000 purchase order had to be approved by the COO of an $800 million public company!  Her response: “With this money, we could hire two more people in India.”  Yet this is exactly the kind of thinking that led to the original problem.

  1. “Competing solutions” tend to drive decisions rather than understanding the problem.  In the book, Getting to Yes, Fischer, Ury, and Patton discuss “position-based” vs. “interest-based” negotiation strategies.  Position-based negotiation starts with each party taking a position (their preferred solution) and trying to bargain to a common solution.  In interest-based negotiation, the parties put their positions aside and try to understand what the goals and priorities are.  Not surprisingly, where position-based negotiations are prone to deadlock (e.g. labor union negotiations), interest-based negotiations can find creative solutions that leverage the fact that the parties may have different value or cost curves for different benefits.

    he obstacles are that problem-centric (e.g. interest-based) analysis can take longer and require a deeper understanding of the whole problem.  Good architects tend to be effective systems thinkers, and as a result tend to be able to handle this complexity.  Some business leaders are also good system thinkers.  However, many prefer snorkeling to scuba diving and resist having the discussion go here.

  • Software, unlike hardware, networks, or manufacturing plants, is invisible.  In the real world, we know that the number of concurrent production lines is a function of variables such as:

    • manufacturing,

    • machines and their floor space & power requirements

    • machine operators, and

    • other variables such as up-time

    We also know that plant capacity is a function of: the number of lines, the throughput of each line, and the number of shifts (assuming no interdependencies between the lines).

    Software fails to benefit from the physical world visibility.  As a result, it is much easier to make unrealistic, simplifying assumptions, such as:

    • splitting technical people 50/50 between two projects and not accounting for immersion time

    • setting up a project without a full-time product manager or business sponsor

    • having 3 or 4 top-level projects depend on 3 or 4 low-level infrastructure projects without having anyone to coordinate the tradeoffs or interdependencies

  1. Software leads to partial areas of competence.  If somebody has experience with one area of software, they often tend to believe that what they learned there applies to all other areas.  In the real world, just because you have a license to drive an automobile doesn’t qualify you to drive a motorcycle or 18-wheel tractor trailer.  Yet in software, why should we believe that hard-fought lessons learned in speech recognition (a technology) will necessarily help you in developing an enterprise-class product framework?

  1. Significant complexity, time pressure and information overload discourage deep thinking.  Consider the 2008 presidential primaries.  The problems that face our nation (economic recession, health care, the war in Iraq, public education reform, federal government deficits) are complex and interrelated.  It is quite difficult for any of the candidates to articulate their strategies in any significant level of detail.  And even if they did, how many of the electorate would want to digest and understand them, never mind do a comparative analysis.  So what do we get instead?  The candidates send shallow, digestable slogans like “change.”  When things are complicated, time is short, and people have limited capacity for new information, a chocolate bar can be more satisfying than chicken marsala.

  1. Software, as a largely invisible commodity, is prone to unprovable assertionsImaging that somebody asserts, “By using C# and .NET to implement this project, it will be done faster and cost less than if we use Java / JEE).  Perhaps this is a true statement, perhaps it isn’t.  But how would a business person know?  Maybe they have been reading magazine articles touting some .NET or Java capability.  Maybe they had a particularly good or bad experience with .NET or JEE in the past.  OTOH, maybe the topics of the magazine artlcles don’t really resemble their problem, or their prior experience is cause by factors other than the technology platform.  In the retail world, we can refer to Consumer Reports or J.D. Powers, or Angie’s List for guidance.  In the software world, reliable North Stars that you can navigate by are difficult to come by. "

work with what we're handed. The shovel. And the elephant. Charlie Alfred, personal email, 2/10/08

These are all excellent points, important to make and more completely articulated than many of the "but" arguments other smart architects present to me. Still, the point is not that we architects don't face big challenges. The point is that we have to work with what we're handed. The shovel. And the elephant.

I used the elephant metaphor as an allusion to a book I have long liked—it is by Rosabeth Moss Kanter, and it is called When Giants Learn to Dance (it was titled Teaching the Elephant to Dance when I read it not too long after it was published in 1989). There's also a book by IBM's Gerstner called Who Says Elephants Can't Dance? (2002). I haven't read this latter, but Moss Kanter's book was a quiet landscape shaper entering the 90's; incidentally, Gerstner took the reigns in early 1993. Anyway, to make a long story short, I think we have to work at getting the elephant to budge, and to do so we have to get out front and lead. Pushing elephants, like pushing string, is pretty ineffectual.


Tangential Aside

Speaking of Getting to Yes—yes, I am aware that one of the co-authors also wrote a book titled Getting Past No. Even so, the double entendre in Getting Past But is pretty irresistible; Dana made the point early on that when one signs up to lead a workshop, one is signing up to being an entertainer. I didn't know that it would also mean corrupting my pure and intellectual side. Oh well, if bawdiness was good enough for Shakespeare... Ryan, by the way, is endlessly quoting the Bard, for his class is acting A Midsummer Nights Dream and Ryan (still 9 years old) can recite most of the play (in mostly original Shakespearean English—they're using Shake Hands with Shakespeare). 

In his inimitable way, Charlie's contribution (above) is thought-provoking and funny. And I just can't let the election piece dangle so provocatively. You see, I had this thought... During the last election my daughter (Sara) decided she would be the first woman president of the United States. And, I'm very much afraid she will be. Ouch, ouch, ouch! Political commentary. Only for the brave. But really—a boxing metaphor coming off super-Tuesday? There is much that I like about Obama (like, well, he's intelligent and has the great leader's mastery of rhetoric). But that was a blow below the belt. It usually takes a woman to point stuff like that out. For instance, it took a woman to point out that Justin Etheridge hadn't found any balding bearded women who'd heralded in some new frontier of the software field. Long-haired he could have found. But hey... Ok, so Justin recovered himself and found some women for part II. Still, won't it say something about the US if it takes fear of a woman becoming president to get an African-American elected? Or vice-versa? What an election—sexism, racism and agism all working undercover here. Even so, if America was really forward-looking, we'd elect Hillary now just so that we don't have to end up with Sara as the first woman president! That said, even a few years ago Sara had an excellent platform—in her manifesto, a key item was taking turns, and she severely admonished George Bush for not playing fair and giving John Kerry a turn when he wanted one. The things girls think about...

Along the lines of the things girls think about, I was sickened when the media called Hillary's laugh a "cackle"—deliberately associating her in the subconscious mind of America with "witch" and totally, totally sexist and unfair. Did you even notice? Insidious stuff!

{9/12/08: Ok, Sara B. is not so bad that you need to vote differently just to get another woman in the White House first! Given recent events, I just had to let you know that.]

2/12/08 Seeds in the Desert

You wouldn't plant seeds in a desert unless you had a way to get water to them. Some organizations are just inhospitable to architectural seeds: wandering in the desert*, rampaging elephants and all that. So, while I generally urge taking ownership of the excuses we erect with "yes, but," I do recognize that there is a lot of spread in receptiveness to (intentional) architecture, and some organizations are intensely hostile to it—intense to the point where the architect has to decide whether he/she has the passion to persevere, or find a new environment. We wouldn't have the US Constitution if it weren't for the perseverance of James Madison. Amazing Grace is a great story of hard-won victory against strong and persistent opposition. Across history, important changes have been wrought by determined individuals and groups. They have worked doggedly, and with political savvy to navigate around obstacles. Even so, sometimes taking one's passion and talent to a new venue where it can flourish is a good move, big picture. Along those lines, I have a couple of backlogged architect job posts I need to add to the jobs listing page on the Resources for Architects website [ok, that's done].

And, I have to say, for all her sweetness, Sara is here to remind me that it can be downright unpleasant to be on the receiving end of dogged persistence! Endless nagging, never letting no be no, can raise it's own set of barriers. Oh yes, Ryan and Sara are quite taken up with the Getting Past But idea. When Ryan was about to answer "but" to some get-ready-for-school urging this morning, he substituted "elephant" for "but" in his sentence. Getting Past But is raising awareness of how readily we hide behind ... "elephants." 

* Dana uses the image of wandering in the desert when talking about architects who have to work without strategic direction. In "What it takes to be Great," I wrote "Enterprise architects must choose a path: wander in a wasteland of insignificant and ineffective decisions or make a laudable contribution to the excellence of their enterprises. Having a clear, articulated strategy and a way to move from that strategy to activities and decisions that align with it, will help you make a strategic difference in your organization." Clearly, if the organization is an architectural wasteland, then the architect has to choose whether to work to change that or leave, and this will in part depend on the prognosis the architect assesses for strategic and cultural change within the organization.

2/12/08 Intentional architecture or accidental architecture

Grady Booch contrasted accidental architecture and intentional architecture. What we get depends a lot on the organization and on the architect(s).

In one scenario, accidental architecture is simply a trial-and-error response to novelty. In another, accidental architecture is the result of accommodation after accommodation in response to environmental stimulus—change in technologies, change in needs or interpretation of needs, a broadening market base, and so forth. Thus, accidental architecture might be quite well adapted to the current environment. But it may not be. And in another scenario, developers are allowed to make any decision they wish either because there is no architecture or the architecture is not taken seriously. Then the architecture is accidental, rather than intentional, and the real strategy of the business is emergent from their decisions, to the extent that what the business is able to do, is dependent on its products, services, or operational and intelligence systems.  

Strategy determines differentiation; that is, strategy seeks to be a shaping force in the competitive landscape. Intentional architecture takes the current environment into account, and explores how to deliver differentiation not through ad hoc adjustments to the competitive environment, but by delivering the capabilities demanded by the strategy.Architect under the capstone

Of course, even intentional architectures tend to be compromised under schedule pressure and pressure to tune to specific/local environmental (use context) concerns. Accommodations seem adaptive, and they generally are—short-term. But near-sighted accommodations can quickly erode into kludginess that stifles future agility; we know it as the big ball of mud. Keeping the architecture clean, simple, uncluttered, is a big job. And an important one. The architect should be around through implementation and evolution, to stand under the capstone as it is lowered into place, to be held to that accounting, and to hold others to their commitments, too.

2/13/08 From Seeds to Levers

I just have to share Charlie's response to my "seeds" piece:

"It is an architects’ job to be a systems thinker, a bridge builder, a diplomat, and a change agent.  One interesting thing is that many hiring managers don’t quite understand this.  They see an architect as a senior technical leader of a small development team.  As a result, the architect can easily find him/herself in a position of little leverage.  Archimedes said, “Give me a lever long enough and a fulcrum on which to place it, and I shall move the world.”  There’s a third, unstated phrase in this quote – the position of the fulcrum.  If it is too far from the object and too close to your hands, you can’t use the lever to move anything."

Charlie Alfred, personal email, 2/13/08

The lever image is such a helpful one! We have to help our managers understand where that fulcrum needs to be placed!

2/13/08 Books and Green Things

Daniel Stroe recommended that I read Invisible Engines: How Software Platforms Drive Innovation and Transform Industries. And I will, I will. In the meantime, I've returned to "Education of a Reluctant Businessman" and I'm really enjoying Chouinard's stories, design perspective, and call to ecological consciousness.

I lift my head from the sand, and discover the world became a more frightening place while I was burying myself in the distractions of work. Madi Hirschland, of microfinance fame, is working to raise awareness locally. Indiana, you see, is fighting for top spot in the nation's worst offenders list when it comes to global warming. On the Forbes list of greenest states, Indiana was 49th, followed only by West Virginia! And Indiana is ranked 6th in per capita carbon dioxide emissions. It's not that we consumers are so much worse than others in the nation, it's more that our electricity is produced by the biggest pollution offenders—coal plants. And, apparently, we export electricity—to our greener neighbors to the west??? And we (Indiana) have no state incentives/subsidy for installing solar panels! Still, the US is second only to China in CO2 emissions. And one could argue that China's pollution is fueled by our consumerism; we didn't just outsource our manufacturing to China, we outsourced our pollution—but the impact is global. The New York Times says: "Every week to 10 days, another coal-fired power plant opens somewhere in China that is big enough to serve all the households in Dallas or San Diego." 

This whole global warming thing is a mess. Our neighbor has been researching global warming for years, from an academically serious environmental physics angle. His concern has been growing, and he drives a hybrid electric car or rides his bike, even in winter. In Indiana, where coal-fired power plants are the biggest global warming offender, an electric car would make for a conundrum. While it is hard to tease out the bottom line impact of our "carbon footprint," it is clear that we need a small car for day-to-day errands. And that's just for starters. er... I think I need to do some more work now. The "real world" is much too depressing! Ah, elephants.

Mohandas Gandhi said "Be the change that you want to see in the world." First, we have to see the world. It looks much like it did yesterday. Unless you're a polar bear. Or you just read that 1 in 8 women get breast cancer and it is the leading cause of death among women aged 35-54. And your kid has to go to Alaska to eat the fish he catches. Life's simple pleasures, and life at all, are at stake. More or less. And so forth.

This will impact us. More than just the ("do no evil") Googles and Amazons will have to look at their power hungry ways (the concern even made Dilbert—this link goes bad on 3/11). And we have to look at personal and business consumption. Right at a time when recession threatens and pulling the plug on spending could send the world into a tailspin. Conundrums a plenty!

Anyway, Chouinard and Patagonia set out to provide an example to the world, and they're not letting conundrums hold them back. Hard choices can be made, if you have principles to guide you. But take heed; the world is changing fast. I was looking at CO2 emission rankings for 2002 and China was below the bar in terms of offenders, and with rampant industrialization it is now top, and growing. And our greedy ways keep us in an embarrassing position. Obama says: 'And I will send once more a message to those yearning faces beyond our shores that says, "You matter to us. Your future is our future. And our moment is now.” Those are not yearning faces any more. Those are pleading faces, and we need to heed them. And Hillary has a plan to do that. Whatever your political leaning, the world will be better off if you lean on clean.

For counterpoint, see Michael Crichton's essay on Complexity Theory and Environmental Management.

2/14/08 Books and paper things

Paper (digging into architecture archeology) I speed-read yesterday (don't quiz me on it):

Here's a little piece I did that alludes to my approach to architecture archeology.

Books I've returned to reading this week:

Books I'm looking at buying:

I'm interested in system health and business intelligence, so want to ramp up more on event-based systems. Do let me know what you've found helpful in the event-driven architecture space. My interest in SOA and EA needs no comment. Catalyst Code is the follow-on to Invisible Engines. Doing What Matters is by Kraft/Nabisco/Gilette CEO Kilts. Not relevant to IT/architecture as strategic enabler? What about this:

"During my tenure at Kraft, we developed something called IMI - Integrated Marketing Intelligence - which gave us state-of-the-art insights into our brands, their categories, and consumer dynamics; how responsive they were to different forms of advertising and promotion; how much spending was optimal; and much more that will be explored later [in this book]. When we spent marketing dollars at Kraft, we were truly investing in brand building." (Page 94, Doing What Matters)

How you put together information to create business intelligence is strategically interesting. It is taking information systems to the next level; not just replacing route work by digitizing it, but using information and events to support competitive intelligence.

Books in my cart:

What am I missing???

2/14/08 Happy Valentines Day!

"The sheer wonder, the joy, of working with architects, is that I get to interact with people who shine; smart, creative, investigative, multi-dimensional people. People who lead me." moi, 10/5/06

Happy Valentines Day to you!

2/16/08 Taken Literally

Someone pointed out that there was no scaffolding in my "cartoon" of the Roman "architect" standing under the arch as the capstone is lowered in. I had to smile! Any guesses?

2/16/08 "3 Circles" Innovation Model

We developed a "3 C's" (capability, commitment and culture) model for architecture readiness assessment. Now we have another "3 circles" model (knowledge of customers, knowledge of capabilities, and knowledge of the industry) for innovation. It could have been 3 C's, but using competition instead of industry is strained and misplaces attention. Innovation sources: customer and technology capabilityThe idea is to beat competitors, but not in an incremental nose-to-nose feature race for a market position, but rather by understanding value networks and flows, and opportunities to truly differentiate by delivering unique and compelling value to customers and users.

Technology-driven innovation is technical capability in search of a use. Like Segways finding a niche in airport and mall security. Market-driven approaches seek to understand the day-in-the-life of the customer, and find ways to add something the customer will value.

Each approach has worked. But if we want to make innovation more the way we do business, we need to look at putting insight into what is possible together with insight into what is desired, passion for what technology brings to the table together with passion for making a difference that customers care about.

We need to add another circle if we want to go beyond simply finding opportunities, to sifting for those that are differentiating—they make our products or services, and our business, stand out in the minds and experience of our customers.

Differentiation sources: customer, technology capability and industry knowledgeThe center of expertise for each of these circles if insight, experience and influence is different: marketing and business units, architects, and strategy planners and strategic management. Innovation happens when you put these together. Yet in most of our organizations, job specialization and role turf is pushing these circles apart.


Aside: I went looking for a Tom Peters quote on creativity and I found this "The Birth of the IPM"—I looked for the date to see if it was an April Fool's Day post... Grin. Well, it sure puts me in context! I'm a staid product of the engineering world, after all. Creativity is all very well, as long as it serves getting real work done!

2/18/08 Don't Go Big Bang!

When we talk about creating a compelling vision, we are also careful to talk about creating a path to the vision that does not overstretch the elasticity of the organization. To illustrate incremental change and delivering value before resistance sets anchor, we have long been telling the story of Jaime Lerner's creation of the down-town pedestrian mall in Curitiba**, Brazil. You can read our version of the story in the EA as Strategic Differentiator paper (pages 20-21) that I mentioned earlier this month.

Find the value. And find a way to quickly demonstrate that you can make real on it. This is just as important to making a personal shift, like "getting past but," as it is to project visions. This is about incremental change, but it is also about being careful to take steps that deliver early value.

** If you don't have and don't want a NY Times account, google "jaime lerner new york times" and you can get to the article without signing in... Or not; the command and control thing I reserve for Ryan's dog. I did see a woman wearing a t-shirt with the following on the back "Sit! Stay!" and I wanted to ask her where she got it! There are so many ways I could use that one... ;)

2/21/08 Grady Booch's Memoir (or, should I say, Mine)

Grady Booch posted his "memoir" on the 5th anniversary of becoming very rich, or something like that. :)  It is an interesting read. Of course, he didn't mention that Fusion was the first integration of OOAD methods, including Booch and Rumbaugh's OMT but also Schlaer-Mellor, Cunningham and Wirfs-Brock. Oh yes, he was writing a personal perspective on Rational's history, not the history of OOAD.

It is an interesting history; one I'm so glad to read; thank you Mr. Booch. That said, I just wouldn't want the industry to forget that other factors influenced Rational's move to integrate and then lead the push to standardize OOAD notation—notably the proliferation of OOAD methods and their idiosyncratic syntaxes (hard for a tool vendor to support such an explosion, and the explosion fractured the market). I have to say (with great respect) it was a strategically masterful move, one that should be written about in strategy texts dealing with market leadership through standards leadership. We were creating Team Fusion, the next generation of Fusion that was to do two main things: address architecture and pull in Todd Cotton's work (inspired by Tom Gilb's Evo) on Evo-Fusion or evolutionary development (a precursor of agile, and as I understand it, an influencer of Scrum). We decided to throw our hat in with the UML standardization effort, and Martin Griss and Reed Letsinger were HP's key men on that one. Martin started to collaborate with Ivar Jacobson, and that led to their book on reuse. I continued to focus on architecture, but no longer exclusively architecture for object-oriented systems. Anyway, Booch and Rational's leadership was a clear catalyst to the UML effort. Still, the community got behind it, and it is good to remember that community support, including the collaboration of other leaders in the OOAD space, were also instrumental in UML being developed and embraced as a standard. 

I do want to say that I have had very strong respect for Grady Booch from those days working on Team Fusion. I gave presentations on Fusion at conferences and at OO shindigs, and had to explain both what made Booch's contribution great, and what made Fusion an advance on what had been done by Booch, Rumbaugh and others. One has to pay careful attention to do that; from Booch I learned so much, and that positioned me well to learn still more from Fusion. Of course, Fusion had the advantage of coming in the wake of Booch (the method), OMT, etc. and learning from HP project experiences with these methods. Fusion set out to be a true method supporting the decision lifecycle from analysis through design. For example, in Fusion, designing system dynamics is integral to designing structure. We have learned a lot since Fusion. But Fusion, as far as I'm concerned, was a big milestone on the OOAD path, and I would not want it to be glossed over by the tellers of OOAD history. Of course, my opinion here is not unsullied by vested interest. I owe so much to Derek Coleman, the "father of Fusion," and respect him greatly. He was a demanding task master, and brilliant. Being British, compliments make Derek excruciatingly uncomfortable—even when they're being paid to someone else!!! :) 

Well, I'm happy Booch used the opportunity to tell the story, for it is an important story in our field, and I was personally very interested to learn more about Booch's role and contributions to Rational as well as OOAD. And it gave me an opportunity to say I think Derek Coleman and Fusion should also hold a watershed place in OOAD history. This doesn't at all diminish the role of the pioneers who launched OOAD, notably Grady Booch.

Moreover, I have been privately lamenting that Grady's early blog years left a much richer trace of his thinking and exploration, and I miss that and this history did a bit to assuage that sense of loss. Grady figures among the most important leaders in our field for good reason, and for all that, he remains a nice guy with a sense of humor.

2/21/08 Architecture Documentation: Educate by Providing Value (lighthearted for good health)

I mentioned I've been reading Let my people go surfing (which I like to refer to by its subtitle, because for most of us engineers-turned-architects it is the subtitle to our personal journeys: The education of a reluctant businessman). Well, many things have struck me which I still need to note in this journal for preservation of my thought. But this is the part that pertains to my present train of thought: Early on, Patagonia established a practice of educating it's customer community with essays in their catalog. So, they educated customers on the damage that pitons were doing to rock faces. Yes, they went after their own core business, deliberately cannibalized it, and educated their customers on their disruptive innovation, all via a 15 page essay in their catalog. Now, if you think software engineers don't read, try mountain climbers! Yes, like any community, there are some who read and some who read... let's just say... less. But an essay in a mail-order product catalog. Hmmm. They did this again with layers. They invented an undershirt that wicks away moisture (modeling diapers), and had to educate their customers on the value proposition of layering. They treated their customers like smart people who can and do read when it is of personal value to them. Hey, what a concept!! Shall I say that again: let's treat our customers like smart people who can and do read when it is of personal value to them! Of course, our customers are software engineers, so, glory be, they are smart people (and many are climbers, at that; extreme sports and extreme programming seem to go hand in glove)! The heart of the matter isn't getting them to read. The heart of the matter is writing what will get them to read.

Architecture document and system modelingNow, I've been reading a client's (proprietary) architecture document, covering the architecture for each of their systems. It is to their company what Booch's Handbook will be to the world, and more. Very impressive!! Still, is it for every business person in that company? Good gracious no! Is it for every software engineer? No again; at least not in absolute terms. But parts of it are. Is it for every architect in that company (actually, it's a division of a company, but a fairly big division). Absolutely, in absolute terms. Every architect should know at that level every other architecture in the division. This is not frequently practiced, because too often architectures are implicit in the code and the architects can't afford to go spelunking in more than one codified architecture. But imagine if all the architectures in your division were documented and in one spot (where the owner architects have to keep it up-to-date); wouldn't that be empowering? Enable synergies and reuse, facilitate alignment and consistency, leverage learning across projects, and so on.

Different views need to be crafted for different stakeholder communities, and for strategically influential stakeholders, views should be tailor-made for them. And there's a standard for that; that would be IEEE 1471, the "standard" for architectural description. It essentially says architectures have various stakeholders who have concerns and architectural views should be created to address stakeholder concerns. 

We have to remember that we engage differently with the written word than with the spoken word, and this makes the written word very powerful. Once we have chosen to read words, they run in our heads like our thoughts. We can challenge them in an internal dialog, pass them through the test of our own experience and reasoning, without losing our place. And if they wax too flowery, we can disengage. So, enough of that.

Bottom line—write about your architecture, but make it interesting and valuable to the intended readers of the document you are writing. If you explain some crucial aspect of your architecture to the engineers it will impact, adding to the mix the considerations you took into account, the driving forces, your insights and experience that made your choices make sense, odds are they'll find it interesting and valuable. But, I'm betting on your experience and your ability to communicate it in diagrams and written words.

And, because unintended use may be made of your document, be explicit what the intended use is. Otherwise unanticipated "quality requirements" will be levied against your document, and it may come under fire only because it is being used in a way you didn't scope for.

Now, to be clear, this journal is first and foremost for me. I am my own harshest critic, and I don't wish to be challenged from that rank. And then this journal is for a small and very select set of architects who are extraordinarily smart, who have an intelligent sense of humor that catches the many layers of satire, irony and wit that permeate my writing, and who are so comfortable with their own rare and outstanding qualities that they can stomach my occasional indulgence in self-congratulation. Ok, quickie quiz: just what part of this is satire and irony and what part wit?

Ok, that's how not to do your document scoping! This we call leading by counter-example.

Uh, I think I'd better go now.  Bills to pay. Life to lead. That's me I'm talking about, though clearly you're procrastinating too.

I was joking with the trademark thing (me, joke? no!), and then I thought I'd better check in case I was infringing, and phew, faith restored in humanity, leading by counter-example is not trademarked! But (sinister laugh) now I have dibs on it... ;)  Bills! That must be it. I thought it was Scott Andersen's bad influence. Really Scott, humor in the middle of the day?  At work at that! Tsk!  Tsk!   Then again, thanks to Scott, Dana is in less danger of a heart attach today. Hopefully, I've done my part for you. But, only if you're in the small and select set... you know, awesomely smart, great sense of humor, and ... you have a certain amount of tolerance for my quirkiness...

2/22/08 A Note on Minimalism and Documentation

Ryan is the master of minimalist or parsimonious writing. Of course, in this journal I'm on the other extreme and I recognize that parsimony is hard work. Ryan labors at his strictly elemental reports, with not a single superfluous word. He can summarize an entire novel in half a page, including every important element of the plot and character development. I takes him twice as long to write his book reports as it does for the others in his class who write 10 pages or more. And then, are they interesting? Well, only as an intellectual exercise in assessing accuracy and completeness...

There is a difference between minimalist architecture (keeping the decision set minimal, and the blueprint elemental) and doing what it takes to breathe the architecture to life in the minds of the development community, and to keep its sponsors fully on board as reality throws fake feeds at the scrum. The management team may need sound bites with a liberal sprinkling of "innovation," "excellence in strategy execution,"  "business alignment" and "attract the best talent." (No, I'm not leaking your competitive strategy, I'm leaking everyone's competitive strategy!!!  Hmmmm! Oh yes, context matters!) But the point is, if our system is strategic so that successfully getting hearts and minds engaged is crucial, we need to think about our audience and deliver our architecture to them through different routes. Participation is one. And interesting reading that delivers value to the reader is another. See the Outcomes and Deliverables section (starts on page 5) of our Meta-Architecture chapter.

Minimalist architecture papers:

2/22/08 Architect Jobs

I just added two more architect job listings to the Bredemeyer Resources for Architects site (so in the last week I've added listings for a software architect, senior data architect, senior enterprise systems architect and enterprise architect). I think this is the tip of the iceberg, as we keep hearing about internal development and hiring plans that reflect a growing demand for architects, and a growing recognition that architects play a role that is key to value delivery and risk management.

In areas where capital equipment is invested in, there is a notion that these investments have a lifespan, or alternately put, the equipment becomes out-of-date and even if well maintained, has to be replaced. Our software systems, too, have to be modernized. Some approach this modernization by carving up old systems and giving the chunks a new coat of integration paint. This is all very well for systems that are not central to our differentiation strategy. And it may even be just fine as a migration strategy for core systems, where any change is risk. But we do have to think very carefully about where our strategic systems need to be 5 years out, and have an investment plan and technology roadmap to get us there. Craig Jordan talks about the need to envisage the mosaic, when you're creating the bits of tile—the A in SOA, that must come first, if we want architecture not accident.

Yes, a growing demand for architects, so we can chart new systems and bring old ones into the future. A wave of expertise will be leaving our industry as those who pioneered it take their bows. At the same, we stretch our complexity boundaries in ever more ways, raising the demand for innovators and complexity handlers. There will be more opportunities for technical specialists or "structural engineers," and there will be more need for the architects who create the "big picture," the design that allows all the pieces to work seamlessly together to deliver differentiating value in all its dimensions, from function to quality to life-cycle cost.

2/22/08 Einstein versus Zen Master

Einstein said:

"Perfection of means and confusion of ends seem to characterize our age.”


Yvon Chouinard said:

"I've been a student of Zen philosophy for most of my life. In the practice of Zen archery, you forget about trying to achieve the goal—which is hitting the bull's-eye—and instead focus on all the different movements of shooting an arrow. You practice your stance, reaching back and smoothly pulling an arrow out of the quiver, notching it on the string, controlling your breathing, and letting the arrow release itself. If you've perfected all the elements, you can't help but hit the center of the target. The same philosophy is true for climbing mountains. If you focus on the process of climbing, you'll end up on the summit. As it turns out, the perfect place I've found to apply this Zen philosophy is the business world."

p74-75, Yvon Chouinard, Let my people go surfing, 2007

Nature's Zen art

Nature's Zen Art, photo credit: Dana Bredemeyer

That sounds like perfection of means to me. But it is perfection of means without confusion of ends.

When an architect we'd worked with took on a chief architect position within the same company, but a new business area for him, he said he was comfortable because he knew VAP would carry him through. He'd used VAP on previous projects, so was confident that if he went through the VAP movements he'd practiced before, he'd nail the target. And he did. Because he let the process lead him, he got the target clear, and then he let the process line him up to hit the target.

It is pretty neat, being more than a decade into this, because we hear more and more of these stories from architects who feel they owe us a nod. Even so,

'I have to agree with David Christiansen: "I’m not convinced there is such a thing as a methodology or process that can produce good architecture." People create great architecture, just like it is people that create great software systems.'      moi, 8/12/07

That is to say, VAP didn't create great architects, but great architects are saying that VAP helped them reach their targets: good, right and successful architectures. A good solution: technically sound. The right solution (product, application, system, etc.): it meets stakeholder needs, where the voice of the customer, the voice of the business, and the voice of the development team, are taken into account. And it is successful, in that it is used and is delivering business value. We often get so heads-down-focused on doing the product right (or at all), that we forget to question whether it is the right product. We can't birth or evolve software solutions without writing (lots of) code and we get so focused on code as the holy grail, that we overlook the huge, huge waste in our industry because we forget that getting the right solution concept takes work; needs talent and time to incubate.

We can argue back and forth—for example, one might argue that we need to fail sometimes to create the kinds of gains that we see coming from software. Or we might argue that what we count as failure, isn't really. It was simply failure to estimate correctly. Or failure to judge the technology gestation rate. Or some such failure to establish the right success criteria. But to me, where our failure costs most sorely is in human terms. In terms of the software developers who throw their hearts, brains and serious years of their lives into making something, only to have it be cancelled before it stands the market survival test.  

Put me on a rock face and all the process in the world won't get me to the summit. A hiking trail, yes. A vertical drop? Never! I leave adrenalin sports to my brothers. I got the cautious genes, but more than that, I don't want to hurt the people I'd leave behind. But hey, it makes me really good at risk management, for it is not risk that I don't like, only what would be for me unconscionable risk—the measures for which are context dependent, and often personal.

2/24/08 Update on Failed Projects

In May 2006, I collected together links on software failures as well as some links on learning from failure (see Project Wipe-out).

Now, if I was doing research on failed projects, I would want to separate those that are cancelled early from those that are cancelled late, from those that are a market failure. Those would be interesting and relevant statistics, for it would better help us track the kind of failures we want to invest in, from the kind of failures that create waste. We want to fail fast and cheap; if we're innovating we need to stretch and have a tolerance for exploration and course resets. We don't want to fail fast and cheap all the time; but enough to find the solutions that will win out in the market.

I would also want to track not just how many projects are late and over-budget, but how well they do, once they hit the market. I've been close to enough of these "late" projects to know that the market is the ultimate judge of a project's success. Being late hits team morale like an avalanche that is hard to dig out from, and may require digging deeper into the investors pocket book than they may be willing or able to go. But if they make it past these challenges, how often do they meet with market success? Does project lateness correlate with failure in the market?  

But, I'm not running those research projects. Here's an update to what's "out there:"

"A study commissioned by the U.S. Department of Commerce's National Institute of Standards and Technology (NIST) found that software defects cost the U.S. economy almost $60 billion annually. The study also found that about 80 percent of development funds are consumed by software developers identifying and correcting defects. In another study, The Standish Group reports that canceled software development projects cost organizations US$55 billion dollars annually."

Geofrey Bessin, Business Value of Software Quality, 2004

70%-80% of new product development that fails, does so not for lack of advanced technology but because of failure to understand users needs. Harvard Business Review, February 2007

One remarkable thing is that there are many out there still using the 1994 Chaos Report statistics, in which it was reported that some 31% of software projects are cancelled, as opposed to the 2005 Standish Group report which apparently found that 23% of projects were cancelled (I don't have access to the 2005 report, but these stats are reported in Why Software Projects Tend to Fail by Cohen Oren, 2008). Did we get more tolerant and give projects more leeway on schedule and budget, did we get better at not starting doomed projects, or did we get better at establishing and hitting the target?

2/24/08 Requirements as Invention

Anyway, the big take-away is that Einstein is still right. Software projects too often fail because there is a confusion of ends! And our pursuit of perfection of means too often detracts from establishing the ends. A perfectly constructed system is only a perfect system if it delivers sufficient value to its stakeholders.

Einstein also said:

"If I had 20 days to solve a problem, I would take 19 days to define it."

No, I don't see that as an argument for waterfall! I see it as an argument for applying agile principles to figuring out what the problem is, but I don't believe we need to use (only) code to do that. Building architects use drawings, 3D models, and simulations to convey the design to the stakeholders so the stakeholders can perform thought experiments to see if the design meets their needs. We need to do more of that.

Requirements don't exist out there in some extant state that just has to be captured—like cattle that just have to be corralled. Requirements are an invention that come from an interaction between current need, future (invented) capability, and future need that springs from the interplay between that capability and the new world it creates. So, yes, we need to involve the architect in coming up with models and talking stakeholders through the thought experiments that will help them figure out what their problem will be, when the system is in place; that is, what their real requirements are for the fielded system! (If I think of replacing a paper-based forms system with an online forms systems, and do not think about the immediate next things my customers will want the minute online forms are in place, I have done them and my development team the disservice of leaving everyone less than satisfied. After all, we know, the moment we think about it, the next thing they'll expect is integration with some other system to turn that data into business intelligence. And what else?)

To make it more clear why our status quo approaches to requirements and architecture lead to failures, in early "architecture appreciation" courses for managers, I developed these two slides:

Here's the architecture


Ok, so that's making a point by over-emphasis; still, even our best used-patterns salesman uses that tactic. :)  But, yes, too little requirements and too little architecture leads to a baroque concoction of best guesses and interpolation.

Links to material that didn't make my earlier list:

2/24/08 Kiva Widget

Something along the lines of HelpMatch, but here and helping people in need today:

This is similar to the Heifer widget that you can plop on your blog, and is really neat! Kiva is a microfinance organization that connects lenders of small loans to individuals, to help people help themselves out of poverty. Now, shouldn't we be doing this for informal, person-to-person help networks that enable goods (new and used) and services to get from people willing to help to where they are needed?

And I hope you'll be inspired to join the Kiva loan network—do look at the impact ticker that flashes on the left column! See, for example, the story of Danson Ng'ang'a—read all the way to the bottom, for an update in this time of political crisis in Kenya. Good and evil still duke it out in this world, even while we bury our heads in work. But it is heart-warming to see how rapidly innovation and "technology" (online social networks) is being applied to helping the needy.

Another site that is doing something along the lines of HelpMatch-y ideas is Give2Network. It makes an important contribution, though it still focuses on giving help to organizations:

"The team at Give2Network wants to enable people to contribute to their communities. We want to do our part in giving back by giving away free and easy-to-use tools that schools and non-profits normally can’t afford. We recognize that much volunteering revolves around fundraising (selling and buying needless products) and time-consuming tasks such as sending emails, soliciting sign-ups, and communicating with supporters. Give2Network aims to simplify those tasks." Give2Network

It is a good place to look for analogies. DonorsChoose.org is similar to Give2network and Kiva. It is focused on helping public school projects. There are more and more sources of inspiration and ideas.

'Such stories... thrill [Kiva president] Shah. "Dude, seriously, this thing is executionally so ridiculously hard - until it's actually working, and then it's a flywheel effect," he says, referring to Jim Collins's metaphor in Good to Great. "The first crank is really hard, but by the 100th turn, it's just moving by itself. And before you know it, people will quit their jobs and go out and work in Uganda for four months."

Or at least put up $25 and try to find Uganda on a map.'

Jeffrey O'Brien, "The Only non-Profit that Matters,' Fortune, 2/26/08

Ready to help build HelpMatch? Money is much easier to move than goods, but helping with stuff still seems to be on the table.

2/25/08 Architects and Innovation

In the discussion around whether or not architects still write code, the point is often made that architects need to investigate new technologies, and that is where they still keep their hand in the coding game. Bill Barr makes salient points, but I would want to caution that innovation is not just about better means; that is, not just about developer productivity. Naturally, we couldn't be creating the complex systems we create today using Assembler! One might argue that without innovative development technologies, the iTouch/iPhone couldn't have delivered such innovative capabilities. But innovation in software development isn't just about retooling or modernizing software development, deciding whether to hibernate until spring, or make some other framework or technology selection. It is first and foremost about innovating to create products, applications or services that delight customers. But it is also about keeping talented, passionate developers in high gear, and (carefully selected) new technologies generally speaking help boost productivity in of themselves (after the learning curve is scaled), but they also help attract and/or keep tech-star developers.   

That said, those in the architect role, especially architects with broad scope of influence and accountability, may find themselves squeezed on time to code. Chris Kempster, in the comments to Bill's post, goes out on a limb that would come down in flames if Bill's blog was as hot as TheServerSide:

"The idea of IT architects coding is a joke, it's akin to building architects laying bricks! Rather than spending time talking with clients and understanding business issues, laying a foundation with your technical staff to collaborate, share ideas and capture enthusiasm... You don't need to code to show leadership and span the business and technology divide." Chris Kempster, comment.

I would agree with Bill Barr, that for project architects and technical leads, being credible comes from being able to dive in and explain by example—with an example, and setting an example. But I also agree with Bill and Chris, that creating the right product requires the architect's bandwidth, and this competes for attention with creating the product right. Naturally, we don't want to go wrong on either—we want right products with right capabilities and properties, and right properties is a function of both creating the product right (structurally sound, correct, and reliable) and having the right target (SMART property requirements).

And since "right" products or applications don't usually simply exist out there in users minds, just waiting to be captured and coded up, we need architects to be working actively to understand what technology makes possible for stakeholders. For developers and how they build and assemble systems, yes, that too. But not only that. Architects need to actively, creatively, explore how technology capabilities could be brought to bear so that, for our customers, our products:

"...make their lives the way they wish they were."

Yes, this is the quote Joachimsthaler (Hidden in Plain Sight) uses from the inside front cover of the J. Peterman catalog. I never knew that the way I wished things were had anything to do with an iTouch, but now that it's here,Group graphics inspires I wish my interactions with my iPAQ were that way! How we want our lives, and the things and experiences in it, to be, is constantly being reshaped, and it takes innovative thinking not just in the present, but in the future world that our application or product will exist in, to really find our opportunity to differentiate—to be "right."

If we ask the architect to be the design authority, and if we really mean design authority, we need to give the architect the charter and the bandwidth to be doing the things that allow innovative ideas to spark. Remember, "Eureka's" that may, in a flash, gel a sudden innovative idea, take hard work, exploration, and ... many showers, in my case; bath's in Archimedes case.

So, what things should we be doing to allow innovative ideas to spark?

  • Yes, what Chris Kempster was saying—get out there and talk with customers (clients, users, etc.) and understand their business issues and their dreams, hopes, aspirations, passions, sources of joy and delight, and concerns, fears, aversions, frustrations or hassles—focusing on goals, not just actions and activities. For ideally, many of their actions and activities will be obsolete, not just automated, if we do our part right.

Booz Allen found that the companies that get the [highest return on their R&D investments] are the ones that integrate customers and users deeply in every stage of the innovation process.  These successful innovators involve customers in idea generation, in selecting the best ideas, and in refining and elaborating ideas.

Keith Sawyer, "How Customers Drive Innovation," Creativity and Innovation blog, December 14, 2007

  • Look to our innovative customers to find what they're already doing to "...make their lives the way they wish they were." This anecdote makes the key point that Patricia Seybold (Outside Innovation) takes a book to make:

    'A major auto company recently presented its “innovation road map” for the next ten years to a group of journalists and car enthusiasts. As the presentation progressed, it became increasingly clear that some members of the audience were restless. Finally, one listener stood up and said, “Many of us have already built and installed every single one of the innovations you say you are planning to develop in the next ten years. Wake up and smell the coffee! Come out to the parking lot and take a look at what we have developed and installed in our cars!”'

    Eric von Hippel, Breakthrough Idea Number 6, Harvard Business Review, February 2007

  • Understand the demand ecosystem (every time I use "ecosystem," I think of David Ing's post), à la Hidden in Plain Sight. Remember that we bring a technologist's perspective to bear on understanding the ecosystem. This is not to say we're running around techno-pontificating, arguing that MySQL is just the thing for the backend, or whatever our current wicket is. Rather, we see where technology fits in the daily experience of our customers; what it does make possible and what it could make possible.

  • Graphical facilitation of group brainstormingCreate a Competitive Landscape which gives a big-picture view of business context, including the demand ecosystem. It is a good place to start bringing the perspectives of the multidisciplinary product concept (or at a higher level, business strategy) team together on the same page. It provides for structured brainstorming, and when the participants are selected for diversity of perspective, can really stimulate the creative foment that produces new ideas.

  • Use multi-functional teams, with diversity of style and perspective. Innovation is not, should not be, the exclusive province of marketing, or business analysts, or architects, or any one discipline. Ten Faces of Innovation makes this point. And we've been making it with the circles of innovation model. Though of course, like the circles that ripple out from a pebble thrown into a pond, each of these circles speaks to other circles—customers and those who understand them, technologists and those who have foresight into technology ripples well before others do, and value partners and competitors, and those who understand forces shaping the marketplace.

  • Read for other ideas on how to get ideas, and how to get ideas to pay off—for example, here's a good one: 7 Reasons Why No One Likes Your Ideas.


CIOs, CTOs, COOs, even manufacturing VP's are getting with the idea that technology is a key ingredient in innovation-driven business success:

"Management's most crucial investments for factories of the future won't be the hardware or the software, but in the understanding of how new technologies provide new options for powering business success."

John Teresko, Finding the Next Big Thing, IndustryWeek, March 1, 2008

Yes, apparently John is writing this from the future!

2/25/08 Innovation Blogs

2/25/08 Coupling

Here's a neat story about tight coupling (not software, but I expect you'll be able to translate):

"Henry Ford ... spent roughly 7 years developing mass production and then another 10 perfecting it.  In the process, Ford built such a tightly-coupled factory that, when GM and others demonstrated the market for variability in car makes and models, Ford could not respond.  Changing the design of even a single bumper created ripples all up and down the line. 5 years later, to finally change, all Ford manufacturing operations were shut down for six months—laying off 75,000 men—while Ford engineers worked on a new production line. The Ford Motor Company never regained its dominance in the market."

Andrew Hargadon, Creativity versus Efficiency part 2, September 2007


2/25/08 Scaling

And here's an example that illustrates why strategies for scaling (projects or systems) in the small don't necessarily carry over to scaling in the large:

"Let's say that you have a recipe for strawberry shortcake that serves four people.

One day you invite over seven friends to eat this desert. To make it, you simply double the recipe's proportions.

On another occasion, you make it only for yourself and a friend, and you halve the proportions.

Now, let's suppose that you invite 50,000 people over for strawberry shortcake. At this point, the biggest challenges confronting you have nothing to do with the recipe. These include buying strawberries on the commodities market, making deals with the teamsters to deliver enough cream, traffic-flow coordination, and large-scale renting of tables, chairs, bowls, and spoons."

Roger von Oech, Beware of Moreness, Creative Think blog, February 5, 2008

2/25/08 Differentiate—or... was that Imitate?

Ok, so I'll X out the name, and you guess who company X is:

"Why is Strategic Innovation imperative at X?

It has to do with achieving X's vision:

To be the First Choice of:

    * The world’s most coveted talent

Sanjay Dalal, Strategic Innovation at Deloitte, The Innovation Index, February 19, 2008

So, did you guess? Odds are pretty high you're thinking I spilled the beans on your strategy, right? Ok, X is Deloitte. The top challenges for CEOs in 2007 ranked as follows:

  • excellence of execution
  • sustained and steady top-line growth
  • execution of strategy by top management
  • profit growth
  • finding qualified managerial talent
  • customer loyalty/retention

  • speed, flexibility, adaptability to change

  • corporate reputation

  • stimulating innovation/creativity/enabling entrepreneurship

  • speed to market

18% of the CEOs surveyed cite stimulating innovation/creativity/enabling entrepreneurship as their greatest concern. Moreover, acquiring/developing the right talent was rated as the top innovation challenge, according to The Conference Board report. (Source:  CEO Challenge 2007: Top 10 Challenges which reports results from a survey of 769 global CEOs from 40 countries.)

If everyone (or even just 1 in 5 companies) is seeking to innovate by acquiring top talent, that's going to make for some pretty stiff competition for talent!  It sounds like a zero-sum game, but hey, how about this:

'"Hire naive misfits who argue with you; encourage failure; avoid letting client input limit your vision; and fully commit to risky ventures."

In fact, "failure" seems to be a dominant theme with just about every business guru interviewed for the article. At Palo Alto-based innovation and design firm IDEO, there is a simple mantra: "Fail often in order to succeed sooner." Often, the best employees turn out to be the people who might not have been hired in the first place: "Fresh perspectives derive from mavericks with wildly diverse backgrounds and no preconceptions who challenge the status quo, champion their own ideas, and illuminate the metaphorical darkness..."'

How to create a culture of innovation, Endless Innovation blog, February 13, 2008

OK, so that was about building architects and designers; that wouldn't apply to product and application development, would it? Or, could Steve Jobs be a case in point?

What I'm getting at, is that the way we define talent for our business, and the way we go about innovating in our business, become the starting points of our differentiation strategy around innovation and talent. This is why context and strategy maps are so important—they take high-level bullet points like the Deloitte vision and tease them out to find the real leverage points for value creation and differentiation.

2/25/08 World's Most Innovative Companies?

See if this list (from FastCompany) matches your list of the top 10 most innovative companies in the world:

  1. Google

  2. Apple

  3. Facebook

  4. GE

  5. IDEO

  6. Nike

  7. Nokia

  8. Alibaba

  9. Amazon

  10. Nintendo

We expect technology to be tied closely with differentiation at the likes of Google and Apple and Nokia. But why was Nike in the list? Social networks, on and offline. But online. And so it goes.

Google has gone after the hire-the-best-talent strategy and done very well with it. But Google created an innovation ecosystem. (That's even better than ecosystem on its own, huh Erik? **) No really. Google created the physical environment, the hiring practices, the performance monitoring and reward system, the time, etc., etc., and a mass  of Google groupies who think Google is cool. Google's talent strategy works, because Google is doing work that top talent wants to do. But that is not the whole story. Google has created an innovation identity, and top talent whose personal identity aligns with that, are attracted to Google.

GE being in the Innovation Top Five is important, for it does a lot to dispel any myths we might hold that elephants can't dance. I watched an interview with GE CEO Jeff Immelt, and he said something along the lines of "if you want a front seat on history, work for GE, not some start-up" (I'm paraphrasing from memory).

Gosh, I sure hope GE figures out how to make wind and solar energy as de facto on our homes as satellite dishes—providing green solutions to the energy problem in developed countries not just developing countries! So, residential wind power is gaining momentum. Hollywood could do its part—put a solar panel and/or wind turbine on every house in every movie that is produced over the next year (and why stop there?), so that we get the vision firmly implanted; we could leave this planet better off than it was when we entered it! Isn't that what we all want, in some small or big way? Well, then, let's not kill the environment while we go about making our mark on the world!!

** Here's a litmus test for architects: you're a good candidate if "innovation ecosystem" has you feeling antsy, but even so you are drawn to it. This test indicates that you are able to traverse the business world without being tagged an imposter, yet you are, in your heart and in your true allegiance, an engineer. Eh, I just made that up so I'd qualify!

2/26/08 Architect as Time Traveler

Two things I really like about working with Dana Bredemeyer:

  • he likes my ideas!

  • he has explored far and wide, and brings deep perspective to bear, so better ideas are formulated

I told Dana about the gavel I've been pounding: requirements aren't simply extant, waiting to be captured, or even "discovered." They are invented, or at least, they should be—and are, when innovation happens. There is an interaction between needs/goals/desires that exist, and ideas for meeting those needs, which changes the concept of the needs and the range of possible "solutions" to them. 

So the architect is, in Dana's words, a "time traveler" who must go into the future, invent the problem/solution that will deliver delight and value in the future when the system is delivered and it is interacting with the new world it and other systems and processes have created, and all the new expectations these systems and interactions have created. One agilist may say the best way to do this is to incrementally evolve the system, allowing self-organizing system principles and Darwinian evolution (what is that called, when it is evolution in an economy rather than biological evolution?) to have sway. But this agilist (moi) says we can do better than that, because we evolved to have a prefrontal cortex, which though not a crystal ball, does let us imagine a future and take steps towards creating it.

When creating the iPod, it wasn't enough to think about playing music on a device more portable and sexy than a CD player. A whole new world had to be created around licensing, uploading, downloading, managing digital rights, and ... a truck-load of other stuff I haven't hallucinated. The whole experience had to be thought through, to be created. First in the mind's of men and women, yes. But the ideas had to be iteratively explored, to understand what it will take to make the new ecosystem (sorry Erik) not just viable but compelling; to create an experience that delights. This iteration doesn't have to proceed at the pace of cutting code; we can speed up the Darwinian evolution of our inventions using models and other techniques.

It sounds all very well put like that, no? But do we have practical ways to make real on this kind of innovation, when we aren't Apple and we don't have a visionary-extraordinaire like Jobs? We use Competitive Landscape maps, Technology Roadmaps and Projections, Scenarios (à la Art of the Long View, as opposed to OOAD instances of use cases) and Desired State Interviews to help move us into the future. These are what I've found time and again to be great Pareto tools (i.e., 20% effort for 80% value, as compared to other techniques), which is not to say I don't use other techniques as and when I see the need to borrow or invent to add to early envisioning/concept-germination iterations of the Visual Architecting Process.

If we divorce the activity of "inventing the problem" from the activity of "inventing the solution," we break the innovation cycle and the necessary interaction between problem concept and solution concept which redefines the problem concept. (We need better terms than "problem" and "solution" here; but you know I don't mean we're creating problems, but rather opportunities to deliver value.)  So the place we have to start, is making the partnership work. And I don't just mean marriage counseling between marketing or business analysts and architects! For one thing, given the right architect, I'd want him or her to lead the whole design—the invention of the problem and the invention of the solution. A team, preferably a diverse team, is needed to do this, but having someone end-to-end responsible for leading the design lends critical accountability, for pie-in-the-sky dreams are not what this is about.

And for those of you who are pooh-poohing all this as only relevant to greenfields situations and disruptive innovation, let me quickly say I think that it is important to do our "time traveling" when we're marching down the sustaining innovation path. Sure, we're more constrained by the past when we're creating incremental improvements, and we don't time travel as far into the future, but we still need to be inventive, creatively interpreting expressed needs and goals in terms of system capabilities.

See also Requirements and Innovation, by Ruth Malan, July 28, 2006

And how do you like this for a trend map? Hmmm! Well, I guess it takes into account diverse perspectives, and that's good... And the format is neat! Like, let's get off at the "attention economy" stop (on the green line) and explore that for a while.

"Don't worry about what anybody else is going to do. The best way to predict the future is to invent it." - Alan Kay

2/26/08 Tags and Google Reigns—or Not!

I haven't bothered to use tags because with a Google search restricted to my domain, I can quickly find all references to any word or phrase on my site, and I don't have to do any work! In this regard, Google has a serious edge over Yahoo! Try, for example, a search on innovation site:ruthmalan.com on Yahoo and then on Google. Yup, Mi-Yahoo has some work to do. But, but... I have to report, I just Googled "Fridays at Google" site:www.ruthmalan.com and got zip, nadda. I Yahoo'd the same search term and got exactly (and only) the piece I was looking for. And there's further irony to it, but you'd have to read the piece.

2/26/08 My Influence Dashboard

This report from Amazon for the last 2 months will clearly show you that my influence is... well, Reepicheep comes to mind... a valiant mouse but for all that, hard to hear above the din... (Don't worry, if you don't recognize the reference, you will in a few months after the movie [careful—mute first—this is a noisy site] comes out... ouch! Didn't I give you a Koosh ball for that?)

Book title Conversion Looked Bought
The Leader's Guide to Storytelling: Mastering the Art and Discipline of Business Narrative 8.33% 12 1
The Wheel on the School 4.76% 21 1

Hmm, well, at least I got 21 people to look at The Wheel on the School! Perhaps they were so excited they decided to run over to Barnes and Noble and buy a copy right then and there... Either that, or they thought I was bananas bringing kids stuff into the work place—serious credibility hit, and all that. But really, when innovation is the battle-cry of the day in the corporate wars on consumer pocket books and talent, this vision story is quite illuminating. It does the visioning bit so well, and then there's teams, of teams, working together like cogs in an intricate system.

Oh well, never let it be said that I don't take risks, even if you won't catch me scaling a rock face!

[2/27/08] Speaking of which, let me be perfectly clear here: I am highly recommending Let My People Go Surfing: The Education of a Reluctant Businessman, by Yvon Chouinard. There are moments when Yvon strikes me as a little egotistical and self-serving ... like when he says "doing risk sports will create stresses that lead to bettering one's self." Um, Yvon, some of us can apply the Socratic method to ourselves without being in personal peril.  It's called introspection and I don't have to be facing death on a Himalayan peak to examine my life! I don't even have to be taking a hike. Oh, I should be...? okaaay...

Now I know, I know, if you had to read everything I got excited about (plus everything you're excited about) you'd have no time to do your architect job! But, one of the things that often comes up in "how to be more innovative" advice columns is read outside your normal box. Patagonia may seem outside the box, but when you see how Yvon uses philosophies and principles to lead the highly individualized Patagonia employee base, you'll see that it is all quite relevant, even if it needs some translation. But, you're an architect. You translate all the time. And innovation is mostly about translation. Even ground-breaking inventions are often about translation—using a model that exists in some other space, like in nature.

Nature! Yes, that reminds me. Yvon makes a strong case for pulling out the stops to save the environment from its rapid slide into irreparable devastation. If you're hiding your head in the sand like the proverbial ostrich I've been emulating, you'll hopefully find Yvon's message a good wake-up call. It's not just about our carbon footprint (that too, is crucially importantly) but about how broad and devastatingly we are destroying this planet—beyond it's capacity to regenerate, despite how miraculously adaptive this planet is. Yvon tells of this insect that has, just since WWII, evolved this capacity to shed its legs when it comes into contact with pesticides! Yvon is using that to make a point about stresses being vital to evolution, and the rapid adaptation that happens in response to stress. So stress is important—to businesses, not fragile river ecosystems and non-renewable resources! We use the Competitive Landscape this way, to help produce a shared sense of unease with the status quo that builds to a shared sense of urgency and passion to change. We need to do that with our business and our personal lives, so we change what we do, and impact the planet in healthy, life sustaining ways. Everything we strive for now amounts to NOTHING, if our children have to suffer on a dying planet when they reach the age we are now!Save the planet please

It would be great if coalitions of the world's super-wealthy were to lead an effort to buy, for world preservation, as much as possible of the most fragile lands on earth, and put it in a world trust, so no one nation can do damage to it. But we have to start doing what we can, personally and in our businesses, to reduce our carbon footprint and our pesticide and chemical footprint. Has our generation done more damage than all the generations that preceded us, put together? It seems that way. Ultimately, I'm afraid, history will show that is a bigger scourge to bear, than the scourge of initiating WWI or WWII. And we, each of us, is culpable; but I am, in bigger part than most! So, change I must! And for my penance (if you'd just read Chouinard...), I must urge us all to become tree-huggers...

2/27/08 Herding Cats

To show you just how superb and relevant Yvon Chouinard's Let My People Go Surfing: The Education of a Reluctant Businessman is, I've quoted above and beyond the usual amount of text in what follows, but it is to urge you to buy or borrow and read this book (the purple highlights are mine):

"We've had psychologists who specialize in organizational development tell us that Patagonia has a far above average number of very independent-minded employees. In fact, our employees are so independent, we're told, that they would be considered unemployable in a typical company.

We don't hire the kind of people you can order around, like the foot soldiers in an army who charge from their foxholes without question when their sergeant yells, "Let's go, boys!" We don't want drones who will simply follow directions. We want the kind of employee who will question the wisdom of something he regards as a bad decision. We do want people who, once they buy into a decision and believe in what they are doing, will work like demons to produce something of the highest possible quality—whether a shirt, a catalog, a store display, or a computer program. How you get these highly individualistic people to align and work for a common cause is the art of management at Patagonia.

Since we don't order our employees around, either they have to be convinced that what they are being asked to do is right, or they have to see for themselves it's right. Some independent people, until the point they they "get it" or it becomes "their idea," will outright refuse to do a job. Or worse, you get a passive-aggressive response so that you think the job will be done, but in the end the person just won't do it—a more polite but more costly form of refusal.

In a company as complex as ours no one person has the answers to our problems, but each has a part of the solution. The best democracy exists when decisions are made through consensus, when everyone comes to an agreement that the decision made is the correct one. Decisions based on compromise often leave the problem not completely solved, with both sides feeling cheated or unimportant or worse, as in the biblical example of Solomon, cutting the baby in half to settle the dispute between two harlots claiming the same baby. The key to building a consensus for action is good communication. A chief in an American Indian tribe was not elected because he was the richest or had a strong political machine; he was chosen chief because of his oratory skills, which were invaluable for building consensus within the tribe. In this information age it's tempting for managers to manage from their desks, staring at their computer screens and sending out instructions, instead of managing by walking about and talking to people. The best managers are never at their desks yet can be easily found and approached by everyone reporting to them.

Patagonia's offices support these ideas. No one has a private office in our company, and everyone works in open rooms with no doors or separations. What we lose in "quiet thinking space" is more than made up for with better communication and egalitarian atmosphere. Animals and humans that live in groups or flocks constantly learn from one another. ...

When you look to hire management, it is important to know the difference between leaders and managers. ... Managers have short-term vision, implement strategic plans, and keep things running as they always have.

Leaders take risks, have long-term vision, create the strategic plans, and instigate change.

The best leadership is by example. ..."

The only thing I would change in the above, is the wording "art of management" to "art of leadership." The foxhole bit should remind you of my Command and Control bit which, of course, you've read at least 3 times by now. What, you didn't follow my links? What kind of good follower are you, anyway? Oh... you're independent minded... So, didn't Yvon just say "the best leadership is by example"? There's a time for leading and a time for following, a time for asking and getting out of the box, and a time for drawing to consensus. Being an independent thinker doesn't mean you never agree with anyone else, and always question (read resist) direction! 

Herding cats: need a little something for everyone

I drew that "cartoon" in something like 1997, while working with the lead architect and a team of architects that needed to be aligned (just, not mechanically like wheels)... it would serve just as well if we replaced "architects" with "engineers," we just couldn't show it to them.  ouch! :-)

[4/19/08: Here's a classic on Herding Cats on YouTube—thanks to James Hooper for pointing to this one!]

2/27/08 Coupling and Decomposition

A couple of days ago, Dana Bredemeyer mentioned Chuang Tzu's "How to Govern" and in particular, this piece:

I.  The Butcher. One of the most famous parables in Chaung Tzu concerns Cook Ding, a skilled butcher whose talent was noticed by Lord Wen-Hui.  When asked to explain his skill, he replied:

 "Sire," replied the cook laying down his chopper, "I have always devoted myself to Tao, which is higher than mere skill. When I first began to cut up bullocks, I saw before me whole bullocks. After three years' practice, I saw no more whole animals. And now I work with my mind and not with my eye. My mind works along without the control of the senses. Falling back upon eternal principles, I glide through such great joints or cavities as there may be, according to the natural constitution of the animal. I do not even touch the convolutions of muscle and tendon, still less attempt to cut through large bones.

"A good cook changes his chopper once a year, —because he cuts. An ordinary cook, once a month, —because he hacks. But I have had this chopper nineteen years, and although I have cut up many thousand bullocks, its edge is as if fresh from the whetstone. For at the joints there are always interstices, and the edge of a chopper being without thickness, it remains only to insert that which is without thickness into such an interstice. Indeed there is plenty of room for the blade to move about. It is thus that I have kept my chopper for nineteen years as though fresh from the whetstone.”

(Translation by Lin Yutang)

“However, whenever I come to a complicated place, I size up the difficulties, tell myself to watch out and be careful, keep my eyes on what I’m doing, work very slowly, and move the knife with the greatest subtlety, until – flop! The whole thing comes apart like a clod of earth crumbling to the ground.  I stand there holding the knife and look all around me, completely satisfied and reluctant to move on, and then I wipe off the knife and put it away.”

(Translation by Burton Watson)

Too far from XML for you? Well, I thought if I mentioned Dana Bredemeyer recommended it to me, I could get away with it...

The title to this section hints at my interpretation in the context of architects. It takes experience and artistry to find the right lines of cleavage in a system, but if we pay attention, we do, and it is satisfying to stand back and know we did right. When we find the natural abstractions that lend themselves to defining cohesive components (services, subsystem, modules), and the natural mechanisms that provide the interstitial matter that makes the system fluid, flexible, yet resilient, then, why gee, we have the bullocks that come apart without dulling the butchers knife... I don't know... maybe we should just let this one rest in the kitchen, as a lesson on how to cut up chicken and ducks (since we prefer not to eat mammals)?

That is the power of the piece—you make what you will of the lesson. I've read chapter 3 of The Wheel on the School in two workshops, and in a third I asked for a volunteer to read it then talk about it. (I go there in Role of the Architect workshops, where I establish permission to tackle more of our confining preconceptions.) One of these times, an architect asked if I thought the author (DeJong) intended the piece to be used the way I use it. My response was that it doesn't matter; what matters is what we learn, what pieces fall into place for us. Because I've learned that some of the most important lessons are the ones that, once we recognize them, are obvious; they were staring us in the face but we just didn't see them, just didn't fit all the pieces quite together, and then suddenly someone or something makes it all go ca-ching and we have that epiphany feeling and everyone else goes "duh" yet they didn't see it that way until you expressed your flash of insight!  Anyway, if you weren't reading along last September, I wrote about wondering lessons from The Wheel, as well as wondering at Google that are both relevant to the innovation thing I've been kicking around this month.

2/27/08 Ackoff's Idealized Design

I picked up Dana's dog-eared copy of Ackoff's Idealized Design and started to read it. So, I have to tell you, Ackoff is quite "allergic" to the notion of time traveling into the future to envision our desired state. He contends we need to formulate the state we want now. Ackoff argues (much like many Agilists) that we aren't good at predicting the future, and concludes we shouldn't design "in" the future. I think it is a matter of how Ackoff is framing up this "going to the future." If we keep ourselves grounded in what we know and can find out about (potential) customer needs and what is happening around us in terms of technology capability and user expectations, we're not flying above the ozone to apply evident trends and patterns. Two years ago, it was our strong intuition that social networks was the way to move forward with HelpMatch; today it is self-evident. But today it is late to be entering the game!

We can ask people to "move into the future when the system is delivered" and think about how things "are" now that the system is in place and delivering value, or we can ask people how they would like things to be today. In both cases, we need to state two important rules of the game:Desired state roadmap

  • Must be feasible and viable: We need to restrict ourselves to what is technically feasible and operationally viable, so we remove the Utopian dreams from scope—no telepathy or "beam me up Scottie" transporters, no flying cars. (Oh no, can't I have flying cars? Or at least, wind turbines on every rooftop, you know, next to the satellite dish?)

  • See past the obstacles: We need to free ourselves from the obstacles of the present. When we design from the present, we want to solve problems we currently face—so we tinker and tweak, but don't make the strategic moves that would change our positioning.

We have found that asking people to think of "being" in the timeframe of the system delivery, rather than now, frees them up from that obstacle-focused rut we tend to be so stuck in. But if our stakeholders have Ackoff's orientation to "time traveling" don't call it that! Don't let the name of a thing get in the way of what is important.

In Ackoff's frame, we try to understand the desired state our stakeholders want based on what we know now—but we can't have it now. We can't change instantaneously and get the desired state we want now, today or even next week; not if the change is the kind that saves us from "the mess" (Ackoff's term) we're in. So we have to do some work to think around the edges of what we know, to find out new things, look at trends and patterns, look at other geographies or industries, look at our markets with a different lens, stretch what we know. You know the adage "If we keep doing what we've always done, we'll get what we always got"? To that we need to add, "If we act on what we already know, we'll keep doing what we've always done, and get what we always got." So we need to find out new things. Call it going to the future, call it staying in the present, or call it whatever. Just get out of the box!

With HelpMatch, you don't go far down the path of envisioning before issues around fraudulent use and trust come up, so then you work on addressing trust and that brings up social networks. And so it goes. Systems have a ripple effect. We have to think enough of this through, to figure out whether we have a viable problem/solution concept pairing. Otherwise, we're just saying we have no recourse but to succumb to the winnowing of Darwinian selection processes. Of course, I believe we can be more intentional than that. No, we can't predict the future. Yes, we can shape it. If we didn't believe we could create at least partially self-fulfilling prophecies, we would not have much reason to do Idealized Design! We'd just take any of several possible obvious next steps, and let the market tune us up or tune us out.

2/28/08 Spam crime

Did spammers decide to take America down today? I received upwards of 2000 3000 4000 8000 spam emails just today! This is more than 4 6 8 16 times the usual spam load, and more of it has escaped the filters than usual today. Has anyone calculated the cost to the economy?

So, sorry if I deleted your email hidden in yards acres of spam today! ...


 Table mountain and power lines at sunset


Gateway to more architecture on my mind

Feedback: If you want to rave about my journal, I can be reached using the obvious traceinthesand.com handle. If you want to rant, its ruth@traceinthesand.ru.cz. 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 priority.

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.

Copyright © 2008 by Ruth Malan
URL: http://www.ruthmalan.com
Page Created: February 3, 2008
Last Modified: January 02, 2012