This post contains materials presented at the Geekle Worldwide Software Architecture Summit, Volume II (August 2021).
TL,DR: There’s not a lot of definitions out there regarding the solution architects roles and responsibilities – especially at a practical task / artefact / scenario level. So, based on my practical experience I’ve put together the following diagram / spreadsheet combo:
And if you need it, here’s the deck I presented which will provide some background:
For those of you feeling like a more in-depth explanation, read on…
Problem Space
Knowing exactly what you’re supposed to do as a solution architect is mostly down to figuring it out on the job, learning from others, and what you negotiate it to be. It’s also hampered by inconsistencies that stem from four causes:
- Variation in organizational size & maturity.
- Variations in methodologies used.
- Variable understanding of the solution architect role definition.
- Organizational politics & human nature.
#1 deserves special mention, so let’s get 2, 3 & 4 out of the way:
- Methodologies are often associated with (or dictate) various roles and responsibilities, so the methodology in use will often impact how architects do what they do, and even what they do.
- The solution architect role definition tends to vary across cultural-geographical spheres and organizations (e.g. government vs private; where software / IT systems are the core business – or not, and so on).
- Politics, e.g. where managers set-up fiefdoms that can sometimes impact who does what, within what scope, how they do it, and so on.
Whilst those three drivers are not uncommon, I’d argue the most consistent drivers are variations in organizational size and maturity. Size drives role focus – how specialized your role might be, whilst maturity drives role clarity – how well / consistently its understood.
Larger organizations tend to bring greater role specialization:
= Less need for you to “wear many hats”.
= More focused responsibility.
The more mature an organisation is:
= The more well developed it’s processes are likely to be.
= The more clearly defined your role is likely to be.
= Greater clarity on roles and responsibilities.
All of these factors will influence exactly what your role and responsibilities are, in a given engagement.
Current Art
Apart from specialist entities such as IASA Global, there’s not a lot of existing stuff out there that describes what a solution architect does, in terms of specific roles and responsibilities – especially if you want to get down to the task / artefact / scenario level.
First off, TOGAF, the popular enterprise architecture framework is… well… enterprise focused, not solution focused:
The Solution Architect has the responsibility for architectural design and documentation at a system or subsystem level, such as management or security. A Solution Architect may shield the Enterprise/Segment Architect from the unnecessary details of the systems, products, and/or technologies.
https://pubs.opengroup.org/architecture/togaf91-doc/arch/chap52.html
And that’s about as specific as it gets – apart from the TOGAF Architecture Skills Framework, which is generally good but it’s not very low-level and more focused on roles central to enterprise architecture.
SAFe goes further and looks like it has some good practical level of detail in terms of roles and responsibilities, based on its concept of “Solution Architect/Engineering“. I haven’t gone through SAFe training so can’t say what all the details are, but as you can see from the linked page, there’s a good level of practical detail.
The only caveat is that the guidance is SAFe specific; applying it outside the context of SAFe is definitely possible but will require your interpretation and adaptation.
My Model
The basis for my RACI model starts with the SDLC (Software / System Development Life Cycle), on the basis that:
- Solution architects typically operate within the context of a project…
- which usually delivers one or more systems / major system changes…
- those changes typically follow an SDLC…
- Therefore: SDLC drives a lot of what a solution architect does.
The gold elements in the diagram represent major concepts under which we can group specific tasks, artefacts and scenarios, for which we can define specific roles and responsibilities. The thread of gold elements in the lower half are directly related to the broad notion of SDLC (see slide 6 in the presentation deck):
- Initial planning & analysis.
- Development of the system / solution architecture.
- Detailed design including API specifications.
- Build, and the closely related areas of delivery methods and engineering.
- All necessary testing including system integration, performance and security.
- Release & deployment including data migration and roll-out planning.
- BAU operations – the system / solution in it’s operational form.
- System change – which may trigger new iterations of the SDLC.
- Decommissioning when the system is replaced, which may happen as part of the implementation of its replacement.
Supporting those, at the top of the diagram, are a few major concepts outside the SDLC:
- Current & Planned Constraints such as existing technologies, emerging systems and technology strategies.
- The Architecture Practice you may be working within.
- The Project / Product Construct you are primarily engaged with.
PaRCINo Matrix
Supporting the diagram is a matrix that describes every element on it, and the typical level of involvement you’re likely to have with it as the solution architect.
You’ll notice the matrix uses a type of RACI to define the solution architects level of involvement, but that it’s “PaRCINo” rather than “RACI”.
Pa – Participate – where you participate in completing the work.
R – Responsible – where you take the lead in completing the work.
C – Consulted – where your opinion is sought.
I – Informed – where you are kept informed of progress or anything of significance.
No – No involvement.
It’s worth taking a closer look at consult vs participate, especially in the context of solution architect, which is a senior leadership position within the construct of a project:
Consult implies you might have a degree of authority in relation to the subject, potentially including the ability to approve or endorse, or to at least lend significant sway to the subject.
Participate is similar to consult in that you might have a degree of authority, however, the practical application of that authority is (or should ideally be) through collaboration and driving consensus.
The challenge you face is that whilst you have responsibilities to your project team and business client, you also have responsibilities to your parent architecture team / chief architect / organizations enterprise architecture, and those two broad sets of stakeholders won’t always align. Where there is misalignment you will have to decide how to navigate them, and this may mean you have to assert your position more strongly than as a member of an egalitarian team.
Example: Domain Architecture & Breaking New Ground
The deck covers five examples from the model, which help to illustrate the roles & responsibilities of the solution architect, and how that can vary depending on circumstances. Let’s take one of those now.
This example actually covers two related concepts:
- Domain Architecture – organisation-wide architecture for a specific domain, such as data, security, infrastructure and so on.
- Breaking New Ground – scenarios where the development of a solution architecture requires the organisation to make major changes or additions. These initiatives may be outside the delivery scope of the project but still a dependency for it.
The connection between these is that projects delivering non-trivial systems, or major system changes, will often discover gaps in the organizations wider architecture / technical landscape. These gaps can be significant enough to block the project, and frequently impact one domain more so than others.
The precise role and responsibility of the solution architect in such cases depends on factors such as those previously mentioned (organizational size and maturity, and so on). What is clear is that such a blocker needs to be mitigated (such as by filling the gap or avoiding it), and that you are in a lead position of responsibility to navigate that.
What I find in practice, is that domain architects will usually want to work closely with you, because they will see your project as a means to deliver part of their domain architecture (because your project has budget and people / delivery resources). This gives you a degree of leverage. Some will also want your opinion.
- Where the gap in question is a big one, and the organisation already has well developed plans to address it, your involvement might be somewhere in the inform – consult range.
- If your project helped “uncover” the gap, or simply because you’re the first project to be in a position to actually do something about it, your involvement will at least be consult and is more likely to be participate. A good domain architect will look to you as someone to help share the load, and develop thinking around the practical delivery and operational details.
- Where no formal domain architecture (or architects) exist, you might find yourself responsible, given that the gap still exists to imperil the project.
Peruse Muse Infuse 