A Trace in the Sand

by Ruth Malan

 

 

 

 

Architects Architecting Architecture  

October 2010

I'm reconsidering how best to use this space, acknowledging the privilege of your interest. An unfiltered view of my journal is too much and I shy from judgmental reaction to that, but creating a filtered view puts me in the critic's shoes and I can't find any entry that (unequivocally) passes my own judgment! 

10/2/10 Architecture Views

I think the images on this Digital Photography course page are a great example of architecture views (along with the view of the optical path here; there are more images of camera cut-aways here)! There's emotional content, there's user experience of utilitas and venustas, with firmitas implied by longevity, there's the cut-away view (which I love as an architectural metaphor to apply to how we visualize software mechanisms) and a mathematical-diagrammatic model. Yes, different views. But I think that the stakeholder concerns-views approach is flawed, or at least misplaces the emphasis. The architect has to decide which concerns matter. Yes, listening to stakeholders, but foremost using her judgment, experience, intuition, inventive spark, and so on. And the architect moves through various standard/general views, views specific to the concern, and ad hoc views, and so forth, to make decisions taking into account she is developing a system.

As the architecture is being developed, yes, the architect will hold conversations -- live and through drawings and text -- with others, hold interactions with other minds, for different purposes (sponsorship, gathering ideas, refining them, vetting them, and to build alignment and understanding among the development team, etc.). And, as with any communication, the architect will consider the best vehicles and views to support that communication. But in designing the architecture, the architect uses models and simulations -- from exploratory sketches, diagrams, mock-ups or paper prototypes and proof of concepts to specification-level detailed models and simulations, prototypes or working code isolating key facets of the design to examine and test whether the design ideas will work sufficiently well.

The architect is foremost using these as thinking and improving tools to create a good, right design, and then selecting and tailoring from them to communicate with stakeholders to ensure a right and successful design. Well, actually, these can't be cleanly separated, because including stakeholders in the discovery and development of good and right design is one of the best ways to ensure good, right and successful design! We just have to manage participation -- design by committee slows things down and may also tend to erode design excellence through over-compromise and wearing away at the stamp of uniqueness that is brought by a strong aesthetic lead architect.

Yes, we need to design a system with a keen sense of what will create strong market pull and loyal, enthusiastic customers. To do so, we need to understand customers and their concerns. And our business, and its strategy and concerns. And our technology community's passions and concerns. And we have to put all of that into the creative hopper to envision and mature our sense of system and use concept, the architectural strategy, and so on.

Well, I do like this freedom to speak my mind, even if it is a view that takes square aim at the establishment view! Maybe I'll take on certification next! ;-)

10/2/10 Tacit Memory

Grady Booch colorfully uses the term "tribal memory" and I like it although tacit knowledge and tacit memory are worth drawing out distinctly. There is what is consciously known and talked about in "the tribe" and there is what is implicit and unconsciously known. So, for example, some assumptions we can't make explicit because they are tacit -- though sometimes new questions can shift our perspective and what was tacit bubbles to the surface of our understanding or recognition. So anyway, with respect to architectural knowledge in "the tribe," for example, there is what is tacit, what is informally but consciously transmitted in conversations and stories, and what is formally transmitted through "documents" (including wikis and such). One thing I've found writing (as much as I do), is that in the act of writing we discover a good amount of our tacit knowledge -- we surprise ourselves with what we know, once we get into the groove of articulating our "good sense" that underlies a decision or orientation to something. 

10/2/10 2010 Enterprise Architecture Awards

The 2010 Enterprise Architecture Awards go to:

1. Aetna
2. Barclay’s Bank
3. Discover Financial Services
4. Skandia UK & International
5. Wells Fargo

-- The 2010 Enterprise Architecture Awards, InfoWorld, 9/20/10

I can't say if we've worked with any of these, but I will say Wahoo!  ;-)

It does reflect where EA has had a lot of emphasis -- yes, financial services. That's big IT because, well, of course services ever more rely on IT. So, it'll be interesting to tack the growth of IT in medical services, for example. And to see who shows up in the 2011 awards...

[1/3/11: This story, about successes and failures in EHR and contrasting EHR with ERP roll-out lessons learned, is interesting.]

10/2/10 Early Facebook

Here's some of the Facebook backstory.

10/3/10 Decomposition Means Addressing Cross-Cutting Concerns!

An architect was saying today that perhaps we should let tech-jocks (not his phrase, but I can't think of another that serves as well just now) ride off with the architect title and define what architecture in effect means to them, and that we should use a new word for what we advocate.

Well, that's an interesting idea! No more pushing rocks uphill! I think "visual design" will work nicely. ;-)

Yet... If architecture isn't the design of systems to meet a conjoint set of stakeholder goals including those that relate to the market/customers, the business (competitive context, value network, product set, etc.), and goals associated with structural integrity, then what is it? The solution to the technical crisis du jour? Spot triage is part of the game, but you don't make things more the way they need to be with constant spot triage! Triage may be how you keep your technical cred, but it is how you will lose architectural cred if it is the limit of what you do. Too soon the structure will be coming to its knees too frequently for triage, the market will move its fickle attentions to a more exciting value proposition, etc.

We know, when we design a system, that we decompose the system focusing on a driving set of concerns, but whatever decomposition we land on, it will leave cross-cutting concerns that we will have to deal with. The same is true for organizational design. Decomposing the organization allows responsibilities to be clearly assigned. And this means those responsibilities and their measures drive behaviors to optimize the parts, unless clear cross-cutting goals are set and managed.

Project managers are responsible for project delivery. While no project manager sets out to undermine the future, the delivery deadline is what the project manager is measured against.

Product managers are responsible for setting product strategy. They are responsible for determining a value set that will be competitive in the market segment. 

The business/requirements analyst is responsible for requirements.

The architect is responsible for creating a technical strategy and structural integrity.

Neat. Decomposed.

Except that these things interact! And design integrity is at risk when cleanly decomposed! Structural integrity is a euphemism for a contraction whereby future concerns must be accommodated in the present. Did you see "future" mentioned in any of the other responsibilities? No. The only other role that has responsibility for future success is strategic levels of management, and even there it depends very much on the board whether a company is short-term focused or not. Design integrity is a euphemism for a contraction of user experience, market value and structural integrity. I say "euphemism" in both cases because each is treated as a simplifying gloss-over for a complex of concerns that needs-must be handled in a messy way! Yes, messy. From the standpoint of those who would like the organizational decomposition to be clean and viable. But it is either clean or viable! [Well, extremes are prone to exception, but I suppose you grok my intent if I exaggerate just a little. :-)] It is not just that trade-offs have to be made to submit these concerns to any degree of intentional design (in Herbert Simon's "making things better sense"), but intense collaboration is required just to elicit and elaborate and understand the factors involved.

The project manager is there to make the team successful by managing resources. The architect is there to make the project successful by providing context for many minds to work effectively together to provide design and structural integrity.  These are complementary roles. But one is focused on the delivery term, and the other has to balance the delivery term and the longer term. So that is a point of creative tension.

Gerrit Muller's chapter  The Tense Relation Between Architect and Manager is really wonderful.

10/4/10 Architecting: Judgment Calls Across Stakeholder Values and Concerns

Architect (Archman holding the world) needs insight into the vlaues and concerns of a variety of stakeholder groups.

"Sustainable" is a compound of customer value (even excitement or delight, so that customers are active advocates), economically viable (a matter not just of revenue stream but costs), technologically feasible (taking into account internal capabilities and capabilities acquired in technologies incorporated in the product and its broader value set), and environmentally sustainable (increasingly a matter of organizational concern, but also of concern to a growing proportion of the customer base).

The architect looks across the needs of a variety of stakeholders to found the judgments that are integral to the architecture. Yes, we try to capture these as "requirements" (often they'll show up in system qualities or "non-functional" requirements) but requirements are simply a set of judgment calls that have been explicated and agreed upon. Like it or not, many judgment calls are going to be based on tacit assumptions. We balance the speed of blink thinking with the need to be more explicit, intentional and carefully reasoned. Safety critical systems, for example, need more formal exploration and agreement on the meaning of safety and the boundaries between acceptable and not, and we set goals with regards to those qualities. Generally, we will try to work towards a set of concerns and requirements of various stakeholders, but when we talk about, for example, "reliability" we have conflated a potentially vast space of concerns onto one quality attribute. By reliability, we mean customers and their environments shouldn't bring the system to its knees in some way that a reasonable person would be surprised at, and which will harm the product's acceptance in the marketplace (or worse, harm people and/or assets). It will behave consistently according to expectations. Etc. So we try to make reliability scenarios explicit, but it is a big space and we accept that our related quality attribute scenarios help us create a more reliable system but they aren't complete. The point is, these are judgment calls and good judgment doesn't come from being walled off from the source of insights that the judgment calls will be based on.

Here's a neat example of unintended consequences of unforeseen interactions:

A joint investigation by the U.S. Securities and Exchange Commission and the Commodity Futures Trading Commission has issued a report calling the May 6 stock market flash crash the responsibility of an automated trade execution system that inundated the Chicago Mercantile Exchange's Globex electronic trading platform with a major sell order that triggered a nearly 1,000-point plunge in the Dow Jones Industrial Average in a half hour. "[A] large fundamental trader chose to execute this sell program via an automated execution algorithm that was programmed to feed orders into the June 2010 E-Mini market to target an execution rate set to 9 percent of the trading volume calculated over the previous minute, but without regard to price or time," the report says. "The execution of this sell program resulted in the largest net change in daily position of any trader in the E-Mini since the beginning of the year." The study found that under strained market conditions, the automated execution of a big sell order can induce extreme price movements, particularly if price is not factored in by the automated execution algorithm. "Moreover, the interaction between automated execution programs and algorithmic trading strategies can quickly erode liquidity and result in disorderly markets," the report concludes.

-- ACM newsgram, 10/4/10 referring to this ComputerWorld article:  Regulators blame computer algorithm for stock market. 'flash crash' of 10/01/10

One of the fundamental tenets of architecture is: we must architect across the interfaces.  More usefully put, perhaps, as: to achieve system goals, we must architect across the boundaries of the system. That is, we create synthesis and make trade-offs across the system, and to do so, we must have perspective across the boundaries of the system. All the boundaries of the system, not just the internal structural boundaries! And the worlds of the different stakeholder groups that we are balancing the needs of (for example, the customer wants more value for the price while the business wants profit), are pretty well carved up, so the architect is doing something unique, paying attention to strategic and tactical, customers and internal agencies like call centers and manufacturing, suppliers and value partners downstream in the value network, etc.

If you want to say the buck for system integrity stops at the architect, the architect has to be able to decide what system integrity means for that system because everyone else has limited perspectives and bounded responsibilities -- unless you go high enough up in the management hierarchy to reach a manager that has purview across all impacted internal stakeholders (marketing and sales; customer care; IT and operations; manufacturing, and supply chain management; R&D; etc.). You could take the position that the product manager or requirements/business analyst is responsible for gathering requirements and shepherding stakeholders through the negotiations involved in clarifying and prioritizing these requirements. Certainly they are importantly part of the process, and may even lead it. But architects provide critical insight into what it will take that is essential to these tradeoffs. As understanding of the impact and interactions among requirements across stakeholders grows, the requirements may shift (in statement and priority). And the architect's perspective is needed to elicit the needed information and to inform these choices. In turn, by being involved, the architect gains a good sense of the values and concerns of stakeholders across the space, and this is essential to creating context for, and making informed judgments and decisions during system design.

Indeed, this recognition that system design ideally happens across the space of deciding what the system will be and how it will do that, leads us to advocate that the architect lead this system design work, not just the structural design work.  Next best (for example, if the architect isn't a strong leader in the multi-functional setting required to design what the system will be), is for the architect to be involved in this work. How much should, in true empowered, self-organizing team fashion, be a decision the architect makes because the architect will have to use judgment to figure out where the architecturally significant challenges, risks and uncertainties lie.       

The last sentence from my notebook reads: If we want to make things more the way we want them to be, we need to get a sense of how we want them to be! For products, we're integrating across the stakeholder space to come up with this sense. You can see this most clearly with Apple's products, where design is a factor from packaging to product guts, and clear unifying aesthetic is set across all these realms by the lead architect -- who may bear this title formally, but who creates the values, principles and oversees the designs to ensure that across the systems of systems that develop, manufacture and package the product there is design integrity. But of course this is more than "skin deep" or what we see on the surface. It runs through the design of the user experience of the thing in use, not simply the thing as superficially encountered. And the thing in use is very much about the design of the internals that deliver the user experience. Schlocky internals bleed out, undermining the user experience, creating frustration, etc.

All these words -- integrating across, interpolating, judgment calls, ambiguity -- raise discomfort for those who want a narrow clear charter so they can just get the job done. The architect has to create enough of this sense to create comfort for the technical team, and the project manager. We resolve the ambiguity by making decisions, by putting a stake in the ground and declaring the target.

I learned very early in my career that customer visits were invaluable to me in designing systems, because our customers had an entirely different perspective on our products than I did, and neither our customer support and nor our requirements analysts could convey this to me because it was a perspective difference. The customers encountered our device in use, in their context. I encountered it as a designer, developer and tester, but not in their use contexts until I spent time with them and closely observed them using the system. I couldn't spend all my time with customers, nor even even much time, but I had to spend enough time across customers I found interesting, to gain an appreciation for their varying perspectives, uses, and contexts. There simply is no substitute for that! I have a good imagination, but not that good! Once I gained more of their perspective, my imagination and empathy were very useful. Now, when I work with clients and the architects take me on a facilities tour on the first day to see, if not their systems in use, then at least their systems in various test beds, for the different application/products, I thrill because they already know that lesson -- giving me insight into their systems, and their sense of the importance of system (stress) tests as they apply to understanding system behavior in the norm and at the edges. Depending on the depth of our involvement, we will take that initiative if it is not offered, but the point that I am making is that there are architects who have climbed this learning curve and integrated this lesson, even if you're still wondering about it. ;-)

Which leads to the next point. We don't expect anyone to leap 2 meter chasms if they have never leapt 1! A tech lead, or architect new to the role, may have so many points of learning to assimilate that they just aren't ready to take on broader responsibility for design integrity, and the first step is to focus on structural integrity. As she gains confidence/unconscious competence there, it will become natural to see that the decisions made in system design are systemic -- product concept design and user experience design impact and are impacted by the structural design (not in every detail, but it takes some experience to know what is architecturally significant). If it doesn't become natural, advancement to more strategic, senior levels of contribution may be withheld. The good news, though, is that by starting to apply VAP even in low key ways to understand the competitive landscape, stakeholder value, and system capabilities by using VAP views to summarize and draw out the key drivers or architecturally significant aspects of strategy and requirements being passed in documents and such, helps to inform the technical decision-making process of architecting. That way the architect gains practice and confidence without exposure to questions about turf, and as the system-in-service-of-stakeholder-goals orientation permeates and strengthens the technical work, doors will open to a more active role in strategy and requirements so that technology considerations inform strategy and product design and so that architecting can start to proceed concurrently with strategy and system concept formulation, etc. 

Another way of coming at this, is to look at the value stream and all the various ways the system you're architecting impacts and is impacted by the various entities and their contexts (including processes and system/infrastructural contexts). That gives a view of the scope of concerns to be factored in when we're creating the system design -- its "functional design" and its "structural design."

"Functional" and "structural." The "what" and "how." Or in VAP terms, the stakeholder goals, the system goals (derived from, and expanding on the stakeholder goals), and the system capabilities, on the one hand, and the system architecture (technical strategy and principles; architectural elements, relationships and interactions; key architectural mechanisms; key technology choices) on the other. While we try to focus requirements on the "what" not the "how," it can get hard to tease these apart. In a traffic management system where the system goal is "early hazard detection with warning", we might identify "automatic upstream accident detection" as a capability. It doesn't say how accidents will be detected, but it does say how hazard detection will be early (automatic and upstream with a focus on accidents). We're already designing the system. So it is splitting hairs to try to be too pedantic/anal about the what/how split. The key is to identify capabilities we can agree on. How we get to that agreement can vary. For example, we might split off a team to investigate how we might approach automatic detection of upstream accidents. Etc. 

10/4/10 Nested Nagging

The child wants a dagger. But see how dangerous the kid is just with words... pictures, and a sense of humor.

10/4/10 2c on "Today's 2c"

This "Today's 2c" window is perhaps a right happy accident! I like the freedom created a 24-hour zone of exposure! :-)

10/4/10 Today's 2c: Defining Sustainability

The architect looks across the needs of a variety of stakeholders to found the judgments that are integral to the architecture. Sustainable is a compound of customer value (even excitement or delight, so that customers are active advocates), economically viable (a matter not just of revenue stream but costs), technologically feasible (taking into account internal capabilities and capabilities acquired in technologies incorporated in the product and its broader value set), and environmentally sustainable (increasingly a matter of organizational concern, but also of concern to a growing proportion of the customer base).

Yesterday's penny: Structural integrity is a euphemism for a contraction whereby future concerns must be accommodated in the present.

[This is called applying the Tom Sawyer Principle. :-) Just kidding! I'm simply reducing your exposure to my propensity to apply a word fire-hose to even the simplest question or push-back. The push-back du jour runs along the lines of "is design of the "what" of the system really something an architect needs to engage in?" My reaction can be summarized as: everyone else has a confined field of view, as does the architect ostensibly. But to deliver what the architect is charged to deliver, namely design integrity, the architect has to look and work across those divides.]

[Euphemism? We make it sound clean but its really inherently messy. Right? Try reliability. Protection against a conflation of known and unknown hiccups, inducements to inconsistency, outright failure,... Yeah, and structural integrity is more than a structure that will reliably stand up to stresses and strains within some envelope which could be characterized as "what a reasonable person might reasonably expect from a system in that context." Whoa! Euphemism sounds like a mild word!]

[Tom Sawyer Principle? Saved by the bell! Gotta get the kids to bed. ;-)]

10/5/10 Today's 2 c: Integrity and Design Mastery

Structural integrity is a matter of how well the system will stand up to stresses and strains placed on it in use and under future evolution -- in contexts we may or may not have foreseen, in interactions we may or may not have foreseen, but which a reasonable person would expect once the system is put into "reasonable" use. Structural integrity is the foundation for stakeholder's perception of the system as it is fit within their use contexts and adapted to new contexts, uses, or use modes. The structure delivers value through the functions of the system (what it does) and its qualities (how well it does that). Design integrity (as I am using it) encompasses the what and the how well. Structural integrity addresses delivery of the what, and the how well (now, and in the future, through adaptation and evolution). Integrity is bigger than a check-off on stated requirements. It is bigger than aesthetics and consistency and fit. Christopher Alexander was saddened when his patterns didn't lead to more habitable architectures, necessarily. This, I think, is because integrity is bigger than point by point addressing goals and concerns. It is a matter of synthesis, judgment, experience -- of design mastery. It is not just how we take things apart, nor even how we put them together, so it is not a matter even of pattern languages that fit patterns that "belong" together. When we start to think about integrity, we realize that triage on the crisis du jour is not going to get us there, even if it is a survival necessity for the architect and the system. The problem comes when we allow the architect role to be just that -- just focused on technical heroics.

We have to scope the requirements of the system so we have clear goals and clear criteria for delivery and project success. Of course, system success is a bigger thing than project success. It is measured in the market and on the bottom line, in satisfaction of users who work with, and those who work on the system, and more. So we need to scope and clearly delineate the requirements of the system, but the architect needs to be looking down the road and around corners to ensure that the system will be successful, given the criteria that are being established to enable project success -- so that on the project we can say YAGNI, even though the architect has to work with a more fuzzy conception of how the system could be asked to play nice with other systems, in variant uses contexts, with changing loads, with new ideas for application during its next release span and beyond. We don't want to enable all that will be thrown at the system in advance (we'd never ship), but we want to be careful about choices and directions that will constrain and disable the future. We don't want to be paralyzed by this ambiguity and uncertainty, but we want to design for, and being open to, change, since change is the most certain demand that will be made of the system!

Yesterday's penny: Architects uniquely work across the boundaries of the system, and across organization divides. The system impacts and is impacted by a variety of stakeholders, in a variety of contexts, but these stakeholders have well defined, and cloven, responsibilities, so the architect needs to understand values and concerns across these diffuse and organizationally partitioned sets (some external to the organization, some within the organization but in different functional groups) to integrate, synthesize, balance and make tradeoffs.

10/5/10 Focus -- Bursty!

it doesn't help when one is holding a dog leash and the dog is rambunctious

We bring some things into focus, and others go out of focus. Attention is bandwidth limited. So we, and organizations, pulse our attention cycles or act in bursts.

There is also the matter of propensity. Some organizations have a proclivity for here-and-now, action-frame, tactical focus on short-term results. To exacerbate matters, the Recession is causing many organizations to attend to the short term, to be very tactical and focused on surviving the current contraction. Which leaves opportunity on the table for those that seize the moment to invest in innovation, but innovation means making new connections and this is not easy to do when the organization is acting cautious and retreating to the confines of well-defined, partitioned job turfs and short-term, reactive, protective behaviors. Innovation means getting out of the box -- getting out and talking, getting out and playing (with new ideas, in new contexts).  

10/5/10 Theories Anyone?

Daniel Stoe pointed to this graph showing monthly commits by (open) source code developers. Anyone got theories about the drop-off?

10/5/10 Capturing a Moment

Well, it turns out that trying to capture the moment holding the dog's leash on a rather busy road is, well, compromised. Dat dog! She has no sense of occasion! And what an occasion -- the fog was lovely -- like a ballet of wispy fog and geese rising, circling and returning. I was transfixed.

It looks like the tide is out, huh? Well, that's 'cos we've had an extremely dry summer. Many trees have just given up and are dropping their leaves without their usual Fall blaze of color.

10/5/10 Theories Anyone?

Daniel Stoe pointed to this graph showing monthly commits by (open) source code developers. Anyone got theories about the drop-off?

10/6/10 Truthy Architecture

The diagram of the Truthy system (and designated the architecture on mouse-over) is interesting, because it indicates that it is functionally decomposed, with integration via the database. Truthy.indiana.edu aims to uncover deceptive tactics and misinformation in politics by analyzing tweets.

10/6/10 Today's 2 c: Vogue Gone Rogue

Addressing structural integrity means resolving wicked problems of the systemic sort as opposed to performing triage on the crisis du jour. Such triage may play well to maintaining technical cred. But perhaps "software ninja" is a better title for a role that focuses there. An architect may be a "software ninja" some of the time, and during certain phases of the project even much of the time, but wicked systemic problems generally aren't best addressed with local triage, and "band-aid" retrofits become part of the matted fret of the problem. In an old village, this may be picturesque, but in modern business systems it inhibits adaptation to new forces and value vectors.

Yes, I'm hearing rumblings that "architecture" may have gone the way of "reuse"... So I'm advocating a new hype wave around "visual design," "fractal and emergent," and "agile architecting." Mischievous grin. I'm teasing myself, and I don't actually think architecture has jumped the shark! Maybe it isn't heading any attention wave, but it is, and while complexity and wicked problems hound us will continue to be, a core discipline in software and systems development and evolution.

Yesterday's penny: Structural integrity is a matter of design mastery, because it is not just about meeting, point-by-point, stated requirements. It is about having keen intuition about what lies between the stated lines, too.

The Mars rovers are a great example! Now that's some resilience! (Of course, resilience isn't the only quality bundled into "structural integrity." Look at your qualities Kiviat. That's the focal set. Of course, if resiliency doesn't make it to the focal, differentiating set, it doesn't mean it doesn't matter! It only means it has to be good enough to be at parity with competition and meet general expectations, and isn't the basis for differentiation.)

 

10/7/10 Federated, Diplomacy and Capitalized

I read this (quite old I think, but new to me) post on the role of the architect by Fabrice Marguerie, and my only quibble is that it doesn't reference our papers/the Bredemeyer site! Just kidding!! I like the post, and it makes many of the same points I have made variously journaling, on the Bredemeyer site, or in papers. But three concepts jumped out as especially great ways to frame the role of the architect:

"The architect must work hand in hand with the whole of the team to federate the energies of all the team members."

"Diplomacy and pedagogy skills are also required to be able to explain architectures, debate about them and have them adopted."

"Often, architects will initiate in-house frameworks, which represent a big part of the capitalization work of a company."

-- Fabrice Marguerie, The role of the Software Architect

Federated architecture comes up a lot, but I love the "federate the energies of the team," which provides a neat alternative to my "align" and "provide context" and so forth.

Diplomacy is central to "organizational politics" but it is good to highlight -- better than "negotiation" because it encompasses that but belies more.

The notion that frameworks are a medium for the organization to capitalize is a great framing/way of expressing value. We capitalize on expertise and built assets, and create intellectual capital, which we leverage into more quickly and cheaply building product variants. We can also capitalize development costs by turning the framework into development assets and selling those assets (the framework becomes a product).

10/7/10 Today's 2 c: Some Notes on Visualization

"Everything points to the conclusion that the phrase 'the language of art' is more than a loose metaphor; that even to describe the visible world in images we need a developed system of schemata." -- E. H. Gombrich, Art and Illusion, 1959.

Language (visual or verbal) is a construction that relies on agreed meanings attached to (combinations of) symbols and relationships among them. Rendering and understanding pictures and text is a process of abstraction and interpretation that is highly reliant on context. 

Children are adept at drawing abstractions even at a young age. This is Sara's drawing of a child, drawn when she was two years old.

 

This is her self-portrait drawn (and painted) when she was five years old:

Abstract? Well, this is the photo she was basing her drawing on:

Just five, and she has instinctively simplified, abstracted, drawn the essential (but with details that matter, and to a five year old, five fingers matters).

Then, we forget. The more complex we find things to be, the more we try to capture, laying ourselves open to this quip from Michele Lanza's presentation titled Of Code and Change on Slideshare: "A picture is worth 1,000 words"...

A picture is worth 1,000 words...

But software is not tangible, though it generally has observable (physical) effects. We might say the code is manifest, but to design and create complex software we have to deal not just with the structure of the code (arguably manifest although size obfuscates) but the behavior of the system (not directly visible, and indirectly only by way of observable effects or by monitoring and creating visual expressions or transforms).

Even in terms of the code structure, we're creating abstractions that lend themselves to making the system more cognitively tractable. So, it's all in the abstractions. Abstractions of abstractions.

Yesterday's penny: On vogue gone rogue: Did you see today's xkcd? (It's great family entertainment, really! Oh, right. That'd be my family. The kids didn't get the Craiglist reference. Phew.) Ok, before you attempt to place me, let me just tell you: since there's no other way to geo-locate, let's assume Cartesian co-ords. I'm at (2,1) (inch scale, on a printout).  Yep, adrift in the sea of opinion.  ;-)

Image source: from Michele Lanza's presentation titled Of Code and Change on Slideshare

10/8/10 Don't Miss!

Don't miss the play button on Google's search logo today! :-) (But if you miss it, you can see the cute doodle animation here.)

And on today's xkcd -- notice the clenched hands on the "very wrong" person. We are good at creating and noticing abstractions, aren't we? Just the slightest up-tick at the end of stick arms, and we can see anger.

During an in-house workshop in Europe some time ago, the architects would not draw rich pictures. Would not! Upon Dana's insistence that the exercise of looking at the organizational entities, interactions, concerns and intentions, etc., in the value chain was valuable to understanding the system context, opportunities to create value, and expectations/drivers, they drew boxes. Boxes! When clouds and stick figures can be so expressive! Grin.

I hope some day you'll join us, indeed! ;-)

10/8/10 Today's 2 c (with serious inflation): More Notes on Visualization

Yesterday in an e-conversation, I observed "my view of software visualization is inherently biased/warped/filtered/threaded/[list generation here] by my interest in visualization of the design (as intended and as built)."

Of course, that is a packed statement. So, what insight does it hold? Well, it relates to who is the actor whose intent is being served, and that is an important avenue for creating distinctions (that would show up in a visualization taxonomy). Yes, that. But also design visualization is an interesting avenue for investigation. When we focus there, design intent versus reflection of design as built are both important to "design visualization." When we focus on code visualization, our orientation is to code -- that is, we are placed within a frame of reference and that is existing code.

Now the software visualization community has generally gone after visualization of the code (e.g., code maps of various forms) or control flow (e.g. flow charts), etc., which is more tractable because the code is manifest. We can see it, and analyze it, and so forth (just as we can a poem, or book, or mathematical proof, which are also text and symbol based). The intent is to assist in code navigation and understanding, but also to facilitate some level of analysis by associating attributes or metrics with the visualization.

Now, we could say that the architectural design of the system has a two-fold purpose:

  • design to meet system goals or purpose/intent with desired properties: it is the intellectual, creative activity involved in intentionally designing the system to be the way we want it to be
  • design to describe or prescribe (depends on specificity and degrees of freedom) what should be built. A by-product is that developers of pieces of the system can locate their contribution to the system. It becomes part of their mental model orienting and relating their work to that of others (logically and in the code base).

In the absence of up-to-date architecture models, developers hold idiosyncratic mental models of the code and its design in their heads. Well, this is true regardless, but in the absence of up-to-date architecture models, all thinking about the architecture and design is held in mental models on the one hand, and code expressions on the other. There is no shared form other than the code itself, and, for larger, complex systems, intermediate forms are held in mental models to locate and orient the developer to the code base and their, and others, contributions. Because these mental models are partial views of the code base, even the orienting views tend to be incomplete and possibly even wrong (Cherubini, Venolia and De Line, 2007).

Code visualization becomes especially important in the absence of (up-to-date) architectural design models or when these are inadequate. Thus there are two important cases:

  • no or inadequate (architectural) design models
  • code diverges from the design models, so that the design-as-built is different from the design-as-intended, and the design models no longer serve (except as historical markers).

The first points to a difference in philosophical orientation, or simply context. By which I mean, some believe that design is best done in the medium of code (iterative and all that good stuff) and this may well be the case for smaller projects/fewer minds to engage and align. The latter being true of the beginnings of systems, and as the system and its development team grows, at some point the cognitive load is such that models are needed. In contrast, others place value in models (importantly visual models) as a medium for thinking, reasoning, exploring, testing and validating design ideas from the get-go.   

The second leads to an important "use case" that those who focus on code visualization don't generally address: noticing when the code diverges from design intent and alerting. Of course, this is exactly one of the key values of the tool implementations of SDMs by Lattix and others, although they are doing this for a very focused set of design rules. Specifically, those that have to do with static dependencies among elements (which may be conceptual elements composed of code elements like layers, or code elements like classes).

The other side of this coin is that we want a feedback loop into the design, so that the design evolves with the learning and feedback that comes from the implementation.

Of course, this is not to say that the code visualization work doesn't have important design implications! Finding imbalance in responsibilities ("god" classes), for example, highlights design "smells." One point I'm trying to make is that when we take design intent and design reflection as a visualization driver, we serve designers and we serve developers. It becomes a mechanism for governance and design improvement, but also for orienting and aligning development work.

wicked problems lead to wicked messes unless we are disciplined about mess management -- from design intent to design reflection to enable more intentional design evolution

Yesterday's penny: Design of software is very much about abstraction, and design in terms of abstractions. Younger children are pretty good at dealing with and creating abstractions, but we become more adept at noticing and dealing with complexity and can overlook the value of the simple -- abstract and seeming simplistic in some dimensions, but providing clarity (or a "weight lifting" thinking tool to gain clarity) in others.

10/9/10 Dana's 2 c (huge value for the money)

"The question most interesting to me in this issue space is to what extent can architectural intent, or atoms that assemble into the molecules of architectural intent, be described in such a way that tools can detect it/them. If we work from what is detectable, we're an alley away from the key."  -- Dana Bredemeyer, 10/9/10

Dana has also recounted this story (which I used journaling last month) in different contexts, but perhaps it fits this one rather nicely:

On a dark night, a man is looking under a street light. Another comes by and asks if he can help. The first tells him he is looking for his keys, and the second remarks that it is a fortunate thing he dropped them so near the light. "Oh no," the first replies, "I dropped them over there, but this is where the light is."

10/9/10 My 2c (Leveraged; cramming too much into the day)

IU's Choreographers' Evening/Fall Ballet last night was FANTASTIC. I watch ballet (especially these more modern choreographies) and I can't help thinking about (visualizing) software -- the patterns, the interactions, the dynamic coupling, the importance of the narrative to understanding the structure and the flow, and the assembly of a narrative in one's own mind in the absence of being told the choreographer's version! ;-)

[I left yesterday's 2c up for context for Dana's 2c today. Don't worry, I'll zap it tomorrow.]

10/10/10 10:10:10 Geek Time!

A good time to watch the powers of ten video!

10/10/10 Today's 2c: Intentional Serendipity

We design to make things more the way we want and need them to be -- to achieve better outcomes, to create sustainable value. Outcomes that are intentionally sought as well as those that were serendipitously achieved because talent and intuition are focused in the right places.

Yesterday's penny: if all we have is the code (with no design documentation and architects long gone), that presents a more challenging design visualization problem than if we have expressions of the design intent to use along with visual models built from automated analysis of the code. This is in part because not all the design is expressed, or expressible, in terms of visual/graphic models. Right. This motivates the architecture documentation mantra! But more, the design abstractions are translated into code abstractions, and the translation may be hinted at by the choice of names and so forth, but the link is highly cognitive and machine understanding is advancing rapidly but is just not mainstream enough to be assumed in our visualization tools! 

Remember this from last month:  Dana pointed out a bumper sticker to Sara. It said:

Obey gravity
It's the law!

She's the kind of kid that needs to be reminded of that. 

Well, here's a candid shot taken today: she's walking on air!

As if I didn't have enough on my plate, the child wants to camp, so we had to go and pick the location today. Such hardship to be out in the Fall colors when there's so much work to do! ;-)

10/11/10 Today's 2c: Top Job!

This via Grady Booch's blog: Top Job in America: Software Architect!  Ok, that does it! Architecture has jumped the shark! I'm outta here!

Did you see the second in the list? Physician assistant! Then management consultant. ... Dentist at number 12.

Like, we want to top that list?

Be careful what you wish for, right?

No offense to those professions intended, but they're (very important but) more typically in the shadow of much more "desirable" jobs...  [So, the "real" top job list actually goes like this: 1. software developer/technical specialist, 2. physician, 3. CEO, ... 12. heart surgeon.  Grin.]

Um, if you're new to my journal, I am perpetually playful (and often satirical; I love tragicomedy -- it maps so well onto life); playful  -- to a fault. I think it is neat that the software architect job has exposure, and the points made about it in the summary are quite balanced. Moreover, a number of the comments on the software architect page are interesting.

Well, even if "software architect" has made it to the attention of CNN Money, there's still plenty of crazy world changing (video below) to do, to help organizations really get software and systems architecture.

Yep, in a world of points, there's still room to think unpointedly (if you're impatient to get to the point, jump to minute 2:03):

Thanks for the pointer, Daniel!

10/12/10 SATURN 2011

Given that SATURN 2011 will be held in San Mateo, CA (on May 16-20, 2011), I definitely have it on my To Do List to submit! Oh, right, I'm hoping you'll be there too, because it's not just about location but people too. ;-)

The deadline for submissions is November 30, 2010.

10/13/10 Today's 2c: Something About Boxes

First, yesterday's penny: Given that SATURN 2011 will be held in San Mateo, CA (on May 16-20, 2011), I definitely have it on my To Do List to submit! Oh, right, I'm hoping you'll be there too, because it's not just about location but people too. The deadline for submissions is November 30, 2010.

I'm thinking about submitting something about boxes to SATURN, probably as a tutorial. So, would you want to take part in a tutorial called "Something About Boxes" -- with me, that is? or Dana Bredemeyer? If you were reading along in September, you might have an inkling of where that would go. Just in case you didn't get it, it lies in the category of "fierce simplicity" -- this last being a term I'm borrowing from Grady Booch, but it so well fits what I hope I did with the Making It Visual keynote slideset I put together for and with Dana. I know, there are a few people who'd go "gosh, Ruth, if you think something about boxes will be useful to me... I'll suspend disbelief and put myself wholeheartedly in the crucible." But so much of architecting is about boxes, wouldn't that be something? Breaking out of boxes, identifying and clarifying boxes, taking ephemeral boxes we draw on the whiteboard and growing their meaning until... Ok, don't get overexcited... Well, I think it could be great, but great depends on who participates! So, would you? 

Alternatively, how about "Beyond the Lines"? This would be for the special set of architects who are comfortable with ambiguity, and looking to fake the appearance of a rational process while acknowledging our fallibilities and complementing "blink intuition" with just enough process scaffolding to build confidence, judgment and alignment -- with a set of levers to get ourselves out of fallibility traps.

The first focuses on abstractions, the art at the technical heart of architecting. The second on "process scaffolding" for agile architecting. Oh, those might be better titles... Ok, survey time:

  • would you participate in "The Art at the Technical Heart of Architecting" or "Something About Boxes"?
  • and would you participate in "Beyond the Lines" or "Process Scaffolding for Agile Architecting"?

I like the one about boxes myself.

My world today :-)

10/17/10 Alive!

Dana got back from The Netherlands on Friday night. Last night we took the "walking on air" girl and her friends camping. Dana should be knighted! Asked if he was tired today, Dana said "Well, the good news is, I know I'm alive!" As for me, I have to "uncamp." No 2c today! I'm "alive!" Wahoo! Hey, it was great, really. The Fall colors are past peak, but still quite lovely, and the sunset over the lake and morning lake stillness was splendid! 

Sadly, though, Benoit Mandelbrot died on October 14 at the age of 85.

10/17/10 Instead -- Books

Instead of 2c today, here are some books I'm thinking about (the economy, my dear Watson, the economy; I don't like to have to make choices when it comes to books):

Directly relevant/will get:

and Daniel Stroe pointed me/us to these:

10/19/2010 Um, Hello World

No effusive encouragement for "something about boxes"... Still, the art in creating resilient abstractions -- what's not to like? Oh well, do we change the world by doing what we are told, or by listening past the noise to find what needs to be done? Leading change is very much about getting patronage/sponsorship for and alignment around doing the thing the leader sees needs to be done. Yes, not in a vacuum ignoring the clamoring voices, but having listened to the needs, concerns, intentions, pressures, etc., formulating the seeds of a vision of a compelling way to create value. 

So, should I call it "Something about Boxes: The Art at the Technical Heart of Architecting" or "Creating Resilient Abstractions: The Art at the Technical Heart of Architecting" or "Creating Resilient Abstractions"? I like the first. It makes it so much more likely that the right people participate -- where "right" means people who'd get value from me, which is a peculiar kind of way to define "right" but very pragmatic if I'm the one slated to lead the thing!  :-)  I am actually hugely excited about this topic space, and it'd be fun to co-lead with Dana, but I'm not sure. Oh, it's not Dana per se. It's how people respond to me in the context of co-leading with a strong male. Our social world has come far, but our innate brain-priming is tipped against me. I generally refuse to ratchet up "alpha assertiveness" because I believe our software world especially needs a plurality of voices, but to create a setting where a shadow is cast on that plurality is not helpful.

10/20/10 Upcoming Workshops

Seeing an ad along the side of a bus yesterday, Ryan pronounced "If no-one else will advertize on your bus, advertize your bus!"

The bus ad read: "It's hard to miss a red bus! Especially if you have a schedule."  Well, here's our schedule:

  • Software Architecture Workshop, Boston, MA on November 8-11, 2010. Only a few seats left!
  • Enterprise Architecture Workshop, Chicago, IL, on December 6-9, 2010. Instructor: Dana Bredemeyer.

10/19/10 More like 10c today: Why Don't Developers Draw Diagrams?

"Why Don't Developers Draw Diagrams?" That is the provocative title of Grady Booch's conference capstone at SoftVis next week. Why not, indeed?

First, it is obviously not universally true, but one might expect the opposite, surely? Indeed, models, including visual models or diagrams and sketches, are the stock-in-trade of designers in other engineering fields. A tempting cop-out would be to say it is all very well in those fields, for there are physical manifestations of the thing being designed, so the sketches and then blueprint schematics are based on things we see. Well, things we will see once built, and things that are in good part similar that have already been built. Actually, that's not entirely true, because engineers create, for example, visual models of heat distribution in turbulent fluid flow to think through the dynamics of their designs, to help them visualize and compose the elements of mathematical or statistical models, or to create simulations which produce more visuals to understand phenomena we can't see but need to understand or predict to improve or validate designs. Besides, we model abstractions, to be sure, but these abstractions are rendered in code which is manifest. The interactions, dynamic coupling, giving rise to emergent properties, and so forth, create a tricksy space, but this is true for other engineering disciplines too! So, if it is not about the physical manifestations of "things," is it because developers do not think of themselves as designers?

Another cop-out (in my view, from my soapbox) is the notion that a programming language is a modeling language, so let's just give developers a break on this whole modeling score. Ye-es. The point is, what models best serve the thinking/problem finding/solving that must be done? And if this thinking needs to be shared (now, or into the distant future as the system is ever-evolved), what vehicle best serves this need for communication? Now, people have different styles, but it is also true that our educations have typically downplayed, or even outright left out, the role of visualization in problem definition and problem solving -- which are central to engineering design.

Now, architects surely do think of themselves as designers. Grady Booch has colorfully said "all architecture is design. but not all design is architecture" and I haven't seen any counter to this notion that architecture is design. System design. In our case, system is scoped to the software, which, for a software-intensive system, may be a (sub)system within a larger system(-of-systems). But design all the same. And many architects -- though, surprisingly, by no means all -- do use visual models fairly extensively to aid them in the design process. Still, I hear model-drawing architects being disparaging talked about (by other architects, even!), and I wonder how our field allowed itself to get to the point where it can be so (um, excuse my extravagance here) clueless about the value of models!   

What else may be playing a role? I suspect that our tech field's hype-orientation, with its pendulum swings, is a factor. To get a new technology to the tipping point often takes significant hype-momentum. After which there is the classic crash caused by over-expectation and just the natural depletion of energy that comes after too much zeal is poured into something. So, we overdid UML-centered processes (or its OOA/D predecessors), got burned with "analysis paralysis," and instead of self-correcting back to a helpful sustainable level, the rubber band snapped, and we sprang all the way back -- to the Agile Manifesto and it's positioning of code above all else. Which, in our binary all-or-nothing zeal, became for many (despite protests from many in the Agile camp that this was not the intent) an excuse, if not a mandate, to forego models.

And, perhaps, we expected too much. We wanted to leap-frog all the other engineering disciplines with CAE on steroids, and use UML to define our systems to the degree of precision that we could generate our systems from visual models -- any system, even those that, to differentiate, are systems where design is constantly pushing the envelope of what has been done before... Which naturally gets us to the position that the programming language is the better modeling language! 

Visual models, from informal sketches to precise schematics, are tools for thought (in our own heads or mind's eye, and collaborating now and across time with our own and other minds) and recording and communicating. Therein lies another source of the mess we're in. We engineer-types tend to under-value informal sketches! We want to be precise, to specify, to be unambiguous. And that hurts us! Early on, we need to be more comfortable with being sketchy, because that reduces the cost of change and opens us to more exploration of design possibility! And it opens our stakeholders, likewise. I do not think UML is the culprit here. I think our use of the UML is. [Now, I would point you to the "Making It Visual" slideset but... no-one asked for it, so I haven't bothered to complete typing in the narrative so I can post it -- speaking of cop-outs ;-)] As our design matures, we can add more precision to our models and document them more fully, but early on, actually, a "few diagrams with dubious semantics that [we] may hastily and ethereally sketch on a whiteboard" are actually "a good thing"! We start sketchy, and then how far we push our models towards precision and detail is a judgment call. I've quipped that that is why we are called aRchitects -- it stands to Reason. But engineering Reason is highly experience based. Yes, theory applies. But our field moves so quickly, we are very reliant on experiential learning to feed into our reasoning process. Which does not argue against models! The two are highly complementary, for models give us experiential feedback too--but we have to keep validating what we learn from this experience, like all experience, by setting up "tests" of key hypotheses we are intuitively generating and then leveraging. And we need to consider, given the complexity of our system and the organization developing and evolving it (distributed teams and off-shoring, etc. all add organizational/communication complexity), how much we want to document, how precisely. Moreover, we need to be realistic about how well memory serves when it comes to keeping track of our rationale and reasoning so we don't, even days later, find ourselves asking frustratedly "what were we thinking?"!

Another factor is at play, and it drives the difference between how much architects use "diagrams" versus (other) developers. The kind of thinking and decision making that the architect is doing is qualitatively different than the thinking of the developer of a granular piece of the system. And the code base is not a great medium for doing that thinking. Yes, if you were following along in September and saw what I shared of that "Making It Visual" slideset, you'll remember my "can't get your arms wrapped around 3 stories high volumes of code" slide. It is hard even with code piled a few feet high! And no, we don't start with code piled that deep. So we could start with stubs as our early design vehicle, and grow that. But the point is, is that a good vehicle for thinking through the design decisions that need to be thought through? How about factoring responsibilities? Ok, we can comment our stubs.  Yeah, and then we're playing a game of modeling without admitting it, and because we aren't admitting it we are not preserving (and keeping up-to-date) that all-important view!  Besides, how do we find responsibilities? Yes, dynamic models. If we do that all in our heads, we miss key interactions and succumb to our own fallibilities and blind-spots. Ok, so we use interaction models. Which use our structural models as starting points (and then we may refactor and change the structural and dynamic models, hence the need to play it fast and loose early on). So we are thinking about the most useful vehicle for our current thinking, and we are thinking about what we will need to convey down the road -- to bring developers on board and up-to-speed on the design, to keep the architecture from drifting from its intent without due reflection, and to leverage the design as a medium for intentional and productive system evolution (we we can only do if we keep the design up-to-date, and that is part of the heart of the visualization game).

Etc. More thoughts flow than I have time to corral!   

10/22/10 Reworking some of the ideas: Why Don't Developers Draw Diagrams?

"Why Don't Developers Draw Diagrams?" That is the provocative title of Grady Booch's conference capstone at SoftVis next week. Why not, indeed?

First, it is obviously not universally true, but one might expect the opposite, surely? Indeed, models, including visual models or schematics, diagrams and sketches, are the stock-in-trade of designers in other engineering fields.

So, what factors are at play? For one thing, the malleability of the artifact, and the distribution of cost, is different in other fields. The cost of changing the design once production is being ramped up (tearing down production lines, re-designing and remaking molds, etc.), is cost-prohibitive. When molds can cost $1m to manufacture, this too puts pressure on getting the design very precisely right!

Is software so different, that we can beg out of creating explicit designs? Software tends to (d)evolve into a "big ball of mud" which becomes decreasingly malleable, with changes taking longer and being more prone to producing unintended consequences and outright errors. The stress of making changes goes up, the people most knowledgeable about the system move on to more exciting systems with more degrees of freedom/scope for creativity and using the newest slate of technologies, contributing -- unless rigor and discipline is applied -- to continued devolution.

Another tempting opt-out would be to say it is all very well in physical architecture and engineering fields like building architecture, civil engineering, or mechanical and aeronautical engineering, for there are physical manifestations of the thing being designed, so the sketches and then blueprint schematics are based on things we see. Well, things we will see once built, and things that are in good part similar that have already been built.

Actually, that's not entirely true, for in other fields engineers create visual models of non-visible phenomena to improve their designs. For example, they create visual models of heat distribution in turbulent fluid flow to think through the dynamics of their designs, to help them visualize and compose the elements of mathematical or statistical models, or to create simulations which produce more visuals to understand phenomena we can't see but need to understand or predict to improve or validate designs. Besides, we model abstractions, to be sure, but these abstractions are rendered in code which is manifest. The interactions, dynamic coupling, giving rise to emergent properties, and so forth, create a tricksy space, to be sure, but this is true for other engineering disciplines too!

So, if it is not about the physical manifestations of "things," is it because developers do not think of themselves as designers? Now, architects surely do think of themselves as designers. Grady Booch has colorfully said "all architecture is design. but not all design is architecture" and I haven't seen any counter to this notion that architecture is design. System design. In our case, system is scoped to the software, which, for a software-intensive system, may be a (sub)system within a larger system(-of-systems). But design all the same. And many architects -- though, surprisingly, by no means all -- do use visual models fairly extensively to aid them in the design process. Still, I hear model-drawing architects being disparagingly talked about (by other architects, even!), and I wonder how our field allowed itself to get to the point where it can be so (um, excuse my colorful extravagance here) clueless about the value of models!   

Still, software is malleable -- unless we allow it to become a tangled, opaque mess. So why not continuously design and redesign as we go, in the medium of code? Refactor. Sniff out bad code smells early, and remove the source. (Geek fun with puns allowed, right?) We could say that our programming language is a modeling language, so let's just give developers a break on this whole modeling score.

Ye-es. The point is, what models best serve the thinking/problem finding/solving that must be done? And if this thinking needs to be shared (now, or into the distant future as the system is ever-evolved), what vehicle best serves this need for communication? Of course people have different styles, but it is also true that our educations have typically downplayed, or even outright left out, the role of visualization in problem definition and problem solving -- which are central to engineering design. The thing that I take away from the left brain-right-brain research is that while some of us may lean more toward the visual than others, or toward "big picture, integrative thinking" than others, we all use both sides of our brain! We are generally adept at processing visual images. We can all draw stick figures and boxes, and more besides. We have what it takes to do well enough, and as we exercise visual and system thinking skills, we get better at it (which is not to let educators off the hook). Besides, a lot of what we do with visual models, it seems to me, requires an intricate dance between "left brain" and "right brain" kinds of thinking. Thinking through interactions is more linear or sequential. Thinking about the elements and relationships of the structure and factoring in our mind's eye before playing it out in the model with our team, we're doing some "big picture" integrative thinking and visualizing, and some analytical thinking. And on it goes. I imagine that the interaction between elements of the left and right brain while architecting would light up as interesting a visualization as viewing the interaction between software elements during execution! 

Ok, what else may be playing a role? I suspect that our tech field's hype-orientation, with its pendulum swings, is a factor. To get a new technology to the tipping point often takes significant hype-momentum. After which there is the classic crash caused by over-expectation and just the natural depletion of energy that comes after too much zeal is poured into something. So, we overdid UML-centered processes (or its OOA/D predecessors), got burned with "analysis paralysis," and instead of self-correcting back to a helpful sustainable level, the rubber band snapped, and we sprang all the way back -- to the Agile Manifesto and it's positioning of code above all else. Which, in our binary all-or-nothing zeal, became for many (despite protests from many in the Agile camp that this was not the intent) an excuse, if not a mandate, to forego models.

And, perhaps, we expected too much. We wanted to leap-frog all the other engineering disciplines with CAE on steroids, and use UML to define our systems to the degree of precision that we could generate our systems from visual models -- any system, even those that, to differentiate, are systems where design is constantly pushing the envelope of what has been done before... Which naturally gets us to the position that the programming language is the better modeling language! 

Visual models, from informal sketches to precise schematics, are tools for thought (in our own heads or mind's eye, and collaborating now and across time with our own and other minds) and recording and communicating. Therein lies another source of the mess we're in. We engineer-types tend to under-value informal sketches! We want to be precise, to specify, to be unambiguous. And that hurts us! Early on, we need to be more comfortable with being sketchy, because that reduces the cost of change and opens us to more exploration of design possibility! And it opens our stakeholders, likewise. I do not think UML is the culprit here. I think our use of the UML is. [Now, I would point you to the "Making It Visual" slideset but... no-one asked for it, so I haven't bothered to complete typing in the narrative so I can post it -- speaking of cop-outs ;-)] As our design matures, we can add more precision to our models and document them more fully, but early on, actually, a "few diagrams with dubious semantics that [we] may hastily and ethereally sketch on a whiteboard" are actually "a good thing"! We start sketchy, and then how far we push our models towards precision and detail is a judgment call. I've quipped that that is why we are called aRchitects -- it stands to Reason. But engineering Reason is highly experience based. Yes, theory applies. But our field moves so quickly, we are very reliant on experiential learning to feed into our reasoning process. Which does not argue against models! The two are highly complementary, for models give us experiential feedback too--but we have to keep validating what we learn from this experience, like all experience, by setting up "tests" of key hypotheses we are intuitively generating and then leveraging. And we need to consider, given the complexity of our system and the organization developing and evolving it (distributed teams and off-shoring, etc. all add organizational/communication complexity), how much we want to document, how precisely. Moreover, we need to be realistic about how well memory serves when it comes to keeping track of our rationale and reasoning so we don't, even days later, find ourselves asking frustratedly "what were we thinking?"!

Another factor is at play, and it drives the difference between how much architects use "diagrams" versus (other) developers. The kind of thinking and decision making that the architect is doing is qualitatively different than the thinking of the developer of a granular piece of the system. And the code base is not a great medium for doing that thinking. Yes, if you were following along in September and saw what I shared of that "Making It Visual" slideset, you'll remember my "can't get your arms wrapped around 3 stories high volumes of code" slide. It is hard even with code piled a few feet high! And no, we don't start with code piled that deep. So we could start with stubs as our early design vehicle, and grow that. But the point is, is that a good vehicle for thinking through the design decisions that need to be thought through? How about factoring responsibilities? Ok, we can comment our stubs.  Yeah, and then we're playing a game of modeling without admitting it, and because we aren't admitting it we are not preserving (and keeping up-to-date) that all-important view!  Besides, how do we find responsibilities? Yes, dynamic models. If we do that all in our heads, we miss key interactions and succumb to our own fallibilities and blind-spots. Ok, so we use interaction models. Which use our structural models as starting points (and then we may refactor and change the structural and dynamic models, hence the need to play it fast and loose early on). So we are thinking about the most useful vehicle for our current thinking, and we are thinking about what we will need to convey down the road -- to bring developers on board and up-to-speed on the design, to keep the architecture from drifting from its intent without due reflection, and to leverage the design as a medium for intentional and productive system evolution (which we can only do if we keep the design up-to-date, and that is part of the heart of the visualization game).

So we reach a point that perhaps lies at the heart of the issue. Every decision that is made in explicit design activity by the architect (whether up front or during development cycles), takes some freedom of action and decision power from someone else (project managers and developers), and puts the architect in a potential power struggle with, typically, no formal recourse -- only good influencing and partnering skills to make the decision stick. This is going to tend to put the "model drawing architect" in the line of fire. "Mistakes" will be used as ammunition, and no-one is going to be looking for all the work that models saved and all the productively engaged minds the models enabled, only for the places where some stake was bravely placed in the ground early by the architect, and then shown to need to be moved or replaced.

Etc. More thoughts flow than I have time to corral!   

10/20/10 Corralling More Thoughts on "Why Don't Developers Draw Diagrams?"

Architecting is so much about designing not just things (abstractions or conceptual architectural elements that we reify and transform) but relationships among those things -- relationships that make the system and give rise to emergent properties of the system. Models help us reason about the things, and the relationships among them. This is inherently a design activity and central to architecting, and at smaller scopes for design of more granular structures. The smaller the scope, the more we can hope to keep it in one head. The larger the scope, the complexity that we have to abstract away from goes up, and the number of minds that will have to be engaged to build the elements goes up too. For both reasons, models are pivotal.

But what if we already have a code base, and no good models providing an overview of the system, nor models of key architectural mechanisms? The structural models that many of the software visualization tools create are a good starting point for creating the structural overview, but they focus on code structures and static dependencies. Useful, but it is good, too, to surface what we can of the conceptual architecture and the intent and reasoning behind it from the tribal memory and particularly the "stories" told to keep the tribal memory alive. What does a senior developer pass on in conversations about the code structure and the design guidelines they convey? What view does the test team have of the code? And more. And play the CRC-R game with key component (architectural element) owners in the room. Etc. Build up from a combination of what we can generate and what we can surface, and create models and descriptions of the current architecture.  

The more visual we can make something, the more we have brought to bear on the problem defining-problem solving process. AND we have brought it into a medium that allows others to interact with our thinking.

Here's an entry I jotted back in July, relating to starting with those sketchy whiteboard diagrams and refining, elaborating, and reifying (in models, as appropriate, and in code):

7/19/10: Which is not to argue for BDUF (big design upfront), but rather explicit, intentional design--iterative and incremental, in terms of the cheapest design medium for the design decisions that are the order of the day--in the Bucky Fuller sense of "what, at this extraordinary moment in time, should I be thinking about?" Early, I'm looking at what is make or break to get right, including what has diffuse impact, so becomes harder and harder to change the more code we have cut. But also, I want to understand the success and fail factors, what will shape the destiny of the product/market/use concept and meaning, what will shape structural integrity, what forces will impinge on this system now and as it is broadened in use/application (or scope) and scale, ... But it's not just a matter of the cheapest design medium. It is also a matter of human tendency. When we put working code in front of someone, they work at tuning that--the mindset is small delta. That's a generalization, of course, but generally once we are reacting to something concrete, the concrete thing shapes our expectation, and we tweak that. Instead of having a whole gamut of design options in front of us, we have narrowed the design space.

So early on, if we really want to be creative, to explore the market and design opportunity, we need to keep people in the zone of possibility. That is a key message of Sketching User Experience--informal sketches and paper mockups convey that the concept is not a done deal; we're still working at the concept level, not at the reaction to detail level. So early, we want to play (literally, wherever possible), with concepts, with quite different sketchy designs and mockups. This helps drive our creativity and keep our circles of design influences and partners fluid and thinking dynamically about what they value. Then, as we progress through all the divergent-convergent phases on the iterative and incremental design, the scope of our attention shifts (sometimes narrowing focus, sometimes returning to broad scope to refactor given a surprise or learning) but we need to keep applying this discipline of exploring design options. And as design decisions are made, and changes to the design start to bear higher and higher cost because the design is being molded in code that many minds are wrapped around and many hands touch, we need to bring that under change control, and that is where the design rulez in tools come in very handy. That way, we spot deviations from the "rules" inherent in key architectural design decisions early, rather than once they have becomes "hard cast" in a growing web of dependencies  ... that take a lot of work and destabilize the system in unpredictable ways when we try to factor them back out.     

And from September, 2010:

We just start our iterative cycles with the cheapest and most effective design medium for the kinds of decisions that need to be made, and think about which challenges and uncertainties to go after early. Those that will cost a lot to change. Those that cut across the system, and have far reaching impact. Those that are make-or-break. Those that will be lived with for a long time, so we should incur the cost of "quality of life" improvement (e.g. for the development team, or for user experience) earlier rather than later. Some will be market related. Some will be technology related. And code is not the Grail, value is the Grail, so artifacts that add or shore up value (like architecture models and descriptive and prescriptive architecture documents, etc.) are peer considerations to code when it comes to weighing how to invest time/budget/attention/talent. Remember, when we think in value terms, time invested in enabling many people to be more productive  (create more value with less resources), can be economically justified! Everything else applies--iteration, stakeholder participation, willingness to be wrong and renegotiate the value targeted. Etc.

Oh, today Dana was asked for the "Making It Visual" slideset because the conference organizers want to post the slides, so I guess I'll need to get the narrative completed after all. Rats! I thought I could let that slide...

10/21/10 Corralling Still More Thoughts Inspired by "Why Don't Developers Draw Diagrams?"

In the "Making It Visual" presentation (ahem, you're sick of me referencing that, aren't you? Well, good. Let's move on. Um, right after this.), there's this sequence:

Part of the point of that sequence is that a sea of classes in a class diagram is still an intractable medium for reasoning about and making architectural decisions -- decisions about resilient system structures and mechanisms that address functionality and cross-cutting concerns, etc. We need higher level abstractions, and we begin with conceptual entities, and elaborate and reify these in abstractions supported by our programming language and development framework. And we need to visualize architectural mechanisms. (I loved Ulrich's pragmatic succumbing to "chunks" for there's a mix of notions we're trying to capture here, including sub-assemblies and composites, but I prefer to use "mechanism" as "chunk" tends to focus on the structural and I really want both the structural and the dynamic or behavioral or functioning/how it works aspect to be included in the term I'm using, and mechanism does that for me. And I think of many of the design patterns as well-documented, tried and true, mechanism designs.) 

Image sources: 3 amigos, don’t know who to credit as these are used variously on the internet and I haven't located the original source. UML collage:  wikipedia; UML trademark logo, OMG; OOAD convergence map: wikipedia;  Vermeer’s Woman Holding a Balance, in National Art Gallery in Washington DC; http://commons.wikimedia.org/wiki/File:Woman_Holding_a_Balance_(Vermeer).jpg; "UML took it literally" image: Michele Lanza, presentation titled “Of Code and Change” on SlideShare; fellow reading and towers of books: Arnold Lobel [1933-1987]; Facade image source: Failblog http://failblog.org/2009/10/07/house-fail/Fox in the Hen House by Adolf Mackeprang (Danish, 1833 -1911) image at http://www.designsourcect.com/productsandvendors/fineartandmirrors.html; Boston Symphony Orchestra, http://www.bu.edu/today/files/images/articles/BSO%20(Michael%20Lutch).jpg; snip from Eric Whitacre’s Virtual Choir video on YouTube http://www.youtube.com/watch?v=D7o7BrlbaDs

And that's part of the introductory lead up to "something about boxes." Which you still haven't asked for either. Well, I make what I will of the sounds of silence... and do whatever I feel makes sense regardless. You know that. So you leave me to it, right? Just kidding.

I had to include those next several slides because the UML has made a huge contribution to our field, but we do have to use it effectively! Think about it -- do we blame English for what people do with it? We can say it is expressive and provides the medium even for a rule-breaker like ee cummings to create great work. But we don't blame language for naive or inappropriate use thereof! Nor has English been, and nor do we expect English to remain, static and unchanging. And we should expect this to be even more the case with a modeling language that supports a field that is as young and fast-changing as software!

10/20/10 Software Visualization Notes

Use contexts

  • architecting/designing the system

  • modularizing/refactoring/re-engineering the system

  • improving/tuning performance

  • coming on-board/learning

  • developing/evolving ("maintenance of") the system

  • collaborating on system development

  • testing

  • debugging

  • comparing architectures

  • teaching/learning
    - software development (cs, sw eng)
    - learning design/architecting

  • researching system designs
    - pattern mining

Please add to or correct/amend my lists!  (Oh, right, you can reach me at .)

I say "design intent" (or specification, but often the intent is pretty informally/conceptually described) to distinguish the models we create during explicitly intentional design activity from models of the design that is actually realized in the code. The latter, I call "design reflection" to designate a reflection of design aspects extracted from the actualized code or exhibited by the running system, executing actualized code. Which is to say, the design as realized may diverge from the design as intended. Alternatively, there may be no explicit model creation so that design is happening implicitly during code development. So we need to be able to distinguish the design inherent in the code, from the design intent. They may coincide. Or not.

How do you talk about this/make this distinction? If you prefer a different set of terms and distinctions, please let me know!

Definitions of Software Visualization differ in their inclusiveness. Each bullet point in the list below adds a dimension that various definitions may allow within the scope of the definitions (and hence the field of software visualization).

Software visualization: use of visual/graphical representations to visualize (aspects of):

  • source code

  • and executing software

  • and design (intent)

  • and activities of the teams developing, evolving, testing, etc. the software

I  vigorously advocate the inclusion of design intent, for many reasons. One is it allows conformance checking, which increases the value of software visualization to architecture governance and design improvement (if the realization does not match the design intent/specification, then either the code must change or the design must change and the visualization alerts us to this need to revisit either the code or the architecture/design).

10/22/10 Some Related Notes From the Archive

12/15/09 What are Models Good For? No, not that kind of model! The kind the guys putting together the Agile Manifesto swept under the table! ;-) [I'm still gathering thoughts and notes... this is just scratching the surface...] A model is a representation or abstraction of something that we are trying to understand. Here we are focusing in particular on visual models in system design and evolution. Models help

  • to express problems
  • reason about and solve problems
  • evaluate various outcomes, to make decisions
  • sharpen our understanding
  • compare alternatives
  • surface and make assumptions explicit
  • guide risk assessment
  • discover new questions
  • allow thought experiments (for example, exploring "how does/will this work" or "what if")
  • enable simulations to be constructed
  • predict future trends
  • communicate clearly and compellingly
  • provide a basis for explanation and training

If we think of the model as the visualization (as in the case of a model expressed in UML, for example) we need to remember that "pictures are worth 1,000 words"--but only 1,000. The rest of the words (rationale, descriptions, assumptions, implications, etc.) still need to be written down, if we want to accomplish goals like communication and preservation of design and intent.

When to model?

To support reasoning:

  • limitations of the human mind/complexity of the subject of inquiry
  • difficult to keep track of all dimensions/variables at the same time
  • make relationships among factors/variables explicit
  • reveal the structure
  • explore and illuminate dynamics
  • draw on analogies and models or theories from other domains

To support collaboration (bring more minds to bear on problem definition/solution):

  • facilitate understanding
  • lead more structured discussions
  • discuss specifics in the context of the "big picture"
  • set shared context

To support experimentation:

  • modeling effort is small, in comparison with the magnitude of the outcome
  • perform sensitivity analysis
  • test assumptions/beliefs

To support persuasion and influence (visual rhetoric):

  • improves confidence (team: "we can do it"; stakeholders: "they demonstrate they know what they're up against/need to do")
  • interesting
  • the power has influenced our idiom: "I see what you mean," "it draws people in,"

To specify:

  • illustrate and specify design intent
  • to show what parts we need, how they fit together, and how they collaborate to do the work of the system, and how cross-cutting concerns will be addressed

To evaluate:

  • to show how we will address stakeholder concerns
  • to show we have what we need (parts, fit, coverage, etc.)

To retain:

  • to capture otherwise fleeting thoughts -- our minds are lossy!; "tribal memory" is ad hoc and unreliable
  • to preserve our decisions and the reasoning that supports them (so we can intentional build better systems, and intentionally evolve them)

(When) Is a diagram a model? In software design contexts, I've seen some people distinguish "diagrams," or informal sketches of the architecture, system topology, use context, etc. from "models," and the distinction seems to be between more formal use of notation like UML and informal, ad hoc pictures. When these informal sketches are abstractions or representations of the system, these kinds of diagrams (from my perspective) are still models; they are just informally sketched. So perhaps this means that a model might have a lifecycle? Grin. Improving visualizations

  • interactive visualizations are more effective  (Pat Hanrahan, Tableau's CTO)
  • Visualizations should be used collaboratively – We intuitively know working in groups is powerful. They diversify knowledge and provide checks and balances. Pat’s example this time was a study done that watched groups problem solve an emergency escape route both with and without visual aids. It was much more difficult to do with discussion only. To make collaboration more successful, Pat recommends adding context with the use of comments and annotations -- Pat Hanrahan, Tableau's CTO

Epstein's essay titled simply "Why Model?" is targeted at (social) scientists, but makes a number of pertinent points--and he references one of my favorite Feynman essays. Here's an extract:

Simple models can be invaluable without being "right," in an engineering sense. Indeed, by such lights, all the best models are wrong. But they are fruitfully wrong. They are illuminating abstractions. I think it was Picasso who said, "Art is a lie that helps us see the truth." So it is with many simple beautiful models: the Lotka-Volterra ecosystem model, Hooke's Law, or the Kermack-McKendrick epidemic equations. They continue to form the conceptual foundations of their respective fields. They are universally taught: mature practitioners, knowing full-well the models' approximate nature, nonetheless entrust to them the formation of the student's most basic intuitions (see Epstein 1997). And this because they capture qualitative behaviors of overarching interest, such as predator-prey cycles, or the nonlinear threshold nature of epidemics and the notion of herd immunity. Again, the issue isn't idealization—all models are idealizations. The issue is whether the model offers a fertile idealization. As George Box famously put it, "All models are wrong, but some are useful."

Here's an alternative to the George Box quote:

"A theory has only the alternative of being right or wrong. A model has a third possibility: it may be right, but irrelevant." -- Manfred Eigen, (1927 -), The Physicist's Conception of Nature, 1973.

This slideshare presentation is neat: Creative Thinking: What we learned from Peter Pan and Willy Wonka.

7/31/10 Software Visualization

The software visualization community seems to have focused on one meaning of visualization -- forming images of the design implicit in the code, etc. That is, there is a focus on the existing system, and making aspects/characteristics/dimensions of the system visible. So, for example, the structure of the system is rendered; a picture is formed. I think, however, that both the following meanings are useful: forming images of system as intended (imagined, designed) and forming images of the system as it is. Then we have visualization applied to design intent ("smoke") and design reflection ("mirrors"). The focus on the (static) code visualization problem, liberated the conception of software visualization from our standard for visual design expression (the UML and sysML). This has meant that there has been creative exploration of forms and metaphors useful for visualizing existing systems. The apparent desire to distinguish and demark the field of software visualization, with its side-effect of highlighting weaknesses in design expression/visualization, has this plus side, but we need to be alert to where one informs and is informed by the other, because ultimately we would like the evolution of the design expressed in code and actualized in the system to inform and be informed by the evolution of design intent. The software evolution we want, is that which is driven because our intentions evolve, rather than devolution that comes because we have less and less design traction and start to make more and more ad hoc changes to the code (to try to keep pace with evolving intent or goals/objectives/needs). If there is a divergence between the way we express design intent, and the forms and formats for expression/reflection of the design (structures, mechanisms and processes) inherent in the code and dynamic system behavior, then we have to create mechanisms to translate between the two. That's ok too, if we can tool the translation process, but it is more transparent, there is less to learn, etc., if the same expressions serve both the design thinking/improving and the exploration of the design of extant code and running software.

Visualization: What?

visualize [www.websters.com]

–verb (used without object)

1. to recall or form mental images or pictures.

–verb (used with object)

2. to make visual or visible.

3. to form a mental image of.

4. to make perceptible to the mind or imagination.

 

visualization or visualisation [www.websters.com]

— n

1. the act or an instance of visualizing

2. a technique involving focusing on positive mental images in order to achieve a particular goal

Visualization: Why?

  • answer a question

  • make decisions
    - support analysis and reasoning

  • to explore and discover, encourage creativity
    - to look at things in a new way

  • communicate information to others
    - make a point
    - tell a story

  • inspire
    - part of our cultural heritage

  • amplifies cognition/perception [Card, Schneiderman, MacKinlay, Readings in Information Visualization]

-- Source: Pat Hanrahan, Stanford CS448B: Visualization

10/23/10 Software Evolution Map

Remember this outstanding xkcd (Ryan has fact-checked the Lord of the Rings map and declares he only found one inaccuracy; but he's only watched it several times ... too many)? Well, now see this: "Software Evolution Storylines," by Michael Ogawa and Davis Kwan-Liu Ma, SoftVis 2010. More here.

10/24/10 Today's 2c: Getting Past "But... it's not physical"

I pointed to this Visualization in Music slideset a while back, but... even if you were following back then, did you check it out? There are similarities with software visualization if you're willing to back up sufficiently to see them... for example, trees and cartography as organizing metaphors for visualizing information. In software the containment relationships are well, at least logical, and the data collection for the visualization can easily be automated. In music, assignment to genres and "this is like that" classification is interesting frontier-pushing kind of stuff -- such classification has been a human-centered activity although something like the Mechanical Turk can be used to help utilize the mass mind. But so far it looks like assignment to conceptual abstractions needs to be done manually (with human assistance, what a concept!), although semantic analysis together with good coding conventions could get us there... In both cases, there's an interest (among a sector of the visualization community, which presumably serves a (sub-)population) in evolution or genealogy, focusing on participants (artists or developers) and streams of influence and adaptation. There's the visualization of the "design" through informal and (to share and ease understanding) standardized notation, and there's visualizations of the non-visual "executing system," or sound in the case of music.    

One of the neat things that popped out for me, in the category of "hidden in plain sight" was the role of sketches in visualization. No, of course I know the role in design, but I mean human rendered visualizations of the built system. I mean, like DUH! We get so down in the channel of automated visualizations (yes, even I) that we overlook the role of the architect and engineer developing a mental model of the built system, and drawing out that mental model to explain the system. Then, what do we draw? Anything from blobs and boxes to UML diagrams. And I highly value blobs and clouds and boxes and other sketchy ephemeralia! So long as we don't pretend/expect that to be the system specification! Ok, why would that matter? Because in architecture/design extraction/reflection, we can utilize this! Again, this has been staring me in the face, because that is what we do with teams (playing the "system in the room" CRC-R game, for example). What we need to be doing more, in the visualization space, is to ask: how can we help man and machine complement each other? That, I expect, will be (even) more productive than (only) saying "how can the machine do this for us?"  or (more commonly) "what can the machine do for us?" Then we leverage the machine for what it is good at, and man for what she is good at. ;-) Partly, this is saying make the visualization/reflection game much more interactive, with the ability to compose conceptual structures that map to logical structures, for example. Some of the dependency/conformance analysis tools do this (like the Soto family from hello2morrow and many of the SDM tools like Lattix), but I think it would be useful if this process was more organic (allowing it to be done as the thinking progresses, as opposed to being entered from an already thought-out conceptual model).

Anyway, what I like about the Donaldson and Lamere "Using Visualization for Music Discovery" presentation on slideshare is that there seems to be a genuine pleasure in and appreciation for the human rendered visualizations, as well as the computer generated ones. Perhaps in music it is easier, or more obvious, to enjoy the art along with the science/engineering, but we need that mindset/value-structure in software too! Yes, the computer can troll enormous datasets and extract data which we can organize into information and render in pleasing and/or informative ways (hopefully generally both, though simply pleasing is nice if we can afford it). It can be more exhaustive, and uniformly/systematically created. Presumably this is, in some dimensions at least, more reliable, since human judgment and analysis is overlaid with perceptual biases and other fallibilities. How reliable, of course, may be a another matter of judgment or taste (music classification is subjective and multi-faceted). So, how about pattern mining and sniffing out code smells...? How about assisting comprehension when coming on-board and having to understand an existing system that you are new to, or which is just too big to grok unassisted? These are premier applications of software visualization, of course. Some of the research projects in this space are navigating in this direction of multi-views and more interactivity. Likewise with the tools in the commercial sector. Most, though, are growing from a simple, single-purpose tool (like an SDM), and moving outward. That puts them in competition with multi-purpose tools that include UML modeling and reverse-engineering, which will surely be adoption visualization strategies like SDMs as fast as they lift their heads and survey the competitive playing field!  One particularly interesting sounding project is IBM's System Grokker. I wonder if that work has been seeded into IBM Rational Jazz...??

Oh yeah, and I'm still looking for that model recognition tool -- I'll have to check in on how that MIT project is coming along. :-)

10/24/10 Visual Analogy, Symbol and Iconographical Rendering

File:Caspar David Friedrich 006.jpg

Image source: The Wreck of The Hope, Casper David Friedrich, Wikipedia

I was struck by The Wreck of The Hope on the cover of Visual Analogy -- of course, it is an important example of visual analogy, but so depressing!

"Bits and pieces of shattered masts lie wedged in among the pyramids of ice which rise into an empty, pale blue sky, creating a powerful emblem of life's end amid the failure of hope, of hope crushed by destiny and the forces of nature. All is cold, dead, jagged - and the sun shines brightly on the crushed hopes of man."

-- "Images of Crisis", George P. Landow, Victorianweb.org

But often the symbolism is plain enough, as in a well-known picture usually called The Wreck of the "Hope" (circa 1822). Friedrich was inspired, at first, by reports of early expeditions to the North Pole, all of which failed. But the image he produced, with its grinding slabs of travertine-colored floe ice chewing up a wooden ship, goes beyond documentary into allegory: the frail bark of human aspiration crushed by the world's immense and glacial indifference. "The ice in the north must look very different from that," Friedrich Wilhelm III of Prussia is said to have grumped on viewing this picture. He was right, though it scarcely matters. Friedrich's shipwreck survives as one of the most remarkable images of "sublimity" in all 19th century painting.

-- "The Awe-Struck Witness", "Time" online, Monday, Oct. 28, 1974

quote source: The Wreck of The Hope

[Note on 9/26/10: Dana points out his interpretation is very different from those above. The Hope is crushed, but all the pointers are to the light-filled Heavens. It is a spiritual interpretation. So, ultimately, it is all about man's quest for larger meaning, and a superb image to have on the cover of the book! It is a visual commentary on, and reflects on, this human duality: for atheists, death is the wreck of hope, a desolate end; for theists, it is just a turning point in the movement toward the light. (Dana goes further, and says it is hope transcended by knowledge.) Atheism has become more popular, and I have no idea if this duality was intended in the painting. But does that matter? Emergent, serendipitous meaning in art, and emergent, serendipitous value in systems only mean that the artist-designer was open to greatness, and didn't disallow it with a small-minded, petty design! Now, back to the flow from 9/24...]

Which reminded me of Albrecht Durer's Melencholia I. There is a wonderful discussion and interpretation of Melencholia here (Andrew Graham-Dixon Archives); of particular note are the pointers to iconic representations that assist the interpretation. 

Image source: Melencholia I, Albrecht Durer, Andrew Graham-Dixon Archives

Image source: Melencholia I, Albrecht Durer, Andrew Graham-Dixon Archives

Aside: The association of melancholy with "writer's block" resonates with me, for I do suffer a recurrent pattern of crisis in the "gestation" phase of a project. If I was Frank Gehry, I'd do something useful with the "terror of the thing" phase -- clear my desk! (Daniel Stroe recommended Sketches of Frank Gehry to me a few years ago, and I pass on the recommendation.) Instead, I look for confirmation that what I do works. I don't get it, but it seems to be important to look, get disconsolate, and fight my way back reminding myself that I have to follow my instincts because nobody else cares enough to let me know what I did was helpful, worked, etc. I don't think it is about hubris at all; we push ourselves in the aspiration of achieving excellence, and all that self-criticism is intrinsically humbling. It is more that we have to establish a kind of energy to cross the razor's edge. Or something. [Aside aside: Seeing that I'd just bought the novel (The Razor's Edge, that is), Dana said we really ought to get both movies and watch them side-by-side. He's seen the Bill Murray one from the 80's.]

 

Yes, I used Vermeer's Woman Holding a Balance in a slide in the Making It Visual presentation to make points about symbol/imagery and making and conveying meaning. I love that painting! Aside from how I was using it, architecting is so much about weighing and finding a balance between the more immediately material and the harder path of integrity.

It is worth bearing in mind that we have a host of iconic imagery that we use even as small children. Children seem to have a natural propensity to simplify or abstract. Ryan, for example, has long drawn people as stick figures on sketches where the mechanical is rich with detail and perspective. And yes, in a post earlier this month I used a series of Sara's drawings to show the natural aptitude for abstraction in visual rendering. And there are those that stick to the iconic visual symbols of our culture. Just think -- where on earth do kids get the idea that a sun is drawn with a smiling face? Or that stick figures mean people? Or that a house is a square and a triangle? Do these symbol sets just seep into us from others drawing them -- sometimes as a kind of visual shorthand, sometimes as a simplification because a more realistic depiction is "too hard"...?

I'm looking forward to reading Visual Analogy -- right after I finish Engineering in the Mind's Eye. I had read around in the latter, even read much of it, but hadn't read it cover-to-cover and it fell to hand reaching for a book to occupy me while "parked in the hallways of IU's music school" (waiting on harp lessons which are too long not to use the time productively, tempting as it is to just listen to the IU students practicing all around, and too short to get back to the office). In parts, Ferguson is rather opinionated, but it is full of great stories and relevance (despite being targeted at physical engineering disciplines), reminding me that I liked being a software engineer (as opposed to a computer scientist).

I did get the new edition of Documenting Software Architectures and have scanned around in it. It is one of those books that are more challenging to spend intimate time with because one feels sort of obliged, but the delta is harder to isolate because I spend so much time in that space... Reading about fortress design and thinking about the implications for software was just so exciting! I want to assemble "fortress design patterns" for software as a result! That gives me a much more exciting way to navigate security patterns and reliability patterns and even coupling and cohesion considerations. Well, anyway. Did I mention I like Engineering in the Mind's Eye? :-) The historical perspective is illuminating and interesting. For example, the hammer of insight dropped resoundingly when I read about the transition of (decision) power from foremen to model drawing engineers. It's not like I was unaware, but it shifted realizations into a new constellation that is useful, I think. I mean, think about it. In a world where people work for intrinsic satisfaction not money (we don't want to be treated unfairly, and we don't want to battle economically, but beyond that, we work for fun and meaning), taking decision freedom away is going to generate a significant power struggle! Like -- of course! Ax those model drawing architects! Make them look bad! Because every decision they make with those models they draw, conscribes and removes freedom. Yeah, we like to say architecture constrains and enables. But the constrains part is the part that is resented!  So, prove we don't need models; demonstrate that code is value and we can deliver increments of value that do double-duty in that they are a design proving-ground, stress-testing and improving the design along the way... and when the stress produces failure points, well, code heroics win the day. And then we can throw code at the code to extract the design and wahoo! Architects are obsolete!  Well, not quite. There are the small matters of scaling development, of design excellence and integrity, of cross-cutting concerns, of... Oh right. Model drawing architects help us deal with complexity in system and organization, and to achieve structural and design integrity or excellence. Well, gosh, we might need some of those! And so it goes...

Physical engineering is becoming more iterative and design is being pushed into the hands of consumer-inventors by 3-D printers and so forth, and software engineering might get there too. I mean, really get there. Like, agile software engineers and architects might even, at some point, talk to users. Now that would be transformative! ;-) We do play such games don't we? You know, we'll say we're doing agile, and have a product manager play the role of the user, and put all the effective design responsibility in the hands of the product manager. Stuff like that.

Well, all evidence to the contrary, I'm working on multiple fronts, including creating a "poster" of visualizations, and this is a draft assembly of two columns that leverages Jeff Heer et al's tour of the visualization zoo:

 

Image source: composite of multiple images, the first column primarily from Jeff Heer's "A Tour of the Visualization Zoo" article in Communications of the ACM.  

I say draft, 'cos I'm still working the analysis, even of these two columns (and others are still being pulled together). For example, I just realized I probably want to pull the SDM (Lattix shown above) up to below the hierarchy and arc view, since the rows (or columns) are essentially the containment hierarchy (with allowance for designating conceptual entities/modules). It's fun!

10/25/10 WTK! WTx?

This WSJ visualization is one you need to see! Who's watching you, and what they're looking at... :-) See also WTK - kids. (Heads-up via the awesome visualcomplexity site.)

But, um, software development managers are a lot happier than software architects, even though they earn about the same. I wonder why? Oh, yeah, right -- when it's rhetorical, you answer. And developers? I guess they're so unhappy they didn't count...

10/25/10 Uh Oh!

This is looking like a full several day slice of my journal, isn't it? Oh well. At least you're not getting the whole month! So, grateful for the daily 2c yet? Should we bring that back?

10/26/10 Towards a Layout for the Software Visualization Zoo

Well, here's a preview of the ideas that are currently taking and giving shape to the Software Visualization Zoo.

 

10/27/10 Delta

I need to amend or clarify that "dashboard" is a "status" view. Status then can include polymetric views of the code base and dashboard views of project and system performance, and it all hangs together better.

I'll have to add some explanations, but hopefully my "architecture" of the software visualization zoo is making sense just from the informal visuals illustrating (one way of) cleaving the space... :-)

I put Organization alongside the System views, but I see it also being like a cylinder, with organization wrapping over the static/structural view and mapping the organization to the structure. For example: who is working on what piece of the system right now, is a mapping onto the structure. Who owns what pieces is a mapping onto the structure. So, it needs to have an overlay onto the structure, much like the other overlays... But there are also unique organizational views that have nothing direct to do with the system structure... 

10/28/10 Ozzie's Lessons to Heed

and this is really cool -- Ozzie's notes from 1985 (gives insight into Windows 1.0 -- Windows is about to turn 25)!

10/28/10 Serendipity and Imperfections

This story about Mozart and the inclusion of happy accident is interesting!

I also bumped into this "master of imperfections" article, and it is interesting how, in this age of machined "perfection" we lean also to the human element in the imperfect -- even when mass produced!

When we go into future state envisioning kinds of things, I think it is just as well to keep returning to how this "human element" plays out... In visualization too. As we progress to more and more technology-slick and our aesthetic is pushed to a finer and finer tuning, we want, perhaps even need, to feel the organic and (inter)personal in work and art.   

And I watched much of Carl Zimmer's talk Inside the Mind's Eye. There are some interesting stories about early books and printing. I especially like the point that the advent of printing enabled much more rich and extensive scientific debate. As you know, I've been reading Engineering and the Mind's Eye, and that has lots of stories about the early use of sketches by artist-engineers like Da Vinci and Michelangelo and peers, and the role of their sketchbooks and the sharing and copying that happened among engineers. There's at least one chapter I'm skipping, even in this more systematic read-through, but it is well worth reading several of the chapters even if you aren't into history or engineering design and the role of sketching/diagramming/modeling to understand and communicate and debate... :-)

10/29/10 Wired to Solve!

We are just so wired to solve problems aren't we?

Here are some notes I took earlier this month:

Characteristics of the Software Problem (Pertinent to Visualization)

  • (Running) Software is intangible and observed only through its effects; that is, observable through interactions with the physical world (e.g., displays)
  • Code is manifest, but the manifestation is through linear textual artifacts (multiple of them) that are often not cognitively interacted with linearly. That is, we jump around in the code to reason about or follow how it works.
  • Moderate to large scale systems have considerable code mass and complexity ("wicked problems"/technical and/or organizational complexity such as large/multiple and/or distributed teams, etc.)
    -- cannot be held entirely in the mind
    -- many minds must be useful engaged
    -- minds are lossy!
  • Code creation is a complex conjunction of art and engineering, knowledge and invention, etc.: code is created in the mind and expressed in a highly symbolic language, and software execution by processors has to be "simulated" in the mind (or on paper) to design the dynamic interactions between the software abstractions that do the work of the system.
  • System properties emerge from the relationships (structural and dynamic or interactions/collaborations) among the parts and between it and its environment/context (of use, as well as technology context)
  • Software is (viewed as) highly mutable
    -- it is made to adapt when less flexible parts of the system (-of-systems) are hard/expensive to change
    -- it becomes less mutable with indiscriminate change/development creating (obfuscating) "mess" (so, for example, we have the exhortation to apply the Boy Scout rule "leave the site cleaner than you found it") and diffuse dependencies
  • Successful software systems tend to be long-lived (past anyone's expectations when originally built) and continuously evolved
    -- turnover on development team evolving the system
      -- attrition/loss of "tribal memory" of system structure and the intentions/rationale/reasoning behind it
      -- changes made without fully understanding system or implications of changes
      -- need to understand a growing, ever more complex, system structure and how it works
    -- code is treated as the "system of record" and other documentation/views are neglected, becoming out of date and mistrusted/not useful
    -- system structure degrades through time-pressured accommodations, lack of understanding, etc.

We have problems to solve! Wahoo!

The approach of looking where we can shine the light of a tool most easily, namely mapping the code (and package) structures, is a good effort to address the comprehension/location aspect of the multi-faceted "software problem." But compound problems tend to need to be viewed variously, to fully grok and apply reasoned design thinking (making things better than they'd be if we just let things happen without intentionality) to them. We apply a separation of concerns to make some aspect tractable, but then we need to work across the models and decision spaces to resolve tradeoffs and/or conduct synthesis thinking across the compound of concerns that is the system -- within a larger system.

As our systems encompass higher and higher ambitions, meeting expectations for more functionality, utility, integration and more, there is ever greater intertwining and interaction of concerns. When we model, we decide which limited set of concerns to focus on. That is, we abstract from the mass (and, often, mess) of detail and more than that, even given a focal concern, or small set of concerns, we tend to (need to) treat that abstractly too. Reality is a tricky concept, for our encounters with whatever "reality" is supposed to be are already limited by our perceptual filters and biases and the restricted nature of our sensory system and cognitive processing, and on and on. Some aspects of "reality" are tangibly physical but part of what we perceive to be reality is a shared construct; for example, was the Recession part of "reality"? But whatever "reality" is, our models are some very limited, restricted, restrained, constrained, filtered, abstracted rendering or reflection of some aspect(s) of that current "reality" or a projection of a future reality -- one we fear, or expect, or desire and want to cause to come into existence, etc. In design modeling, we reduce the problem to some essential characteristic(s), and focus on that design dimension and how to do well enough or to excel, at the limits, or something in between. We design to make things better. And we design to (try to) make sure things don't fail, and to provide recovery mechanisms and... more.

When we do all this design thinking in the medium of code, perhaps it is just as well to acknowledge that we are making all kinds of simplifying leaps in our mind's eye, tracing these threads of concerns and grappling with the problem without any cognitive aid -- without any aid to memory (what were we thinking 5 minutes, hours, days, months, years, ago?), to seeing what we're missing, to thinking and to discussing (or debating) and getting the benefit of other eyes on the problem. Yes, there's the code as record of our thinking, and we can see what it does, and that's a lot. And therein lies the problem! It's a lot. More every day! Moreover, it is but a partial record of our thinking, for it records the outcome of our reasoning. So we have to draw away from the code to better equip ourselves to reason about and bring other minds into the reasoning process for key kinds of problems (in particular, the architectural ones which are, by nature, challenging and diffuse in their impact and highly strategic/important to system success), and if we draw just in words, we have left an enormous cognitive aid to idle in our problem finding/defining/solving toolkit.

It occurs to me, given how hype-driven our technology world is, we have to make modeling "sexy" again. The UML wave produced it's post hype-bubble crash, giving rise to code-over-process (taken to mean anti-modeling) in Agile. Then that was getting too old for our nuevo-chasing tech world, and Agile relaunched itself as Lean, timed well to fit the tenor of the times what with the pervasive retrenchment produced by the Recession... Now DSLs are gaining attention as a leveraged way to code. MDA didn't quite do it, in terms of having enough nuevo sizzle. I don't know, but model-driven doesn't sound like quite the right way to sell a paradigm to developers... Yet modeling and iteration are not counter to each other or to any other of these. It amazes me that every single software engineering, computer science and informatics graduate doesn't emerge from college fluent in UML. We have to recognize that systems need to be designed, and we need to be fluent in visual design language not just programming languages. Oh yes, one might argue that programming languages are design languages -- very expressive ones at that!  And I totally buy into that argument. I just also think when we want to see the forest, to separate concerns, to think through higher level mechanisms and interactions so that we can get teams of teams productively building a collective work-product, a complex system, we need a visual modeling language that is expressive at that level of abstraction. Visual models simply help us see the design. Seeing it, we can manipulate it. We can discuss and test it. Improve it. We have to get to the point where we know that designs have independent value. That designs are competitive advantage. Implementations matter, but only to the extent that they deliver differentiating value. Design is where we address what that means and how we will accomplish building it in terms of sets of interactive parts -- with and through the creative, productive engagement of many minds.

In the innovation and business space, design thinking is in a spin cycle. We can ride the hype wave up. Of course, we need to do better, this time, at making sure visual design gets embedded in our culture so that when the spin/hype attention settles out, the values persist.      

Well, it is too bad that the OMG owns the UML. The tech equivalent of an exclusive country club is an elitist group to shepherd to an industry standard... but large corporations can dominate the political agenda so why not standards, huh?

10/29/10 Architect as Agent

Oh, while I'm being contentious... I think the design should be expressed in terms of multiple views as useful to expressing the design. Stakeholder concerns need to be weighed, and all that good stuff. But the views the architect focuses on are the views the architect determines are important to getting the thing designed and built.

A security (set of) view(s) is a design view -- made necessary because there are stakeholders who care about security, but it is first and foremost a design view. It is a set of models (and text) that we use to address the various security concerns of various stakeholders taken and balanced by the architect (team). The architect acts as the agent of these stakeholders actively and dynamically balancing their various security-related concerns and creating the models and capturing the reasoning and decisions the architect needs to think through, validate and communicate the design dimensions that address security. It comes back to my heretical notion that design is a conjoint matter and much is being dynamically balanced during the design process.

The views are addressed at some separation of concerns, at isolating some concern to gain design traction on the threads of reasoning that must take place to do that piece of design work and to have something to resolve across, as we iterate through the concerns that cut across the separated concerns (however you cleave concerns, you leave a set that then cut across; if you focus on security, you then have to look at the impact on cost and scope, performance, usability, scalability, etc.)...  

Which is to say, I think the architect is the first-order citizen in the creation, selection and construction of views. The architect has to balance across so many demands, that the architect (team) is the agent of all those stakeholders. To be an effective agent, the architect has to understand those stakeholders and their concerns, and use models and views to facilitate conversations with those stakeholders to gain and sustain sponsorship and advocacy for the work, to gain and mature understanding of the value sweet-spot and the spread and intensity of demands on the system, and so forth. But ultimately the views have to serve the architect in creating and expressing the design. We just fool ourselves if we don't recognize that design is a game of guts and intuition aided by as much reasoning, experience and mathematical/statistical modeling, and more that we can bring to bear in pragmatic timeframes. So, yes, if we swing the pendulum all the way over to some point of extreme technology push and architect as some kind of demi-god who invents without listening to or answering to stakeholders then we may need to force our architect through a systematic process of stakeholders-concerns-views-models... But the views of 4+1 or the core viewpoints of 1471 are design views -- architectural design views. They are the expression of the design and as such they serve multiple stakeholders and address multiple concerns. When the architect is working with one stakeholder (set), she will emphasize and draw out particular pertinent aspects of a design view, explain in terms of and relate different intentions and concerns to the view. The architect may decide more views are needed. Different views. Whatever the architect (or team) needs to think through, get input on, test, improve, communicate the design. And if the architect wants to express the design by building a mock-up with gourds, so be it. No, just kidding! Boxes maybe. But probably not gourds. ;-)  

10/29/10 Time for the NeXt Experiment?

It didn't take me long to lose interest in pulling out 2c worth every day... Grin.

I've been thinking for a while that what I need to do with my journal is provide a map that links to various entries by topic. So, I'd have to map the space, and link to my journal entries as a first pass (trimming off the personal as I go through that linking), and then, if I can rouse the energy, pummel them into more coherent shape as articles. But that is a big piece of work with 4.5 years of journaling here!

Tempting as it is to make that body of work accessible, I do really need to get the Visual Architecting/Action Guide book done already! It is rewarding to see how often people search for the book and we have to get it to ink (electronic and otherwise).

10/30/10 Design To Improve

I came across this sketch (below) in a notebook. I suppose it was my thinking picture response to Grady Booch's "architecture as shared hallucination" IEEE column from a few months back. Anyway, it prompted me to listen to that column again. I admire Grady's writing, the insights he invites us to share, the references he draws in, and the vividness of it. And I love that it makes me think! So, the thought-sketch alludes and responds to that column. But takes its own shape and makes its own points -- extending at least the boundaries of my perception and understanding. I like the "dream that shapes and improves reality, which improves the dream," iterativeness of it. The all-important dream that propels progress; the all-important building of the dream, what is learnt thereby, and the (re)fresh(ed) dream. It is also a comment on the software visualization tools space, reflecting for us to see and grapple with the design in the code, and the role that plays with respect to architecture design (as intent; or design to make things better than they'd be absent intentional, reasoned design thinking). Inspiration and pragmatics. It is a dance that moves us forward -- for the most part. Slam-bam into climate change, so now we need a new set of dreams, to pull us into a future lit with hope and full of realization. A dream the lights and guides a cascade of contributing dreams that guide and align action to combine to make some big thing real in the world. Something that makes a ding in our time, if not the universe.

We design to achieve our intent and then as we build the system, we use code analysis tools to reflect the design implicit in the code so we can improve the design and how well we meet our intent/goals

Of course, you know that we have long talked about threads of reasoning in VAP, and these weave across views. This scribbled note adds that we need to reason across abstractions, and iterate:

We model to abstract away detail so that we an reason, but then the abstractions leave off details that are important so we need to reason across abstractions

Reading that scrawl is like catching a thought by its tail and drawing it back in! 

We separate concerns so that we can deal with a tractable space that we can hold on paper and in mind, and manipulate, reason about, test and intercompare, synthesize, analyze*. We cope with our bounded rationality by simplifying what we have to deal with along various dimensions: we divide and conquer, carving the system into elements; we focus on a thread of concern, and let other concerns drop out of view. And as we work our way to a better understanding of the problem -- that is, a better characterization of the dream -- and as we design how we will realize that dream, we have to think across the views, resolving implications, synthesizing, analyzing, making tradeoffs. We accept that we generally have to ripple our thinking across various views -- explicitly where we need to "go more slowly" (a reference to the Master butcher Taoist story), and implicitly where our past experience has honed our judgment to the point where we can afford to rely on blink intuition and insight built on experience and careful observation and pattern/theory building.

Oh, by the way, I think this separation of concerns is what drives the design views. I know it is heretical and not "PC" of me to say that. Right? We serve stakeholders. They have concerns. Our views must address their concerns. Well, ye-es. But mainly we need to do what we need to do to design the thing. We use our models to show various stakeholders how the design addresses their concerns, but the foremost consideration is what do we need to apply design thinking to, and how best do we do that, and how best do we communicate that. So I see the thing from the other angle. I believe we act as agents of our stakeholders, and we need to get input from and test our ideas with stakeholders. But I think we do the design thinking in the medium that we feel best fits the decisions to be made, and then we filter (and potentially craft) what and how we reveal and explore that thinking with various stakeholders based on what they relate to, care about, and need to know, and what medium and media is best to serve them and reach the outcomes we are responsible for attaining. Remembering that attitude shifts, changes in mental model, and enablement are key to "successful" in that "good, right, successful" we go after. Anyway, I think an architectural design is a composite of views whose first and foremost function is to serve the creation and communication of a great design, where "great" balances across stakeholders. Because of this balancing, and because of this conjoint nature of the thing, I think it is better to orient ourselves to what views serve the architect! Given that the architect serves multiple stakeholders.

That said, I like leverage and Pareto. And I think that visual rhetoric is as important to the architect as it is to a social change agent/leader like Florence Nightingale (who is credited with the first statistical visualizations created for the purpose of persuading). Tufte is vehemently opposed to weighting the dice, so to speak, to make visuals mislead. So opposed, perhaps, that he comes across (to me anyway) as neglecting the emotive importance of visuals. We have to look to our moral compass and the goodness of what we are trying to bring about, and not try to mislead to get there. But to indicate that our design models should be analytical devices and no more, neglects the importance of engagement! Oh yeah, right. People are paid to do their jobs, so they should just act professionally and pay attention. No need to sugar-coat the pill of design. No need whatsoever. Wink wink. Well, it's Halloween. Time to deal with sugar! And a carnival-like atmosphere in our neighborhood!

* Yes, "intercompare, synthesize, analyze" is a reference to a wonderful Carl Sagan quote that Grady uses in the "as hallucination" column; there's also this great video that he pointed to in a presentation at Models 2009:

10/31/10 Happy Halloween!

Dana carved an Archman pumpkin! He's cool. Dana I mean, but the pumpkin-Archman too!

Journal Archives

Journal Map

2011

- January

- February

- March

- April

- May

- June

- July

- August

- September

- October

- November

- Current

2010

- January

- February

- March

- April

- May

- June

- July

- August

- September

- October

- November

- December

More Archives

October Topics

- Architecture Views

- Tacit Memory

- Early Facebook

- Decomposition and Cross-Cutting Concerns

- Architecting: Judgment Calls

- Defining sustainability

- Integrity and Design Mastery

- Focus -- Bursty!

- Capturing a Moment

- Truthy Architecture

- Vogue Gone Rogue

- Goose

- Federated, Diplomacy and Capitalized

- Some Notes on Visualization

- Don't Miss

- More Notes on Visualization

- Dana's 2c (Huge Value for the Money)

- Cramming Too Much Into the Day

- Intentional Serendipity

- Top Job

- SATURN 2011

- Something About Boxes

- Books

- Um, Hello World

- Upcoming Workshops

- Why Don't Developers Draw Diagrams

- Reworking Some of the Ideas: Why don't developers draw diagrams

- Corralling More Thoughts on Why Developers Don't Draw Diagrams

- Corralling Still More Thoughts

- Software Visualization Notes

- What Models are Good For

- Software Visualization

- Software Evolution Map

- Getting past But ... it's not physical

- Visual Analogy, Symbol, and Iconographical Rendering

- WTK WTx

- Uh Oh

- Towards a Layout

- Delta

- Ozzies Lessons to Heed

- Serendipity and Imperfections

- Wired to Solve

- Architect as Agent

- Time for the NeXt Experiment

- Design to Improve

 

Chief Scientists

- Grady Booch

- Martin Fowler

Enterprise Architects

- Todd Biske

- Adrian Campbell

- Leo de Sousa

- Chris Eaton

- Roger Evernden

- Tom Graves

- Adrian Grigoriu

- Paul Homan

- James Hooper

- Kristian Hjort-Madsen

- Alan Inglis

- Janne J. Korhonen

- Nick Malik

- Sethuraj Nair

- Jim Parnitzke

- Chris Potts

- Praba Siva

- Serge Thorn

- Jaco Vermeulen

- Tim Westbrock

Architects and Architecture

- Charlie Alfred

- "Doc" Andersen

- Tad Anderson

- Jason Baragry

- Simon Brown

- Rob Daigneau

- Udi Dahan

- Matt Deacon

- Louis Dietvorst

- George Fairbanks

- Kevin Francis

- Sam Gentile

- Simon Guest

- Todd Hoff (highly recommended)

- Steve Jones

- Frank Kelly

- Philippe Kruchten

- Sjaak Laan

- Dave Linthicum

- Anna Liu

- Ruth Malan

- Nick Malik

- Chirag Mehta

- JD Meier

- Gabriel Morgan

- Robert Morschel

- Dan Pritchett

- Chris Potts

- Bob Rhubart

- Arnon Rotem-Gal-Oz

- Carlos Serrano-Morales

- Shaji Sethu

- Leo Shuster

- Collin Smith

- Brian Sondergaard

- Michael Stahl

- Daniel Stroe

- Gavin Terrill

- Jack van Hoof

- Steve Vinoski

- Mike Walker

- Rodney Willis

- Eion Woods

- Brian Zimmer

Architect Professional Organizations

- CAEAP

- IASA

- SATURN

Software Visualization

- Adrian Kuhn

- Jennifer Marsman

Domain-Driven Design

- Dan Hayward

Agile and Lean

- Scott Ambler

- Alistair Cockburn

- NOOP.nl

- hackerchickblog

Agile and Testing

- Elisabeth Hendrickson

- Elizabeth Keogh

Software Reuse

- Vijay Narayanan

Other Software Thought Leaders

- Jeff Atwood

- Scott Berkun

- CapGeminini's CTOblog

- John Daniels

- Johanna Rothman

- Joel Spolosky

CTOs and CIOs

- Rebecca Parsons

- Werner Vogels (Amazon)

CEOs (Tech)

- Jonathan Schwartz (Sun)

CEOs (Web 2.0)

- Don MacAskill (SmugMug)

Innovate/Tech Watch

- Barry Briggs

- Tim Brown (IDEO)

- BoingBoing

- Mary-Jo Foley's All About Microsoft

- Gizmodo

- Dion Hinchcliffe

- Oren Hurvitz

- Diego Rodriguez

- slashdot

- smoothspan

- The Tech Chronicles

- Wired's monkey_bites

 

Creativity

- Marci Segal

 

Social Networking/Web 2.0+ Watch

- bokardo.com

- Mashable

 

Visual Thinking

- Dan Roam

- David Sibbet (The Grove)

- Scott McLoud

 

Leadership Skills

- Presentation Zen

 

Strategy, BI and Competitive Intelligence

- Freakonomics blog

- Tom Hawes

- Malcom Ryder

 

Um... and these
- Nick Carr

- Tom Peters

 

Green Thinking

- Sylvia Earle, TED

- CNN Money Business of Green videos

- Matter Network
 

Comics

- Dilbert

- gapingvoid

- xkcd

- Buttercup Festival

- phd comics


 

I also write at:

- Resources for Software Architects

- Trace In the Sand Blog

 

Papers:

- Strategy, Architecture and Agility: The Art of Change: Fractal and Emergent, 2010

- Innovation and Agile Architecting:
Getting Past ‘But’: Finding Opportunity and Making It Happen, 2008

 

Visualization

- Links to tools and other resources

 

Misc. me:

- Other Interests

- Introducing Archman

 

Copyright © 2010 by Ruth Malan
URL: http://www.ruthmalan.com
Page Created: October 1, 2010
Last Modified: December 01, 2011