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