Matt Hessinger

My summer with Hofstadter: A prelude + week 1

2009-05-19T15:19:13Z

While waiting for my flight at LAX after TechEd, I strolled into the newsstand for a little light reading. Somehow, I made it past the tabloids (“Jon and Kate: Swinging with aliens? We have the truth..”), and at the back found the book section. I had no preconceived notion of what I was looking for. As I perused the tiny science section, I was shocked to see not one, but two copies of Douglas Hofstadter’s seminal work, “Gödel, Escher, Bach: an Eternal Golden Braid”. These were copies of the 20th anniversary printing from 1999, making this year the 30th anniversary. I had read the book over 20 years ago, at a time when it’s nuance and technical depth were well beyond my intellectual, spiritual and personal maturity. Maybe I was more prepared today to absorb its wonder. I figured that it was worth finding out. My purchase in hand, I headed for my flight.

As I read the introduction, and the first chapter, I new I was in for a good ride. I would have to take this one slow, since there was much to consider, on many levels. There is the base “this is what the book is about”. Then, there is the “hey, this applies in a parallel way to what I do professionally”. The final consideration was “It might be nice to blog about some of what I am experiencing”. This last point relates to my motivation to document and share a bit more of what I am experiencing and thinking (read: blog a bit more than once every other month!). It seems that the theme of this site, the relevant threads that the book might present, and my own opinions and experience might make for an interesting mix.

This will not be a book review per se (My review: It’s good. Go read it.) It will rather be an extraction of key points, quotes, and thoughts, applied to the work that we do and the world we live in as software architects. So here goes: Week 1 of my “Summer with Hofstadter”.

Links:

The book on Amazon
The book on Wikipedia
Douglas Hofstadter: Indiana University faculty page
Douglas Hofstadter on Wikipedia

My summer with Hofstadter, Week 1

(through page 41)

Paradoxes vs. Consistency…the grudge match

Hofstadter sets up his conceit, introducing his characters, laying the foundation for the deeper discussion, and as such presents a number of interesting concepts and quotable passages. Two jumped out at me as relating to the work that we do as software architects. The first, from page 22, speaks of the push in mathematics, and other disciplines, to create systems that are paradox and contradiction free:

“…the drive to eliminate paradoxes at all cost, especially when it requires the creation of highly artificial formalisms, puts too much stress on bland consistency, and too little on the quirky and bizarre, which make life and mathematics interesting. It is of course important to try to maintain consistency, but when this effort forces you in to a stupendously ugly theory, you know something is wrong.”

This resonates with me, and also demonstrates a key challenge that we face. Our clients, our customers, the consumers of our work, don’t handle paradoxes well. They want us to make decisions that, once written in the stone tablets of their memory, never change, grow, expand or go out of fashion. How many of your customers can tolerate “quirky and bizarre”? They may say they want flash (I mean, Silverlight, of course), but what they pay for is bland. In fact, Ralph Waldo Emerson takes an even stronger tack, stating “A foolish consistency is the hobgoblin of little minds, adored by little statesman and philosophers and divines. With consistency a great soul has simply nothing to do”. Note that it is not all consistency, just the “foolish” kind. Our job is to make that distinction.

How many times have you let a drive to consistency push alternative solutions out of consideration? How many times have you come to regret this singular focus on the polished, smooth edged approach? I for one want things to look, feel, taste the same, especially as the breadth and depth of a solution grows. This is natural: A proliferation of conceptual and logical views (or, even worse, meta-views: approaches to viewing) can make communication that much more difficult. However, the communication, the concept is not the goal: The solution is. We need to balance the overall need for consistency with the need presented by the problem. In some cases, we have to surgically throw away our preference for the smooth, and allow a few jagged edges to creep in.

Ralph Waldo Emerson, “Self-Reliance, Essays: First Series”, p. 57

A definition of intelligence

One of Hofstadter’s areas of interest is in Artificial Intelligence, and the concepts that might drive our proof of its possibility. Figuring out what intelligence is, determining where the finish line is, so to speak, is a important component of the AI puzzle. Hofstadter presents one definition of intelligence, which, because it is not attributed to anyone else, I treat as his opinion (from page 26):

“No one knows where the borderline between non-intelligent behavior and intelligent behavior lies; in fact to suggest that a sharp borderline exists is probably silly. But essential abilities for intelligence are certainly:

to respond to situations very flexibly;

to take advantage of fortuitous circumstances;

to make sense out of ambiguous or contradictory messages;

to find similarities between situations despite differences which may separate them;

to draw distinctions between situations despite similarities which may link them;

to synthesize new concepts by taking old concepts and putting them together in new ways

to come up with ideas that are novel.”

This sums up pretty well the challenge that architects face. Do I mean to infer that the architect is the only “intelligent” member of the team” Of course not. What I do mean is that the balance of what we know working against what we feel might be needed can make us uncomfortable, yet it is that very tension that makes what we do so important. Following processes by rote, filling out document templates mechanically, following prescribed, standard rules by the book: Is that intelligence? No. Applying, in new ways, (or even ignoring) standards, processes and tools is sometimes the most appropriate.

A recent Gartner essay, “Five Questions the CIO Should Be Asking About Enterprise Architecture”, presents an argument whose support could be found in the above statements, namely that “In a time of economic turbulence and uncertainty, a business-focused enterprise architecture can ensure a rational approach to investment.” (emphasis is mine). Do you see “ fortuitous circumstances” in the current whirlwind of layoffs, closings, bailouts? Maybe not, but you had better be flexible, you have to create clarity from ambiguities and contradictions, and novel ideas are probably a good place to put some effort. The more of this kind of intelligence that we can apply to our work, the better off our clients and customers will be.

“Five Questions the CIO Should Be Asking About Enterprise Architecture”, Gartner, May 2009

TechEd 2009: Pre-conference questions posted

2009-05-18T13:09:56Z

Jim Wilt (Metrics Reporting), Miha Kralj, Simon Guest, Angela Yochem (Dell) and I hosted the Architecture track’s pre-conference session at this year’s TechEd conference in LA. During the afternoon, we had the audience post some of the questions that were top of mind to them, and then had an open discussion around them. I have captured most of the questions from that day, and have posted them to the “Interests” forum. You can also look for the tag “TechEd 09”.

Thanks to everyone who attended.

Architect Resources – Business Analysis Book of Knowledge (updated)

2009-03-31T19:53:52Z

In this post, I mentioned that I would follow up with posts summarizing the six focus areas that IIBA outlines in the BABOK. However, what I didn’t realize at that point (and what I should have updated in the post) was that the IIBA was working on releasing their 2.0 version of the BABOK. It just released today, so I am going to spend some time reviewing it in the coming weeks, and then will put out the posts on the knowledge areas.

In the new version, the knowledge areas are as follows:

Business Analysis Planning and Monitoring
Elicitation
Requirements Management and Communication
Enterprise Analysis
Requirements Analysis
Solution Assessment and Validation

They also discuss a host of Underlying Competencies that support the work in the knowledge areas.

As I mentioned in my previous post, I would recommend that you all join the IIBA (the fee is $95 US). Among other things, becoming a member gives you access to the new BABOK 2.0.

Reference to great post on architecture skills

2009-03-13T17:33:00Z

A former colleague from the Microsoft Visual Studio Advisory Board/.Net PAC has posted a very interesting, very topical blog post relating to architecture skills. Wiebe Wiersma is Capgemini's Principal Technology Officer in the Netherlands. His latest post, entitled "Why do we need solution architects?", talks about the breadth and depth of experience and skills that architects need to have. I will admit that the title threw me a bit, but I get where he is coming from. Read it, then form your own opinions. Note that the post also includes a nice bibliography for your further reading.

I posted a comment on his blog, and mentioned my SAF presentation. For anyone reaching this post from my comment, you can download the presentation, "Architecture and Analysis: Perfect Together".

Portrait of the Architect as Artist

2009-03-02T20:28:00Z

- "Walking" (detail), Carolyn Hayes, 1964

(FERDINAND)

This is a most majestic vision, and
Harmoniously charmingly. May I be bold
To think these spirits?

(PROSPERO)

Spirits, which by mine art
I have from their confines call'd to enact
My present fancies

- "The Tempest", William Shakespeare

How many of your software projects do you consider truly beautiful? How often does your customer feel the same way? Are you, the architect, ultimately responsible for those feelings?

I ponder these issues often, particularly when reviewing and analyzing the successes and failures of my own career path. Then there is that agonizing question: just what is a software architect? We all often fall back on the traditional “building designer” metaphor. While it is a tried and true description, I find it lacking for one reason or another. Other models must exist that better describe the numerous challenges and responsibilities of our software profession. Even our customers, the ultimate benefactors of our work, need a better way to understand the value of our contribution. Other careers inspire similar passion, enjoyment, frustration and challenge, and offer meaningful parallels that enhance our work and crystallize our ambitions.

Beauty is in the eye of the beholder. This is often the case for subjective work with intangible or non-existent requirements. It is the responsibility of the person charged with creating the work to ensure that the multitude of details that do not exist on paper, that can not be quantitatively tested once complete, are present in a real enough form as to enter the awareness of the consumer. Software, while theoretically tangible, is often viewed by users with a mixture of awe, suspicion, expectation, frustration, and sometimes even gratitude. The software architect bears the brunt of the responsibility for ensuring that the user experience fall on the positive side of those reactions.

It is not enough to have a vision for the solution; we must persistently nudge our team to successfully achieve that vision. Our challenges are immense. Frequently our team membership represents varying skills, personalities and experiences. They must work within the boundaries of the available or chosen technologies; deal with the whim of fashion and style; and conform to arbitrary expectations that often compete against the best solution to a problem.

Art is a powerful force in my life. I have been a musician since I was very young.. In high school and college, I spent time in technical theater. My wife is a stained glass artist, and herself spent 12 years in technology. Today I play several instruments, but have turned my creative focus to glassblowing. Yet while art is important, maybe even a passion, I am a software architect by profession. I get much of the same satisfaction out of participating in software projects as I do from my involvement in music, theater and art. I notice too that many of my peers and mentors share a similar connection to the arts. I find interesting parallels between software architects artists that offer to improve our careers and enhance our professional enjoyment. In these comparisons, I will draw on parallels in team arts, such as glassblowing and music ensemble, which share many characteristics with software projects.

The following comparisons make these assumptions:

- The architect has experience in what is proposed

- The architect influences substance, manner and motivation of the team’s work

- The architect is a part of the entire project lifecycle, and touches pieces of the project as it progresses

- Becoming a good architect takes time

- Not everyone can be a good architect

The learning lifecycle

In the creative arts, especially those that have both individual and team dynamics, there are very established and effective learning processes. These combine a focus on individual skill with real time performance assessment and team collaboration and feedback.

Learning the repertoire

For musicians, regardless of their instrument, there are certain standards that are learned. For example, there are certain basic techniques that must be mastered to be proficient as a glass artist. These are important foundations to the emerging artist. For the musician or glassworker who wants to become the visionary, the composer, they can not bypass these steps. It is a shared set of experiences and fundamental knowledge that will connect them to their “teams” as they progress.

The recital as learning tool

Music is not just about “making music;” it is about the performance. For visual artists, the performance is seldom live; nevertheless, the critical peer and teacher review remains a close analogy and an important part of the learning process. These real-time, candid, ego-pressuring experiences refine vision, focusing attention on details that others see or hear. When teaching software architecture, this technique would be a valuable addition to standard modeling and documentation tasks. In the real world, the vision of the architect must encompass many other views.

Apprenticeship

Many of the best artists, the most visionary composers and conductors, worked for those who came before them. In participating in another’s efforts to realize a particular vision, they are freed to experience the process, and at the same time required to continue to hone their own sense of what will be “right” in a particular work. To become a great architect, apprenticing with a more experienced mentor provides countless opportunities for first-hand experience –– close to the material at hand. In fact, just like in the creative world, this apprenticeship often leads to the student becoming the master, as the master moves on to greater and or different things.

The project lifecycle

Once in the architect’s chair, there are many facets of the process that await the architect’s inspiration. Their sphere of influence includes the selection of technologies to how those technologies are implemented to how well the team knows how to implement them.

Breaking molds…and repeating what works

In art and music, as in software, there is a fine line between breaking new ground, and digging one’s grave. In many cases, even ideas that seem radical are based in fundamental patterns and techniques. Whatever the case at hand, it is the architect’s responsibility to carve away any unnecessary innovation, only breaking the mold for the most necessary and justifiable reasons.

Know your role…and theirs

A symphony orchestra has many components, all of which must work in concert. Likewise, teams on large glass art projects have scientific, artistic, safety, environmental and commercial challenges, requiring individual expertise to be focused in different areas. In the end, these group leaders are responsible for the end result, know everyone’s role, and can demand refinement based their knowledge of the substance, manner and motivation of the work at hand. In essence, the leader knows how to do it. In software, the architect without direct understanding of what needs to be done AND how it is going to be done will never get the best work out of the team.

It’s not done until it’s done…but know when it is

The end result is measured not only by the architect, composer or visionary artist. It is measured by all those who experience it, who use it, those who make it a part of their lives. However, those same people know how they feel about it when it is done often can not articulate beforehand when it should be done. The vision for the end must take into account the needs and wants of these consumers, but also must be advocated by the architect.

In my world, the software architect is like the artist. Those artists who depend on their own inner vision for a solution, but who also rely on the skills of those around them to achieve that vision. Artists are as good at doing as they are at proposing. Artists that have a powerful impact on those who come in contact with their work, work which is made that much greater by all who are involved.

Further reading: Several months ago, I had a long conversation with Ward Cunningham, who had recently joined Microsoft. Our discussion turned to linkages between art and software. He pointed me to work by, Richard P. Gabriel, a Distinguished Engineer at Sun. Gabriel has been working, with others, on a proposal for a Masters in Fine Arts in Software. You can read more about it here, and read some of Cunningham’s (and others) comments here.

Architect Resources: Business Analysis Book of Knowledge

2009-01-05T00:22:00Z

Last year, i worked with several colleagues to prepare a presentation to Microsoft on tool support for the Business Analyst. The audience included leadership from Visual Studio Team System, DPE, Office, Oslo, and others. One of the members of our small working group considers himself first and foremost a Business Analyst. He brought a tremendous amount of domain knowledge, reference material and credibility to the discussion. One of the organizations he referenced was the International Institute of Business Analysis. There are several things that this organization offers, including their core publication, "The Business Analysis Book of Knowledge", and their certification, "Certified Business Analysis Professional".

As I have been working on the topic of the relationship between Architecture and Business Analysis, and their requisite roles, I decided to join the IIBA. My main reason was to gain access to the BABOK. I expected that it would give me an objective assessment as to whether my thoughts on integrating the two roles had merit. I also figured that, as someone who has focused on architecture, there were most likely many things to learn. The result: Yes: There is serious overlap. And, Yes: I have lot to learn.

The BABOK outlines six core areas of focus for Business Analysis. Even without any of the details, I would expect that many of these line items will resonate with my fellow architects. In fact, I would expect that you all perform some or all of these activities. In a series of subsequent posts over the coming weeks, I will explore each of these areas, presenting some of the topics that the IIBA feels are important to that focus area, and discussing them in the context of the architect and what they need to do to create good architecture.

The six areas of focus, with their related topics, are as follows.

Enterprise Analysis
Requirements Planning and Management
Requirements Elicitation
Requirements Communication
Requirements Analysis and Documentation
Solution Assessment and Validation

I would recommend that you all join (the fee is $95 US). Among other things, becoming a member gives you access to the BABOK. Having read through about half of the BABOK so far, the areas that they consider in detail are all valuable for the architect to have in their box of tools, and to have at the top of mind as they work through the process of creating the architecture at hand.

One size never fits all.

2008-11-29T18:44:00Z

This article was originally published on MSDN in the Architecture Center in April, 2004. With its relevance to discussions about simplicity, I felt it worthwhile to dig it up.

...(read more)