TRIZ, but those Russians are clever!

A while back I came across a concept called TRIZ.  Concepts and techniques that are used in non-English speaking countries sometimes do not get translated quickly into use in our insular English worldview.

Triz is a Russian Engineering tool that has been used for some time.  It is apparently a definitive list of design trade-offs that should be considered in any engineering design.  It Consists of 39 Features of any solution and 40 Principles that may be applied to address trade-offs of those Features.

see: http://www.triz-journal.com/

and

http://www.innovation-triz.com/

So the 39 Features are placed on both the X and Y axes of a matrix and when you need to optimize one of them you will find the list of principles (from the 40 possible principles) to apply, at the intersection point of the potentially contradictory Features.  Typically the method is to place the features you intend to improve as rows in the matrix, and the features you anticpate worsening as columns in the matrix, and then finding the principles to apply at the relevant intersections that you hope to manage.   I won’t place the matrix here as that has been done on the sites listed above.  (These 39 Features have been variously and severally translated into Software System analogs, but I haven’t seen a version I agree with fully yet.)

Some proponents of TRIZ found that in software system design these engineering and innovation principles can be applied by simply shifting the terminology from engineering terms to Systems Terms.  The 40 Principles of TRIZ for software are listed here: http://www.triz40.com/aff_Principles_TRIZ.php

I hope to help clarify when a solution architect or systems designer needs to apply these principles.  I have created a slant on these 40 principles that may be more useful to a solutions architect by abstracting some of the principles slightly (others are left intact as per the TRIZforSoftware site).  (Note: this list now includes suggested changes as per Dr Claude Meylan’s comment) :

1. Segmentation – Selecting an appropriate degree of Segmentation.  Some problems require a Unique approach to segmentation.
2. Interference – Will this affect other Systems or will other Systems interfere with this system
3. Local Quality – Will we have to make special exceptions to our standards to improve the quality of the solution for this specific instance?
4. Load Balancing / Resource Utilization – Is the design making optimal use of resources as well as appropriate use of load balancing/ parallel processing
5. Consolidation – Sometimes it is appropriate to perform multiple functions in a single module or sometimes processes are so similar it would make sense to consolidate them
6. Universality (mulitfunction or Personalisation) – It may be appropriate to build a module or system in a way that it can be personalized or that it can serve multiple purposes.
7. Nesting (classes within classes) – Nesting of Classes can add to reuse
8. Multi-Context (reuse within multiple contexts) – sometimes a system or module built for another purpose is actually reusable within a different context altogether
9. Pre-Processing
10. Just in Time action without lag – is every module aware of when it can start processing to avoid slack or unnecessary load.
11. Pre-compensation for reliability problems – what periodic procedures can ensure a greater degree of reliability or stability.
12. Equipotentiality – Various modules within a system must be equally scaled
13. Ability to Rollback – The system must be able to rollback transactions that cannot be fully processed.
14. Abstract / complex Data structures – Does the system really require the flexibility of Abstract data-structures or will straightforward design suffice.  Is it futureproof without these?  Will it be replaced anyway?
15. Optimal Operating Conditions –
16. What if the system fails half-way or does too much – Will it be possible to interrogate the system / data-artefacts and determine what happened / how to fix it – or is the system intelligent enough to roll back/forward to a valid state.
17. Affecting other Systems, Data or layers
18. Rate of Operation – How fast does the system need to operate?  What is the potential future requirement.
19. Scheduling – When will the system need to run?  Is Self-Scheduling part of the design?
20. Idle Time – optimal load – Is the system Idle for stretches of time and then overloaded for others?
21. Burst mode / peak load – how will the system cope with peaks in load?
22. Convert harm into benefit  – Is there some inherent problem in the process that we can use to our benefit or at least be alerted of should the event occur.
23. Feedback – How much Feedback does the system need to give? Too much will slow it down, too little will leave operators wondering if it is functioning properly.
24. Intermediary Layers : middleware – Required?  What about SOA?
25. Self-servicing (built in updating / alerting) – Does the system automatically raise alerts or check for a newer version of itself or at least submit traps to a monitoring system.
26. Copying – how easy to deploy elsewhere?
27. Disposal – will it be easy to replace or dispose of? Is the data migrateable and is the level of loose-coupling appropriate so that other systems feeding off it can be converted to talk to the replacement system easily.
28. Alternatives to this process (What if we did the whole process another way?)
29. DMA or Meta-Data structures – Are there parameters in the system that will restrict us going forward that we could address by a dynamic design.
30. Wrapper Objects – Are there existing objects we could wrap to use in the project, or will the new ones be more widely usable with some for of wrapper.
31. Required to be less than optimal – e.g. chess: beginner levels.  See Equipotentiality – a system feeding another system may need to operate less-than-optimally.
32. User Interface appearance & usability
33. Homogeneity – Container Objects – Is it all implemented “The way we do it”
34. Code self-healing / intelligence & Garbage Collection – Are appropriate clean-up processes designed-in?
35. Transformation properties – Multi-role objects – Some objects may be reusable
36. Phase transition – unexpected behaviour
37. Storage or Memory utilisation during operational cycles
38. Encryption – required?  Appropriate level.
39. Not affecting the live environment during testing – Test Harness
40. Use mulitple methods to attack the bigger problem

(adapted from TRIZ for Software: 40 engineering principles.)

This may be a useful checklist for a solution architect to check their design and optimise the proposed solution.

My translation of the 39 features of Triz are listed here: http://www.sobercounsel.com/2015/02/25/39-triz-features-long-overdue/ ?

Good luck.  Have fun.  Any comments welcome.