Sober Counsel

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 conflicting Features.  I won’t place the matrix here as that has been done on the sites listed above.  (These 39 Features have yet to be translated into Software System analogs.  Has anyone done this yet, or does anyone know of a Software version of the list of Features anywhere?)

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.triz-journal.com/archives/2001/09/e/index.htm.

I believe that this approach is focused too much on software engineering and is not that clear when a solution architect or systems designer needs to apply these principles i.e. some of these analogs get into coding algorithms instead of modular design.

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.

I’m still working on translating the 39 Features.

Good luck.  Have fun.  Any comments welcome.

Tags:   Engineering · Solutions Design · TRIZ2 Comments

Have a look at this video clip before we get into the concept of understanding performance.

Video clip:

Fiat Bravo vs. Ferrari 550 Maranello vs. Ferrari F1

The three cars in this video are clearly very different. For a formula one car the objective is easy to define. “Get around the track as fast as possible while meeting all FIA regulations and maintaining appropriate (two race) reliability of every component.”

For a Ferraro F550 it is a little more difficult to define. Probably somerhing like “Meet super-luxury standards and reliability for a road going sports car while offering super-car performance at a super-car price-point.”

For the fiat it is more likely “provide basic mass producable budget transportation”

Based on their specific goals it is obvious that we would define performance slightly differently.

For the F1 car it is about winning the constructors championship. For the GT car it is being recognized as the best luxury sports car. For the fiat it is about sales and market share in the budget category.

The point is that for three products produced by the same organisation the goals are completely different and the performance goals are consequently completely different as well.

The key is understanding your goals, understanding how you could measure success, and then target optimizing those metrics.

My view is that architecting for performance starts here. It isn’t a one- time thing either. This is why monitoring is key.

Tags:   Improvement · Monitoring · performanceNo Comments.

I will be speaking at an Enterprise IT Architecture Conference on the 28th and 29th of July 2008.

Attached are my Presentation Notes that I will talk to on the topic of Architecting for Performance and IT Asset Management

Asset-management-practices

Performance

The videos used in the Performance Presentation are:

Fiat vs Ferrari F550 vs Ferrari F1

F1 Safety Focus – Telemetry

Alonso in McLaren vs 3 Mercedes

Tags:   f1 · IT Asset Management · Monitoring · performance · Systems ManagementNo Comments.

At IBM’s headquarters, a contribution to cost saving is to shut down the catering services in all but one building from Friday mornings.

This means that someone wanting a cup of coffee would have to walk 10 minutes to the central building in order to get a cup of coffee.

So a 20m break for each cup of coffee.  Now a few techies I know have up to 8 cups of coffee in a day.  Some software developers seem to be entirely fueled by coffee.  How will this end?  Are developers no longer being fueled by coffee?  Or is this just a mistake?

Tags: No Comments.

A lot has been written about how one might make use of WEB 2.0 and social software in a corporate. It seems that some large consulting firms and IT companies have been trying this out for a while.

IBM have had their “Sametime” product for a while, and also Lotus “Connections” which is a social-networking and collaboration suite.

There are a few others aimed specifically at corporates, where one can purchase the software and host it internally and I intend to try a few of these (Including Lotus Connections) over the next few weeks.

ClearSpace is not very well known in South Africa and in fact I had never heard of Jive Software until I found their site a few weeks ago.  They are based in Portland, Oregon, and boast over 2000 customers and a coverage of 15% of the Fortune 500 Companies.

The ClearSpace 2.0 and ClearSpace Community Products are written in Java and require Java 6.

A while back I mentioned some of the potential I saw in Facebook for the Corporate.  I wasn’t saying open Facebook to corporates to use, nor that an exact replica of Facebook would be ideal in a large corporate.  What I was saying was that some of the social concepts that work for Facebook, would be very powerful when applied to corporate problems.

For example, I work on a number of projects at any given time, I have several documents in draft and pending review, I consult on various topics and sit on a number of governance and IT committees.  Keeping track of activities and actions across all of those can be an onerous administrative task and requires discipline on my part.  As a “creative” thinker, administration and discipline are not my strong points.  If projects and forums and communities-of-practice had things like facebook groups where all their documents and discussions and actions were tracked, I could simply login to MY personal page and instantly see the latest activities across all of the areas I am involved with.  That would be freedom.  I would also no longer have any excuse to say “I didn’t know” about some decision or event or outstanding action.  

Enter ClearSpace.  This is exactly what I described above.  The concept around which ClearSpace revovles is the “community”, not a document or post.  For example a document sharing site revolves around “documents”.  A Wiki revolves around the “pages” or “entries”.  A Blog revolves around the “posts”.  ClearSpace revolves around the community. Communities may exist because of Strategies, Projects, Topics of interest, anything that warrants creating a new area of focus.  One can even create hierarchies of communities and the Parent Levels can aggregate the updates and feeds of their children.  Within these communities individuals can post Blog entries, write documents, poll other users for opinions, ask questions, create discussion forums and many more.   Almost all of these allow others to respond or comment.  The major contributions can all be scored.

In addition to community blogs, individuals may also have blogs.  individuals are attributed with the scores for their contributions.  Individuals become “experts” on the topics they contribute on most, and are considered better experts when the ratings of their contributions are higher.  

Everything in the system is based on a widget concept, so if you need a new content-type for a particular community, write the widget for it, and snap it into the framework.

This is the first Corporate-community-based collaboration software that I have tried, and I am truly impressed.  

If you need to get people in your organisation to work together and you need a software solution to enable that, then ClearSpace is definitely one to consider.

Ease of Use: 9/10
Super easy, and a really great looking interface. 

Installation / Setup: 9/10
I used the embedded database to test with, so little setup was required.

Admin Pages:7/10
Lots of menus and submenus, and I couldn’t always find the setting I wanted without browsing through a number of the admin pages.

Engagement: 9/10
This pulled me in.  I loved using it, not least of all because of how good it looks and how intuitive the user interface is.

Tags:   ClearSpace · Collaboration · Community · Corporate · Jive Software · Social SoftwareNo Comments.