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 an 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
  • IT Functions that are considered Commodity IT functions will expand and those considered Core Strategic Business elements of IT will shrink.
    • 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 takes 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  and Unimportant-Unhealthy and Important-Health 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

Agile adds Discipline

I have often found that corporates are prepared to spend huge amounts of money to maintain control and manage risks.  Risk is typically calculated as the product of probability of the risk materialising and Impact of the risk materialising.

Agile approaches to Software development and Remote Developers are often avoided as mechanisms because of several misconceptions about Agile that organisations view as risks:

  • Agile teams don’t plan.
  • There is no design in the Agile approach
  • Agile teams do not test.
  • Agile = no documentation.
  • Loss of management control

(Note that all of these are untrue)

The statistics on Adoption of Agile are compelling, with 83% of the organisations surveyed (Versions One’s 7th Annual State of Agile Dev Survey) saying they would definitely do Agile Projects again, and 70% saying that Agile allowed them to Deliver projects faster.

So why the resistance?  I’ll answer that subjectively first by saying I was a skeptic until I saw one Agile project work well:  Now I am a convert.

What about the remote workers?  The survey showed that Agile was also useful in managing distributed teams very effectively.   The fact is that your developers sitting in the office could just as easily skive-off while they are at their desk.  They get interrupted by noisy colleagues, adhoc meetings and the daily commute.

The origins of Agile are in OpenSource distributed teams, creating a process to allow them to work effectively together and deliver productively.  This takes discipline! The Cynic in me says that corporate software development teams do not want that amount of discipline – it’s hard work.  And it seems to have been easy for them to convince management that this Agile thing is no good.

“To say that companies or CIOs are reluctant to embrace agile is like saying they wouldn’t take aspirin for a headache….And they’re not only not taking the aspirin, they’re banging their heads against the wall and wondering why it hurts.” – Jim Johnson, Standish Group Chairman

On the distributed team issue, surely it makes sense that the very best people for a given project may not all be located in one place, or near your offices. Why limit yourself to the resources near you?  Why not get the benefit of the best the world has to offer in a given technology? We now have the mechanisms to help them work effectively together with the internal teams, but we need to follow the disciplines to get that benefit.

I would challenge any manager of an IT team that includes software development to read these survey results and remain skeptical.  :-)


Posted in Management | Tagged , , , , | 2 Comments

A brief look forward

Here are the slides I presented at the Enterprise Risk Management Africa 2013 conference.

Hopefully I’ll find the time to comment soon.

(Contains 1 attachments.) Share
Posted in Management | Leave a comment