The software architect job description
There are a huge variety of job descriptions for software architecture: some define this as a souped-up developer lead role, some specify a technical platform for base skills (and avoid business involvement entirely for this role), some JDs are simply a list of academic acronyms and certifications almost never used together in practice. This article attempts to simplify what a software architect really does — or aspires to — on a daily basis.
The software architect evaluates and designs software solutions, leading the technical software development effort. The job description includes 2 primary groups of skills: one broad and facing externally to define the value and proper form of the solution, and one deep and internal to coordinate and execute parts of the development effort.
Software architects may focus — at different points in the project lifecycle — more heavily on one of these groupings; professional architects can manage both skill sets equally well and flex between them. It is my belief that a software architect needs to be competent at each “side” and that this competence grows through experience. A successful architect cannot be code-free nor can she or he be oblivious of the business value being delivered.
For instance, if you were to hire a home remodeler who did not know how long a 2”x4” should be to match up floor to ceiling, or how frequently plugs should be spaced for electrical needs, would you hire them? (You’re not hiring them to cut the studs but they have to explain the design at least to someone who will implement the design) Similarly, when starting a project, your finance group asks how much it might cost, the answer being “I need a blank check, just trust me” would not satisfy them so much. (You are hiring someone to be a good steward of resources).
Architects may have additional skills such as developing an enhanced engagement model (consultative skills), business domain or competitive software productization understanding, deep experience in parts of the lifecycle, or experience with specific technology combinations or application styles. Software architects typically come from either a technical business role or a core IT role such as infrastructure engineering or software development.
The core job functions of a software architect:
Business value-oriented functions
Work with team stakeholders/sponsors and the product owner to identify value streams and quantitative measurements for the project success
Work with team sponsors to develop the initial context/environment and system views for the project
Create a series of views for feature sets (or modifications to feature sets) following the initial design, defining platform components and optionally selecting subcomponents
Work to resolve issues and blockers to “shipping” the software product which includes collaborating across the lifecycle with other team members
Technical leadership functions
Develop and manage an architecture runway representing prioritized and sequenced tasks (guidance, mockups, prototypes, development stories, etc.) to embed quality attributes on the project
Develop and triage portions of the codebase on the target platform (does not have to be the lead developer on any portion of the system, however)
Manage the design handoffs through structured documentation for the implementation team and continue to consult on specific changes; verify work completion and participate as a mentor for less experienced staff.
Socializing the technical roadmap and setting the stage for team evaluation of changes throughout the lifecycle
Many of these core job functions are measurable while some are very hard to quantify (and in fact the impact of a single architectural decision may not be realized until years later). Some of these overlap with related roles; for example, resolving issues in one part of the project may be within the product manager role and in the code area specifically with the architect.
In my courses, I usually talk about attributes that architects have — the way (or dao, pun intended if you know me) of their practice: there is a lot of commonality among experienced practitioners.
· Architects understand domain value as a participant in the business
· Architects work in pictures (which can be structured guidance or documentation like ERD, UML, agile stories or specifications)
· Architects continuously learn new technologies, design patterns and business innovation
· Architects adapt patterns from their own and others’ experience (simplify, reduce effort, speed to value)
· Architects translate terminology and are concise with words; the corollary here is that architects like driving ambiguous scenarios to specifics
· Architects communicate broadly & specifically at the correct level for a varied audience
· Architects don’t break the rules (or laws — just had to say this after seeing it a few times)
· Architects are team members, first and foremost, and respect diversity
Software architects work with a broad set of roles throughout a project: from the sponsor & key users (stakeholders) to the project manager or product owner, to functional business leads (domain, finance, security, procurement, etc.), to development, DevOps, operations/SRE, & infrastructure staff, to external suppliers, to external customers and other architects. Human dynamics skills are key to assess for this role.
To hire a software architect, I would recommend assessing their experience with projects similar to the one being undertaken and in the organization’s future portfolio. This can be effectively done through case studies and unfortunately the standard 45-minute phone call with standard question & answer is usually not enough to gauge how an individual may fit culturally or in their decision-making style.
Having been an architect at Microsoft and now in my own practice, I would say that some organizations seem to grow architect skills well but it is by no means a guarantee; some of my favorite architects are from little known organizations, have not worked on “nameplate” systems like Netflix, or do not blog at all. You’ll have to check some references. There are also some certifications that lend credibility to the architect’s background.
Hiring an experienced software architect — when you’re betting the business on a new app or a move to the cloud — is a large investment and has some risk. I’ll talk later about how case studies can serve this need and how the organization and candidate architect might reduce the shared risk of a mismatch by using architecture-as-a-service (contingent and incremental staffing).
Cheers!