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.

Roles & Responsibilities of the Solution Architect

Posted on August 3, 2021 by adriankearns

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:

Variation in organizational size & maturity.
Variations in methodologies used.
Variable understanding of the solution architect role definition.
Organizational politics & human nature.

#1 deserves special mention, so let’s get 2, 3 & 4 out of the way:

Methodologies are often associated with (or dictate) various roles and responsibilities, so the methodology in use will often impact how architects do what they do, and even what they do.
The solution architect role definition tends to vary across cultural-geographical spheres and organizations (e.g. government vs private; where software / IT systems are the core business – or not, and so on).
Politics, e.g. where managers set-up fiefdoms that can sometimes impact who does what, within what scope, how they do it, and so on.

Whilst those three drivers are not uncommon, I’d argue the most consistent drivers are variations in organizational size and maturity. Size drives role focus – how specialized your role might be, whilst maturity drives role clarity – how well / consistently its understood.

Larger organizations tend to bring greater role specialization:
= Less need for you to “wear many hats”.
= More focused responsibility.

The more mature an organisation is:
= The more well developed it’s processes are likely to be.
= The more clearly defined your role is likely to be.
= Greater clarity on roles and responsibilities.

All of these factors will influence exactly what your role and responsibilities are, in a given engagement.

Current Art

Apart from specialist entities such as IASA Global, there’s not a lot of existing stuff out there that describes what a solution architect does, in terms of specific roles and responsibilities – especially if you want to get down to the task / artefact / scenario level.

First off, TOGAF, the popular enterprise architecture framework is… well… enterprise focused, not solution focused:

The Solution Architect has the responsibility for architectural design and documentation at a system or subsystem level, such as management or security. A Solution Architect may shield the Enterprise/Segment Architect from the unnecessary details of the systems, products, and/or technologies.
https://pubs.opengroup.org/architecture/togaf91-doc/arch/chap52.html

And that’s about as specific as it gets – apart from the TOGAF Architecture Skills Framework, which is generally good but it’s not very low-level and more focused on roles central to enterprise architecture.

SAFe goes further and looks like it has some good practical level of detail in terms of roles and responsibilities, based on its concept of “Solution Architect/Engineering“. I haven’t gone through SAFe training so can’t say what all the details are, but as you can see from the linked page, there’s a good level of practical detail.

The only caveat is that the guidance is SAFe specific; applying it outside the context of SAFe is definitely possible but will require your interpretation and adaptation.

My Model

The basis for my RACI model starts with the SDLC (Software / System Development Life Cycle), on the basis that:

Solution architects typically operate within the context of a project…
which usually delivers one or more systems / major system changes…
those changes typically follow an SDLC…
Therefore: SDLC drives a lot of what a solution architect does.

The gold elements in the diagram represent major concepts under which we can group specific tasks, artefacts and scenarios, for which we can define specific roles and responsibilities. The thread of gold elements in the lower half are directly related to the broad notion of SDLC (see slide 6 in the presentation deck):

Initial planning & analysis.
Development of the system / solution architecture.
Detailed design including API specifications.
Build, and the closely related areas of delivery methods and engineering.
All necessary testing including system integration, performance and security.
Release & deployment including data migration and roll-out planning.
BAU operations – the system / solution in it’s operational form.
System change – which may trigger new iterations of the SDLC.
Decommissioning when the system is replaced, which may happen as part of the implementation of its replacement.

Supporting those, at the top of the diagram, are a few major concepts outside the SDLC:

Current & Planned Constraints such as existing technologies, emerging systems and technology strategies.
The Architecture Practice you may be working within.
The Project / Product Construct you are primarily engaged with.

PaRCINo Matrix

Supporting the diagram is a matrix that describes every element on it, and the typical level of involvement you’re likely to have with it as the solution architect.

You’ll notice the matrix uses a type of RACI to define the solution architects level of involvement, but that it’s “PaRCINo” rather than “RACI”.

Pa – Participate – where you participate in completing the work.
R – Responsible – where you take the lead in completing the work.
C – Consulted – where your opinion is sought.
I – Informed – where you are kept informed of progress or anything of significance.
No – No involvement.

It’s worth taking a closer look at consult vs participate, especially in the context of solution architect, which is a senior leadership position within the construct of a project:

Consult implies you might have a degree of authority in relation to the subject, potentially including the ability to approve or endorse, or to at least lend significant sway to the subject.

Participate is similar to consult in that you might have a degree of authority, however, the practical application of that authority is (or should ideally be) through collaboration and driving consensus.

The challenge you face is that whilst you have responsibilities to your project team and business client, you also have responsibilities to your parent architecture team / chief architect / organizations enterprise architecture, and those two broad sets of stakeholders won’t always align. Where there is misalignment you will have to decide how to navigate them, and this may mean you have to assert your position more strongly than as a member of an egalitarian team.

Example: Domain Architecture & Breaking New Ground

The deck covers five examples from the model, which help to illustrate the roles & responsibilities of the solution architect, and how that can vary depending on circumstances. Let’s take one of those now.

This example actually covers two related concepts:

Domain Architecture – organisation-wide architecture for a specific domain, such as data, security, infrastructure and so on.
Breaking New Ground – scenarios where the development of a solution architecture requires the organisation to make major changes or additions. These initiatives may be outside the delivery scope of the project but still a dependency for it.

The connection between these is that projects delivering non-trivial systems, or major system changes, will often discover gaps in the organizations wider architecture / technical landscape. These gaps can be significant enough to block the project, and frequently impact one domain more so than others.

The precise role and responsibility of the solution architect in such cases depends on factors such as those previously mentioned (organizational size and maturity, and so on). What is clear is that such a blocker needs to be mitigated (such as by filling the gap or avoiding it), and that you are in a lead position of responsibility to navigate that.

What I find in practice, is that domain architects will usually want to work closely with you, because they will see your project as a means to deliver part of their domain architecture (because your project has budget and people / delivery resources). This gives you a degree of leverage. Some will also want your opinion.

Where the gap in question is a big one, and the organisation already has well developed plans to address it, your involvement might be somewhere in the inform – consult range.
If your project helped “uncover” the gap, or simply because you’re the first project to be in a position to actually do something about it, your involvement will at least be consult and is more likely to be participate. A good domain architect will look to you as someone to help share the load, and develop thinking around the practical delivery and operational details.
Where no formal domain architecture (or architects) exist, you might find yourself responsible, given that the gap still exists to imperil the project.

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/

Fireside Chat with Zheng Li, VP of Product @ Raygun – Product Tank Wellington MeetUp

Posted on August 17, 2018 by adriankearns

The Product Tank Wellington meetup ran a “fireside chat” last night with Zheng Li, who is currently VP of Product with Raygun – a Wellington-based company, currently on loan to the U.S.

The conversation covered her career path to Product via UX, advertising, championing women in tech and passion for business, as well as delving into specific topics with being a product person.

Here are the key takeaways I jotted down, which I’ve tried to organise by topic…

Career Path

Zheng gave us a neat little story about how she started out (in a sense): a classic tale of taking something that nobody else wanted to do and absolutely nailing it.

The task was designing banner ads for TradeMe. She obviously attacked her self-imposed challenge with passion and drive (significant keys to success on their own), but I also noted that:

She formed a loose multidisciplinary team which (I think) included people with knowledge and access to data analytics and marketing folks.
Was data driven – each time she/they ran a new design, they would analyse the data to see what was working and what wasn’t, and think about why that was the case.

The other factor which she used to her advantage was being able to iterate at an appropriate speed – which was obviously supported by the data she and her team had access to.

Some pretty obvious takeaways there, a key one for me would be about being data driven / enabled > implication: you need to have the data. As a data architect colleague of mine once said: before doing any data design, you must first think about what questions you will want to ask your data.

Other stand-out points around career path included:

Turning weaknesses into strengths, by using them as differentiators. The context for this was around credibility.
Follow your passion. Zheng laughed in response to a question – someone asked something which inferred she had planned her career out; she said that in retrospect her career may look like it was planned but the reality at the time was anything but. Her response to challenges was to consciously seek out ways of addressing these – which in her case frequently included training courses, which she collectively found effective (I think for one particular area she did 7 different courses).
People want to work with people they like and trust. Zheng spoke of this in reference to relationships between companies, but it’s obvious from her perspective that this is based on interpersonal rapport. It’s not hard to see this concept also applying at a personal career level – something I can attest to having also experienced it first-hand.

Another key career theme Zheng had was based on “that venn diagram” – meaning the three overlapping lenses in Design Thinking which cover business/viability, technology/feasibility and people/desirability. The specific terms she used might have been a little different, but for me the connection was pretty clear.

Her basic advice was to become proficient and confident in any two of these lenses; although that seemed to be somewhat tempered with her other guiding principle of being customer focused – which suggests the business/viability and people/desirability lenses.

“Product” Means Being Close to Customers

This was one of Zheng’s key themes. Part of this was getting out and talking to customers, which is critical.

It was interesting to hear of her experiences using product “management” (my term, not hers – can’t recall exactly what she called it) as a selling tool. The basis for this was:

Selling the value of the product, not the product.
Establishing a 1-on-1 rapport with people, and understanding what kept them up at night.
Taking the time to really understand that problem from different angles.

As far as point #3 goes, that meant engaging with different people in the organisation to understand the problem from their perspective: technical, marketing, sales, etc; this obviously links back to the three lenses of design thinking mentioned above, and being close to customers – all good sensible product management stuff.

We can also expand this theme out “customers” to “people”. In her experience, product management is more about being people-based than technology based (this was mentioned in reference to a technical product for developers).

There was also a leadership angle: for her leadership was about aligning the purpose of her staff to the purpose of her business. The implication here is to talk with the people on your team and really understand what drives them and where they want to go with their career.

A Quick Note on Persuasion

If you want to persuade someone (such as your product manager – if you’re a tech working on the product, and you have a pet feature you want to add), you need to two things:

Speak in the language of the audience.
Back it up with data. This could be qualitative such as customer feedback, or quantitative data showing conversion rates.

Producty Bits

Dealing with Product Debt

Something I really liked was how she addressed debt – debt in the sense of technical debt, and even marketing debt, and so on: things which worked but could work better and had gotten to the point that they were affecting the bigger picture. She referred to it (I think) as the “99 issues” or “99 problems” story.

They got all the issues and logged them into Jira – meaning that they got it all out into the open. Not just development/technical debt, everything.
Presumably some sort of sizing and prioritisation work took place.
They then knocked off a number of the items, reducing the overall debt.

The way she spoke seemed to indicate this was an annual event – which didn’t happen every year. Bit of a spring-clean, I guess. Zheng didn’t call it out specifically but based on her other comments I presume space in the teams capacity / product roadmap was allocated to this work.

Another interesting idea which occurred to me as she described this was the technique that Agile / Scrum teams sometimes use, whereby they adopt a sprint goal – something non-deliverable – that they want to improve during the course of the sprint/iteration/timebox. Zheng didn’t explicitly say that was what they were doing but the idea seems relevant. Zheng, if you ever read this I’d be interested to know if that concept was one you consciously used or were aware of.

Roadmap

Items on a roadmap (i.e. the implied promise / expectations set) should be based on two things:

The teams capacity to deliver them.
Evidence that a given feature is wanted by customers.

Pushing Back

Don’t be afraid to push-back. If a customer requests a feature (for example) that is outside your roadmap and/or ability to deliver then be wary of following the money.

This definitely fits with my experience; I tend to think that at a inter-business level or interpersonal level, the relationship needs to be built on mutual trust and respect – if the other party does not reciprocate then they’re probably not someone you want to be dealing with.

Zheng gave two examples:

A major multinational effectively tried to bully their 50 wanted features on top of Zheng’s existing product roadmap – “you want our business or not”? To have done so would have caused massive chaos within the company, affecting product delivery and so on. Zheng counter-proposed a different approach which she and her teams could sustain. The multinational rejected the offer and went elsewhere – only to return months later, accepting Zheng’s proposals.
Another major company approached Zheng with features (she didn’t give specifics but I think we can guess their approach was more reasonable and more adaptable). Zheng recognised that some of these features would be great differentiators for their product, so (presumably) some changes were made to the product roadmap and the featured added – in essence Zheng followed the money, but did so because there was further advantage than just the money.

Final Thought: The Iron Triangle

At one point Zheng told an anecdote about a developer talking with her about code quality. I forget the story but it reminded me of the the old “Iron Triangle” or project management triangle – the one that is made up of scope, quality and cost (or some similar combination; cost and time obviously being closely related). The model effectively states that you can control any two; the implication being that if you nail people down in terms of scope and cost (or time) you have no control over quality.

I asked Zheng if she was familiar with that model and how she approached it. Her answer wasn’t as clear-cut and direct as I would have hoped (which is not a criticism – having presented publicly I know how hard it is to provide an off-the-cuff answer that is cohesive and concise), but seemed to boil down to this:

Her first substantive reaction was to discuss scope and features, so I would guess that this is her first priority. This would align with her other comments that put great importance on being close to the customer and understanding their needs.
Her second substantive reaction was to discuss product roadmaps, specifically in reference to their timing and how they are used as the basis for cross-team coordination (marketing and so on), so I imagine time would be her second priority.

By default this would leave quality to manage it self; but we shouldn’t forget the “spring clean” approach, whereby random items of debt (arguably involving quality) can be addressed in a structured way.

https://www.linkedin.com/in/zhenglinz
https://raygun.com
My original hand-scribbled notes from the session: Adrians Notes – Fireside Chat with Zheng Li, VP of Product @ Raygun – Product Tank Wellington MeetUp – 16-Aug-2018

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.

Are traditional architecture engagement models still relevant?

Posted on June 19, 2017 by adriankearns

An article I wrote, originally posted on the Davanti Consulting website, 30th November 2016, reposted here with permission.

Reinvention dominates the business landscape, pervading how we work and how we engage with those around us. As an architect, I sometimes wonder how many of my industry colleagues have noticed this and contemplated similar innovation. As architects we are often perceived as dinosaurs; surely then, the time to start reintegrating ourselves is now.

THE CURRENT STATE OF ARCHITECTURAL ENGAGEMENT

A good architect can bring excellent value, but that value is lost if it arrives too late. Some of the barriers to this value even appear to be systemic or stem from entrenched legacy thinking.

The way in which architects engage is influenced by several factors, including:

Control: architectural governance is often perceived as regulatory rather than wisdom.
Processes: these are often complex, “heavy”, unwieldy and time-consuming.
Resourcing: architectural capability is often scarce, a scarcity which is exacerbated by heavy processes.

Traditional architectural engagement tends to be based on a “these are the rules” approach renown for volumes of documentation and thinking before any real work starts. Interestingly this way of working doesn’t really have a name – it “just is”. There’s definitely a number of architects who got the Agile memo, but overall that percentage is still relatively small.

There are architecture frameworks such as TOGAF, but a framework is not an engagement model. TOGAF has the “Request for Architecture Work” concept, but this is more of a one-shot form. TOGAF is aimed at enterprise architecture and whilst it refers to solution architecture it does not attempt to address how architects should engage with stakeholders in a product or project delivery setting.

At the project level, architectural engagement will ideally be in the form of an embedded solution architect. Ideally their engagement will start with the business case and continue through to overseeing the implementation. At worst, their involvement will be sporadic or non-existent. For various reasons such as a scarcity of architects, coupled with the weightiness of architecture processes, this engagement will likely be forgone for smaller projects. The associated risk is that smaller projects often grow into bigger ones, consequently attracting belated architectural attention.

So, short of everyone drinking the agile Kool-Aid what should we do? What might a revamped engagement model look like? How do we start, and what are the challenges we need to solve?

FUTURE STATE

The goal is to ensure that architects are able to add value in a timely and sustainable manner.

As architects often work as part of an architectural practice, and within the boundaries of architectural governance, both the architecture practice and governance may need to be revamped:

The architecture practice should reinforce behaviours and processes that make the team more consistent in their approach, allows them to support each other, and thus positions the team to offer a more consistent experience to their business clients.

Ideally architectural governance should support the team in this change as they are its ambassadors. Governance should not be about doing architecture for the benefit of the architect.

At a high level, think about making these changes so that the following value is unlocked:

Do this	So that
Revamp governance.	It provides supportive guidance, rather than be a place where things go to be vetoed. It is easy and relatively painless to use, and therefore gets used more often.
Create a toolbox of processes, tools & artefacts that is accessible.	Non-architects find it easier to understand and use, as a result the architects will need to spend explaining it. More time can be devoted unlocking value and less time given to discussing the process. Architects have the time (and opportunity) to spend engaging more broadly and more regularly with the business.
Encourage architectural mentoring and coaching.	Architects can be seen more as collaborators and supporters.

REVAMPING GOVERNANCE

This isn’t a wholesale re-write, but more of a health check and possible diet. You might be familiar with the concept of a good value proposition being one that your grandmother could understand; check your architectural governance processes and make sure they can pass that test. Make sure that what is expected is very clear, not onerous, and that its business value is self-evident.

CREATE A TOOLBOX OF PROCESSES, TOOLS & ARTEFACTS THAT IS ACCESSIBLE

Empowering the business, whilst keeping them and the architect team aligned, is going to mean having some supporting materials available. These will work with the revamped governance and be very practical in nature. In situations where architects are working with the business in a mentoring context they will need materials that they can refer the business too, and which the business can use with a degree of self-reliance. These materials should outline:

Technology constraints that are deemed important, and why. If possible, a sense of direction, as business and architecture are seldom static.
What questions to ask themselves, and when, so that the business doesn’t paint themselves into a corner.
Areas of danger or concern; things they should escalate to the architect so that they can be appropriately supported. Thinking along the lines of RACI can be helpful – for example: when should they inform and when should they consult.

These material might be pre-written guides, checklists and (lightweight) documentation and diagrams, or, checklists that the business progressively complete with varying degrees of assistance from an architect. They might be anything from risk assessments, solution option assessments to solution architecture definitions.

Creating materials that effectively support the business (and the architects) means creating materials that are easy to access – not just in terms of being easily located, but also easy to read, and understand.Materials should be suitably light-weight, so that they are easy to consume and keep up to date. After all there’s no point freeing up an architect’s time just to write more documents.

In terms of the artefacts you expect the business/projects to deliver, ask yourself “who will read the documents”? If the answer is “only other architects” then exactly what value does it provide and is it really necessary?

ENCOURAGE MENTORING AND COACHING

There will always be a need for architects to do the architecture, and to be deeply embedded in a given project; but conversely there are many opportunities where a lighter touch may be equally effective.

Coming to the business with a mentoring approach places everyone on a more equal footing, and increases the chance of a more meaningful collaboration. The architects are close enough to spot potential issues, establish some sort of rapport with the business and lead them where appropriate. The business is free to do some of the heavy lifting themselves, freeing up some of the architect’s time.

If successful, architectural value should become easier to unlock, and more valued by everyone.

ENGAGEMENT STYLE

So far we’ve focused on the engagement model, i.e. elements of structure, broad approach and the rationale behind it. Hand-in-glove with those concepts is the style of engagement, i.e. the communication style used and how you relate to stakeholders on a personal level.

It is vital that you tune-in to your audience. Architects need to be leaders, they need to manage stakeholders of all types, and in a range of different situations. To do this effectively will require you to adjust your engagement style to suit both the audience and the message.

The best laid plans are easily ruined by poor execution, and as good architecture is dependent on good communication it is essential to get this right. Effective communication is a substantive topic in its own right, and beyond the scope of this article, but to get started, consider:

Being available, approachable and responsive.
Being good at active listening.
Being able to relate to others.
Being able to simplify the complex.
Being able to speak up.
Being good at asking questions.
Being effective at persuasion, mediation, facilitation.
How to say no without coming across as (or actually being) a roadblock.
Picking the right communication style for the audience.

IN CLOSING

As a discipline architecture offers great value, and architects tend to be clever people, but realising that value is not straightforward – as architects we need to be proactive, we need to be mindful of changing expectations as the world changes around us. Just because architecture deals in the fundamental does not mean it is impervious to change.

As practitioners of architecture, take what you can from new ways of working, such as Agile and collaborative tools.

Show the business and the rest of IT that architecture is not something up an ivory tower, and that we can lead innovation and change by example.

Career Progression into Architecture

Posted on January 31, 2017 by adriankearns

In terms of career progression into architecture, people typically start off from one of several common “starting positions”. For example, a solution architect or application architect this is likely to come from a software development background.
Here a map of some of the more common paths:

typical-career-progression There are more types of architect and pathways than what’s depicted here, but based on conversations with architects I have met (or interviewed) this is a fairly accurate summary of some of the more common paths.

The Architectural Role Meta-Model

For simplicity, I define it in three parts (outlined below). In broad terms, Enterprise and Solution architecture disciplines cover the full range of domains but operate within a specific level of abstraction; whereas Domain architects cover all levels of abstraction but within a specific domain. An in-depth write up on this can be found here, but in summary:

Enterprise Architects – who typically operate at the highest level of architectural abstraction and across a broad range of domains.
Solution Architects – who typically operate at a project or programme level. Although solution architecture covers the full breadth of domains, an individual solution architect will typically be relatively narrow in their focus – either providing general technical leadership within the scope of a specific project, technology or domain.
Domain Architects – typically operate simultaneously across the spectrum of enterprise and solution architecture, but within a single specific domain. They will support both enterprise and solution/delivery specific needs.

Progression

We typically see common paths into and through architecture, such as the software developer into the application or solution architecture space; business analysis into the business architecture space, and so on. Once in the architecture space it is possible to side-step into related roles – this might be done as a conscious and fundamental career choice, or may simply represent shorter-term variety driven by the work available.
The progression from solution architecture to domain architect to enterprise architect is common but by no means the only career path.

To a certain extent there’s a drift upwards in terms of abstraction (developer to solution architect; solution architect to domain or enterprise architect), but this isn’t always strictly the case. It’s fair to say that each role has a set of skills and a temperament that suit it – some people will mature from one role into the next, others will take an alternate path.

The Product Specialist

One of the assumptions behind the solution, domain and enterprise architect roles is that these people often have a breadth of experience that goes beyond a single product or technology stack. In other words, their careers are not defined along narrow vendor specific lines. This is largely borne out by what I have seen in the market in terms of the experience people have and the career paths they have taken.

Such specialists will be genuinely skilled at what they do but lacking breadth of vision and depth of understanding that someone with a more diverse background is likely to have.

Is this good or bad? Well I think that depends on what you need for the problem at hand; sometimes you need a very specialized tool for a very special problem, whilst other-times a more flexible tool is best.

One thing to be sure of though, as the technology market grows in breadth and diversity, areas of specialization will deepen. As anyone familiar with web development in the early 2000’s can tell you, the number of stacks and architectures available has grown considerably; as that range increases so does the potential for individuals to specialize; so does the possible combinations of skills a specific job description might call for.

This specialization is reflected in the vendor space where larger vendors have their own subset of roles (think marketecture) that mirror the role hierarchies found in the general market. We therefore have product specialist roles starting to emerge, with people operating at the level of a solution architect but with a background that cannot assumed to be as broad as those from a more general background.