Archive for Januar 6th, 2009

A Principal Exposition of Jean-Louis Le Moigne’s Systemic Theory (Eriksson, 1997)

Dienstag, Januar 6th, 2009

DSC01427

Eriksson, Darek: A Principal Exposition of Jean-Louis Le Moigne’s Systemic Theory; in: „Cybernetics and Human Knowing“. Vol. 4 (1997), No. 2-3.

When thinking about complexity and systems one sooner or later comes across Le Moigne.  Departing point is the dilemma of simplification vs. intelligence.  Therefore systems have to be distinguished to be either complicated = that is they are reducible, or to be complex = show surprising behaviour.

Complicated vs. Complex
This distinction follows the same lines as closed vs. open systems, and mono- vs. multi-criteria optimisation.  Closed/mono-criteria/complicated systems can be optimised using algorithms, simplifying the system, and evaluating the solution by its efficacy.  On the other hand, open/multi-criteria/complex systems can only be satisfied by using heuristics, breaking down the system into modules, and evaluating the solution by its effectivity.

In the case of complex systems simplification only increases the complexity of the problem and will not yield a solution to the problem.  Instead of simplification intelligence is needed to understand and explain the system, in other words it needs to be modelled.  As Einstein already put it – defining the problem is solving it.
Secondly, to model a complex system is to model a process of actions and outcomes. The process definition consists of three transfer functions – (1) temporal, (2) morphologic, and (3) spatial transfer.  In order to make the step from modelling complicated system to modelling complex systems some paradigms need to change:

  • Subject –> Process
  • Elements –> Actors
  • Set –> Systems
  • Analysis –> Intelligence
  • Separation –> Conjunction
  • Structure –> Organisation
  • Optimisation –> Suitability
  • Control –> Intelligence
  • Efficacy –> Effectiveness
  • Application –> Projection
  • Evidence –> Relevance
  • Causal explanation –> Understanding

The model itself follows a black box approach.  For each black box, its function, its ends = objective, its environment, and its transformations need to be modelled.  Furthermore the modelling itself understands and explains a system on nine different levels.  A phenomena is

  1. Identifiable
  2. Active
  3. Regulated
  4. Itself
  5. Behaviour
  6. Stores
  7. Coordinates
  8. Imagines
  9. Finalised

Posted in Complexity, Decision Making | No Comments »

Framed! (Singh, 2006)

Dienstag, Januar 6th, 2009

DSC01426

Singh, Hari: Framed!; HRD Press, 2006, ISBN: 0874258731
Amazon-Link

I stumbled upon this book somewhere in the tubes.  I do admit that I felt appealed to combine a fictional narrative with some scientific subtext.  Unfortunately for this book I put the bar to pass at Tom DeMarco’s Deadline.  On the one hand Singh delivers, what seems to be his own lecture on decision-making as the alter-ego of Professor Armstrong; on the other hand the fictional two-level story of Larry the first person story-teller and the crime mystery around Laura’s suicide turn murder does not really deliver.  Let alone the superficial references to Chicago, which I rather found off putting, I think a bit more of research and getting off the beaten track could have done much good here.  Lastly, I don’t fancy much the narrative framework driven style so commonly found in American self-help books – and so brilliantly mocked in Little Miss Sunshine.

Anyhow let’s focus on the content.  Singh calls his structure for better decision-making FACTNET

  • Framing/ conceptualising the issue creatively
  • Anchoring/ relying on reference points
  • Cause & effect
  • Tastes for risk preference & role of chance
  • Negotiation & importance of trust
  • Evaluating decisions by a process
  • Tracking relevant feedback

Frame – Identify the problem clearly, be candid about your ignorance, question presumptions, consider a wide set of alternatives
Anchoring – Anchor your evaluations with external reference points and avoid group thinking
Cause & effect – Recognise patterns and cause-effect-relationships, try to regress to the mean, be aware of biases such as the halo effect
Tastes for risk & Role of chance – be aware of compensation behaviour, satisficing behaviour, cognitive dissonance, signaling of risks, gambler’s fallacy, availability bias – all deceptions which negatively impact decision-making
Negotiation & Trust – just two words: Prisoner’s dilemma
Evaluating decisions by a process – Revisit decisions, conduct sensitivity analyses
Tracking relevant feedback – Continuously get feedback & feed-forward, be aware of overlooked feedback, treatment of effects, split up good news and bundle bad news, think about sunk costs, man & machine, and engage in self-examination

Three methods for decision-making are presented in the book – (1) balance sheet methods with applied weighting, (2) WARS = weighting attributes and scores, and (3) scenario strategies.

Lastly, Singh reminded me again of the old motto „Non Sequitur!“ – making me aware of all the logic fallacies that occur if something sounds reasonable but ‚does not really follow‘.

Posted in Books, Decision Making | No Comments »

10 Mistakes that Cause SOA to Fail (Kavis, 2008)

Dienstag, Januar 6th, 2009

DSC01430

Kavis, Mike: 10 Mistakes that Cause SOA to Fail; in: CIO Magazine, 01. October 2008.
I usually don’t care much about these industry journals. But since they arrive for free in my mail every other week, I could help but noticing this article, which gave a brief overview of two SOA cases – United’s new ticketing system and Synovus financial banking system replacement.

However, the ten mistakes cited are all too familiar:

  1. Fail to explain SOA’s business value – put BPM first, then the IT implementation
  2. Underestimate the impact of organisational change – create change management plans, follow Kotter’s eight step process, answer everyone the question ‚What’s in it for me?‘
  3. Lack strong executive sponsorship
  4. Attempt to do SOA on the cheap – invest in middleware, invest in governance, tools, training, consultants, infrastructure, security
  5. Lack SOA skills in staff – train, plan the resources, secure up-front funding
  6. Manage the project poorly
  7. View SOA as a project instead of an architecture – create your matrices, war-room; engage collaboration
  8. Underestimate SOAs complexity
  9. Fail to implement and adhere to SOA governance
  10. Let the vendor drive the architecture

Posted in Failed Projects, IT Project, Software Development | No Comments »