Consulting Architect

As (intended to be) presented at the Geekle Worldwide Software Architecture Summit 2023
May 16, 2023 at 9:00 am UTC – May 17, 2023 at 7:00 pm UTC

consulting-architect-geekle-wsas23-may-2023-v0.1Download

In this talk is based on my lived experience, working as a consulting solution architect.

There’s a skills overlap between consultancy and architecture; and I think architects have an opportunity to be more effective by applying some of the consultants mindset and techniques. In short – “consider being a “the consulting architect”.

The deck includes extensive notes on selected slides, and I’ll be publishing blog posts on selected topics in due course.

One of my motivations behind this talk is that there’s lots of ideas, skills and techniques which (as far as I am aware) aren’t usually discussed in architecture circles, so this is a chance to explore some of those and see how they can help us be more effective architects.

Update – Q&A Session Responses

As much as I like the challenge of answering questions on the fly (in Q&A sessions), because I’m (almost certainly) dyslexic I often don’t have enough processing time to give really good answers. Last night I got three questions, and I’ve done some more processing 🙂

To those who asked the questions – I hope you see this and that its helpful.

How to select / weigh which is hardest easiest problem to start with?

Usually the size of a problem is obvious. Whilst I think it is wise to be mindful about which problems we start with, it’s also something which is easy to over-think.

In my talk a mentioned how the brain has two modes of reasoning: heuristic (intuitive) and analytical; the former is usually pretty good at sizing up the relative size / difficulty of a problem, and that’s often sufficient. Is the relative difficultly immediately obvious?  If you have to stop and think about it for too long that probably indicates it’s not easy.

If you do want to be more analytical, below are some of the things I think about when doing problem triage, in roughly the order you may want to consider them.  Remember:

1. You don’t need to apply all of them!  Just use whatever works for you to sort the problems.
2. Triage is just an initial assessment – it’s okay to change your mind later (as to if it’s an easy or hard problem) because all you’re doing is sorting out which problems you want to tackle first.
3. Because its an initial assessment, use simple coarse-grained measures; for example easy or hard; or easy, medium, hard, unknown.  The point is to balance effort and accuracy – whilst we’d like an accurate measure, but it’s probably not worth investing a lot of effort.
4. A lot of these techniques can be used with different levels of effort: a 30 second thought exercise in your head; a 5 minute doodle on the back of an envelop; a 10 minute whiteboard chat with a colleague.

Things to think about:

1. Is the relative difficultly immediately obvious?  If you have to stop and think about it for too long that probably indicates it’s not easy.
2. How many unknowns?  Easy problems tend to be well understood because there’s not much to them.
3. Can we change our minds?  Architect is about making sound decisions, where we know that once we make those decisions it will be very challenging to change them, so we need to be careful.  Easy problems can sometimes also be relatively straightforward to change later.
4. Blast radius.  If you misjudge the problem and it explodes – what’s the likely blast radius?  Would it affect just you, the project or the whole enterprise?  The bigger the perceived blast radius the harder the problem might be.  Also see “risk profiling” (below) which expands on this idea but is more complex.
5. Is the problem rooted in people or technology?  Technology problems tend to sit there waiting for you to research the answer online (easy).  Problems that involve other people can be harder because people tend to have their own ideas about things (how dare they!), so you may need to engage with them: take time to understand their perspectives, motivations and priorities, factor any new ideas and information they provide into your mental model; sell them your ideas, influence and negotiate.
6. “Firsts”.  In solution architecture you’ll often be faced with “new” problems, coming up with new patterns, using new technology and so on.  This relates to “unknowns” but the nuance here is about doing new things for the first time – you might have a good idea of what needs to happen but because it’s the first time in this context there’s a degree of unpredictability.
7. Risk profiling: think about the risks that might relate to the problem – hard problems tend to have more risks.  For the risks, think about them in terms of likelihood and impact – the more likely they are, and/or the bigger impact they have the more serious you need to take the risk.  Harder problems tend to attract more serious risks i.e. more likely and bigger impact.  For an initial problem triage you don’t need to think of all the risks associated with it – you only need to identify if it has any that cross a red-line in your head.  As soon as it crosses that line put it in the hard basket and move on.

Must read book for developer wanting to migrate to solution architecture?

The developer to architect journey is one I took myself, so it is important to me.  I’ve been focused on this topic for a while now and have these resources which may help.  They are listed in a suggested reading order.

1. https://morphological.wordpress.com/2017/01/26/the-laymans-guide-to-it-architecture-roles/
2. https://morphological.wordpress.com/2017/01/31/career-progression-into-architecture/
3. https://morphological.wordpress.com/2021/01/27/your-first-project-where-to-start/
4. https://morphological.wordpress.com/2021/08/03/roles-responsibilities-of-the-solution-architect/
5. https://morphological.wordpress.com/2021/02/26/geekle-meet-up-feb-2021-apis-and-microservices-architecture-cheat-sheets/
6. https://morphological.wordpress.com/2021/01/27/four-traps-experienced-solution-architects-fall-into-and-how-to-mitigate-them/

How do you manage continuous delivery?

This is a very open-end question, but here’s some thoughts:

Is it even your problem?  If you are new to architecture, and in your last job you were responsible for delivery (maybe you were a tech lead), then it’s possible the answer is “no”.  In such cases you’re mentally still trying to do your old job; you need to try and move past it.

In those cases you can still be supportive but don’t make the mistake of doing someone else’s job for them at the expense of your own.  In general I think solution architects need to be ready to support delivery, but with as light a touch as possible.  This assumes you’re on a fixed term project as opposed to a product team in which case it might be different.

If we look through a RASCI lens, typically architects are not responsible for delivery (outside of the architecture), they are only consulted or supporting.

How to be supportive in managing delivery?  At first glance continuous delivery is a classic “people, processes and tools” scenario, so considering it through those lenses might be a good place to start.

Here’s some thoughts: things you might observe, and responses.

Observations that might prompt these questions:

1. Are there problems, is the delivery on fire?  Investigate – what’s the root cause?
2. Are there issues working with teams / stakeholders outside of your control?
3. Are things sustainable?  Are people working at a sustainable pace?
4. Is there too much work, are the deadlines unrealistic?
5. Do people have the right skills, and skill levels?
6. Do you have the right processes?  Are the processes being followed correctly?
7. Do you have the right tools?  Are they being used correctly?
8. Is there a bottleneck or some kind of resource contention?
9. How do you know the above is true or not – do you have the right visibility?

Potential responses:

1. Is it something the team can self-resolve through discussion – e.g. at a retrospective and by adopting some goals?  (Don’t forget SMART).
2. Faced with a risk or issue?  Can you: avoid it, reduce or control it, transfer it somewhere else, or do you have to accept it?  The latter might mean making changes at your end even if the issue originates from outside.
3. Do you understand all the stakeholders involved – their motivations and priorities?  Sometimes smooth management just means keeping the right people in the loop.  Consider stakeholder mapping.
4. Bring in expertise from outside, probably on a temporary basis.  Could be a formal engagement or informal.  Sometimes someone from the outside will immediately see the issue which the team couldn’t see because they were too close to it.  Sometimes advice from an outside (neutral) perspective helps get doubters on-board.
5. Do you need to escalate?  Perhaps you need more staff, better technology or something else which you need to ask for.

Advertisement

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:

Solution Architect RACI v1.5 (png file)Download

Solution Architect RACI v1.5 August-2021 (xlsx file)Download

And if you need it, here’s the deck I presented which will provide some background:

Solution Architect Roles and Responsibilities – Adrian Kearns – Geekle WSAS Conference Aug-2021 (pptx file)Download

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:

your-first-project-where-to-start-adrian-kearns-geekle-sa-jan-2021Download

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

Solution Architecture Engagement Flowchart

solution-architect-engagement-flowchart-jan-2021Download

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).