What is a "Software Architect?"

2008-09-10

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... — 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:

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.
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.
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.
Do forward-looking research and proof-of-concept work to drive risk out of potential directions on the technical roadmap.
Identify/sponsor/promote/create high-value innovation. (“High-value” is evaluated against vision…)
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 aitect 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.

Comments

What a Software Architect is NOT « Software, Wetware, Webware, 2012-06-26:

[...] another post, I defined the role of a software architect. This post points out some duties that are not [...]