Month: September 2008

What is a “Software Architect?”

When people ask me what I do for a living, I usually say I’m a computer guy and leave it there. But if they want more detail, I tell them I’m a software architect. When I give that answer, I often wonder if I sound pretentious, like those who say “sanitation engineer” instead of “garbage man.” Do those who ask the question think a “software architect” is just a fancy way of saying “computer programmer?”

Well, although I am a programmer of sorts, what I do is different enough from standard computer programming to require a different name.

An architect is responsible for the strategic health of a technology portfolio. “Health” embraces many different considerations, such as how maintainable the code is, how easily it can adapt to changing business requirements, how technically differentiated it is from the can-do assets of competitors, whether the portfolio makes appropriate use of (and embodies/generates) trade secrets and patents, how performant and scalable it is and whether those characteristics are a good match for the “sweet spot” customers, obsolescence, and so forth.

The overall goal of the architecture function is to maximize dev ROI and technical competitive advantage over the long run.

An architect lays out a vision. Photo Credit: mootown (flickr.com).

By its very nature, architecture is broad in scope and overlaps with many other disciplines. Because it concerns itself with fragility, boundary conditions, and theoretical limits, it needs to interact with design and actual code, and architects must be proficient engineers. Because it cares about supporting potential uses beyond the confines of a specific release, architecture must consider the market landscape from both a business and a technological perspective, and it must understand when short-term compromises carry long-term risks.

The duties of a software architect include:

1. Meet with Product Management and executives to understand their business/market vision. Use this understanding to inform a perspective on the relative value of various technical tradeoffs.

2. Be a keeper of a technical vision/roadmap that supports the business/market vision optimally. Give feedback, based on that vision, about the technical tradeoffs implied by various potential business plans before those plans are codified into a plan of record, or before they are accepted as a change request.

3. Articulate to engineering the technical guidelines that should inform a new release, including the considerations behind various tradeoffs — and get formal buyoff from both engineering and PM on those guidelines. Participate in design reviews to guarantee that appropriate tradeoffs are honored and embodied correctly.

4. Do forward-looking research and proof-of-concept work to drive risk out of potential directions on the technical roadmap.

5. Identify/sponsor/promote/create high-value innovation. (“High-value” is evaluated against vision…)

6. HR-related stuff: Provide leadership and mentoring to other engineers. Evangelize the technology portfolio to other stakeholders (internal and external). Vett IP for patents and M&A. Be a voice. Etc.

Of these duties, items 1, 2, and 3 sometimes get lost or watered down if an architect is just a senior engineer. In that sort of environment, PM may convey a vision to dev without involving architects. As a result, the team has conversations about feasibility or cost of implementing, but rarely if ever about whether a requirement is a good idea in the first place. Whether a requirement is a good idea is more than just a question of whether customers want it, whether it can generate revenue, and whether it can be built — it also must take into account things like technical opportunity cost, long-term baggage, effect on the expertise and focus of the engineers who will build it, technical differentiation, and so forth.

It also might be worth highlighting some things that I *don’t* consider part of an architect’s job, for the sake of clarity. I’ll do that in a separate post.

Annotating the Web

Bookmarks just remember a location. That’s kind of nifty, but even with all the power of del.icio.us or a similar service, it’s not something that keeps me awake at night with enthusiasm.

Why don’t we move beyond simple bookmarks? Let’s let people remember what they were thinking when they read a particular piece of content. Let’s figure out a way to annotate web pages so that if you come back to that same page, your annotations show up again.

Annotations could take the form of text (with all the hypertext and multimedia features of html itself), ink (to scribble or draw on top of a page, circle key elements, etc.), audio… Annotations could be a layer on top of a web page — something you could toggle on or off. You could even share your annotations with someone else so they could turn on your layer or compare yours to theirs.

Imagine this in an educational setting. An instructor wants you to read an essay about existentialism in Waiting for Godot. The instructor takes a few minutes to highlight the parts of the essay that she finds particularly interesting — underlining a couple sentences, jotting a note about a section that’s out of sync with her own research, etc. When you read the essay, you can turn on the instructor’s criticism of the essay and add your own. Maybe other classmates can share their ideas with you as well.

To make this maximally powerful, you’d want to be able to anchor your comments to particular slices of content on the page. Over time, if the content of the page or the rendering of the page changed, you’d want your annotations to adapt. Example: you disagree with an author who claims that “peptide bonds are a boring subject that any first-year biology student can afford to sleep through.” You highlight that sentence on the page, bring up a context menu with a right-click or control-click, and on the menu one of the options is “annotate.” You create your annotation much the same way you’d create a bookmark. (You could also anchor annotations to graphics or other elements on the page pretty easily.)

You visit the same page 3 weeks later. The .css behind the page is different now, and the content has been extended (e.g., it’s a blog and a dozen people have commented). And you’re using a different browser, on a different OS, possibly in high contrast / large font mode where you were in normal mode before. The point is, visually the page looks completely different. But the annotation engine searches for the anchor text for your annotation, finds it, and basically offers a tooltip to pop your annotation at the correct location on the page.

(By the way, the annotation mechanism I’m describing here might be a more interesting way to accumulate blog comments than the current way which is email thread-like. Instead of reproducing the salient portion of an earlier thread contributor’s text in your own, and then adding your words after, just anchor your annotation to the relevant portion of existing content…)

Lastly, imagine what we could do if we allowed a user to enumerate all their annotations. Annotations could be organized by key word of the page they apply to (and, to make them even more findable, by key word in their anchor text). A simple query to the annotation back end server would give you a sort of personal knowlege base on any subject.

Update: I went out and did a little research and found that some of the features I’m dreaming of already exist. If you’re interested, check out this article on wikipedia.