Keynote address at Contact Centres World.


I will be delivering a Keynote address at the Contact Centres World – Africa 2009 convention.

The Topic will be:
Enabling business growth and innovation in a technologically converged world

  • Technology convergence impacts on service quality
  • Developing a consolidated ICT environment through long term vendor partnerships
  • Achieving more with less resources
I’ll have some great prizes to hand out and there will be a raffle to be the next person interviewed on my Podcast show “PlanIT” hosted by ITWeb. (www.discussit.co.za)  See you there!
Share
Posted in Management | Leave a comment

Why Strategies aren’t implemented.

Have you ever said something that sounds really silly, then replayed it in your head and thought “Actually that’s really profound”.

I was trying to describe the strategic process to someone the other day and I ended up saying:

“If you have no desire to be somewhere else, then you must be happy with where you are.”
– Me

I immediately thought “what a stupid and obvious thing to say” then I thought “No, that is exactly right!”

If people are happy where they are, and have no desire to be somewhere else, then they have absolutely no motivation to move. They will stay where they are.

This in the context of strategy is why strategies are often not implemented. The people who are supposed to implement them have no desire to be “somewhere else.”

One of my professors at Wits Business school, Prof. Rasoava Rijamampianina “Rija” used to say:

“The only person who appreciates change is a baby with a wet nappy”
– Prof. Rija

This is really it. Have we as strategists spent enough time on the consequences of NOT changing. If the organisation believes it is OK where it is, or that the strategy is not addressing the right problems then change will not happen.  What’s more if the change is forced it will only be sustained as long as the leader who forced it is continuously maintaining it. As soon as that leader leaves, the fascade of change will fall off.

  • The People implementing it need to believe in it.
  • They need to understand why staying where they are will be disastrous.
  • They need to understand why it will be “so much better” where we are going
  • They need to believe in both of those.

Simple.

This doesn’t mean the strategy is the right one, or that any of the promises it makes are true. We have many examples from history of people fervently and whole-heartedly striving for something totally wrong. The strategy was wrong, the outcome disastrous but the strategy WAS IMPLEMENTED.

The skill of the strategist is two-fold then.

  • Find the “best” strategy for the organisation that will have desirable outcomes.
  • Convince the implementers of the need to change.

Some of my stakeholders will say, “Yes, Yes, Yes! That is exactly what we need! We agree. Let’s do that” and then they proceed to do nothing.

Intellectually they agree with the proposed strategy, but they do not believe it will be implemented, or they believe it will not address their immediate needs. This is of course the proverbial “self-fulfilling prophecy.”

Watch out for this. Those people need special attention. A strategy will not be implemented if the people who have to implement it do not believe in it as evidenced by their actions.

I have waffled a bit, but I think the point is clear:

  • Make sure your stakeholders believe in the proposed strategy.
  • Measure their belief by their actions, not their words.
  • If you want it to be sustainable, avoid the temptation to use “Brute Force” to get it implemented.
Share
Posted in Management, Philosophy | Tagged , , | 2 Comments

Architectural Patterns: A Pattern

We have often in the past struggled with the process of establishing some architectural patterns.

It is probably one of those things, that if you try to find a use for it, you will fail, but one day it will suddenly be obvious.

One of my esteemed colleagues was working on an audit of a Disaster recovery capability for one of our business units.  During the course of his work he was mapping out the locations of all of the servers and the links, and since this was a high availability solution, when he was done he had drawn a picture representing a typical high availability solution, with links to a disaster recovery site for replication and clustered servers for redundancy and load balancing etc.

We decided to abstract the drawing he had made to a more generic view, listing instead of the actual server names, simply the roles they played, like “Application Server”, “Web Server” etc.  Abstracted a bit further we had a picture of what a typical high availability solution should look like in our environment.

It was a simple job to extrapolate from there what a “Continuous Availability” solution and what a Regular and Budget solution should look like.  So what we had now was a set of “Deployment Patterns” for solution hosting.  From Low-end to High-end requirements.  Next we gave them names and described their defining characteristics.  The “Budget” offering would have daily backups and if it failed we would order new hardware with up to 3 weeks of lead time. Each pattern inherited more characteristics as they became clear: Recovery time objectives, Recovery point objectives, Availability targets etc.

So now when we refer to a Bronze deployment or a Silver Deployment, everyone should immediately have in mind the same set of characteristics, and pricing level.

Then we publish a nice little poster describing the patterns we have discovered.  Patterns are discovered, not created.  Standards are created, but patterns usually already exist.  We know what “Should” be done in a given set of circumstances and what typically “Has been” done before.  The trick is seeing how things relate to one another. “Ahh, these are different types of hosting deployments, and they have different levels of availability requirements.”

Another point to note is that patterns come in sets.  We have a set of hosting patterns, a set of monitoring patterns, a set of integration patterns.  We cannot sit down with the objective of creating “Architectural Patterns” without an understanding of their objectives.

In Pattern-Oriented Software Architecture: A System of Patterns, (F. Buschmann, R. Meunier, H. Rohnert, P.Sommerlad, and M. Stal, John Wiley and Sons, 1996) three types of patterns are noted:

  • An Architectural Pattern expresses a fundamental structural organization or schema for software systems. It provides a set of predefined subsystems, specifies their responsibilities, and includes rules and guidelines for organizing the relationships between them.
  • A Design Pattern provides a scheme for refining the subsystems or components of a software system, or the relationships between them. It describes commonly recurring structure of communicating components that solves a general design problem within a particular context.
  • An Idiom is a low-level pattern specific to a programming language. An idiom describes how to implement particular aspects of components or the relationships between them using the features of the given language.

From the Book above and some adaptations of other pattern concepts I have adapted this Pattern for Patterns:

  • Name: A meaningful and memorable way to refer to the pattern, typically a single word or short phrase.
  • Problems to be solved: Describes the problem to be solved, with reference to the goals and objectives as appropriate.
  • Pre-context: The conditions relevant to the pattern that exist before the pattern is applied.
  • Principles: Adopted rules, policies and predetermined modes of action for the pattern.
  • Solution: A description of how the problem is solved.
  • Products: Example products which can be used to implement the pattern.
  • Resulting context: The conditions that result after the pattern is applied, including resolution of competing forces.
  • Resulting context owner:    The enterprise client who owns the benefits of the resulting context. Typically this would also be the owner of the requirement for this functionality.  This may be a role rather than an individual e.g. “Operations Manager”,”Integration Committee” etc.
  • Examples: Sample applications of the pattern.
  • Rationale: A description of why the solution is solved in a particular way – possibly describing the key trade-offs made between competing forces.  For example:
    • Security, robustness, reliability, fault-tolerance
    • Manageability
    • Efficiency, performance, throughout, bandwidth requirements, space utilization
    • Scalability (incremental growth on-demand)
    • Extensibility, evolvability, maintainability
    • Modularity, independence, reusability, openness, composability (plug ‘n play), portability
    • Completeness and correctness
    • Ease of construction
    • Ease of use
    • … etc.  (SEE MY PREVIOUS POST ON TRIZ…)
  • Related patterns: Related patterns are predecessor, successor and alternative patterns, which provide similar solutions.
  • Parent pattern: If this pattern is completely contained within another pattern, the name of the containing pattern.
  • Sub-patterns: Patterns which provide specialised behaviour yet are completely contained within this pattern.
  • Known uses: Known applications of the pattern.
  • Immediate predecessor patterns: Other patterns that contributes to the immediate pre-context of this pattern, i.e. They give inputs that are critical to the functioning of this pattern.
  • Immediate successor patterns: Other patterns that depends on this pattern for their pre-context, i.e. This pattern must provide inputs to these successor patterns.
  • Security considerations: Security aspects that must be considered for the pattern.  Does this pattern treat sensitive data or have capabilities that should be secured.

The Names of the various Patterns should be used in a “Framework” or Navigation matrix that will help a user to select the appropriate pattern for their particular use.  An Example of this is a set of Monitoring Patterns that we have created.  The Framework indicates monitoring “objectives” (SLA Management, Operations Management etc) as column headings and the “activities” (Instrumentation, visualisation, correlation etc) as row headings.  At the intersection of each pair is a pattern name.  Find the point in the matrix that best matches your specific intentions and you will have a specific pattern or set of patterns indicated for your business or technical problem.  It is really important to have this navigation structure in place to help users find their way through a potential maze of options.

Some Resources:

Share
Posted in Challenge, Management | Tagged , , , | Leave a comment

The Benefits of Idempotence

This is supposed to be an IT philosophy blog, but I’ll argue that Idempotence should be a coding philosophy.

Loosely, something that is Idempotent (Idem:Once, Potent:Having effect) will have an effect only the first time it is executed or will have exactly the same result every subsequent time it is executed.

Some say that dividing or multiplying by 1 is an idempotent operation.  In a coding sense I disagree somewhat.  Dividing or multiplying by 1 NEVER changes the result, not even the first time.  So maybe multiplying by zero is a more appropriate example of idempotence.  It changes the result the first time it is executed, but thereafter has no further effect if executed multiple times (i.e. after the first time you are multiplying zero by zero and the result will of course remain zero)

In software this translates into writing code that knows when it has already been “effective” and that if it is executed a second time will have no further effect.

An example of this is in batch processing.  A batch program written in an object oriented way could have a stack of calls to the same process (one for each item in the batch) so the batch program simply calls the same routine once for each item in the batch.  If this routine (let’s call it the batch-item-processor) is written according to idempotent principles, then calling it twice for the same batch-item will have no harmful effect, i.e. that item will not process a second time.

If you have ever had to troubleshoot batch faults you will immediately recognise that this has many benefits.  As the troubleshooter, you do not have to worry about which batch entries have already been processed and which ones have not.  Once you have found the faulty batch-item and either corrected or eliminated it, you simply resubmit the whole batch.  The batch-item-processor will not allow any batch-items to be processed twice.

You may be tempted to code an override switch so that you can force a second-potency of the batch-item-processor for a specific transaction, however it would be more effective to reverse the effects that the “Idempotency-detector” in the batch-item-processor uses to detect whether it has been processed previously.  This would roll back to a state before that transaction processed, so the new call to this batch-item-processor would correctly process for the first time “again”.

When writing an idempotent batch processor it would therefore be prudent to write a reversal processor at the same time to reverse the effects of the transaction as discussed above.  In fact I would write this in a “-1″potent way 🙂   So this means it will not try to reverse transactions that have not been actually performed yet.  This means if you want to do a batch reversal you can simply submit the whole batch to the reversal processor and only transactions that have actually been processed will be reversed.  It’s the same principle in reverse.

The key here is that you give sufficient intelligence to the batch-item-processor and reversal routine to know when it is safe for them to execute.  This is a higher principle than idempotence.  Appropriate-potence: A code-object knows when it can/should process and will not process until those conditions are met.  For example if you call a step in a process which requires that previous steps have already completed, it will simply respond that it cannot run yet because these upstream processes have not yet completed.  Depending on the process you may put it then into a polling loop checking for that state to occur.  Every subsequent call simply responds that it is waiting to run and the new instance terminates itself while the original continues to wait.

NOW you can start building an intelligent network of objects that together form an optimised just-in-time no-lag process in which every step performs at the moment it needs to.  As soon as a required state is reached the dependent process will begin its tasks.  This means that to initiate a process you simply call the LAST step in the process and as it checks state, all the way up the stack it will have initiated the whole process.  If you create a monitor agent for the required state for the FIRST step in the process an event can be generated that triggers this LAST step in the process, and hence the entire end-to-end process is automated.

Another side effect of giving each step the intelligence to know when it can run is that you manage dependencies at each node, you do not have to create a complex dependency matrix, simply worry about the dependencies of each object and let the network of objects calculate the matrix in runtime.

I’m sure there are many examples of this having been done before.  Leave a comment if you have tried this, or implemented a cool example of this approach – or of course if you simply want to make a comment. Find the “Respond” link below the Article date in the Article Header.

Share
Posted in Management | Leave a comment

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.

Share
Posted in Architecture, Philosophy, Technology | Tagged , , | 4 Comments