Dealing With Ambiguity

Posted on May 24, 2023 by adriankearns

Introduction

“Architect” is a thought-leadership role, and being a thought-leader means dealing with ambiguous problems. You may need to be the solver of ambiguous problems, or guide your colleagues so they can do so.

Dealing with ambiguity is an important skill, otherwise it will slow you down or lead to poor decisions.

Beware of Over-Baking

A symptom of being paralyzed by ambiguity is to over-bake a piece of work – probably one that is comfortable.

Our brains love avoiding difficult or unpleasant tasks in flavor of easier and more enjoyable ones, so it’s important to recognize when you are faced with ambiguity before too much time is lost to avoidance. If you find yourself putting a lot of effort into something fun but relatively trivial – that might be a sign to move on.

For example, imagine some two part process: step one is to conduct some analysis, but you’re unsure what step two looks like. If you find yourself (or someone else) over-baking the analysis (“Oooh, I really need to add some more colour to these charts”) it might be due the next step is not well defined i.e. you don’t know how to start it or you don’t have a plan.

Mitigation Strategies

The following approaches can be useful for dealing with ambiguous problems. These approaches aren’t mutually exclusive – you can mix and match.

Go back to the Objective

One of the first things to do is make sure you haven’t forgotten the objective.

Often we immerse ourselves in a complex problem and get so caught-up in its intricacies that we forget what we’re actually there to achieve. Once we lose sight of our objective we tend to get lost. Therefore, remember to keep coming back to the objective: make sure you clearly understand it and don’t lose sight of it.

Also, you can use the objective as a point of reference – to work backwards from, and that can help penetrate the ambiguity.

Go Back to First Principles

Similar to the previous strategy, a good way to take control of a problems intricacies is to go back to first principles.

“First principle” is essentially a fundamental truth that stands alone. Aristotle defines it as “the first basis from which a thing is known.” In the context of this strategy, first principles refers to things which you know to be true – not things you assume.

Often our understanding of complex problems is a web of linked assumptions; if the overall hypothesis is flawed we can end up getting lost due to circular reasoning – essentially we get defeated by the complexity. Going back to first principles is essentially to throw all your assumptions out the window and start again.

Using first principles helps you work methodically and focus on specific things that matter; “divide & conquer” can be a good complimentary approach.

Give Yourself Time / Space to Think

Complex / multi-dimensional problems will require more mental processing than usual.

The number of variables & possibilities present, plus the variety of disparate information available, will be larger than usual. Therefore, its important to give yourself time to think.

“Chipping away” is a great companion strategy – digest part of the problem and mull it over or sleep on it, then take another bite. As you build up a picture of the problem you’ll develop a mental model that you can fit new things into. Also be ready to change and restructure your mental model as needed – try not to be too rigid.

Just Attack the Problem

Brute force. Like starting a cold engine, you might need a surge of energy to make an initial break-through.

One way to break writers block is to just start writing – even if the initial output is total garbage, the act of forced writing can help kick-start the brain into the right kind of processing, and productive writing will follow. The same can hold for problem solving – sometimes you just need to get stuck in and warm your brain up.

Divide & Conquer

Break a big problem into smaller ones. Concentrate on one. Make progress or recognize when to give it time and come back to it.

Slightly related – rather than trying to solve the entire problem first, see if you can put some “stakes in the ground”, i.e. make concrete progress on some key points and use those as a basis for further work.

Find Themes / Consolidate

Group many moving parts into themes to reduce overall “noise”.
Look for patterns.
See the big picture.

Chip Away

“Death by a thousand cuts” but in reverse.

Putting a small amount of effort into something huge usually seems futile,
but many small efforts added together
will make an impact.

Works well with “giving yourself time/space to think”. Take a small bite at the problem and mull it over.
Supports a sustainable pace. (Its a marathon, not a sprint).
Start early. Expect course corrections.

Defer

Putting-off something difficult by procrastinating is not a recipe for success. That said, problems sometimes have a timing dimension to them, and so picking the right time to tackle the problem is sensible.

The trick is to successfully identify the factors, and recognize that its real and not procrastination.

For example, the work of you and your team will often have dependencies on other projects, teams, decisions and future state strategies; sometimes the direction of these will be unclear. In such cases you may need to get clarity on where they are likely to land before it is worth investing significant effort in related problems.

Share Your Problem

If you’ve been struggling on your own, share your problem with a colleague or a friend. Often an outside perspective is all we need to get us started.

Time-boxing

Not so much a strategy of it’s own but something which applies to many of the strategies above.

Think about how much time to invest in a given approach. If you still haven’t made progress after an appropriate amount of time, ask yourself:

Is this a signal you need to switch to a different approach?
Should we put the problem to the side for the moment and come back to it later?
Is the problem insoluble, and we may need a change in overall strategy?

More Info

This expands on part of the “Consulting Architect – How To Get Sh#t Done” talk I gave at the Geekle Worldwide Software Architecture Summit, May 2023:

Deck, extended response to some audience questions, etc: https://morphological.wordpress.com/2023/05/16/consulting-architect/
recording of the event stream: Worldwide Software Architecture Summit’23 – Career Track – YouTube
Event Schedule & speakers: Agenda- Worldwide Software Architecture Summit 23 (geekle.us)

Consulting Architect

Posted on May 16, 2023 by adriankearns

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.1 Download

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:

You don’t need to apply all of them! Just use whatever works for you to sort the problems.
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.
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.
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:

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.
How many unknowns? Easy problems tend to be well understood because there’s not much to them.
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.
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.
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.
“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.
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.

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:

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

Potential responses:

Is it something the team can self-resolve through discussion – e.g. at a retrospective and by adopting some goals? (Don’t forget SMART).
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.
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.
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.
Do you need to escalate? Perhaps you need more staff, better technology or something else which you need to ask for.

Enquiry Questions

Posted on July 22, 2022 by adriankearns

TL;DR – Asking questions when you already think you know the answer still has benefits including relationship building, gauging expectations and navigating tricky situations.

I was in my first meeting with the client for a new consulting / architecture assignment. The project had been running for a while with one of my colleagues already involved. At one point I put a question to one of the customer representatives – but my colleague cut-in an answered on their behalf. It wasn’t totally surprising, since we had discussed the same subject in preparation for the call, so to a certain extent I knew the answer. Straight after the customer meeting my colleague and I were doing a debrief:

Colleague: “Why did you ask about [that topic]? I already told you [something relevant].”

Why? There’s several scenarios: relationship-building with the customer, getting on to the “same page”, verifying / re-verification information, or using it to then transition into more delicate topics. I’m going to call these “enquiry questions”. Let’s look at some different scenarios.

Relationship Building & Inter-Personal Connection

When you’re coming fresh into a already running project you need to get up to speed as quickly as possible – and not just the technical side, more importantly it’s about quickly establishing effective inter-personal connections with the people you’re working with. As an architect you are in a leadership position, and your success will largely hinge on your key relationships and how well you can leverage them.

In the consulting context, asking about some aspect of the project is a bit like showing personal interest – it demonstrates that your engaged and interested, which is exactly what key people want to see from you: that you are speaking their language, that you have a sense of the right priorities, that you’re not afraid to ask questions, and so on.

Asking enquiring questions also gives you an opportunity to gauge their response – how they react to a question can indicate how they feel about a given topic, where their priorities lie, and so on.

Getting on the “Same Page”

Being on the “same page” is metaphor for having a similar understanding of a given context, and being broadly like-minded regarding how that context will be treated. In a project or consulting context this must at least cover scope, objectives and priority – it’s critical for everyone that you and the customer are on the same page, otherwise it will lead to friction that will distract from getting things done.

Asking something we already know (or strongly suspect) allows us to confirm we are on the same page or expose gaps where we are not, allowing us to then start closing those gaps.

Reconfirmation

Personally reconfirming something directly means that you won’t get caught-out by information that is secondhand or out of date. It feeds into the “same page” concept and can also help transition towards more detailed and focused conversations.

Being an architect, or in any position of responsibility, means you need to be very attuned to the information you are basing decisions on – because if you don’t do due diligence on critical information and assumptions, it’s your fault if things go wrong.

Direct personal reconfirmation isn’t just risk mitigation, it also means you can tune in to any nuance – such as the customers attitude to the topic:

Are they clear and precise when they discuss it – implying they have a clear understanding that also gels with reality.
Do they show genuine passion or are they indifferent, i.e. how much you need to care about it might be driven by how much they care about it. Alternatively, low customer enthusiasm for something critical may indicate an issue which needs addressing.

Through no fault of their own, the people before you may have “listened but not heard”, so reconfirming things also about giving yourself a chance to dig deeper and be more precise.

Delicate Topics

Asking about something you already have some knowledge of can be a safe way to start a specific discussion – on the assumption that you already have some expectations around where the conversation will likely go – meaning that you are better prepared for it. Starting off with a conversation that goes well also helps to build immediate confidence and provide a platform for trickier questions.

Sometimes people need to feel that they are heard. Asking an open question can be a good opening for that, perhaps allowing a customer to air frustrations that need to be worked through. Asking the question in the right way can also indicate your position, which may in-turn help channel the type of response they provide.

Risks

Is there a risk you’ll look stupid asking something you should already know? Yes, but it’s usually small risk. Generally I’ll be asking the question for a reason, and part of the calculus will be a gauge of how the person is likely to respond – will they be annoyed or open.

A big factor in risk management, which you control, is how you frame the question. Done correctly you can use such questions as a lead-in to harder topics – assuming they are related and the segue is therefore natural. A simple way out is to literally say that you want to start by ensuring everyone is on the “same page”. Being new to the project usually affords you a certain amount of leeway, so covering old ground is not likely to cause any issues.

Geekle Meet-up Feb-2021: APIs and Microservices, Architecture Cheat Sheets

Posted on February 26, 2021 by adriankearns

I recently had the pleasure of presenting a couple of topics at a Geekle architecture guild meet-up: Modern API & Microservice Platform Reference Architecture and Architecture Cheat-Sheet. The decks and supporting materials are all below:

Modern API & Microservice Platform Reference Architecture

Presentation (pptx).
Presentation (pdf).
Modern API & Microservice Platform Reference Architecture (pdf)

Architecture Cheat Sheet

My thanks to my employer, Middleware New Zealand, for supporting me in this meet-up.

Please note, all the materials are licensed by either Middleware NZ or myself under a Creative Commons Attribution-Non-Commercial 4.0 International License. https://creativecommons.org/licenses/by-nc/4.0/

You are welcome to use the cheat sheet materials internally within your commercial organisation as long as it’s only used for internal staff development, and not offered externally for payment, and the Creative Commons attribution is honored.

https://www.linkedin.com/in/adriankearns

https://www.middleware.co.nz/

Four traps experienced solution architects fall into, and how to mitigate them

Posted on January 27, 2021 by adriankearns

Here’s my “four traps” deck (MS PowerPoint) from the Geekle solution architecture summit, January 2021.

four-traps-experienced-solution-architects-fall-into-and-how-to-mitigate-them-adrian-kearns-geekle-sa-jan-2021 Download

Why?

Experienced architects are not immune to falling into traps of their own making.

By looking at some specific ones we can be more aware of what we do, and why,
so that we can self-improve.

What’s In This For You?

Four traps I have seen architects fall into: their causes & consequences, plus some potential mitigations.

How to use this deck:

Evaluate yourself honestly against each of the causes. Seek feedback.
Consider the mitigations; action the ones you think will work for you.
Repeat – seek continuous incremental improvement.

Your first project – where to start?

Posted on January 27, 2021 by adriankearns

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-2021 Download

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

Solution Architecture Engagement Flowchart

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

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/

Agile – the Rationalism vs Empiricism Epiphany

Posted on March 17, 2018 by adriankearns

23-Mar-2018. Just an FYI that I’m currently re-drafting this article with feedback from a couple of colleagues; you can expect some significant changes at some point – all of which should make the article clearer.

I’d like to share with you an epiphany. I run the risk of it being like a riotously funny party joke, retold later to much less effect: a case of ‘I guess you had to be there’, but that’s seldom stopped me before.

This epiphany is essentially a new way of viewing several things:

Waterfall vs agile, and agile vs Agile (big A, little A).
Why people often don’t ‘get’ software development; and probably why your developers and project managers have a fractious relationship, especially whenever estimation and deadlines are hot topics.

In short, the epiphany is based in philosophy. First the recognition that waterfall is inherently rational, whereas agile is inherently empirical. You then realise that as theories within philosophy they both have roots back in antiquity (Plato and so forth) and have essentially been elaborated and compared for significantly longer than waterfall and agile have been around. Therefore, we can contemplate agile and waterfall from a purely philosophical viewpoint (without any pretense of ‘brand’ or additional baggage), and we can also draw on significant body of previous philosophical work.

I also suggest to you that there exists a rationalist-empiricist continuum on which each of us are placed – some people are naturally inclined towards one or the other.

Let’s look at this further and see what we can through this lens.

Short Philosophical Primer

Rationalism and Empiricism are both theories within Epistemology – the branch of philosophy concerned with the theory of knowledge:

Rationalism is the view that “regards reason as the chief source and test of knowledge”, or in other words, where “the criterion of the truth is not sensory but intellectual and deductive”.
Empiricism is a theory that states that knowledge comes only or primarily from sensory experience.

Philosophical literature frequently discusses one in contrast to the other. One often also sees references to things being ‘a priori’ or ‘a posteriori’. This isn’t something you need to remember, but it is interesting to note the concept behind these two terms as it’s relevant to our subject and subsequent contemplation:

A Priori is “what comes before”, as opposed to
a Posteriori which is “what comes after”.

The question (of whether or not something comes before or after) is significant enough that a priori and a posteriori appear in ‘Elements’ – Euclid’s 300 BCE work which served as the model for precise thinking throughout 15th-18th century Europe.

For those of you less well disposed to latin, you might also come across the terms deductive and inductive:

A deductive argument is where the conclusion follows from the premise, i.e. via reason. I think, therefore I am.
In contrast, an inductive argument is based on experience/observation; in such cases the argument may be strongly supported by the conclusion but not necessitated by it.

It’s also interesting to note that empiricism is a key part of the scientific method.

So, key takeaway: Rationalism and Empiricism have been around and thought about for ages, and there’s lots we can draw from that.

Is Waterfall Really Rational and Agile Empirical?

If you already ‘get it’, then you can probably skip this section.

Waterfall, as it is practiced in an Information Technology related project delivery context, is a sequential approach. Typically it consists of phases such as analyse, design, build, test, and so on. Each phase informs the next: analysis informs us what the problem is, based on this we design a solution, based on this design we implement the solution, and so on. Only at the end, when the solution is complete, do we see it working and finally see how well it addresses the original problem.

In other words, the basis for the solutions design and implementation is rational thought – what we can deduce. It’s essentially theoretical.

The planning of waterfall projects is also based on rationalism; at the outset, estimations are made as to how long each phase will take, how much it will cost, who needs to be involved. All of this happens in advance, and is frequently updated. Should reality hit the project, the team is forced to ‘re-baseline’ – delivery schedules, resource estimates and costs are all calculated, based mainly on a rational thought process.

Agile, again as practiced in ‘IT’, is based on an empirical approach where work is done and the results evaluated before proceeding. At the beginning of an agile project effort is spent working out an initial prioritised list of problems to be solved, a small chunk of this is then worked on by the team, the results are evaluated and corrections made – corrections in terms of the base assumptions and the work/output itself. In this way the project proceeds, repeating a consistent cycle of delivery and inspection.

The planning of agile projects is also based on empiricism; teams typically provide relative estimates based on the size of previous work that they have already done, and in this way the estimates are evidence based.

Agile Explained

As I wrote previously, Marty Cagan has a nice simple way of asking people if they are agile:

How soon can you test?
Does shipping out a release mean you’re finished?

At face-value this appears fairly straight-forward, but I think we can go further:

Are you driven by what you have planned or what you can prove through experience?

If you primarily “know” a thing because you have deduced it then you’re not being empirical, and therefore you’re not agile. It’s that simple.

Agile: A vs a; Big A vs Little A

It’s true that in the context of contemporary software development the concept of Agile (as in the big A, as in the Agile Manifesto) is bundled up with additional ideas: individuals over interactions, collaboration, and so on; and whilst these additions clearly add immense value and have made agile more accessible for many, they don’t alter what’s arguably the single most important foundational idea behind agile – empiricism.

Take the agile manifesto and its guiding principles, for example:

Individuals and interactions over processes and tools.
Working software over comprehensive documentation.
Customer collaboration over contract negotiation.
Business people and developers must work
together daily throughout the project.
Build projects around motivated individuals.
Give them the environment and support they need,
and trust them to get the job done.

Many of these ideas (such as those listed above) are not mutually exclusive with waterfall; any group of people using waterfall can still choose to collaborate, be motivated and trust each other. It’s true (in my experience at least) that we don’t often associate the above with waterfall projects – but that’s inductive, just because it’s often the case does not mean it is bound to always be the case.

Sure, waterfall is based on rationalisation, which is often accompanied by process, requiring tools – but I’d argue that often the use of those processes and tools is often driven by other factors: social norms, people hiding behind process, and so on; it is still possible to put ‘individuals and interactions over processes and tools’ and follow a rational process.

There will no doubt be many for whom these additions are in fact indivisible parts of Agile, and I think that view is fine. My point is that one of the ways to better understand agile/Agile is to mentally remove all of these additions and conceptualise agile/Agile (and waterfall/agile) from a philosophical perspective based on Empiricism and Rationalism.

We can also apply this lens to a more recent phenomenon, the mainstream adoption of Agile as a product to make money off. Don’t confuse agile (and the key part: learning from experience and evidence) with Agile (i.e. specific recipes, brands and elaborate constructs).

State of Mind

Thinking about social norms and human behavior brings us to my second key point: the existence of a rationalist-empiricist continuum, and the premise that everyone is somewhere on this continuum – usually closer to one end than the other.

In my view, many software developers that I have worked with are empiricists – in that they have a greater affinity to an empirical way of thinking rather than a rational one. Conversely, many project managers I have worked with are rationalists – they have a greater affinity to an rational way of thinking.

Are these philosophies, these states of mind, mutually exclusive? I’d say not. For a start this article is itself based on ideas which have emerged through a combination of both. Furthermore, I can think of many occasions when I have personally used each.

Both are clearly useful tools, and like all tools they are most useful when the correct tool is matched to the problem being faced (not the other way around). The problem that rationalists are frequently confronted with in a software project is that the nature of software development is inherently empirical. Or to be a little more precise, the nature of software development when applied to solving a particular real-world problem, is usually inherently empirical.

I say ‘usually’ because I cannot say for certain that all such problems are categorically empirical. If we stretch software out to encompass IT, and therefore hardware, rationalism becomes more relevant.

We must acknowledge that for a lot of people, especially the senior executive who’s paying the bill, the basic question of “when will it be ready and how much will it cost” is not unreasonable. The challenge is how to best answer it – in this regard both Empiricism and Rationalism have their unique challenges.

How to Introduce Yourself as an IT Architect

Posted on November 8, 2017 by adriankearns

If, like me, you are an “IT” architect, you’ll know that describing what you do to other people is a challenge… even to people who have some idea about information technology.

It’s definitely not like being a fireman.

I think where we go wrong is that we try to explain the totality of what we do, which is too much (too broad, too complex, too nuanced). Instead, perhaps we should just pick one thing and put it in a context people will understand.

Let’s break it down. Broadly I think architects do four things:

Create visions
Craft decisions
Technical leadership
Be wise gnomes

Creating visions is all about the ability to paint the metaphorical big picture. It’s the big picture that helps people understand where we should all be going, and why. Sometimes the vision is ours – we discover it; other times the vision comes from others – they simply need help crystallizing it and then communicating it.

Crafting decisions is about getting decisions made. Sometimes it’s about guiding and facilitating people so that they make the necessary decisions, in a logical and sensible way; other times we need to make and assert decisions – to break an impasse, fill a void, or provide a specific direction.

Technical leadership is about making sure the thing is well made. It’s dealing with the nuts and bolts, widgets and gizmos. It’s not just limited to which tools should we use and how should we put the parts together, it also extends into how we should structure our work so that complexity is managed.

Wise gnomes have been there before. They’ve done that. They have first-hand knowledge of where the traps are and experience in dealing with them.

Which of these resonates with you the most? For me, it probably depends on my most recent project, so if someone asks me what I do I’d mentally gravitate to whatever was most front-of-mind.

Explaining it to someone

Pick one thing that you do (i.e. one of the four above if you’re stumped).
Put it into a context the person will relate to.

Putting it into context could mean using the metaphor of someone they know, someone with qualities that have some relevance to what you do:

“Basically I’m like Gandalf, I stop the team getting themselves into trouble, support through mentoring, and take the lead in making hard decisions.”

“I’m like the ‘Spock’ of our team – when something complicated needs to be solved I’m the go-to person for logical advice and to make sure we’re not going to break anything.”

Alternatively the context could be based on something you do:

“I’m like the translator that helps the techies figure out what people want, and I help people understand what the technology can do. That means I usually get stuck in the middle and have to work out the hard problems.”

“I’m like the navigator of the ship – people have a vague idea of where they want to go but need help deciding exactly where and how to get there. That’s kinda what I do in terms of choosing which technology we use and how we want to use it.”

“Oh, so you design computers?”
“Sort of, I design systems for [system purpose or name of organisation] and help make the big decisions like which technology we’ll use.”

“I’m an IT architect“

Do you start with “I’m an IT architect“, or something similar? Personally I do. Most people know a little about a regular (i.e. building / civil engineering architect) and that context is useful for helping to explain what is it you do.

Some of my peers think architect is becoming a dirty word in some circles – I hope that’s not really the case.

Remember the Audience

Finally, the important foundation underneath all of this, is to tailor your response to the audience – what background information you think they might already have, and how you want to come across.

You’ll notice that in the examples above I’ve largely avoided talking about the specifics of what we do, this is because successfully leveraging those topics requires the audience to already know what you are talking about.

I think the key is to just get the conversation successfully started – stick to small easy concepts, once that’s achieved you can elaborate further or add to it with additional information.

Try This: Everyone Draw The Architecture – A Retrospective

Posted on September 1, 2017 by adriankearns

There’s this really cool idea I read about in Luke Hohmann’s book “Beyond Software Architecture : Creating and Sustaining Winning Solutions”, only I haven’t yet found an opportunity to use it… until a couple of nights ago.

Have you ever been in a situation where: you’ve started working with an existing team and realised that things aren’t quite right? The way people talk about the solution isn’t entirely consistent, things seem to be going in random directions, maybe they are talking at cross-purposes or even arguing about how things are done? You might be familiar with this – it’s the kind of discussions you get when there isn’t a consistent team view of what the architecture is.

Luke’s idea is pretty simple:

Get everyone in the team, as an individual (no talking), to draw the architecture as they perceive it.
Once everyone is done, put all the drawings up on the wall and review as a group.

Have a discussion along the lines of “what occurs to you and the team”, and “do you find congruence? If not, why not?”.

The idea fascinates me, but I hadn’t yet had a chance to do it – until I got a chance to speak at the Product Tank Wellington meet-up. This specific meet-up was basically about architecture, and the intersection with product development. I wanted to introduce some architecture ideas and get some discussion going around how they perceived architecture in their space.

Here’s the intro slides and brief I gave for the exercise:

It all sounds great, what could go wrong?

Well, I was feeling a little bit flat that day – nothing major but not quite as “on to it” as you’d want to be if you’re presenting – especially when some of the audience are possibly more qualified in some ways to present on this than I am. During the exercise I walked the floor observing, and after a few minutes we put all the 16 or so pictures up in the wall.

Everyone gathers around, a piece of pizza in-hand, and waits for the pay-off moment where I take what they have done and deliver some revelation and insight.

[Gulp].

Unfortunately it was bit of a “fake it until you make it” moment. Because I hadn’t done the exercise before I was a little unprepared for what to do next, but that’s the problem with activities like this where you need the input from a group of people – it’s a little tricky to test it out in a meaningful way.

Before I explain further – take a look at some of the diagrams – what might you have said? (Think of that as a little self-test).

I managed to waffle a little bit so it wasn’t a complete farce, I asked a few questions and we generated some “ok” discussion – so I don’t think it was a totally wasted effort, before moving the conversation on.

Retro – What Did I Learn?

So first off – my thanks to everyone at the meet-up who took part, thanks for being guinea pigs in this little experiment! I hope you got something out of it even if it wasn’t necessarily what I was aiming for.

What Worked Well:

One of my colleagues at Middleware attended, and like a lot of people I meet he’s interested in architecture but the whole concept is a little intimidating and he’s keen to know more. He said the exercise was really great for keeping people engaged:

It gave people a chance to get up and stretch their legs, good for energy.
It gave people a break from listening to me and watching slides.

But that’s not exactly a surprise, in my experience (both presenting and being presented to, anything interactive is usually positive).

Challenges

The volume of information to process.
The variety of visual styles and approaches.
Messy handwriting.
Having very little time to analyse and respond – in front of a group.

I tried to look for common themes and areas where people had varied wildly; and in this regard the exercise went exactly as I had anticipated as there was a lot of variety. The problem was that:

The insights that occurred to me weren’t quite in-line with the brief I thought had given the group, and I didn’t want to start making comments people thought were unfair because the goal-posts had changed.
I had a clear idea in my mind of how the exercise would go and how I would respond, but my assumptions didn’t entirely survive what actually happened, and consequently I felt I didn’t responded as well as I wanted to.

What Could Have Gone Better If:

I had been more “on to it”.
I had done more preparation and thinking about what might get drawn, and how I might need to respond.
I had thought to ask one or two people to give us a quick summary of what they were thinking and the process they went through, as a way of generating some further discussion.
I had picked a drawing at random and tried to interpret it “Ok, this is what I think you’re saying”, and use that as a way of generating some discussion and insight. Repeat as appropriate.

Final Observations

The context of the exercise is important, as the objectives flow from the set-up:

In this exercise people were dealing with a domain problem (flight bookings) that was essentially new to them – I presume they all have some background idea of such a system, but it not like they will have be actively building one for some time – which would be the case in a real-life scenario.
It’s similar for the reviewer/facilitator; they way I would run the second half of the exercise would be different because what I needed to get out of it would have been very different. Unlike an exercise at a meet-up, in a real-life project I would be bound to the outcomes as a member of the team – i.e. I’d have to live with them, so the drivers would be immensely stronger.

Would I do it again?

Absolutely. In some ways the exercise was bit of a failure, at least in the short term, and I can only hope that people were able to take away something useful from it. That said, it was a success from an iterative point of view: I now know a lot more about this technique and how to make it better next time. These learnings will also help me should I ever need to do it “for real” in a project.

I also hope it was successful in that this write-up gives you something to think about, and perhaps the inspiration or basis to run this exercise yourself – either informally as a meet-up/learning activity, or as a “serious-face” exercise as part of your project.

Postscript

I’d like to belatedly comment on the work people did and share some observations on the content and possible thought-process (rather than the visual style):

It’s interesting how people’s background comes through – the second diagram takes a decidedly infrastructure based lens. This is not necessarily bad. In situations like this (where it might not necessarily answer the question you thought you had asked) it may prompt valuable questions you hadn’t thought to ask. That’s a strength of this sort of exercise, the variety of responses can provide insights you hadn’t expected and therefore might not have uncovered.
It’s also interesting the different functional emphasis people use. For example the last one seems to have a finance focus – three of the most prominent boxes are “Prices”, “Finance” and “Payment”, the first two of these are also in the center of the diagram, which might also be where they started drawing – and where they conceptually started.
The first one is interesting because it blends functional concepts like “flights” and “Finance” with solution/technology concepts such as the enterprise service bus that links stuff together.
The third example appears to have started with the “portal”, large and across the top; it then decomposes the portal down into parts, and then further elaborates those into related concepts. It’s easy to see how the drawers mind may have been methodically working through the problem.
The second-to-last example is interesting because it seems to very much be an exploratory diagram, where the drawer is literally working it out as they go: drawing some concept and then digesting that before adding the next piece. There’s absolutely nothing wrong with this approach. It’s true that a “messy” diagram might reflect the drawers understanding of the domain, but it hasn’t stopped them bringing in elements that others missed, such as thinking about search through to external providers (Expedia). Like some of the other, this example also mixes technical and non-technical concepts (think “apples & pears”): “bank API’s” and “Weight Allowance”.
Not all of the examples have included people/actors. Neither approach is wrong, but to me including people starts to provoke thoughts around who does what, what scenarios they might have, and begins to bring people back into the discussion – which I think has a lot of value.

Were you one of the participants in this exercise? If so, please feel free to add your thoughts in a comment.

Design Thinking Entrée, with Blair Loveday, et al (#ITEA 2017)

Posted on August 22, 2017 by adriankearns

Coming out of the ITEA conference, I referred to three magical signs that (IT) architecture is going through a positive transformation; #3 was around design thinking, a topic that a number of speakers covered in varying depth. Amongst those was the heretic Blair Loveday; I mean sheesh, the guy’s a BA Chief Culture Officer, what blasphemy is this, him presenting at an architect conference?

Blair and the others spoke enough about design thinking to wet our appetites, but not nearly enough to constitute a meal; so, based on what I got from the conference and after some digging of my own, here’s my quick overview of design thinking – a sort of entrée to get you started.

In a Nutshell

I’m conscious that I’m partially trying to appeal to IT architects, let me do so by using the term ‘scientific method’, because it’s going to get a bit touchy-feely later on.

According to wikipedia, Design Thinking is comparable to the scientific method (feedback is obtained by collecting observational evidence and measurable facts) but with the addition of also considering the human aspect, or emotional state. The inclusion of the human dimension is a key theme that you’ll find throughout design thinking literature. For example, use of empathy is one of the specific techniques suggested for during the ‘learn from people’ phase.

The Three Lenses

One of the concepts Blair used to describe design thinking was a “the three “lenses” that you’ll see repeated in design thinking literature: desirability, feasibility and viability.

Blair respectively described these people, business and technology lenses, and then talked about then in the context of innovation – by type, depending on which lenses overlapped. The central overlap of all three was “Experience Innovation”, which sounds fine but with all due respect is just a smidge too touchy-feely, even for me, on Monday – but that doesn’t matter.

Design thinking, according to Blair, is centered on the people / desirability lense – which is in keeping with Wikipedia’s view vis-à-vis the scientific method. You’ll notice that this puts emphasis on emotional and functional innovation.

The thing I really like about this model is that it’s simple yet useful, calls out the human part (which is pretty essential) and provides one of several good anchors to understanding design thinking: making stuff that “is cool” or “just works”, for people.

Getting to Grips: Four Into One

Trying to understand design thinking by reading about it online is a little like talking to people who witnessed a traffic collision: everyone’s got a slightly different view. Given how long design thinking has been around that’s probably not surprising. I found a number of approaches. What I’ve done below is to try and distil the main phases from the 4 interpretations that I studied:

The colour groupings are my own, looking for commonality across the different approaches, and are only indicative. The four approaches are based on (from top to bottom): Design thinking example video (wikipedia), IDEO, Stanford University’s ‘Taking design thinking to schools initiative’ (wikipedia), and ‘A Framework for Design Thinking’ (Creativity at work). Links to these references are below.

The third process, from Stanford, is the one Nick Malik referred to in his talk at ITEA 2017.

Chris Tuohy’s talk on experience’s at Westpac also touched on design thinking. The Westpac approach has seven phases (not including an 8th step which seems to be a decision point at which the prototyped ideas are passed into a delivery-focused design and build lifecycle. Unsurprisingly, these seven phases are all in common with those suggested by the 4 approaches above.

Distilled Comprehension: One from Four

Here’s my general take on what things a reasonable design thinking process should include:

Learn from people:
1. IDEO seem to refer to this as “Insights”, observation, learning from extremes, interviews, immersion and empathy, and doing this all through the three lenses.
2. Getting an idea of people’s motivations, habits and delights is a good place to start.
3. A concept I came across more than once was the idea that people on the extremes (think bell curve) are good at helping to explain ideas that the mainstream are less able to articulate.
Find patterns:
1. Look at what you’re learned, try and make sense of it.
2. Look for themes, apply intuition.
3. Put yourself in the shoes of the users, leverage empathy.
4. Distil design principles. For example ask the “how might we” question: if a design principle or theme says “x” ask how you might turn that into a specific idea or prototype (and remember the three lenses).
Generate ideas:
1. Don’t prequalify ideas out, just generate them.
2. As IDEO say, “Push past the obvious”.
3. The emphasis is on creativity. Basically this is the divergent thinking (creating choices) phase.
Make tangible, prototype and test:
1. This is the complementary convergent thinking phase (making choices).
2. Make things tangible and real through prototyping. Use any method you like, but make sure it’s using something that will resonate with your audience.
3. Refine and improve.

Some of the descriptions include steps that come after what I would consider to be the core of design thinking (e.g. delivery). I don’t think that’s necessarily bad.

You could say these were “steps”, implying a formal process; obviously you want to take time to understand before you race off and prototype stuff, but to put constraints that are too formal on the approach would do it a disservice. For example, the phase of generating ideas and prototyping them could (and even should) be an iterative process. After all: how many iterations = how long is a piece of string.

Finally, I got hold of Peter G. Rowe’s book “Design Thinking” from the Wellington public library; I haven’t made serious in-roads yet, but it looks interesting. One of the things about it I am keen to explore the author’s views it given he’s coming from the perspective of a “real” architect (i.e. buildings, not IT).

Further online reading and viewing:

Wikipedia – check out the example video, it’s a really nice little summary.
IDEO – some useful content for sure, but not a lot of it (unless I did a “man-look”).
Creativity at Work