"Congrats on the Star Performer recognition from your Talent Management Program. It is very forward-looking of XXX Bank to establish such a program. We’ve long been saying that there needs to be a talent development program for architects that is equivalent to the fast-track program many companies have in place for promising managers—but our viewpoint on this is sullied by the fact that we are in the architect talent development business; still, while our view is biased, it is not purely self-serving. J
Your manager makes a good point about our open enrollment classes—there is a high density of talent, experience and interest in architecture and the 4 days of working together makes for strong networking/relationship building and experience sharing. I’ve also been an advocate of sending architects to neat places for their training—to inspire and reward them. I rather like the idea of (evening) classes on a Norwegian or Alaskan cruise liner myself. J But kidding aside, I just came back from teaching a workshop in the Austrian Alps and it was definitely something I recommend; it gets architects away from their email and fire-fighting in the office, and lets them just focus. Given the opportunity cost of architect’s time, on top of the workshop fee and travel costs, it makes a whole lot of sense to make it a time where architects can be fully focused on getting value."
Ok, so just in case this isn't completely clear, the game works like this: We convince your management team that your company needs (more) tech stars in the Innovation Hall-of-Fame, and they need to invest in creating a talent pool from which these stars will emerge to lead the company to dominance in the rampant-growth-through-innovation field. We convince the management team to invest in an architecture workshop on that Alaskan cruise. You demonstrate that you are a star worth investing in. Etc. Storyboarded as a cartoon, this looks... like classic Dilbert on management. Goodness, I've just discovered my true calling—I should be storyboarding Dilbert cartoons!
10/23/07 Another Real-life Skit, Courtesy of my Inbox
Here's a request that came by email today:
i have an assignment
and currently doesn't have any idea to solve that one. i
have to design architecture of a system. the assignment is
The court in a town wants to get rid of the larg amount of paper that gets produced in their case study. They want a situation in which the record of a case, the hearing of witnesses ,court report etc are all stored electronically. judgs and lawyers don't rummage through a larg pile of paper but zap through an electronic file.
(1): your company is asked to develope a architecture of this system. inportant functional requirement for the system are,
1.storage of all part of dossier.
2.the passibility to add part to dossier. change part with most recent version or annotate part of dossier. if authorized to do so.
3.Protection against unauthorized access to a dossier.
4.Part of dossier can be in different format, plain text, picture, scand handwritten documents etc.
5:a function to search a dossier.
Next to these functional requirement there are a number of additional things to be decided upon. One may think of wether or not Open source is required ,and wether or not the court should continu its business with the two person company which earlier provided the court with a cheap scanner and accompanying software.
(2) Develope Two Architectural View.
please send me a short solution of this assignment.
i wil be very thankful to you.
Oh, so you want to see my response to this one, do you? But do you think talat will report his source? If he did so, and I was the instructor, I'd give him an A+ (my solution being perfect, naturally) for audacity. And audacity is an ingredient I've come to admire quite highly in architects! In the face of much complexity paired with uncertainty not to mention organizational quagmires, the lack of it is quite disabling, I find. But audacity paired with laziness or deficit in intellectual horsepower, does not qualify. Since I don't know talat, I don't know if the latter is the case. So, perforce, I find I'm off the hook.
Well, what would you do?
Aren't you just so glad I'm back? Ok, no need to answer that.
10/23/07 Morality or Moral Contribution?
Looking for a link to Grady Booch's rants (albeit the most erudite, urbane, classy, refined, and might we even say cultured rants in all blogdom) about email (in particular, his Sam-I-Am classic), I stopped by his blog and was updated on his interview on morality in software development—it apparently raised some degree of controversy. Personally, I'm happy that Booch bravely opened this discussion. It is a big topic, provocatively chinked open in this interview—though I don't conclude that this is any reflection on the full scope of Booch's thinking on this topic, nor Charles Cooper's. Rather, I expect it was a matter of time and the nature of conversations. Certainly, I hope it is a topic that Mr. Booch will have other opportunities to address.
That said, what I would really like to see being brought into the discussion is the contribution of software in the sphere of social good. There is the potential of HelpMatch, but more immediately, more tangibly, there is the good that is being done by WellGood and their ChangingThePresent site, Kiva, and many like these.
Why is it so important to highlight the sphere in which software engineers contribute to social impact projects? My excitement du jour is because this will bring more young people into the field. One of the remarkable things about the USA, is that even with all the consumerism (in which I partake in excess, but with ever more rue) there is a strong desire to address inequity among a big proportion of our young people, including those who are most advantaged by education and family economic circumstance—witness the 18,000 applicants for the 3,000 openings in Teach For America last year!
While software engineering is seen as an insular man-machine bondage that leaves little room for family and less for social contribution, it is not even on the radar for those who want to make a social contribution in their careers; do good, work for change that counts. That sort of thing. Yet software hasn't just changed the business world, hasn't just changed our products. It has changed our ability to change the world. And with HelpMatch, it could do even more.
Yes, I'm still trying to rhetoric some momentum into HelpMatch, when of course, what it needs is some solid time to get a cycle or two under our belt so the concept can be more concretely demonstrated. Or something like that. It's nice to be in demand, earn my keep, all that. But I can see that some downtime to focus on HelpMatch is going to be make or break.
In a recent workshop I used a Derren Brown clip (I'm indebted to you, Kern) to stimulate a conversation around ethics and architecture. My concern there was to head off the discomfort we often get into when we talk about increasing our organizational effectiveness—like, if we software architects got really good at this persuasion and influence stuff, we could get our business people to sign off on all sorts of technology they don't need but we want to get to play with. Oh, we already do that. Oops. Maybe we're more skilled than we thought. No, no, this didn't at all go where I wanted it to!
Diversity watchers looking at university enrollment numbers and company employment stats are conscious of the imbalance in the software field. But, unfortunately, not many of the spokespeople for our field are demonstrating, let alone raising, much awareness of the striking lack of diversity in our field, nor making any credible suggestions for addressing it.
Personally, having navigated my way through a highly satisfying and rewarding career in this software realm, I don't find it to be one that expunges women. So my conclusion is that shifting the perceptions that young people, especially women, have of software as a career, is where we need to focus. And I want to contribute to making this shift, because I think this is an exciting, and socially important, field for women, and men, to be in. Whether we work in non-profits and other for-the-good-of-mankind projects (my sister-in-law, for example, is a senior developer in South Africa's malaria research group), or whether we work in mainstream corporations, there are plenty of opportunities to make a difference and have an impact on people's daily lives, finding ways to introduce connectedness, value and delight.
Now, feel free to read this as a piece that demonstrates how to twist a topic to pound one's own agenda, or read it as an opportunity to evaluate all the ways in which ethics needs to enter into the conversations we have around software engineering. Social contribution on the upside, and the opportunity to address diversity issues on the flip side, are but one take on the topic. One of the comments on the interview alluded to the ethics of quality (or rather, the lack thereof). This is definitely an area that deserves scrutiny; which segues into the whole explosion of the use of technology to perpetrate crimes against productivity (like spam). And so forth. A whole gamut of issues. It is rather too bad that the comments on the interview didn't focus on the all the meat of the topic, rather than personal beef. Sorry, couldn't resist.
You can tell our good Mr. Booch he did well to open that Pandora's box. But don't tell him I suggested you do this. No, no. I couldn't confess to any collusion on crowding his inbox. Not for me the life of crime against productivity. (This journal excepted, of course.) Besides, Booch's Architecture Handbook is almost as overdue as our Architecture Action Guide!
Oh, while you're at it, here's a quote for Mr. Booch (and a warning to you, oh Trace in the Sand reader):
"What information consumes is rather obvious: it consumes the attention of its recipients. Hence a wealth of information creates a poverty of attention, and a need to allocate that attention efficiently among the overabundance of information sources that might consume it."
Herbert Simon, Computers, Communications and the Public Interest, pages 40-41, Martin Greenberger, ed., The Johns Hopkins Press, 1971
10/24/07 Hidden in Plain Sight
I returned to Hidden in Plain Sight. While the target audience is obviously marketing, I strongly urge architects to read it. It is rather tediously redundant/repetitive (grin), but the key points are so important I recommend you get them at the source rather than filtered through me.
The key to finding opportunities to innovate is understanding the "day in the life" of customers from the perspective of dreams, hopes, aspirations, passions, sources of joy and delight, and concerns, fears, aversions, frustrations or hassles—focusing on goals, not just actions and activities. To this I would add assumptions, assertions and context. My most important single-line take-away from this book is:
"People want things that make their lives the way they wish they were."
It is a quote Joachimsthaler uses from the inside front cover of the J. Peterman catalog.
Joachimsthaler introduces the concept of demand ecosystem, and he is sensitive to use contexts and so forth. I've read more than half the book, and skimmed the rest and I haven't seen Joachimsthaler advocate the inclusion of architects in the opportunity framing process which he calls the DIG (Demand-Fist Innovation and Growth) model. That's too bad. But bridges have to be built to span the chasm between the marketing and technical development functions to lay a path to innovation, and we can build this bridge from the architecture side if marketing experts omit to build it from theirs. In this boundary-spanning, innovation-seeking role, architects will do well to ratchet up their marketing savvy and Hidden in Plain Sight will give you a good foothold on the cornerstones of marketing as it relates to innovation and strategy. It is not a textbook covering marketing curriculum fundamentals, but rather a good practice guide to finding opportunity, and this is where it excels.
In this respect, it is much like our workshops. Sometimes we get asked to respond to RFP's where a corporate training department has done a wonderful job of laying out a curriculum for an architecture training course, topic by topic. All good topics. But I prefer a good practice guide and my bias shows up in my course designs. So there you have it.
This diversion also serves to remind me that I need to be more explicit that I have a clear vision of what the architect role is, and it is a role that is responsible front-and-center for value creation not crisis intervention. The latter is the modus operandi too many architects are boxed into because increasing kludginess is the due inheritance of schedule crunch after schedule crunch. But we shouldn't define the architect role by its contribution in a space that is bereft of architecture!
So, my vision for architects who stumble into my workshops is that they step up to the challenge of value creation, by which I mean both value identification and definition and value delivery, where the latter entails strategies for dealing with complexity, uncertainty, challenge and risk that come hand-in-hand with building value. This means designing function and form iteratively to balance the needs of the customer and the business (concerned with shareholder value and strategic, more broad or longer-term, value creation).
For many architects this vision presents a daunting prospect, because their organizational context has clear turf delineations that make contributing to value definition neigh out of reach. At the same time, competitive heat is being turned up and their product development or IT organizations are being exhorted to "innovate." But this is the avenue the architect has to use: innovation needs-must be a partnership between customer understanding and technology understanding; understanding of what is needed and valued and understanding of what is possible and what it will take to make it so. As loudly as the organization shouts for innovation, the architect needs to shout "count me in" and then firmly position how to do that.
Well, I don't know how that happened. I need to get more control over my thought flow! I guess it relates to positioning Hidden in Plain Sight as highly recommended reading for architects even though Joachimsthaler is clearly speaking most directly to marketing folk (doing opportunity analysis as input to strategy formulation). And I'm recognizing that architects who haven't suffered me in workshops (and who are just stumbling upon this journal) may be surprised by my insistence that, for an architect who wants to be great, who wants to be seen as a tech star, this is as much a key as finding an effective strategy to scaling your system while achieving aggressive availability goals, or whatever your top technical concern is today. Essentially, your system has to be a market success for you to be seen as a tech star. Once it is a market success, people will be interested in your technical strategies. But if it is not a market success, who cares what elegant mechanisms you designed? You are judged first by the trial of the competitive jungle, survival of the fittest. Fittest is not just a technical matter. It is a fit-to-context, fit-to-purpose matter. We have to get that straight.
And no, I don't count it as an out to say this is a business decision. That is classic sidestepping of responsibility. In product development this responsibility is shared by leaders. If you are an architect, you are a leader. This makes you responsible. Even if it is a responsibility shared, it is a responsibility you must own; take on to do your best with.
A responsibility shared. A partnership. A partnership with engineering management, with developers, and QA and ops teams, on the one hand, and a partnership with marketing and business people on the other. Documents as batons passed between fiefdoms don't create partnerships. They undergird communication, but they don't serve the give-and-take of partnerships—at least, not on their own. So, to make your business successful by making your system successful, I'm not suggesting, I'm claiming you need to partner with marketing (and your business or requirements analysts) and you need to create and strengthen the relationship by demonstrating a willingness to contribute a useful perspective to the innovation and value definition process.
Wherever software is crucial to your innovation and differentiation strategy, you have a unique perspective. You need to learn from the unique perspective of your marketing and business strategy thinkers, and they need to learn from you, as the technical strategy thinker and direction setter. Innovation and value definition is where your complementary perspectives come together, so the people with these perspectives must too! No more island fiefdoms. The opportunities to innovate and add value are hidden in plain sight, and so is the enemy. He, my friend, is you. Each of us is the first hurdle we have to overcome to creating change.
Ok, pass the bucket. (Last time we were in the doctor's office, my son asked what the bucket is for; since nausea wasn't his problem, he didn't have enough contextual cue.)
Maybe it's not Dilbert cartoons I was meant for. Political spin writing, perhaps?
Then again, I reviewed a client's architecture blueprint today, and it was gratifying to see how much of an impact I'd had, and how much of an impact that had, on the good, right approach to addressing value and challenge. So, little by little, the grains of sand are shifting, a little influence in a vast field.
10/25/07 Architects and Innovation
I had an exploratory conversation with a system architect and his manager in which I was firmly told (I'm paraphrasing) "We get business requirements from marketing, and we do the design. That's our world." The subtext of course is "we don't get to mess with this picture and so don't you even bother going there." Now, architects are by nature a questioning bunch. So why is it that this status quo is not questioned and broken down? My hypothesis is that we're comfortable with it.
So, to raise our level of discomfort, we need to ask ourselves why it is that new entrants into a market tend to be the most innovative. There are other factors, but I put it to you that in good part it is because they don't have to live with stifling preconceptions about decision turf. Small organizations have to rely on people wearing multiple hats and lots of close communication. In short, multi-functional teams—often, multi-functional persons! If your business leadership has delivered a mandate to innovate, you need to deliver a mandate to change the (dys)functional mindset that separates technology from marketing in the innovation (expressed in product requirements) game. Innovation is not just about finding a gap in the product offering. It is about finding a way to use technology to help people reach their dreams, goals, hearts desire—even if just in small moments like connecting with friend (cell phones, IM, ..., Starbucks), or taking a break to free the mind (Starbucks, ..., an internet fix), impressing peers (iPhone, latest iPod, ..., Crocs, ..., Tesla), etc.
Marketing has a bigger role to play, needing to go into a lot of detailed customer/market/industry analysis that I by no means encourage architects to get into. At the highest level, though, they help the business find opportunity and also establish identity in the marketplace. Software architects have a bigger role to play, too, not just in finding opportunity but building the products that deliver the opportunity and which are key vehicles for delivering the product identity. Yes, these are two touchpoints where business (or product) strategy setters and technology strategy setters need to come together: innovation and identity.
In the last workshop, I had a "discussion" (a.k.a. polite argument) with the architecture program manager around Zappos and my position that IT is a key facet of the sizzle that has men (and women, but just think — men!) spreading the Zappos epidemic. His position was that the IT contribution was simple supply chain management and the key differentiator for Zappos was a set of business decisions that created an operating model that caught on. My position is that IT is the nervous system that augments, and is augmented by, people, and which translates data into business intelligence. I don't just mean intelligence of the CIA ilk. I mean a business that acts with intelligence—in its immediate actions and in its foresight. And whenever you talk about business intelligence, you're not just talking about what business decision makers and marketing can dream up. You're talking about the real pragmatics of what is possible, what it will take, what it will cost and you're talking about the motivation that is needed to make the almost impossible, the big stretch, possible. All of this means architects are a key variable in the innovation equation. Set them at zero, and you get what you get—businesses clamoring for innovation on the one hand, or projects tanked out on unrealistic schedules, budgets and ambitions, on the other.
[10/26/07] But my vision for architects is not a futuristic and untested notion. It is born of the great architects I have worked with (and sometimes even helped). And it is born of a long personal experience in the software side of product development. For example, HP already had a strong grip on multi-functional teams when I joined in the early 90's and those experiences shaped me. I worked with architects who were chartered to explore new business opportunities (growth areas as well as entirely new businesses), with architects working in multi-functional teams on next generation customer-centered solutions for all kinds of industries, and, yes, architects working in technical silos creating design specs following upstream requirements "gathering." Big businesses, by and large, are made up a lots of smaller businesses (not small, but smaller). Colossal businesses are made up of big businesses. And so forth. So there's lots of spread of state-of-the-art and state-of-practice within any colossal business. Companies that innovate despite their size have, at least in good part, found ways to connect with their customers (Outside Innovation and Hidden in Plain Sight) and internal and external suppliers of the technology that embodies or enables the innovation.
How well any group does, whether they're in HP, Google, GE, or any other business, depends a good deal on the general corporate culture and climate, but also, frankly, a lot on the individual managers involved. Some are gate-keepers of information, maintaining power and control by entrenching divisions and controlling the flow of relationships and information among them. Others recognize that multi-functional teaming and some fluidity of responsibility and interaction are key to the creative ferment that generates innovation.
So, what are we to do, as architects, if our world is delimited by gate-keeping managers? We can assume that they are committed to the success of the endeavor and are working with their best sense of how to get the job done. So, we may be hampered, but we can still rise to the occasion and (gently but firmly) push the boundaries. Wherever innovation is the mandate (directly, or indirectly because growth is the mandate), we have an avenue to champion bringing technology into the innovation exploration and value definition process through architects who need to understand this picture anyway, to roll it out in the technical strategy.
Recently one manager I was working with pushed back against expanding the scope, and in his mind, the power, of the architect role, saying business analysts do just fine here, thanks very much. But partnering in value discovery and definition is not the same thing as re-allocating decision power. It is a simple recognition that better value definition decisions will be made, and better, more informed technical decisions will be made, all balancing the need to offer differentiating value in the marketplace while keeping an eye on the longer-term, more broadly scoped, concerns of the business. The ultimate responsibility for the decisions remains with the lead in the decision area, but that lead will be more successful if he or she sees to it that better decisions are made. This means opening up more broadly, stimulating and exploring a richer set of ideas during divergence, even though it can mean working harder to reach consensus during convergence, parts of the decision cycle. The gain is stronger leadership and stronger followership, with a clear and compelling set of value propositions to design and build out. Having a deep sense that what we are building is important, a landscape-shaping contribution for our customers, motivates but also aligns all the myriad decisions that follow.
Architects are the bridge between value definition and value design. This bridge is brittle and vulnerable if they have no real contribution to, so no deep understanding of the tradeoffs involved in, value definition—because tradeoffs aren't just made in during technical design. They are already being made in value definition. At a minimum, the architect brings important insight to these value definition tradeoffs, and then takes value definition insights and priorities into the technical design tradeoff process. But also the architect brings technical possibility, and a pragmatic understanding of capability, into the value discovery process.
Many businesses are so focused on the customer, and marketing as the analyst of the customer, that they forget that technology, especially software, provides the capabilities, the intelligence and connectivity, that many innovations rely on. Whether it is a business model innovation, a brand positioning innovation, a channel innovation, or a product or service innovation, there are many ways that software plays into reshaping possibility. In short, companies that do not see themselves as software companies, are relying on software as part of their differentiation strategy, and they need to become more self-conscious about the role of software, and the role of its innovators, in shaping their differentiation options. All is not lost if they fail to do this, because software people will still innovate. But the innovation will be emergent. The direction taken will be an opportunistic amalgam of heroics and happenstance. The organization will move more like an amoeba than an organism with a central intelligence function setting direction... and so on... ad infinitum... pound, pound... that's the trouble with caring about architects who want to be great; the points of debilitation for some become the points of passion for me.
10/26/07 Daigneau's Take
This evening, I read Rob Daigneau's piece on Introducing Domain Services. So, both Arnon Rotem-Gal-Oz and Rob are writing books on SOA Design Patterns. Interesting times.
Having caught up some on Rob's writing, I looked at his "most popular articles" list. Interesting to see how these sort out. Given my current wicket, I wanted to draw out the following, from his What Does it Mean to be a Software Architect—Part III? piece. Please read it at the source, for Rob makes more salient points than I quote here (the bold is Rob's):
"The Creation, Capture, and Management of Business Requirements
Software architects oftentimes play an integral role in the elicitation and organization of business requirements. The premise here is that the purpose of architecture is to ensure that the business needs are fulfilled, and the resulting architecture must be directly influenced by the business requirements. Architects should, at the very least, be well-informed concerning the scope of business requirements to be addressed, must understand how product features map back to business requirements and their associated benefits, and must also be kept up-to-date concerning the evolution of the functional specifications for the proposed software product.
... The reason that the architect may want to step in to provide such consultation is because they ... have learned the right types of questions to ask that would in turn reveal the most beneficial architectural approaches. Furthermore, effective architects know specifically what information software developers require in order to do their jobs...
Architects may also need to work with the analysts to manage the expectations of project stakeholders. While the analysts work closely with the business to define the product scope and requirements, oftentimes it is the architect that helps all parties understand the feasibility of achieving certain project goals given an understanding of the staffing, scheduling, funding, and technology constraints. The architect can help the team understand what the selected technologies are capable of, how they might need to be extended or customized, and the related work effort that is implied by the functional specifications.
I would suggest that the best software architects are good businessmen (or women) and also happen to be excellent technologists."
Rob Daigneau, What Does it Mean to be a Software Architect—Part III, 1/7/2007
and further on in the same piece, under "Whose Job is it Anyway", Rob writes:
"It’s not unusual for architects to encounter resistance or incur a fair amount of angst in organizations... Given that the architect’s unique perspective and experience can not only help analysts capture more useful business requirements but can also be leveraged to develop effective project plans, the architect, in the course of doing what they think ought to be done, may unwittingly wander into territories where they are not welcome. The chilly reception these architects might encounter is oftentimes attributable to the fact that the role of the architect may not be fully understood by project managers or analysts. These individuals might feel a bit territorial over their turf, and may assume that the architect is trying to exert control in areas which are not within the domain of their primary responsibilities. At other times the architect may be overzealous in his or her efforts to help. These architects may, through their bold or outspoken suggestions, lead some to think that the architect perceives them as being less than capable. In all of these scenarios, the architect must keep their social antennae well tuned, and adapt their approach given the unique personalities on the team."
Rob Daigneau, What Does it Mean to be a Software Architect—Part III, 1/7/2007
Rob pitches the need to be involved in requirements most persuasively. I've argued along similar lines (Architectural Requirements in VAP, 2/08/06; Requirements and Design Divide, 4/18/06; Requirements, Innovation and Architecture, 4/19/06; Interplay Between Requirements and Architecture, 3/1/06), but as Rob points out, this involvement meets resistance, and this is exactly why it is so important to have this point being made by leaders like Rob in the architecture space. But, you'll also realize, I go further, because I believe architects are essential to the innovation equation. In part, I go further because my expectation is that architects who bother to work with me (directly in person, or indirectly by reading my thoughts), are architects who want to help their companies reach for higher goals—usually success in the face of success, and it is hard, very hard, for already successful companies to continue to grow (other than through acquisition, which can be expensive in human capital terms, as well as financial capital terms); to grow not just through incremental innovation on the tried idea but also through demand landscape reshaping innovation. Innovation means doing new things, based on new ideas.
[10/28/07] We can look to the demand ecosystem for new ideas, but we are better positioned to find them if we bring architects, with their sense of technology capabilities and directions, into the discovery process. Google does a good job of having it clearly in the line of strategic sight that technologists are innovators. And it is true that Google is more transparently a technology company, and more, Google technologists get to eat their own dog-food. But, when Joachimsthaler is describing the insurance company case study, and never a technologist is mentioned, I find myself getting frustrated at the insular, discipline-centric view that conscribes the innovation effort. Whether there is an insurance broker, or an on-line offering, software could help the insurance company bring more value to the consumer.
Anyway, I strongly encourage architects to involve themselves in the strategy and requirements process for the reasons Rob Daigneau illuminates so well, and because the architect brings good ideas to the table. Sara complained that I was taking "a thousand" photos today (the first calm, sunny day in a week of fall color). I told her I've decided that the way for me to take one or two photos that I like, that stand out, is to take a thousand. It doesn't matter if hundreds are throwaways, if in an hour or two I can get one picture that glows with the transcendent quality of Fall's beauty. So, in part I place myself in situations where I can take "a thousand" photos, any one of which might have a quality that strikes me. And then I take a lot. Someone who is more skilled and talented than I am, may be able to take just a few. But they still have to place themselves in situation where the environment is conducive to that unique point of capture.
Innovation, introducing something new, depends squarely on ideas. New ideas, or at least, ideas in some form new. But not necessarily radically new. Just new in their application, new in their combination or instantiation. Brainstorming may give rise to new ideas, but structured exploration with the right set of perspectives is profoundly productive—that is, demand ecosystem perspectives (understanding customers in different contexts) and value delivery ecosystem perspectives (understanding the business and its capabilities, including technical capabilities, and possibilities).
But, if you're stepping up to the innovation plate and asserting that you need to play too, do so with grace and engender goodwill. In Rob's piece on Leadership resources, he says:
"With all this being said, if you accept the idea that "the problem is not out there, it's within me", you may experience an epiphany of sorts. It's really life-transforming!"
Here's some Dilbert cartoons tailor made for the architect (but be quick; they expire after a month):
I got the J. Peterman catalog in the veritable pile of junk mail we get each day (the reward of online shopping) now that the holiday onslaught is in full swing. The sentence I quoted that is used by Joachimsthaler is indeed in the front flap. The sentence that precedes it is interesting too. I never knew there was such good stuff in the front flap of a catalog! In this case, it begins with a story and it ends with a vision of how things should be:
"People want things that make their lives the way they wish they were."
It is a neat example of a "build identity" business narrative (a la Denning) with an inspire-to-action twist. Deftly done.
10/31/07 Happy Halloween!
Well, I burned some midnight oil, and the Laura Ingalls (pioneer dress) costume was finished in time; phew! Sara's American Girl (doll) went as Mary Ingalls; she had to get candy too, of course. Ryan caught a 6.5 lb brown trout today (really), and he went dressed as a fisherman again this year; 2 years ago he went as a northern pike, and I made that costume too. I much prefer the fisherman get-up, which requires no effort on my part.
So, I'm domesticated too. I kept thinking though, that a working mom has to be superwoman. Some things money just can't buy, and for Sara, a Halloween costume is best made by her mom.
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 firstname.lastname@example.org. Just kidding, I welcome input, discussion and feedback on any of the topics in this Trace in The Sand Journal, my blog, and the Resources for Architects website, or, for that matter, anything relevant to architects, architecting and architecture! I commit to using what you teach me, to convey it as best I can, help your lessons reach as far as I can spread them. I try to do this ethically, giving you credit whenever I can, but protecting confidentiality as a first priority.