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