The SA & SE skills matrix

Last reviewed: 2026-06-29 — see the freshness policy.

Learning objectives

After this chapter you will be able to:

• Distinguish the Solution Architect (SA) and Solution Engineer (SE) roles in HLS.
• Use a competency matrix to assess where you are and what to grow next.
• Apply a leveling rubric (Associate → Principal) to the HLS-specific skill set.

SA vs SE — two roles, one spectrum

"Solution Architect" and "Solution Engineer" overlap and are titled inconsistently across companies, but the centre of gravity differs:

• Solution Architect (SA) — owns the design. Translates a business problem into a defensible architecture, makes the hard-to-reverse decisions, and is accountable for it being buildable, compliant, operable, and affordable. Lives at the C4 Context/Container altitude and in ADRs.
• Solution Engineer (SE) — makes it real and makes it land. Often a pre-sales/customer-facing technical role (demos, proofs-of-concept, scoping) and/or a hands-on integration/implementation engineer. Closer to the keyboard, the customer, and the constraints.

flowchart LR
  Biz["Business problem"] --> SA["SA — design & decide"]
  SA --> SE["SE — demo, build, integrate"]
  SE --> Live["Working solution"]
  Live -. feedback .-> SA

In practice it is a spectrum: pre-sales SAs craft and sell the technical vision; post-sales SAs deliver inside legacy constraints; and full-cycle roles (common in smaller HLS firms) own the whole journey. Most people slide along this line over a career — the matrix below is the map.

Competency domains (HLS-tuned)

The bootcamp's three strands — SA craft, HLS domain, platforms — expand into seven assessable domains. The emphasis differs by role (●●● = core, ●● = strong, ● = working knowledge):

The split to remember: SAs go deeper on design, compliance, and stakeholder communication; SEs go deeper on hands-on build, demos, and customer-facing problem-solving. Both need strong interoperability and platform skills — those are the non-negotiable HLS core.

Leveling rubric

Each domain also has a depth level. A pragmatic four-rung scale:

The bootcamp is built to move you from Associate toward Senior: the chapters build judgment, the labs build hands-on depth, and the capstone is a Senior-level exercise (own and defend a whole HLS design).

The HLS-specific must-haves

Whatever your title or level, these separate an HLS architect/engineer from a generic one:

• Compliance as a design input, not an afterthought (HIPAA/GxP).
• Fluency in clinical data — you can read an HL7v2 message and a FHIR profile.
• PHI instincts — you reason about the BAA surface, de-identification, and data residency by reflex.
• Stakeholder range — you can talk to a clinician, a CISO, and a CFO (stakeholders).

External validation: certifications

The bootcamp builds judgment; certifications are how you signal it externally. None are required, but they map cleanly onto the matrix above:

Treat certifications as a checkpoint, not the goal — the capstone tests the same judgment a certification exam can only sample.

How to use this matrix

1. Self-assess each domain (level × current depth) — honestly.
2. Pick your role vector (SA-leaning, SE-leaning, or full-cycle) and the domains it weights.
3. Target the gaps with the matching chapter + lab.
4. Re-assess after the capstone. Standard architecture-competency frameworks (e.g. the TOGAF Architecture Skills Framework) can supplement this for formal HR leveling.

Check yourself

1. What is the core difference in accountability between an SA and an SE?
2. Which two competency domains are non-negotiable core for both roles in HLS, and why?
3. At which level should you be able to engage compliance and clinical stakeholders unaided?

Further reading

• TOGAF Architecture Skills Framework
• The SA operating model · Bootcamp format