39 TRIZ Features – long overdue

TRIZ is an engineering concept created a long time ago in Russia.  It proposes that there are 39 main features to any system, and that these can sometimes be conflicting, like for example speed and reliability in a Formula 1 car.   The TRIZ matrix puts these features on the axes of a matrix, and list principles that can me applied to mitigate these apparent conflicts.

I have translated these Principles and Features into a Software systems analog to attempt to use the TRIZ matrix as a Software architecture tool.

The 40 Principles are listed here: triz-but-those-russians-are-clever/

The Features of a System are:

  1. Weight of moving object – Average Size of Message
  2. Weight of stationary object – Total size of Data Repository
  3. Length of moving object – Number of Fields per Message
  4. Length of stationary object – Number of Databases comprising System Data Repository
  5. Area of moving object – Size of Metadata contained in a Message
  6. Area of stationary object – Number of Tables Comprising Total system data repository
  7. Volume of  moving object – Size of Message/Data Payload
  8. Volume of stationary object – Size of Code
  9. Speed – Speed
  10. Force (Intensity) – Guaranteed / Not.
  11. Stress or pressure – System Load
  12. Shape – Memory Constraints
  13. Stability of  the object’s composition – Stability of Code Base
  14. Strength – Robustness
  15. Duration of action of moving object – Per Message/Transaction Processing Time
  16. Duration of action by stationary object – Overhead Processing Time
  17. Temperature – Speed of User Interaction
  18. Illumination intensity – Usability
  19. Use of energy by moving object – IO Intensiveness
  20. Use of energy by stationary object – Processor Intensiveness
  21. Power – Ability to do work
  22. Loss of Energy – Reduced Processing Capability
  23. Loss of substance – Lack of Message Integrity / Messages Lost
  24. Loss of Information – Loss of information
  25. Loss of Time – Loss of Time
  26. Quantity of substance/the matter – Size of Database
  27. Reliability – Reliability
  28. Measurement accuracy – Data Accuracy
  29. Manufacturing precision – Data Precision
  30. Object-affected harmful factors – Side effects on Code
  31. Object-generated harmful factors – Side Effects on Data
  32. Ease of manufacture – Ease of Coding
  33. Ease of operation – Ease of support
  34. Ease of repair – Ease of Troubleshooting
  35. Adaptability or versatility – Flexibility
  36. Device complexity – System Complexity
  37. Difficulty of detecting and measuring – Difficulty of Instrumenting or Monitoring
  38. Extent of automation – Extent of automation
  39. Productivity – Productivity


Posted in Architecture, Challenge, Philosophy | Tagged | Leave a comment

Some Observations on Dysfunction in organisations

The Leadership Problem

I have noted with interest that many people inside organisations operate without regard for the good of the organisation, or with a grossly faulty view of what is good for the organisation. Some people operate with their own departments interests in mind instead of the overall organisation’s interests. This is probably a fairly obvious statement, that anyone who has been in business for more than a few months will know to be true.  The issue of concern is how many senior executives seem to be willing to allow this behaviour to persist, once they have become aware of its existence.

  • I have seen Executive committee members that win favour with the CEO by painting their colleagues in a bad light, thus making themselves look “relatively” better than the next executive.  Once this becomes a culture the organisation is on a downward spiral;  The “least-bad” executive gets a bigger share of the ever-decreasing bonus pool.  It is almost as dysfunctional as trying to grow a business by cutting costs – it is doomed to failure.
  • I have seen some IT organisations that have no immune system, and exist in a state of being continuously on life-support.  Actions have no consequences, because the life-support will ensure we go on living, and short-termism can make a new executive look good long-enough to earn a nice bonus, and then leave the organisation in a worse state, but still alive.
  • I have seen some organisations where sales teams from 2 divisions compete against each other to offer their solution to the same client, sometimes cutting the price down as far as “cost” to ensure winning the next sale.  When said this way, it is the most obviously dysfunctional behaviour, yet the incentive-schemes of the sales managers insists that this is the best course of action for him or her.

It is fairly easy to imply that these individuals, acting out of self-interest are at fault.  Surely they should know better, and should be acting in the best interests of the organisation. This is just common sense.

On reflection though, dysfunction in organisations is usually a dysfunction in leadership; Partly because leadership allows the issue to persist and grow, but also because the leadership does not put in place a carefully thought out mechanism to ensure that everyone concerns themselves with the correct and proper outcomes.  Performance management is simply a necessary evil imposed by HR on management.  We have to tick the boxes, but really don’t run the business using these mechanisms.  Hard to believe, but this happens!

For example the competing sales-team issue is simply that incentives and structures in the organisation drive that behaviour.

The short-termism issue could exist because Executives cannot be made to take accountability for their actions, because Board members and shareholders do not know enough about the inner workings of the business to challenge the existing approaches and define a proper set of objective measures for the new appointees.

The finger-pointing and blame-shifting game exists simply because objective measures of a manager’s success are not defined or measured.

Open and honest, robust internal debate is very valuable and healthy, but when the agenda is genuinely not for the betterment of the greater organisation, this becomes a very serious cancer.  An honest individual can be misguided about the correct path, have incorrect or incomplete information, they can have flawed logic, or lack a broad enough education on the topic; All of these can be overcome by debate with colleagues which can result in the betterment of the organisation.  The requirement here is simply honesty, and a genuine desire to act in the best interests of the organisation. If those are missing the organisation has a virus in it that if the immune system does not expel it, will eventually kill the organisation.

I would suggest that the real cancer is weak leadership:

  • Unable or Unwilling to deal with the bad apples who are creating dysfunction.
  • Unable to set a clear objectively measurable course for the business.
  • Unable to see beyond the current ways of doing things, or challenge existing business models.

The IT Leadership Problem

The Leadership problem in IT is compounded in organisations such as the one described above, because IT is seldom understood at Board and Executive level.  When the CIO gives his report the attendees catch up on emails.

If the trust between CEO and CIO fails, it is often because they misunderstand each other, not because of genuine mischievous intent on either part.

Sometimes it is because the CIO was promoted through the ranks of IT, without genuinely being the right person for the job.  I have seen some sincere Corporate IT leaders who genuinely think their job is about the coolest latest technology; But management is about people, and good IT-people are not often great people-people. Obviously a good CIO should have good technical knowledge and be a great people-person.

Occasionally I have seen great candidates for CIO within an organisation who suffer under a technocratic leader because they are too junior to be awarded the role.  Once trust between the CEO and CIO is lost, the CEO is unlikely to look to them within the IT organisation as a successor to the outgoing CIO.  So the CEO appoints someone he or she trusts;  Usually someone with little or no IT experience.  These good Junior candidates should take the opportunity to ally themselves with the new CIO, and help him, and also learn to be great leaders in a relatively risk-free way.


If you are that promising junior IT resource, or this newly appointed CIO without IT experience, then read this blog.

If you are a long time CIO, and you’re constantly at odds with the Board or the CEO, I doubt you’ll enjoy this blog, but if you can manage to read it, I’m sure it will help – like awful-tasting medicine.

If you are on that Board, or you are that CEO who doesn’t see eye-to-eye with your CIO, then this should be an interesting read for you.


Before wrapping up this rather cynical and bitter post, I’d like to say why I think these things happen:

  • Well thought-out, Measurable Organisation Objectives are not set, or there are too many to manage effectively, or they are not used for daily management.
  • Well thought-out, Measurable IT Objectives are not set, or they are conflicting, or they are not used for daily management.
  • CIO’s are promoted through the ranks without regard for their aptitude, and end up managing technology instead of people.
  • Poor Leaders let the resultant problems escalate instead of stopping the rot early.


Enough of setting the scene… Next time we’ll consider some research in the field of IT Performance.


Posted in Challenge, Management, Philosophy, Strategy | Leave a comment

Why SoberCounsel, Why???

The Original concept of SoberCounsel was to be a source of sage advice for IT Professionals, but the speed of change in Business has triggered a need for an adjustment. It is no longer enough to simply plan a signalling system that will help avoid train-wrecks in the future. Someone has to go and warn the train drivers. It is time for an intervention. So the content will be coming faster and in a more structured way. I hope it helps you. I hope that it is taken in the positive way it is intended. I hope it makes a difference. I hope it can be interesting and fun.

So few shining lights…

One of the significantly talked about things in Corporates is how [Insert IT buzzword here] did not deliver on its promise, and quite possibly it is one of these in your organisation:

  • SOA
  • Big Data
  • E-Commerce
  • BI
  • Intranets
  • Collaboration
  • IP Telephony
  • Business Process Automation
  • Document Management
  • Mobile Work
  • Help Desk (some staff asserting that the word “help” should be removed from the name)
  • The IT project Office (ensuring that IT Projects deliver on time and on budget)

…and so on.

Are these things unworkable? Will they always be a problem? Are the technologies immature? Are IT People just unruly and unmanageable? Will IT Projects always overrun and under-deliver?

…so be better

We all know of organisations where one or more of them worked well. We have been to seminars where people talk about great successes. We see some organisation leverage a particular IT advantage to huge profit. We feel aggrieved that our own organisation seems to be incapable of similar success…but why do these successes seem to be so few and far between?

I have been in IT Management for over 15 years and involved in corporate IT for around to 22 years. In my experience the overwhelming majority of conversations about IT that corporate staff engage in, are negative ones. In truth the overwhelming majority of ALL experiences that people talk about seem to be negative ones – just look at the news and media.  So researching the anecdotal material available will simply confirm the sense we have that all is not well. My purpose begins to emerge:

  • To bring IT into good repute in corporates
    • by helping them to be of good repute.
    • and helping them to be seen to be of good repute
  • To have IT staff seen as the hardworking, capable, intelligent and focussed people that they usually are (exceptions excepted :-P)
    • To weed out those exceptions
  • To have corporate IT departments seen as essential Partners in the success of a business.
    • To give the IT Management team the tools to bring that about.

As usual the answer lies in understanding leadership and strategy in an organisation. In this case, specifically how leadership influences and interacts with the IT Department and Technology in an organisation (And I include IT Leadership in the category of Leadership) and how Organisational and IT Strategies interact..

  • Are you curious as to why these things seldom seem to work out, or what can be done about that?
  • Could you possibly influence some of those outcomes in your organisation?
  • Do you perceive the Performance of your Company’s IT Department to be suboptimal?
  • Are you an IT Manager or CIO?

Then this blog is for you.

…or Die

There are a number of things that are inevitable in the long term (certain to happen, unavoidable, unpreventable even) that few would dispute. I will call them generally accepted inevitabilities:

  • Businesses will depend more and more on Technology to function
    • therefore Technology and Business Strategy will become indistinguishable
    • therefore The IT Management Function and the Business Management Functions will be come indistinguishable
  • The number of IT Functions that are considered Commodity IT functions will grow, and those considered Core Strategic Business elements of IT will diminish.
    • therefore outsourcing of commodity functions will expand
    • therefore management of Core Strategic IT functions will become more critical
  • The IT Department will change to align with the above inevitabilities.
  • Organisations (and people) that can embrace these inevitabilities early (but not too early) will have an advantage.
  • Embracing these changes early, will cause them to happen faster, thus disadvantaging those who are not ready.

There are many ways to embrace these changes, but I believe the ideas in this blog, properly applied, will prepare organisations and people for these changes.  So unless you are just waiting to die, this blog is for YOU.


Posted in Announcements, Challenge, Management, Personal, Philosophy, Strategy | Leave a comment


I had the unfortunate experience this last week of having to install Windows after several years of being Windows-free.  I am installing on 2 new Apple computers for some friends.  Windows is needed for some very specialised software that requires a 64-bit version of Windows.  They  have an older version of that software that is certified to run on Windows 7.

The first pain was trying to purchase a copy.  Go to Incredible Connection… Ask for Windows 7: No longer available.  🙁  Okay lets try windows 8 then and hope it works… sigh.  Only available as an upgrade, you have to have a previous version of windows in order to install it.  WHAT??!!!

That is the most arrogant thing I have heard of since Ferrari made models that only previous owners were invited to buy…and I feel that Ferrari are sort of entitled to a little arrogance.   Maybe this is more akin to when Renault did the same thing with their V6 Cleo.

…but wait Windows 8.1 is available, not physically in South Africa yet, but virtually for download, and THAT is a full product not requiring you to have a previous version of Windows!  yay!

OK so I trot off home and purchase the 2 copies I need.  The download link downloads a downloader, which requires Windows to run!!!!!!!!!!!!   Wait, I thought this version does not require you to have a previous version of Windows?  Sigh.  I give up.  I fire up a version of Windows 7 I have installed on my laptop that I bought with parallels 7.  Download their blessed downloader and execute.  It gives three options: Install now, Create media, and Install later (which as far as I can tell just exits the app :-).  OK perfect, create media is what I want.  Next page asks if I want to install to USB flash drive or ISO file.  cool.  this isn’t so bad.  I select ISO and it starts downloading. Downloads in 1 hour… no problem.

Attempt to install.  40 minutes later finish install.  But wait, it has installed the 32-bit version on this 64-bit computer.  Hmmm….the ISO I downloaded seems to only include the 32-bit version???  I need the 64-bit version.   Log back onto the Microsoft store, search for an alternate link.  nope.

Call Microsoft support.  First few times I made the mistake of mentioning that I was installing to an Apple and immediately they tried to transfer me to someone who could help with Bootcamp.  Argh!!  The problem is not Bootcamp, the problem is downloading a 64-bit version.  Eventually after several calls I got to the point:  “OH. no you need to download it from a version of Windows running the same architecture as the version you want to download. ”  WHAT!!!????   Not only do you need to have a copy of windows to execute the downloader for this “Full Version”, but you also need to have a previous version running the same architecture that you want to download.  It makes this decision for you with no consultation or notification whatsoever.

Nowhere on any of the screens I encountered (and I have now done this many many times looking for it) is there any warning or information  to this effect.  The only way to find out which version you are getting is to try to install it, and when you are finished with the whole install process you can check and see if it is the version you wanted. Neither the download page on the Microsoft Store, nor the screens in the Downloader Application, nor anywhere during the installation process are you given any option or warning about which version you are getting.

After 3 hours on the phone of trying to find an alternative, the only option available to the Microsoft staff was “We’ll give you a refund for the download version, and you must order the DVD media….5-7 working days delivery.”  No way to download the 64-bit version of this full product unless you have a 64-bit version of a previous version installed and running somewhere.

WAKE UP MICROSOFT!!!!!   This is the worst software purchase experience I have ever had.  ever.


Posted in Personal, Review, Technology | 3 Comments

Show me your Enterprise Architecture…

The Enterprise Architect or Chief Architect role is often a very murky space to play, because people ask to see this “Enterprise Architecture”, and that unfortunately means different things to different people.  If you asked me for the “Enterprise Architecture” I would want to give you this pack of documents because they are probably most useful in guiding IT decisions:

  • Analysis of the Organisational Strategy clearly showing how the Technology strategy Aligns, and if it doesn’t – giving recommendations on how to make it align.
  • An Analysis of the Business Functions and key processes, clearly indicating which systems support those business functions.
  • A Health Assessment of those systems indicating their systemic health, degree of alignment with the stated business strategies and functions, satisfaction of the users, and technology lifecycle perspectives.
  • A Technology Roadmap integrating Business-Unit-level roadmaps and initiatives into a single Enterprise level Technology roadmap.


It could take years to establish a functioning Architecture Practice that produces and updates such a pack on a regular basis (depending on the size of the organisation).

So my approach would be to create a high-level draft Architecture in a few months, that will then become the basis of incremental improvement as the process gets established.

If one tries to map all Business Functions and processes to a task level, before mapping systems, before creating a roadmap, you may take too long to get to the point of having any useful impact.

Every Architecture artefact MUST help the organisation to make better decisions, faster.  There must be (and there is) a way to prioritise the EA deliverables in such a way that they impact the “next” important decision just in time.    I am a great believer in creating a mile-wide/inch-deep Architecture view first, from which priorities can be selected and more detailed work can be done.  Very often mile-deep efforts are never finished, or they result in EA investment being cut, because they take too long to yield useful results.

Establishing an Architecture Practice

So my approach to EA establishment would be:

  • Assess the enterprise from a high level-strategic perspective
  • Decide on the set of EA artefacts needed initially
  • Plan the phases of the EA establishment programme
  • Create very high-level drafts of the EA artefacts very quickly
  • Incrementally populate those with information, but start using them as soon as they contain useful content.
  • Expand their use as their content evolves to become more useful

This way value is gleaned early from the Architecture efforts, without compromising the ultimate objective of having a complete set of EA artefacts to guide all the relevant IT decisions at the end of the establishment programme.

In the process of establishing an architecture practice it is also critical to focus on establishing the processes and inserting them into the decision making process as soon as possible.  The earlier that  existing  IT decision-making  processes become used to requesting Architecture input and guidance, the better.  In many organisations with mature management, where architecture is in its infancy, the managers all want a piece of the new architect as soon as they walk in the door.  Mature Managers recognise that there is huge value in making better IT decisions, and the way they can do that is by having proper architectural guidance.  The trick is deciding who to help first, and how to prioritise that effort.

With the Priority of Architecture Artefacts established, the problem of which Business Area’s to start with comes into focus.

The Health / Importance metric.

The Importance metric applies to both Business Processes and Systems supporting them.  Some Business Processes are critical to an organisation, and others cause only a small inconvenience when missing (e.g. pause-area coffee replenishment process – except for Software development companies which run on coffee).  Others are critical at certain times of the month and almost irrelevant at other times (e.g. payroll).  Similarly systems supporting a business process may have varying degrees of criticality.  Either way, one of the important metrics to help you prioritise you efforts is going to be some measure of the importance of each Business process and their supporting systems.

The Health Metric applies to systems, and it measures the degree to which that system is functioning reliably, and meeting the business requirements of its respective business process.  Some technology aspects can also be brought into the health metric, such as obsolescence, and ability of the IT Organisation to monitor and support the technology being used.

I have a standard set of survey questions that I use to determine the Health and Importance metrics, that I adjust slightly depending on the organisation’s requirements.

This information is then plotted on a simple 2×2 matrix indicating the Importance versus Health.  Obviously the items that are important and Unhealthy are your first priorities.  The Unimportant Healthy Systems are obviously your last targets, leaving  Unimportant-Unhealthy and Important-Healthy as your second Targets with some discretion applied.

For Most Organisations, a matrix like this can be completed in a few months and usefully inform the Architecture Priorities; All the while you are getting on with the basic establishment of Architecture Processes, Governance Bodies etc.

So now armed with an approach to prioritising EA Artefacts, and an approach to prioritising the Business-Areas. the EA programme looks less overwhelming, and questions about when it will start to pay off, can easily be answered.


Posted in Architecture, Management, Philosophy, Strategy | Leave a comment