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:
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
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.
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.
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".
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.
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.
(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. - Hess.)
One Size Never Fits All
Before a wide selection of inexpensive, off-the-shelf clothing was available in the marketplace, most of a family’s clothing was made at home. My mom made much of my wardrobe when I was younger. Frequently, I would accompany her to purchase material and choose patterns. Later, she would pin the finely marked tissue to the fabric, cut the components, and stitch them together. Whatever the occasion, style, or article of clothing needed, a pattern existed that was specific enough for the task, yet versatile enough for variation and adaptation. She always found what was required, and was able to execute no matter the scale or material.
What was so magical about those patterns? How was it possible for my mom to cope with the seemingly infinite variations in material, size, proportion, and style; yet consistently deliver a quality finished product? While she is one of the most creative people you could meet, why wouldn’t she just craft her own patterns? You would think that she had plenty of experience. And what does this have to do with software architecture?
For software architects, the pattern has emerged as a valued, and widely discussed, component in our toolkits. Because patterns evoke a sense of predictability, even in complex problem spaces, they increase confidence in our ability to deliver the software needed to solve these problems. The Gang of Four, and subsequent pattern community contributors, created a language for cataloguing and describing these concepts. Then they refined this communication in the context of accepted modeling semantics, communication mechanisms, and solid system engineering practices. Yet, how many of us actually leverage patterns as deep foundations for our projects?
|
The diagram at the right is a detail from an early 20th century Russian clothing pattern. It represents a small piece of an overwhelmingly complex model. However, for the tailor this complexity is actually freedom: a form of documentation for an expert practitioner. Subtle variations in scale and implementation style are interlaced in an approach acceptable to like professionals. There is a tremendous amount of information encoded into this pattern. While this detailed information fosters adaptability, it limits broad usability across a range of experience levels.
|
Figure 1: Clothing pattern (detail)
"Neva" Magazine, St. Petersburg, 1906
|
|
Figure 2: MVC pattern, object relationships
|
This diagram is a typical representation of one of the patterns that I believe nearly anyone can grasp: Model-View-Controller. If you have even the most basic understanding of separation of concerns, OOAD principles, and the “box and line” modeling semantics, you can get an understanding of how this pattern works. However, it leaves many of the details up to the implementer. By design, it furnishes no scale or style dimension, letting the system’s requirements determine the instance variations in communication protocol, object interaction and presentation variation.
|
In the software architecture world, which of the above diagram styles has more value? Which diagram is closer to the mechanisms that we use to communicate our architectural thinking to those actually implementing the work? It is my belief that, while we often use the latter diagram model, it falls short in describing the myriad details comprising a real system. There are two challenges that need to be considered when we consider this gap in effectiveness: Our quest for simplicity, and our thirst for creativity.
The architecture of any system today is inherently complex. As architects, we strive to decompose problems into manageable chunks, into understandable models that attempt to simplify the communication of complex challenges. In fact, this is not unique to software architecture. As Stephen J. Gould writes, “From its late-seventeenth-century inception in modern form, science has strongly privileged the reductionist mode of thought that breaks overt complexity into constituent parts and then tries to explain the totality by the properties of those parts…”[1] He wrote this in an article commenting on the discovery that predicted 1,400 genes of the human genome, as calculated from endpoints observed in the human system. In reality, there are more than 30,000 to 40,000 genes. Clearly the quest for simplification and reduction led geneticists to erroneous conclusions. Software architects today often err in the opposite fashion. Rather than encoding additional detail, we highly refactor our models; thereby, leaving much to interpretation. To effectively leverage patterns we should find ways to instantiate patterns in very specific forms. We should use the platform, language, problem space and practitioner experience available to us as influencers to work in an appropriate level of detail.
Architecture is an inherently creative task. We have a multitude of options available to us. Much of our work is not guided by physical principles, but rather by instinct and feeling. Consequently, we are suspicious of “silver bullets:” those predictable, packaged solutions that ultimately fail at some critical juncture. Also, our creativity is challenged by an ever changing landscape of platform technologies, standards, capabilities and tools. Pity our colleagues who are faced with the daunting task of implementing our grand architectures. An abundance of choice hinders our ability to effectively leverage patterns, or even to provide a basic platform for training and understanding. Finally, we each categorize our system thinking differently, creating misunderstanding even when discussing the same fundamental pattern.
Totally reinventing and re-categorizing our architectural patterns is not required. Nevertheless, to make the best use of patterns we should address architectural ambiguity by introducing more context into our pattern usage. As my mom said, “You can’t just make a shirt; you need to be specific about cut, style, and fabric.” What’s more, you can’t simply reclassify “shirt” to “sweater” without forming a clear tie back to a common starting point. As architects, we need to leverage the strengths of our expert practitioners, and furnish them with the tools and resources that provide the correct balance of boundary and adaptability. Only then can we consistently deliver the perfect garment. In this way our pattern catalogues become useful, effective, and can actually be used by our developers.