software architect

What a Software Architect is NOT

In another post, I defined the role of a software architect. This post points out some duties that are not necessarily part of his or her job, for clarity.

foreman

A foreman–vital but usually not the same person as the architect. Photo credit: USFS Region 5 (Flickr).

* An architect is not necessarily a lead engineer. Lead engineers translate architectural guidelines and vision into implementation, not just in the design phase, but all the way through RTM. Lead engineers work for dev managers and are accountable directly to them. Lead engineers might have a technical director pay grade, but whether they are asked to function as architects is a separate question. When lead engineers push back, it’s usually about whether an implementation works or is reasonable, not about whether a vision is the right one. Lead engineers may “own” a particular facet of the technology portfolio through multiple release cycles, and this cross-release perspective is architect-like. However, lead engineers are far less likely to radically question the value of what they own than an architect, because an architect is looking at a bigger picture over a longer horizon. When Bill Gates told every MS employee to drop what they were doing and spend a month thinking about the Internet because the company wasn’t “getting it,” he was being an architect. The lead engineers on all the projects and components that ultimately got ditched so MS could go chase the web wave would never have done that.

* An architect is not a dev manager or dev director. Dev management coordinates the work of a team that delivers product to spec. Dev management scopes work and speaks with authority on whether something is doable with what schedule and what resources. Dev management is extremely focused on release cycles. If we were constructing buildings, dev managers would be foremen — reading blueprints, hiring and monitoring subcontractors, cutting checks, giving status reports. A dev director or Sr. Dev Director would be the general contractor. But neither the general contractor nor the foremen would decide to put an elevator shaft in a different spot without talking to the architect who calculated the load-bearing capacity of the walls. Like lead engineers, dev management should understand technical guidelines provided by an architect, and should be accountable to work within them, pushing back to the architect as necessary. This is parallel and analogous to the push-back that dev management provides to PM when the schedule is threatened.

* An architect is not a product manager. A product manager proxies customers and builds business plans for releases of products. A product manager says with authority, “This is what the market wants, and we can make X selling it.” These business plans should represent our best understanding of revenue-maximizing choices. But without an architect to provide feedback, these plans typically have a one-release horizon — whatever maximizes revenue in the next release is assumed to be best. Or else we have a long-term business perspective, but implementers receive little guidance about technical tradeoffs that are aligned with an appropriate evolutionary path; the technology becomes a patchwork quilt of kludges and dead-ends that is progressively more expensive to enhance and less useful as a competitive weapon.

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.