Consulting Architect

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

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

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

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

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

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

Update – Q&A Session Responses

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

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

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

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

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

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

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

Things to think about:

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

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

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

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

How do you manage continuous delivery?

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

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

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

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

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

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

Observations that might prompt these questions:

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

Potential responses:

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

Advertisement

Roles & Responsibilities of the Solution Architect

This post contains materials presented at the Geekle Worldwide Software Architecture Summit, Volume II (August 2021).

TL,DR: There’s not a lot of definitions out there regarding the solution architects roles and responsibilities – especially at a practical task / artefact / scenario level. So, based on my practical experience I’ve put together the following diagram / spreadsheet combo:

Solution Architect RACI v1.5 (png file)Download

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

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

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

For those of you feeling like a more in-depth explanation, read on…

Problem Space

Knowing exactly what you’re supposed to do as a solution architect is mostly down to figuring it out on the job, learning from others, and what you negotiate it to be. It’s also hampered by inconsistencies that stem from four causes:

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

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

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

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

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

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

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

Current Art

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

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

The Solution Architect has the responsibility for architectural design and documentation at a system or subsystem level, such as management or security. A Solution Architect may shield the Enterprise/Segment Architect from the unnecessary details of the systems, products, and/or technologies.

https://pubs.opengroup.org/architecture/togaf91-doc/arch/chap52.html

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

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

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

My Model

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

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

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

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

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

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

PaRCINo Matrix

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

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

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

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

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

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

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

Example: Domain Architecture & Breaking New Ground

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

This example actually covers two related concepts:

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

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

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

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

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

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

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

• Presentation (pptx)
• Presentation (pdf)
• Architecture Cheat Sheet – Internal Training Exercise Outline – v1.0 – 25-Feb-2021 (docx)
• Architecture Cheat Sheet – Internal Training Exercise Outline – v1.0 – 25-Feb-2021 (pdf)
• My Cheat Sheet v3.3 (pdf)

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

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

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:

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

Your first project – where to start?

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

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

Here’s the deck:

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

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

Solution Architecture Engagement Flowchart

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

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

Quality Attribute Concerns for using Microservices at the Edge

It’s often interesting to look at extreme system scenarios and see what can be learnt from them. This webinar (https://www.youtube.com/watch?v=Fz1BJTephWw) from the Software Engineering Institute (SEI) at Carnegie Mellon University, presented by Marc Novakouski and Grace Lewis, looked at some extreme scenarios and had some interesting takeaways.

Rather than regurgitate the entire presentation here, I’ll touch on the essentials and then discuss some points of interest. If you need further info have a look at the webinar – it’s pretty concise and the information is well presented, and well worth a look in any case.

What is “The Edge”

The edge refers to extreme system scenarios, such as those potentially experienced by first responders, people providing front-line humanitarian aid or combat personal – specifically where this is being done out in the field. For example: disaster relief and on-site coordination.

These scenarios are very far from the office or metropolitan ones most of us typically architect for: infrastructure (power and networking) may be unavailable or limited, limited computing power (maybe only what you can carry with you, on foot), conditions on the ground can be unsafe (natural disaster, enemy activity), and mission duration & scope may be unknown or very fluid.

Relevant System Quality Attributes

The following seven attributes were covered, based on experience gained through SEI’s Tactical and AI-enabled Systems (TAS) initiative:

1. Reliability
2. Survivability
3. Autonomy
4. Adaptability
5. Flexibility
6. Distributability
7. Openness

Many of these may appear as common sense once you think about the scenarios a bit, for example being reliable.

Autonomy is interesting. It’s the idea that systems need some degree of intelligence / autonomy so that it can perform some actions on it’s own whilst the user is dealing with mission or environmental concerns.

Modularity & Monitoring

What I took from the quality attribute discussion is that modularity & monitoring are key to several of them.

High reliability and survivability can be achieved when the architecture is modular – allowing components to be replaced e.g. the instantiation of a new microservice instance; but more than that – in this case a modular system can also imply an array of instances forming redundancy. This second point was one of the interesting ideas discussed – a systems ability to scale down (or in) and still operate, if the edge situation demands it.

Monitoring is obviously the mechanism that enables recovery – whether through user intervention or system automation – i.e. autonomy. Whilst autonomy can cover functional aspects it’s also useful for self-repair, working towards better reliability and survivability.

Complexity vs Reliability

The autonomy discussion threw up AI as a possible way of achieving autonomy, which to me implies a level of complexity that might conflict with the desired level of reliability, since the more complex a system is the more likely it is to fail, because the number of failure points and scenarios increase.

I was able to pose a question on this and the response was elegant and – you guessed it – came back to modularity and monitoring. What I took from it was this: Modularity is the key – the idea is basically to encapsulate areas of complexity so that they are self-contained and isolated as much as possible (think IoC / dependency injection and programming against contracts). Having safely isolated the complexity, you can then use simple and robust architectures to harness the power of these complex modules – e.g. Pub/Sub.

Finally, Microservices?

The majority of the discussion could apply to “edge” solution design at any level – the ideas discussed are not limited to microservices in their application. That said, microservices were covered albeit briefly (there’s only so much you can cover in an hour). Certainly microservices have many attributes and advantages that make them well suited to edge scenarios where reliability and so on are important.

WSAF Meet-Up on the “Brand” of Architects & Architecture

For those who couldn’t make this meet-up, here’s a summary of what was discussed (or at least some of it, it was one of those organic discussions that took it’s own path, and I don’t have a lot of notes as I was too busy actively listening or blabbering making insightful contributions).

The basic question was around: how are architects perceived, and what is our “brand”?  We tried not to focus on specific types of architect too much (i.e. enterprise vs solution), although we tended to focused on solution architecture.

This raised initial discussion around:

1. What does it mean in the context of Agile – which we decided to come back to, but then didn’t.
2. Distinguishing between architects and architecture – the latter will always be needed regardless of who does it and what they are called.
3. The correlation between governance and architecture – where there’s a lack of good governance there is often a lack of good architecture or appreciation of architecture in general.

This led to a significant discussion around “can we define the benefits of (solution) architecture, and the risks of not doing it”?  Whilst this is hardly a new problem it is one that we really need to put to bed.  The obvious challenge is not merely to define it, but to do so in a way that is broadly and easily understood.

We also discussed what would logically follow next – assuming you had the ideal definition, what would you do with it ?  But unfortunately the conversation took a turn and I don’t have any notes.  From memory, there weren’t any major epiphany moments arising directly from this.  Sad.

People Who Do Similar Things

The topic then came up of comparing what architects did with people who do similar things.

One of the attendees mentioned her brother, whom is effectively an architect but doesn’t like to call himself one, but unfortunately we didn’t (or weren’t able to) dig into exactly why that was.

There was also a connection made between the role of a program manager and an architect.  Personally I can see how this might be the case in terms of seniority and leadership, but in other areas the correlation is much less clear.  Perhaps it is such that in some cases a program manager takes on some architectural leadership responsibilities when there is an absence of architects or effective governance.

Later on, this broad topic came back with a comparison to service design.  The widely agreed takeaway was that architects should add this to their general toolbox, the toolbox we all have of skills and ideas that we get from various places but don’t always get to use “for real”.  Service design feels like one of those – something it’s worth knowing a bit about – just enough to be dangerous.

Focus of the Solution Architect: Technical or Business?

We discussed the focus of the solution architect role – is/should it’s focus be technical or business?  There’s no doubt SA’s need a foot in each camp, but is one aspect inherently more dominant than the other?  And because this is about brand, i.e. perception, I asked people to consider not just how they see this for themselves, but also how they think non-architects perceive it.

I asked everyone to think about a scale from 0 to 100, where 0 was all business and 100 was all technical.  I then asked them to silently (in their own heads) come up with the answers to those two questions.  I then drew the scales up on the board and invited people (without changing their minds) to put their scores up.

As you can see, people see solution architecture as a largely technical role, and their perception of how they think others perceive it is similar but not identical.

It makes me wonder about engineering architects (people who architect buildings, etc) – do they have a similar or comparable issue with brand?  Are they perceived as being largely technical, and is this how they want to be perceived?

It Ain’t What They Call You, It’s What You Answer to

We then got on to names – what do we call ourselves.  Sadly the list wasn’t very long and we didn’t really push past the obvious, but it was an interesting enough starting discussion for a Friday afternoon.

What’s wrong with “architect” – well nothing in my book, I still think it’s a useful term, and I still often compare myself to a building architect when describing what I do to a lay-person.  But that didn’t get in the way of our discussion.

“Digital Strategist” came up, but then we realised that’s probably taken.  Later someone adroitly evolved this to “Digital Capability Landscaping”.

“Principle _ _ _ _ _ _ _ _ _ _” made it up onto the whiteboard, a brave start but leaves just a tad too much to the imagination.  Typical architect, right?  In  my notes I wrote “(domain)”, implying the name of the domain you’re a principle in is the key – but what are those domains?  perhaps it goes back to the technology vs business discussion – do you go for a technology or business domain?

Someone suggested “Technologist”, and “Solution Design Thinking”.

I’m quite proud of one I dreamt up later: “Trade-off Merchant”.

The conversation then took a turn when someone suggested we pull up Google Trends with “enterprise architect” and “design thinking”.  We then played around with other terms.  I must admit I was pleased to see solution architect is still trending upwards. What is Google Trends? see Wikipedia.

Final Tidbit

Someone mentioned a neat little resource: http://openmodels.org/

“The openmodels.org website hosts the Open Model Initiative, a project to collaboratively develop enterprise reference models for everyone to copy, use, modify, and (re-)distribute in an open and public process.”

The WSAF would also like to thank Middleware NZ for hosting us and providing drinks and nibbles.

Were you an attendee?  Got anything to add to my semi-random collection of notes?  Add a comment 🙂

Are traditional architecture engagement models still relevant?

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.

Architecturally Significant

“Architecturally significant” is a simple and useful concept that covers a few things…

It’s anything the architect (or anyone doing the architecture) needs to actively spend time and effort on.  It’s relatively more important, and getting it wrong would be “sub-optimal” – it won’t be easy to change and would have far-reaching consequences (e.g. costs and re-work).

Sometimes its about “picking your battles”.  Designing and developing solutions can be described as one long stream of decision making; in such a context the architect is going to be heavily involved in making these decisions, and sometimes the number of decisions that need to be made are more than they can easily handle – so picking the right ones is important.  (Putting aside for a moment the extremely valid point that decentralized decision making is a useful approach and so maybe the architect shouldn’t be the one making all of these decisions – at least not alone).

Working out when something is architecturally significant is a key part of an architects role (if you aren’t going to do it, not one else is), and given all too familiar time-pressures you’ll want to spend your time where it adds the most value.

Confused?  Being able to “separate the wheat from the chaff” is a key skill for anyone performing the role of an architect.

Let’s take an example

Imagine you were talking with someone about what they needed, and they said:

1. We need an online form that the user can fill in.
2. The submit button needs to be red.
3. The form needs to load in [x] seconds.
4. As part of the form they need to upload a file.

Which of these is architecturally significant?

“We need an online form that the user can fill in”

The lesson here is that, like a lot of things, this is unlikely to be architecturally significant in of itself, but, hiding underneath this might be something which is significant.  It’s one of those situations where you just need to keep a watching brief on it in case something comes out of the wood work.

As always, context is critical.  If this is part of a solution where there is already an identified way of implementing forms, then it’s less likely to be architecturally significant as there is already a solution in place.  If this is a “first” for the project and there isn’t an identified way of implementing the form then it probably is architecturally significant.  How many forms are you building, one?  Probably not so significant; 50 – that sounds significant.

“The submit button needs to be red”

Aesthetics aren’t architecturally significant – red Ferrari’s might go really fast, but red doesn’t have the same implications for databases (yes, shocking, I know).

But there might be a wider need here, one that as an architect and thought-leader within the project you are well placed to raise: “Is using red for the submit button good from a usability perspective?  Isn’t there something about colour-blindness we should think about?  Who’s looking after usability anyway”?

Sometimes being an architect isn’t to solve all the problems, it’s to help identify the skills that you need.  “Yes, because this is a new 30 million dollar multi-region, multi-language e-commerce initiative we think having a usability lead is a good idea”.

“The form needs to load in [x] seconds”

In general terms, anything that involves System Quality Attributes¹ (SQA), i.e. the concepts that underpin non-functional requirements (NFR), should immediately receive the attention of the architect; they may not be architecturally significant, but NFR’s are usually one of the architects key areas of attention.

In this case is it architecturally significant?  It largely depends on what the value of X is, and how the architecture and infrastructure compares to that.

As a stake-in-the-ground, I suggest to you that the 80/20 rule applies: 80% of the time a new solution will meet the performance needs of most users, without needing any “special” performance enhancing work.  In such cases performance isn’t architecturally significant.  It’s often something that is discussed – but it’s not common (in my experience, i.e. in more than 20% of projects) that something “serious” needs to be done for performance reasons.  By all means keep an eye on it but don’t loose sleep over it.

When might it be architecturally significant?  If the value of X is especially high, you know the infrastructure is especially poor (slow, known to not meet the requirement), or if there are other functional or computational factors which are out of the ordinary – then yes, it might be architecturally significant.

Don’t forget that you can always push-back: “yes we understand the performance targets you want to hit, but are you aware it looks like it may cost between $x-y,000,000”?

“As part of the form they need to upload a file”

This is an interesting one, for which I have a real-world example.  So before we continue, do you think this sounds architecturally significant?²  After all, handling file uploads is nothing new these days.

For this project:

1. We were using a COTS package which allowed users to upload files.
2. The client was relatively large organisation and successfully managed their own infrastructure.
3. Internal policy required all files coming into the organisation to be virus-scanned.
4. Their infrastructure included a server-based anti-virus solution that was used to verify email attachments going through the email server(s).

Unfortunately, whilst the anti-virus solution had no problems scanning attachments in the email flow it wasn’t able to scan the files being uploaded through the application – as these were embedded in a custom application web-service call from the client back to the service layer, and got inserted into the application database as a blob, and not as a separate file that the scanning solution could read.  And as strange as it might seem, yes we were the first project where web-based file uploading was a thing.

Without doubt, this scenario is of architectural significance.

For a start, what’s going to happen if we are unable to scan the embedded files?  Will functionality be disabled, affecting users?  Or will the entire solution scrapped for one that can? (not likely after >18 months work & associated costs).

Can we get dispensation to just not apply anti-virus scanning?  If so, the architect will be leading those discussions from the projects point of view, probably taking it to the relevant design authority, and documenting the decision(s).

In scenarios like this there’s often no immediately obvious “slam-dunk” technical solution, instead there’s probably going to be a number of technical solutions – all with trade-offs and implications that need to be considered (i.e. “it depends”).

There’s also the non-technical / “business” angle to consider.  If the business/client/users are happy to change the way they do things this can open up new technical solutions, or make existing ones more viable.  Remember that bending the business to meet technology half-way is not always a bad thing, the more aligned the two are the better the end result usually is.

To briefly expand on the technical options, in this case we could change the way the COTS package works and obtain a new module for the existing anti-virus solution so that it can be called by the COTS API.  But even then there’s still a raft of technical options and detail to work through (starting with a proof-of-concept would be wise), and not forgetting we’d also need to convince the COTS vendor that they should change their product and the client that they need (and pay for) this new component.

In situations like this “architecturally significant” takes on new meaning as we’re now impacting the wider organisational architecture – not just the projects.  This is not a totally uncommon thing to happen – in larger organisations change affecting the wider organisation can come from within individual projects, as they are often the ones driving new needs and capabilities.

So to close

1. Constantly be on the look-out for the things that matter.
2. Focus your time and effort accordingly.
3. Keep a watching-brief on things which seem innocent now but could be significant later or if circumstances change.

 

Footnotes:

1. An SQA is a way of describing, defining and thinking about a solution.  Examples of SQA’s include performance, security, maintainability and so on (aka the “illities”).  SQA’s are not NFR’s, just as “Performance” is not a NFR on it’s own: an NFR is testable.  SQA’s are the basis for NFR’s – but they aren’t the same thing.
2. If you said ‘no’, you’re wrong, if fact if you said ‘yes’ you’re also wrong.  Based on that much information (i.e. no where near enough) the correct response is something along the lines of “it depends”.  Once you learn to prefix any response to any question with “it depends” you are half-way to being an architect (yes that’s only partially serious).  Whether the rest of your subsequent response is actually helpful or not remains to be seen.

Career Progression into Architecture

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:

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:

1. Enterprise Architects – who typically operate at the highest level of architectural abstraction and across a broad range of domains.
2. 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.
3. 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.