Roles & Responsibilities of the Solution Architect

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:

  1. Variation in organizational size & maturity.
  2. Variations in methodologies used.
  3. Variable understanding of the solution architect role definition.
  4. 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.

Your first project – where to start?

Here you’ll find my deck and the materials mentioned in my “Your first project – where to start?” presentation at the Geekle solution architecture summit, 2021.

This presentation looks at what to do on your first engagement as a solution architect.

Here’s the deck:

And here’s the underlying content: diagram and notes (see the PDF):

Solution Architecture Engagement Flowchart

This work is licensed by Adrian Kearns under a Creative Commons Attribution-NonCommercial 4.0 International License.
https://creativecommons.org/licenses/by-nc/4.0/
https://www.linkedin.com/in/adriankearns/

Old World, New World: From Projects to Products, and More.

There’s a major new ethos emerging that is going to disrupt a lot of organisations (and careers), with regards to the delivery of systems and services: moving from being project centric to product centric.

Just to be clear, “Product” in this context refers to the processes and disciplines related to the development and delivery of products – not the purchasing or acquisition of existing products from someone else.

The purpose of this post is simply to get some basics information out to you, so that you can start to do your own research and thinking (mainly because I’m also going through that process myself) about what being product centric means.  On a related note, I’m going to write a Solution Architecture Handbook based on my experience, because there’s a real lack of good information out there about that; in preparing for that I’m increasingly seeing a major transition between two worlds – of which the project/product centricity is one aspect.

Old World / New World: Some Definitions

Let’s start with the “what”, as that will provide a point of reference. Here’s my current view of things that often typify the old and new worlds – I’d love to hear your thoughts on this:

Old World New World
Projects Products
  • Project teams and Support Teams (Throwing things over the fence)
  • IT and Business
Holistic Product Teams
Waterfall, Agile (Underground) Agile (Mainstream), Continuous Delivery, DevOps
Big Upfront Design / Architecture Emerging Architecture
Emergence of Digital, Digital Projects Digital as a natural blended element
Software and Infrastructure Infrastructure as Code

Obviously some big labels there – massive over simplification – and the intent is not to define any false dichotomies as things aren’t always so binary; additionally, I’m not trying to suggest that these are collectively mutually exclusive, for example, being project-based doesn’t preclude you from doing continuous delivery.

Some other factors to consider are the increasing maturity and pervasiveness of:

  1. Automation, specifically regarding development and deployment pipelines.
  2. Cloud-based platforms and offerings.
  3. Open source.

Unknown to me until very recently, Joshua J. Arnold arrived at a similar place (back in 2016 – the last point in the table below is credited to Maria Alfredeen – details in the linked content), although my understanding is that he’s orientated along product-thinking lines:

Plan Forecast
Resources Teams
Push Pull
Requirements Experiments
Projects Initiatives
Dates Cost of Delay
Big risky releases Continuous Delivery

So What?

Firstly, the emergence of “Product” as an ethos for delivery (and more) feels to me a lot like how the emergence of Agile felt back in the day (circa 2000-2005).  Something that significant is definitely something you want to be aware of – not just in terms of how you or your organisation may want to work, but also in terms of skills and experience you may want to acquire.

As I learn more about product-based thinking, I find that knowledge tends to fit well with my knowledge of Agile – they are compatible.  Then, as I work with various teams and organisations, I’m increasingly seeing situations where product oriented thinking appears to be desirable, feasible and viable.  For organisations already working somewhat successfully with Agile but in a project context I think the introduction of product thinking may help them further evolve.  For organisations not even at that stage it might be that product thinking helps them evolve faster or by a more direct route, even if the first step is to break down the IT / Business divide; or, it paints a bigger and more strategic picture for them rather than simply a transformation that is delivery focused.

What Do You Think? / Further Reading

Do you agree with my broad definitions of what often typifies the old and new worlds?

Are you seeing a similar transformation in a community, team or organisation that you’re a part of?

For anyone wanting to start exploring the world of product, Mind the Product run a comprehensive network of meet-ups, globally.  I’m a semi-regular participant of their Wellington events, which I have posted about previously (see: Customer Inspired; Technology Enabled – Product Tank Wellington MeetUp with Marty Cagan and Fireside Chat with Zheng Li, VP of Product @ Raygun – Product Tank Wellington MeetUp).