Real World Machine Learning with Susie Sheldrick #APIDAYSAU

I’m at the API Days conference, and one of the first sessions of note was Deep Learning: Real World Applications with Susie Sheldrick, which explored some of the practical real-world challenges related machine learning, based on experience.  I also caught up with her after the session where we expanded on some of curlier questions.

Quick Context: 30 Second Intro to Machine Learning

Susie kicked off with a simple diagram that sums up what machine learning is in comparison to traditional applications:

DeepLearningSusanSheldrick

Machine learning partially turns this model on its head: the solution is able to “learn” its own rules (through training its internal rules model) at much greater scale than some person/team coding them by hand.  So, rather than feeding data and manually created rules into an solution, simply train the solution to produce its own rules.

The Chaser

This nice intro kicked off a mental train of thought for me: in practice the more complete solution probably looks something like this:

DeepLearningAdrianKearns

The end goal is still to build an solution that provides the answers users were seeking, we’re simply using machine learning to help out with the rules.

Devil in the Detail

That all sounds wonderful on paper – or in ivory-tower pixels – but, as should be no surprise, the real world is not so straightforward.

Of critical importance:

  • Understanding the problem you’re trying to solve.
  • Gathering the right data to train the model.

This is much easier said than done, it transpires that:

  • It’s all too easy to inadvertently train bias into the rules model.
  • Tracing exactly how the AI made a specific decision actually turns out to be really hard.

Whilst the second point has obvious implications for developers and testers, both points combined have massive implications for your legal teams, anyone who considers themselves ethical (like you, right?), product owners and anyone at the receiving end of a machine determined decision.

Bias

Susie gave some examples of unexpected and undesirable bias ending up in rule models, such as one experiment that determined prisoners eligibility for parole.  It turns out that the model significantly favored granting parole to white prisoners and was relatively much less favourable to prisoners of colour.   In contrast, in terms of parolees reoffending – the actual results were the exact opposite of the bias.

It turns out that the information used to train the model was “correct” but only in the sense that it faithfully transposed the bias already inherent in the legal system, against people of colour.

True Representation

A related issue isn’t so much of bias in the data, but of bias stemming from an absence of data.  Once more issues of race come to the fore; this time it was a passport application solution that told an Asian gentleman his submitted photo “did not meet our standards” because he was “asleep”.  As you might be able to guess, the model had obviously not been sufficiently trained with data that faithfully represented the entire user base, and therefore could not correctly handle non-european facial features.

Just to be crystal clear, the technology is more than capable of correctly handling a wide range of cases, nuances and subtlety – including racially based facial features.  The actual issue is the correct training of the model – meaning it’s critical to gather the right data, data that covers the entire spectrum of cases.  Not to mention testing and monitoring the behaviour of the solution.

Building an AI Solution: Custom or OOTB?

If you’re about to embark on a project that involves machine learning, one of the practical questions you’ll come up against is whether or not you can use an Out-Of-The-Box (OOTB) solution, or need to custom build something.  Susie’s discussion here was mostly in reference to the rule models specifically.  If you want a model capable of identifying cats in pictures online for you meme generator – you’re in luck, but if you need to correctly identify something more obscure, or more specific, you may have to build this model yourself.  Which is why the stuff above about bias is so important, because you’re going to have to navigate that minefield yourself.

Further Questions

Our chat after the session was very stimulating; a couple of the more curly questions that our conversation provoked were:

How to identify, and test for, unexpected bias?

The obvious ethical reaction to all of this is “great, let’s ensure we keep unwanted bias out of the model and our solution”.  What is much less obvious is how to do that.

Were the team behind the parole example conscious of the bias in that solution?  Let us assume they weren’t aware of it – in such a situation how would they (or you) identify that bias, and in addition, having established an operational solution how would you ensure none was introduced?

This is where, for me, machine learning is like a lens that amplifies human behaviours and bias.  It has the potential to help expose them, but how clearly, how soon, and at what cost?

How will your model react in the event of change over time?  I.e. if there is a fundamental shift in the (data) foundations on which the model was originally conceived and trained?

For example, Google is looking at moving back into the Chinese market, despite pulling out some years ago due to human rights concerns.  Hypothetical example: let’s assume that they have machine learning models built up, based on the data they currently have access to – i.e. does not include China’s current population of 1.3 billion.

What would happen if 1.3 billion Chinese people suddenly have access to a Google solution that is backed by a rules model that was not trained with them in mind?  Sure, Google’s data should be a fair representation of their current global user base, which will include Chinese – but wouldn’t adding 1.3 billion people potentially shift the model?  How will it react?  Will the responses it provides be biased against the new user population because hitherto they were not expected by the model?  Will the model be able to adapt over time, and if so how long will that be?

 

Please note that this post is based on rapidly scrawled notes in session and my recollection of subsequent discussions – my accuracy should be reasonable but may not be perfect.

References:

Advertisements

Customer Inspired; Technology Enabled – Product Tank Wellington MeetUp with Marty Cagan

The Product Tank Wellington meetup ran a really cool session recently called “Customer Inspired; Technology Enabled” with internationally recognised product guru Marty Cagan.

As you can imagine, someone of Marty’s calibre provides a lot of great wisdom.  Some reinforced or reinvigorated stuff I think I already knew, but much was also new.

Here are my old-school hand-scribbled notes (2 pages) if you’re interested (or neglected to take your own, tsk tsk): Customer Inspired, Technology Enabled with Marty Cagan – 12-Feb-2018 – Adrians notes

Note to anyone doing architecture: broadly speaking, anywhere it says “product” I think we can swap with “solution”.  Which is why I’ve tagged this #ArchitectureInTransformation – architects need to (at least) be mindful of this stuff.

Also, in this context  when we talk about “product” we mean a technical product of some kind (i.e. software/technology related) – not something like floor polish or mint scented vacuum bags.

Key Takeaways and Gems

Asking customers what they want

If you’re looking for where to take your product, the short answer is “don’t”.  Instead, invest your time in asking customers about their problems.

You should not rely on customers to tell you about which direction to take your product, or what new features or capabilities to add, because:

  1. They don’t know what’s possible – they generally aren’t technologists. (The clever technologists should be the people on your team).
  2. Great (new) ideas have to be discovered.  For me personally, Marty was making a strong connection to empiricism – in that you can’t rationalize your way to a “new” idea.

The way to flip the question is to be to ask your customers about things that they do know about: their problem, their constraints.

Another reason why you can’t reliably ask customers what they want is because they themselves don’t actually know what they want until after they’ve seen it.

Engineers

Marty spoke repeatedly and at length about the importance of involving engineers in the product process.  He cited several cases where new successful products had emerged from the techies – essentially from random ideas they had on the fringes of a project, where their inventiveness (based on their deep understanding of the technology) led to something entirely new.

He suggested giving developers time for discovery – something in the ballpark of half an hour a day.

Overall his message was clear:

  1. Work with strong engineers that are passionate about your vision.
  2. Do not shelter them – expose them to the full business context; expose them to customers.
  3. Provide them with constraints, not requirements.

Requirements First?

Speaking of requirements (whilst talking about agile) he neatly flipped the old Analyse > Design > Build model around:

  1. Knowledge of the technology…
  2. > enables design…
  3. > drives desires/needs/requirements

Essentially this comes back to the same point posed by “asking customers what they want” – if customers don’t know what is possible then the requirements will always fail to get the most out of what the technology is capable of.

Are you Agile?  Really.

I had to laugh – Marty’s position on Agile was that it’s a no brainer, like why are people even asking this question.  And it wasn’t just the words that gave me a wry grin, it was also his tone: dry, cuttingly sardonic, with a hint of tactful incredulity and thinly veiled loathing.

Point is, there’s a difference between thinking you’re agile and being agile.  Try these two refreshingly straightforward questions:

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

The correct answer to #1 is that if testing is done at the end, it’s too late; if you’re agile you’re testing as early as possible and not just at the end.  If you only test at the end, then that’s where you are putting all the risk.

#2 Is a really key one; it’s about the difference between releasing something and solving a problem.  The common misconception is that when you’ve put out a release, you’re done; but whilst getting stuff delivered is great, you’re only actually “finished” if you’ve solved the problem you set out to solve.  Shipping out a release merely gives you an opportunity to see if you’ve really solved it.

So, if you iterate – great; iterate, test and keep shipping until your target problem is solved.

Roadmaps

Much of Marty’s talk sounded like heresy… in that it would certainly sound blasphemous to many people I can think of.  His discussion on product roadmaps was no exception.

Roadmaps tend to assume that 100% of the ideas on them are good ideas.

The reality is somewhat different.  Marty cited Google: in their experience, for every 10 ideas they have (on a roadmap) only 1 tends to pan out.

Bad use of roadmaps relate back to the second point in “are you agile?” – in that people sometimes confuse delivery with completion.  People walk around with roadmaps and release schedules and focusing on getting stuff delivered.

So if that’s all wrong, what does right look like?

Essentially it comes back to having a strong product vision.

My notes on this part of the talk are scarce – a sign that I was either too deeply engrossed to write, or I agreed with what he said and felt no need to note the obvious.

In either case, the key takeaway for roadmaps takes heavily from the points above: focusing on the product vision – which I think we can safely extrapolate to:

  1. Understanding the customer and their problem.
  2. Giving your teams constraints and time to come-up with the unexpected.
  3. Iterating until solved, not just shipped.

Roadmaps and Agile

From a philosophical perspective, roadmaps are rational – they plan out what is to happen; whereas agile is empirical – it learns from what has happened.

Roadmaps attempt to answer the fundamental questions: how much will it cost, and when will we get it?  And as Marty acknowledges – that’s not an unreasonable thing to want to know.

Agile can answer these questions but only once you’ve done enough work, to provide enough meaningful experience, on which to base a forecast.  Marty elaborated on that theme in terms of a “high-integrity commitment”.  I don’t have any notes on that so allow me to refer you to Marty’s blog:

Teams

  • Measure teams as a whole; not in terms of “functional” teams, but product (solution) teams.  (What does this mean?  Think about the difference between “shipping” and “solving” and you’re pretty much there).
  • Provide teams with a competent and confident product manager.

Product Managers

The final subject I want to cover is around product managers – specifically good ones; it’s important to me because it’s highly relevant to what I see as a architect in solution-architect / domain-architect / enterprise-architect / consultant space.

Marty placed a lot of emphasis on the importance of having a good product manager.  For him the product manager is like the “CEO of the product”, where CEO refers to the calibre of the person in that role, and because good CEO’s know all the elements of their business.

Product managers need to be smart, creative and persistent.

The product manager should must have a deep understanding of:

  1. The customer(s).
  2. Industry trends.
  3. How your business works.

The reason you want a good product manager is because this is type of invaluable knowledge and wisdom they’ll bring to your team, and to your product.

How to Introduce Yourself as an IT Architect

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:

  1. Create visions
  2. Craft decisions
  3. Technical leadership
  4. 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

  1. Pick one thing that you do (i.e. one of the four above if you’re stumped).
  2. 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.

 

 

 

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.

15-09-2017+5-08+PM+Office+Lens+(1)

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.

wasf - trends

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 🙂

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:

Try This Draw The Architecture

Try This Draw The Architecture - brief

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).

30-08-2017+7-35+PM+Office+Lens_30-08-2017+7-36+PM+Office+Lens 1_30-08-2017+7-36+PM+Office+Lens_30-08-2017+7-37+PM+Office+Lens 1_30-08-2017+7-37+PM+Office+Lens 2_30-08-2017+7-37+PM+Office+Lens_

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.

 

 

3 Ideas from Nick Malik on Design Thinking (#ITEA 2017)

Following the 2017 ITEA conference, I recently reiterated what many of us have known for a while: that traditional architecture and architects are endangered.  I also promised to share some of the great ideas from that conference – practical concepts that you can use right now, and which started to demonstrate how architects can still be relevant and add value.

I’d like to start with ideas from a really valuable talk given by Nick Malik, a 37 year industry veteran who describes himself as a “Vanguard Enterprise Architect, Digital Transformation Strategist, Author, Blogger, and General Troublemaker”, currently Senior “Principal Consultant – Enterprise Architecture” with Infosys.

The subject of Nick’s talk was “Using Design Thinking to Develop your Enterprise Architecture Core Diagram“.  In this post I’ll briefly introduce this key concept as well as some of the other ideas that I wrote down during Nicks talk.

#1 – Actually Understand the problem

The first thing I wrote down was incredibly obvious and shouldn’t need reiteration: taking sufficient time to actually understand the problem.  Nick emphasised bringing people into this process – actually talking to people to really understand what they need, so that we “build solutions that people want to use”.

The quote that came to mind during this bit of the presentation was Eisenhower’s “Plans are nothing, planning is everything.”  Why did I think that?  Well, some people will equate “understanding the problem” with analysis and documentation, where the scale of the analysis and documentation corresponds to the perceived scale and complexity of the problem.

But that’s not what was meant – it’s more around the quality of the discussion, and ensuring that there is real understanding of what the problem is, and what is needed.

In my view, the challenge here for some people (and architects) is that doing this well requires quality interpersonal engagement.  I wonder how often we end-up with solutions that are system-centric rather than people-centric?  I suspect it’s partly due to that fact that some of this stuff is hard – it’s easy to let the technology control you.  But I also think there’s another aspect to it – that some people who are good with systems & tech aren’t always as confident with people, and so the people-centric part loses out.

Interestingly, the design thinking page on wikipedia contrasts design thinking with the scientific method; whilst both approaches use iteration, design thinking consciously “considers the consumer’s emotional state”.  Having quality discussions with people doesn’t necessarily equate to discussing emotional state, but even so, I think that the organic relationship between these concepts is apparent, as is their relevance to arriving at better and more holistic solutions.

So, focus more on having quality engagement with people and taking the time to understand.

#2 – The Core Diagram and Design Thinking

The heart of Nick’s talk was the Core Diagram, and using Design Thinking as a way to developing it.  The crucial idea I took from this was connecting the existing and accepted (although possibly under-utilized) architectural concept (the core diagram) with the “modern” technique (design thinking) which has become somewhat hijacked by a market that is “going digital”.

I say “modern” with the slightly sarcastic quote marks because the roots of design thinking actually go back a long way before it became vogue in the current “digital” era. That said, “digital” is relevant to architects because it’s the current language of business, and those not conversant in it risk being marginalised, regardless of what people think digital means.

Before I go too much further I just want to point out that I am new to the concept of the core diagram – at least regarding the specifics of the concept as Nick describes it.  My goal here is simply to help spread the word on this as a idea, because I think it has value.

Nick has been writing about core diagrams for some time (circa 2012), and I wonder how much the approach to developing them have changed?  I haven’t yet properly read and digested the original approach, but it’s now 2017 and Nick is connecting the development of core diagrams with design thinking – I’m not sure whether this represents a fundamental shift in the approach, or a natural evolution that recognizes shared principles that were always inherently there.

The reason I mention this is that if you go searching online you’re going to find articles from a few years ago (c’mon, 2012 isn’t that long ago) , and you might (incorrectly) feel compelled to dismiss them out-of-hand as not being contemporary and not solidly connected to “design thinking” as is currently vogue.

So, what’s a core diagram?

As with a lot of good ideas the key concept is relatively simple, according to Jeanne Ross (Director, MIT CISR):

“For most companies, I think some kind of picture is essential for understanding the expectations for a business transformation.”

The bold is mine.  Nick included this quote in his deck – having taken it from an email Jeanne sent him in 2011.  Nick described it as “the best advice we all ignored”.

Actually Nick, I think I might have a tongue-in-cheek explanation for that – there’s currently no wikipedia page for Core Diagram 😛

Jeanne describes it as:

“a simple one-page view of the processes, data, and technologies constituting the desired foundation for execution.”

One-page is key.  What you’re after is something that everyone wants to put up on the wall, in their office or the teams shared space.  You want it to support a wide range of discussions and thinking across all your stakeholders – especially those who are responsible for, or have a lot of influence over, the end result.

Here’s some links for you:

  • Enterprise Architecture As Strategy” by Jeanne W. Ross, Peter Weill and David Robertson, on Amazon.
  • What is a core diagram?” MSDN blog post by Nick Malik, 2012.
  • (Slides from) Open Group Presentation on MSBI method of creating Enterprise Architecture Core Diagrams on slideShare, 2012.

A Brief aside info Marketecture

As Nick was describing the core diagram I couldn’t help but mentally connect it with Marketecture and effective marketecture diagrams.  In Nick’s view they aren’t the same thing, and I can see why he says that – but it’s subtle, multi-dimensional, and I’m still thinking about it.

I’ve previously found a number of useful definitions that help capture what I think marketecture is (which I sketch out in “Appendix: The Mysteries of Marketecture” in this post).  In summary it’s:

a business perspective, including concepts such as licensing, the business model and technical details relevant to the customer; it can also serve as an informal depiction of the systems structure, interactions and relationships that espouse the philosophy behind the architecture.

We had a very brief discussion whilst walking out at the break, Nick’s view was (and assuming my recall is accurate) that marketecture is designed to assist the “sale” of the solution, with the underlying implication that relates to the “transactional” nature of the sale; where as “you can take a core diagram to governance meetings”.

I guess it depends on what is meant by “sale” – there’s the commercial sense i.e. trying to sell faster processors to end users, but there’s also the idea of “selling” a solution as being viable to executives and governance bodies.  From a philosophical stand-point I think good marketecture and core diagrams have that in common.  There’s no doubt a lot more to explore here.

 

#3 – Ideation Techniques

Design thinking, and the concept of rapidly coming up with ideas deserves more time and space than I can give it here, so to get you started, let me just give you a couple of the ideas Nick shared:

  • Reverse Brainstorming – Instead of asking, “How do I prevent this problem?” ask, “How could I cause the problem?”  The idea is that by initially focusing more on the problem you’re then better equipped to start considering solutions.  It reminds me of the 37 Signals piece called “Have an Enemy”: “Sometimes the best way to know what your app should be is to know what it shouldn’t be. Figure out your app’s enemy and you’ll shine a light on where you need to go.
  • SCAMPER – an acronym of activity based thinking process which help you think out of the box: Substitute, Combine, and so on.  It’s been around since 1953.

 

#ArchitectureInTransformation

Is the Tide Turning? #ArchitectureInTransformation

Good news, I think, from the 2017 IT & Enterprise Architecture Conference, which I attended earlier this week.  As is well known, “Traditional” architecture, and Enterprise Architecture in general, has been on the endangered list for a while now – but I’m starting to see really positive signs that (some) architects are bouncing back and starting to successfully adapt.

In due course, I’ll share some of the many notes and great ideas I captured during the event, but before I do I just wanted to quickly preface the whole thing with this overarching theme (that architects are starting to adapt) – because it was a theme that permeated much of the conferences content – and from what I could see these ideas were generally being embraced by the attendees – but it’s still very early days…

So what are these magical signs?

#1 – Attitudes

It was clear from the architects I spoke with that they recognised the need to adapt, have a positive attitude about doing so, and are on that journey.

#2 – Platform as a Product

One of the clearest signals was from Mike Nooney, who shared with us how Air New Zealand are developing their platform strategy.  A key takeaway here was “platform as product”, in other words, start thinking about your organisations platform and systems as a product (and everything that mental-model entails).

Of course it’s a non-trivial exercise – there’s lots of deep and subtle implications in the statement.  I’ll be looking into this more (a lot more, I’m sure), but for now I suggest you start by thinking about what good products are and how they come into being – i.e. “it’s not just about technology”; thinking about the entire ecosystem: end-users, API-users, support, marketing (and so on); and how you’d actually work with the other human beings across that entire ecosystem to make it happen.

It’s worth noting that there’s a spectrum here; in some circumstances you might simply get away with (or start with) a simply terminology change: “(Digital) Platform” instead of “EA”, although obviously a deeper change is likely to be needed at some point.

#3 – Embracing ‘new’ techniques, such as Design Thinking

Design thinking is one of several approaches that have been gaining serious traction in recent years.  Sure, some of the core concepts inside some of these approaches are not necessarily new, but they’ve reached a level of maturity and market presence that means ignoring them isn’t wise.

There’s this fuzzy nexus of concepts – Digital is one, taking a (platform as) product centric view is another – think of it as the new/emerging paradigm for how the mainstream now conceptualises systems.  Design thinking, and related approaches, are a part of that paradigm.

The good news for architects is that, as mentioned above, the core stuff inside these approaches isn’t necessarily new – it’s stuff that as architects we kinda mentally do already, so the leap isn’t as big as it looks.

Positive evidence of architects taking this sort of approach on was visible in several presentations beyond Mike’s:

  1. Nick Malik emphasised the importance of gaining a deep understanding of the problem, and whilst he didn’t refer to design thinking directly I found it to be a pretty easy mental leap from his advice to leveraging design thinking as one of the ways of getting there.  Update – as per Nick’s comment below, design thinking was a focus of his talk – my memory here isn’t quite as accurate as I’d like it to be (thanks for correcting me).  I’ll share more on this in due course, including links to where you can get Nick’s thoughts first hand.
  2. Nick also made reference to several books including “Stories that Move Mountains: Storytelling and Visual Design for Persuasive Presentations” – and whilst this isn’t billed as “design thinking”, (as a newbie) I can see some parallels.
  3. Blair Loveday did a whole session on design thinking – the fact that this even happened is itself an indication of how things are moving in architecture circles.
  4. Chris Tuohy spoke about his experiences with Agile and culture change at Westpac – design thinking was explicitly called out as being part of their approach.

So whilst “traditional” architecture may be dying, I’d think the good bits from that legacy will continue – with some new additions and perhaps adapted a little in terms of tactics and approach.  When you realise that such a major transformation is slowly happening right before your very eyes, and that you’re part of it – that’s pretty cool.

#ITEA – https://www.conferenz.co.nz/events/it-enterprise-architecture