A Trace in the Sand
by Ruth Malan
7/1/06 Complexity Costs!
Scott Sehlhorst points to a case where confusing complexity introduced by extra features actually cost significant (in relative terms) revenue—$245,000!
7/1/06 Overlapping Roles
Technical product management and architect roles often have a degree of overlap. Who owns the "product concept," the architect or the product manager? Who is the design authority? What does it mean to be the design authority, if the design authority has no authority over the product concept? Wherever roles overlap, there will be some grey area on questions like this, and the answer is going to depend on organizational factors, and even the skills and aspirations of the individuals in these respective roles.
Sherman Dickman (Director of Product Management, Mozilla Corporation) discusses his responsibilities as product manager on his blog (Sherman's blog), and these overlap with responsibilities we would also associate with an architect. These are the activities that Sherman identifies as activities that the Product Manager helps co-ordinate:
"Another critical product management function is to collect user data, and then analyze the information to find hidden stories and opportunities. The biggest challenge in collecting user data is knowing what questions to ask and from whom."
from Sherman's Blog, June 20, 2006
Product management is generally responsible for product strategy, and architects need to partner well with product management, providing input to the strategy, identifying opportunities, risks, and imperatives. Architects are generally responsible for the technical strategy, given the product strategy. But a strong partnership between the product manager and the architect will help set a productive tone for a high-performing team, and generate a strong product strategy into the bargain.
Sherman explores the Firefox Value Chain in his June 28, 2006, blog entry.
7/5/06 Thanks Software Program Manager!
While you're looking into overlapping roles, you might also want to see Life of a Software Program Manager. (This blog has paid me the honor of putting my Trace in the Sand blog in the Blogroll. There you go, another opportunity to be first, taken!) The idea for this blog was to provide an accounting of the life of a software program manager. A great idea, if you ask me. And if you come across architects blogging their daily/weekly odyssey, please do let me know (and when you take up a podium in the blogosphere, please let me know that too).
7/17/06 Interesting EA/SA Links
I've been out of touch traveling this past week, so today I've been re-immersing myself in the Enterprise Architecture and Software Architecture world today. Here's some work that caught my attention:
7/17/06 Bridging the Divide
We often hear that business executives are demanding greater alignment between IT and the business, with the criticism for the shortfall implicitly being levied against IT. But alignment cuts both ways:
"it has often been shown that the flexibility of IT systems cannot compensate for non-existent or imprecise planning of the processes that the systems have to support."
From p.8, Government Enterprise Architecture in Denmark, Ministry of Science, Technology and Innovation, July 2003
Still, it also isn't generally ideal to push the onus onto the business side to get the processes right first. Where possible, we should really create a cross-disciplinary team for process design that includes IT. Alignment comes from both the business and the technology sides working together, not from IT doing all the work to fit the business. A good partnership between IT and the business will yield capabilities (process + technology + skills/knowledge + assets) that are better fit to the business strategy, more innovative, and more sensitive to constraints and opportunities. To address the need to partner across the business-technology divide, we have created a new seminar titled A Day Across the Divide: Bridging Strategy and Architecture.
7/17/06 Architecture Documentation: Courage to Fly in the Face of Convention
The only thing harder than getting engineers to read architecture documentation is getting architects to write it, so why bother? Who cares? It is only going to get out-of-date. It takes work, and isn't that time better spent coming up with better solutions to the challenges we face? Or better still, writing code, which is the ultimate in system documentation—right???
An architectural decision that isn't written down has a lifespan of, let's see, what is the memory span of a goldfish? Actually, it turns out that a goldfish memory span is not just a few seconds as previously thought. And we're even smarter than goldfish. Can't we just rely on our individual and group memory? Well, we have all been in the situation where a decision we thought we made yesterday, is still under debate today, and we have to persuade and coax, inform and influence and defend all over again.
Writing the decision down doesn't get us entirely away from all of this, but it does help. We get agreement on the decision and once that is achieved we can also agree that only counter-arguments that have a strong link to architectural objectives (or the business strategy and imperatives that drive the architecture) can be brought up in contention with the decision. (Remembering that architecture decisions are make or break, and changing them needs due consideration.)
Still, the half-life of an architectural decision depends very much on how we communicate the decision, and what support and follow-through we apply.
So, if we kowtow to the push-back against architecture documentation in the agilist camp, and our own disinclination to write down architecture decisions and thinking that went into them, then we are sending the message that the "architecture" is not a set of decisions but just a fluid initial starting point that we expect everyone to remold and reshape actively and without constraint—or restraint.
Now, in some situations this may be just fine. If we are working on a novel system, without precedent in our experience and in the collective experience of our industry (so we can't hire in the experience we need), then it would be foolhardy to create an architecture specification early on and expect to live by it through the life of the system. But while we are always pushing boundaries beyond what we already know, we are generally also working with a good deal of experience to leverage. To the extent that we can create an architecture that we can validate and build confidence that it will serve us through the first release, and prepare us well for subsequent releases, we should do due diligence when it comes to documenting this architecture.
But what is architecture documentation? In good part, the architecture documentation consists of the very models we use to think through and make the architecture decisions. In short, much of the work is already done, assuming that we use models to visualize and evaluate architectural approaches. The diligence part has to do with:
Architecture documentation explains and justifies the decisions that embody the architecture. So we need to articulate the reasoning, tracing the decisions back to the requirements that drove them, keeping track of alternatives we weighed but ruled out and why (so we don't have to make the same arguments again and again), and writing down assumptions we made (so if these assumptions are invalidated, we know we have to revisit the decision).
When we do this, we also help educate the engineering community, sharing the experiences that shaped our decisions. When we document our reasoning like this, we make our knowledge explicit and shareable. Further, it makes us more careful, because we leave a record that can be assessed and debated.
One of the things we have to do as architects is figure out where to push back against the status quo, to lead out of the rut we are in to a better way of doing things; a better way that enhances our community's quality of life. And we have to figure out which battles just aren't worth it, because it takes energy and passion to lead these changes, and some changes are more important than others.
For the things that we see rising above this cut-line, we need to do what it takes to be effective. We must not allow ourselves to be lulled by the cries of "it's all going to change anyway" to escape the effort it takes to write good documentation for architecturally-significant decisions.
The architecture decisions must be recorded, so we have a ready reference that doesn't depend on us being always in the room, ready to explain and defend each decision. The decisions must be communicated and understood. It is worth it, if the architecture decisions are worth it. So the decisions must be strategic and minimalist, and relevant. As soon as they are not, we must be on hand to adapt the architecture decision set.
Once written down, to be sure not everyone who should read the various architecture documents, will read them. But those that do will have a much better understanding of the architecture, and the rationale for the decisions it encompasses. Good models and well-written explanations get right into the head of the reader in a personal and effective way. The reader can engage, backtrack, hold an internal dialog with the material until it is well understood, or at least clear where the questions are. Each reader will be better positioned to explain to their peers and reports what the architecture means, in the narrow direct sense and in the broader sense of its intent. This very effectively expands your capacity to champion and explain architecture decisions and catch misunderstandings and misapplication (and even downright subversion in errant cases) of the architecture.
All this presumes that you and your team can come up with an architecture. It does not presume that you make every architectural decision in advance of all coding. Not at all! But when you have a complex organizational setting (large number of developers, distributed teams, etc.), then you need to do more of the architecture work upfront, and document AS YOU GO, not afterwards! There never is an "afterwards" and even if there was, you'll have forgotten much of the rationale, if not many of the important decisions. Besides, though we need architecture documentation to help us with system evolution, we need architecture to create a system that addresses our architecturally significant requirements in the first place. Early on, figure out what the architecturally significant uncertainties and risks are, and figure out what you must do to resolve these risks. Leaving them until "you must deal with them" is risky business.
The bottom line: No architecture documentation --> no architecture; no architecture and we rely on organic people-intensive communication processes that don't scale too well. No architecture + big project --> project wipe-out.
6/28/11: See also the discussion following the image in More Making It Visual.
Other Perspectives on Architecture Documentation
For Architecture Documentation:
On-the-fence about Architecture Documentation:
Creating Architecture Documentation:
See also Software Architecture Books
7/18/06 Models versus Code
Several engineers and even junior architects have told me that they "think in code" and have a hard time thinking about software in any other medium. I recognize that some people are more visual, others are more inclined to the written word, and others are more inclined to "building things" including (pieces of) software. Some people just aren't happy "visualizing" and modeling; they can do great, innovative things with code, but feel mired when it comes to trying to express and think in terms of abstractions, especially visual abstractions. To some extent, this is because we just haven't done a good job of making design and modeling a part of what we do in software engineering, so it is novel and hence uncomfortable. And to some extent it is innate predilection. This means that if our predilection is to code, we should be careful not to undervalue the contribution of those who are good at envisaging and expressing system designs.
We have to recognize that we can't communicate to others what to build by writing the code for them! We have to communicate using abstractions that are clear enough in expressing the behaviors and qualities the abstraction must deliver, so that other team members can deliver components and mechanisms that together satisfy the promised services and service levels. So we need architects who are good at modeling and visualizing, communicating and documenting. And we need engineers who understand enough about the models and visualizations to deliver on the commitments they capture.
That said, we can provide code examples, and we can also provide code that makes it easier to deliver systems that follow the architectural decisions:
"For example, we have made a lot of decisions about how we'll do things in our new architecture at Artima, and we recently captured many of those decisions in some code generators. So instead of just decreeing that entities can be versionable, and that versionable entities will have deletion and history tables that follow certain conventions, we made it so easy to do things that way, that no one will ever be tempted to do it any other way. All you need to do is add the word "versionable" in front of "entity" in the DSL we created for defining entities. The generated code will always follow the conventions exactly."
from Software Architecture is Leadership, by Bill Venners
Many product family and domain architects (lead teams that) build "platforms" or "frameworks" where key pieces of the architecture are taken all the way to implementation by the (extended) architecture team. These common services, skeletal components, etc., help provide architectural integrity, consistency and leverage across the products in the family or business domain.
7/18/06 Piecemeal Growth
"Large-lump development is based on the idea of replacement. Piecemeal Growth is based on the idea of repair. … Large-lump development is based on the fallacy that it is possible to build perfect buildings. Piecemeal growth is based on the healthier and more realistic view that mistakes are inevitable. … Unless money is available for repairing these mistakes, every building, once built, is condemned to be, to some extent unworkable. … Piecemeal growth is based on the assumption that adaptation between buildings and their users is necessarily a slow and continuous business which cannot, under any circumstances, be achieved in a single leap."
The idea of piecemeal growth has been taken up enthusiastically in the software community, notably by Richard Gabriel in his Patterns of Software book, and by proponents of agile and other iterative/incremental software methodologies.
While traveling last week I thought I'd leave all work behind, and was reading The Joy Luck Club by Amy Tan. Well, my work finds me no matter where I hide, and this paragraph sprang out at me:
"The house had been in the family for many generations. It was not really so old or remarkable, but I could see it had grown up along with the family. There were four stories, one for each generation: great-grandparents, grandparents, parents, and children. The house had a confused look. It had been hastily built and then rooms and floors and wings and decorations had been added on in every which manner, reflecting too many opinions."
from The Joy Luck Club by Amy Tan p. 48.
Amy Tan describes what we get, if we follow the piecemeal growth approach without attention to architectural integrity. Don't get me wrong—we heartily encourage iterative/incremental development, including iterative maturation and refinement of the architecture. But we also heartily endorse the role of the architect in creating and maintaining system integrity, and creating the overall design and guidelines for growing the system.
Interestingly, the top quote on the back cover of Amy Tan's Joy Luck Club says:
"Powerful...full of magic...you won't be doing anything of importance until you have finished this novel." Los Angeles Times Book Review
Should I take these words to mean that reading this novel is not important? That sort of reminds me of the Nova Awards (see page 56 for a good chuckle)!
7/18/06 Do More than Eat Your Own Dog Food
7/19/06 Enterprise Architecture: EA = BA+EWITA or EA=TA?
In Light Enterprise Architecture, John Chi-Zong Wu argues that to keep EA light, EA should focus on infrastructure, providing a counterpoint to the notion that EA = ”architecture of the enterprise.” (Thanks to Kevin's Architect's Linksblog for pointing to this article.)
We believe that EA can be lightweight/minimalist even when EA = EA not EA = ETA (enterprise-wide technology architecture); it is a matter of strategic focus. If TA is the top priority because strategy execution is hampered until the enterprise infrastructure is sorted out, then well and good. For those enterprises where the computing environment is well enough in hand (given the minimalist principle of pushing all decisions that don't have to be made centrally to those closest to the problem/customer/information/etc.), the enterprise architects can focus on capabilities that enable the organization to execute its business strategy. The EA is kept as light as it should strategically be, by only addressing capabilities in the EA team that require enterprise-scope leadership, visibility and authority.
For more, see:
7/24/06 Allan Hoffman (Monster.com) on the Software Architect Career
Allan Hoffman's article on the software architect career is out. Allan did good investigative work, getting input from various sources, and the article is nicely written and well-rounded. You can see it at Career Spotlight: Software Architect (http://technology.monster.com/articles/softwarearchitect/). This will be a useful article to give to managers looking at formalizing the role of the architect, as well as developers who are thinking about the architect career.
7/24/06 The Long Tail and the Cottage Revolution
7/24/06 How to Give Feedback
Given our role in reviews of all kinds (from business plans and marketing strategy to designs and code), Seth Godin's July 22 blog post titled How to Give Feedback is a must-read for architects! I really like the point about giving your analysis. This helps steer away from emotionally charged feedback, by keeping the focus on the analysis that leads to different conclusions. This reinforces the points I made about architecture documentation needing to include the reasoning (I could have said analysis; maybe I should have said analysis) along with the decisions.
7/25/06 Architecture Portal
In The Past, Present and Future of Software Architecture, Philippe Kruchten, Henk Obbink and Judith Stafford mention the Resources for Architects web site, saying:
"The Bredemeyer architecture portal (www.bredemeyer.com), called 'Software Architecture, Architects and Architecting,' is maintained by Dana Bredemeyer and Ruth Malan. It contains not only their own writings but also a well-organized collection of other resources and announcements."
IEEE Software, June 2006
I like the "portal" reference, and I am grateful for the mention. But... Of course, articles like these "write history" with a heavy bias towards traditional print publications like books and Journals, yet publication via the Internet is at least as, if not more, influential among practicing architects.
Quietly, without fanfare, we've been going about sharing what we have learned about architecture, architecting, and architects freely, via the Internet. In large part, we're sharing what you have learned and shared with us, though of course these lessons are gathered across dozens of architecture projects and experiences. Still, I think we're like honey bees, cross-pollinating—identifying architecture best practices and sharing them. The whole field gains. We get to make a living doing what we're passionate about, while you get to make grand, innovative contributions to your business, your industry, mankind, mostly because you are a great architect, but also in small part because we bring some good practices to your attention. And in turn, we learn from your successes, and from your trials, and we help make these lessons explicit so you repeat what works well, and so that others will learn from your adaptations and ground-breaking architectural practices. The cycle of life; in consulting terms!
The point is that the emergence of the software architecture field has largely been shaped by architecture practitioners, and that is not adequately reflected in an article that emphasizes print publications and academically-oriented conferences as a way to track the history of the field.
In 1987, Dana Bredemeyer was, for the first time, given the title of architect, and he worked in a section called Architecture and Design, and it was part of the Operating Systems Lab at Hewlett-Packard. So you see, there is a time-lag between what is being practiced, and what starts to show up in the published literature. I was never called an architect in that timeframe—I was at grad school (Virginia Tech, then Stanford). In the mid 80's, though, I was what was then called a chief programmer.
That said, it is a good article, and it will be how the history of the field is seen by many, especially as we get further from its genesis. For me, the absolute biggest contribution that the article makes, is bringing Ian Sharp's comments from a 1969 NATO conference to my attention. I think I'll be reading that piece at the start of my Software Architecture Workshops! Here we are blogging about what architecture is and why we need it, and Ian Sharp said it all eloquently in 1969! (See the inset on p. 24, The Past, Present and Future of Software Architecture, by Philippe Kruchten, Henk Obbink and Judith Stafford, IEEE Software, June 2006.)
7/27/06 Avoiding Seagull-style Feedback
Nick Malik has a great post titled Don't walk in with a problem until you have a solution (July 1, 2006), which you just have to read. "Have to"? Well, there is that seagull reference, and it is a good post.
7/28/06 Grady Booch Healing
Phew! I've concernedly checked on Grady Booch's blog from time to time, and at last he has an update: he's slowing getting back the energy to work and blog. He's been through quite an ordeal of the body and spirit, but he is strong and he knows his work and his presence is highly valued, and he will pull through.
Goodness, he's talking about traveling in September! What are those IBM'ers thinking?! They have to make the Handbook a priority. It is good for IBM's branding to provide leadership in this space. I like the work Microsoft is doing to elevate the architecture discipline, but it is important to have other leadership in this field. Get the priorities straight: all the signs sayeth NO TRAVELING. :-)
2006 by Ruth Malan
I also write at:
- Bredemeyer Resources for Architects
- Grady Boochl Archives