What can Software Modellers learn from Innovation Methodologies?

Motivation

Recently I came across this HBR (Harvard Business Review) article A Taxonomy of Innovation on the Luma institute design methodology. It contains three categories of techniques to help innovators develop products and services: Looking, Understanding, and Making.  From my viewpoint as a modelling theorist especially the ‘Understanding’ part seemed quite similar to  what software modelling for the sake of understanding (e.g. as in requirements analysis) is about.

Subsequently, I take a closer look at the techniques that this methodology provides for gaining a better ‘Understanding’ of what users want. It is hoped to gain inspiration and ideas for software modelling (esp. modelling of requirements).  The innovation methodology comes with assistance and description of collaboration, notation, and the logical structure for each of the single techniques. As a modeller I focus mainly on the structural aspects.

Summary

Some techniques like Persona Profile or Importance/ Difficulty Matrix are quite generic and are already successfully in use in software modelling and/or engineering. However, others like Affinity Clustering or Concept Mapping strongly underestimate the structural aspect. They are not aware that structures grow over 1-sheet size, have dependencies, or change during the project.  The techniques simply do not deliver the promise to  scale with ‘the complexity of the systems in which you operate’.

Overall, there is nothing to learn for software modellers concerning structures. However, for collaborative aspects one or the other detail might be worth considering. This is not surprising, since the Luma methodology is almost solely focused on notation and collaboration, whereas software modelling is mainly focused on structure.

However, vice versa, innovation methodologies, like the one considered here, could strongly benefit from the structural thinking in software modelling. This would make them able to scale large and complex structures and handle their changes over the product life-cycle.  In other words, making the step from sketching to modelling.

Why are results from software modelling not considered by other disciplines?  Why does no one come around asking software people for help on structural issues? Are software people mainly seen as technology guys, due to the public unawareness that informatics/ computing is a structural science?

Techniques

Part I: Patterns & Priorities
Part II: People & Systems
Part III: Problem Framing
More detailed descriptions of the single techniques can be found in the article

Part I: Patterns & Priorities

Affinity Clustering

Affinity Clustering‘A graphic technique for sorting items according to similarity.’

As we know from modelling theory (see here) we can structure things basically by their attributes, internal or external relationships or any combination of it. Here, it remains unclear which way is intended. So you are likely to end up wondering where to put the engine:  as part of a car or in the group of engines. In other words, sorting things is more complex, than just putting things into buckets.

 Bull’s Eye Diagramming

 ‘A way of ranking items in order of importance using a target diagram.’

We all know what happens when we ask a customer for a prioritization:
Everything is prio A. There are several ideas to address this, however none can be found here.

Importance/ Difficulty Matrix

Importance Difficulty Matrix‘A quad chart by placing items by relative importance and difficulty.’

In software engineering this is the basic chart for any testing strategy. However, since testing moves more and more towards the early stages of the software process, starting a 2-dimenisnal ABC analysis of this kind already during requirements analysis is certainly no bad idea.

Visualize the Vote

‘A quick poll of collaborators to reveal preferences and opinions.’

Analytically this is about creating views and understanding viewpoints. This always should be approached in two ways: collaboratively, by involving people, and structurally, by systematically creating perspectives on the subject matter (typically in software engineering these involve user, architectural, management perspectives etc). Unfortunately, this method here omits the structural way completely. Typically, this leads to underrepresentation of stakeholders not directly involved in the development process, like users or operators.

Part II: People and Systems

Concept Mapping

Concept Mapping‘A way of depicting the relationships between various concepts in a given topic area.’

Entities with relationships – great idea! :o)
However, as we know from modelling theory, when the number of entities increases some methods for structuring, like modules or generalisation can become very helpful.

 Experience Diagramming

Experience Diagramming‘A way of mapping a person’s journey through a set of circumstances or tasks.’

This can be done for example on classifier level, as use case, or on instance level, as test case. However, when you have a lot of them, the question of keeping them consistent remains unaddressed.  see here

Persona Profile

‘An informed summary of the mindset, needs, and goals typically held by key stakeholders.’

In software development techniques like this come in on the needs level (to understand where the requirements ‘come from’). This can be very useful, especially in consumer software development.

Stakeholder Mapping

‘A way of diagramming the network of people who have a stake in a given system.’

Also in software development, a very useful thing to do, for people having a stake in the final product as well as in its development process.

Part III: Problem Framing

Abstraction Laddering

Abstraction Laddering‘A way of reconsidering a problem statement by broadening or narrowing its focus.’

Asking for the why and how of requirements is a familiar technique in software engineering, for example by modelling business processes or prototyping.

Problem Tree Analysis

‘A way of exploring the causes and effects of a particular issue.’

In software, functionality maps effects to causes (plainly, input to output), and thus software modelling knows a variety of techniques of structuring like classes, components, and interfaces.

Rose, Thorn, Bud

‘A technique for identifying things as positive, negative, or having potential.’

A pretty generic technique. Like with the ‘Visualize the Vote’ technique, it is just collaboration based, no structural support offered.

Statement Starters

Statement Starters‘An approach to phrasing problem statements that invites broad exploration.’

This is a bit like textual entity relationship modelling. Of course you can write down ‘Person drives Car’, but how do you keep the overview of a larger amount of sentences if not by modelling? This makes it more an elicitation than a modelling technique (similar to user stories).

So long
|=

About modelpractice

Modeling Theory and Abstraction Awareness in the gap btw rigour of science and relevance to engineering.
This entry was posted in Abstract Thinking, Model Thinking, Software_Engineering and tagged , , , , , , , , , , , , . Bookmark the permalink.

2 Responses to What can Software Modellers learn from Innovation Methodologies?

  1. Great post Jean. Here is my humble vision of why people are using such methodologies.
    The objectives of these methodologies are to make people think out of the box, not to define the final precise specifications. Here you should imagine different people from different business areas (sometimes clients of your products) in a white room, trying to “design” and re-think a product, a service. Then they have to agree and converge on solutions.
    Using structural languages is seen as too constraining at this stage of the process. It does not mean that in the background somebody could do structural description of the problems (that’s where you need to have the right persons animating and supportingthe work done).
    But First, innovation will concentrate on WHAT’s the problem and what could be done to solve it in business terms!
    You are also right in the fact that IT or engineering people use their own description languages and tools. Some companies still provide business analysis in word documents and ask their IT people to create everything from them. Since each camp speak a different language, we all know the results.
    Even agile methodologies do the same with user stories … The main issue being that sometimes, you do not see the system as a whole.

    • Hi William

      Thanks very much for your comment. Yes, I think, out of the box thinking indeed is a main (and only?) target of these techniques, and the many different people in a room situation is the classic setting. Especially the convergence you mentioned is a quite big issue.

      I cannot speak for all industries, but in my kind of environment – business software in the investment goods sector (no consumer stuff) – the main contribution of modelling in situations like these is, roughly speaking, understanding through simplification (helping people to abstract). Here, the reduced expressiveness of models simply force the different people in the room to bring things to the point – no marketing lingo, no tech glyphs – just essence. This also supports convergence of opinions and concepts, and separates the what from the how and the why, and the light bulb moments happen :o)

      Thus, in this kind of projects I would highly recommend an early use of advanced modelling techniques. However, I cannot say how this experience applies especially to non-software businesses, since I think this discrete kind of complexity that software modelling techniques are addressing might be a quite software typical thing (?)

      Have a nice weekend!
      |=

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s