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 🙂

Advertisement

Try This: Everyone Draw The Architecture – A Retrospective

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

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

Luke’s idea is pretty simple:

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

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

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

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

It all sounds great, what could go wrong?

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

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

[Gulp].

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

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

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

Retro – What Did I Learn?

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

What Worked Well:

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

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

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

Challenges

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

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

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

What Could Have Gone Better If:

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

Final Observations

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

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

Would I do it again?

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

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

Postscript

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

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

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