If and when you can help people with strategy, architecture and transformation challanges.

In deciding if one can help people improve how they do strategy, architecture and transformation challenges the decisions are:

1. Do they recognise the need for a strategy and architecture - as a platform for informed decision making on transformation and optimisation initiatives. If they don't then point them at the material that explains why and leave them for a year or two.
2. Do they recognise the current document based, and often consultant lead, approaches to strategy and architecture as mechanism for decision making for transformation and optimisation fails. It fails for everyone but the consultants and the perhaps the authors of the documents. If they don't then point them at the material that explains why and leave them for a year or two.
3. Do they recognise that systems architecture and software engineering  methods and modelling (e.g. those aligned detailed modelling e.g. ER, BP)  to strategy and architecture are oriented at wrong things for the wrong people. If they don't then them point at the material that explains why and leave them for a year or two.
4. Do they recognise that what is required are wisdom management solutions where all stakeholders can access information in ways suited to the tasks they perform, so that industry best practice can be supported by task specific solutions that all leverage off a common view of the enterprise are required to make rapid and cost effective progress (or do they want to reinvent things for themselves because at heart they are want-to-be taxonomists, methodologists, architects or developers). If they don't then them point at the material that explains why and leave them for a year or two.
5. If you get here - you can explore with them issues associated the cultural changes in the organisation and look at solutions and methods that support decision making and knowledge accretion.

The bottom line is you can't help people who don't want to be helped - and the 1st they need to make (for themselves) is to recognise there is a problem and they need to do something. See the 12-step programme for treating addiction to failed ways of doing things.

Remember Planck's Principle (not his constant) - "A new scientific truth does not triumph by convincing its opponents and making them see the light, but rather because its opponents eventually die and a new generation grows up that is familiar with it."

12-Step program for Enterprise Architects

EA seems addicted to labour intensive work done with unsuitable tools or in documents.

You could imagine a session - where I stand up in front my peers and say "Hi, my name is Michael Ellyett, and I am an Archaholic addicted to using tools and methods that don't work for my enterprise... "

Here are some initial thoughts on how to overcome this addiction - based on programs that work for other addictions.

1. Admit that what we are doing doesn't work. It makes you feel good but doesn't do anyone much good in the long term

2. Recognise that something beyond what we do and use at present is needed to restore us to sanity.

3. Make a decision to think rationally about why we are failing. Rather than pretending it is all OK, or will be OK next time, or blaming others.

4. Make searching and fearless inventory of what we are doing and why.

5. Admitted to ourselves and others the exact nature of our wrongs.

6. Put aside our semi-religious beliefs in framework and methods that everyone says should work

7. Work out how to do things that actually contribute to goals others have

8. List all of work we have done badly that could have been done better.

9. Make amends by telling the people we have worked for and with that we recognise the error of our ways, apologise for our past failing, and are committed to breaking our addiction to tools and languages we are addicted to - but that don't work for the enterprise.

10. Continue to take personal inventory and when we were wrong promptly admit it.

11. Seek through honest and open communication to improve our thinking on what is required

12. Having had an intellectual wakening as the result of these steps, and try and carry this message to others.

Sustained value from strategy and architecture work

The world is full of people who say they can do strategy and architecture work - maybe they can, maybe they can't.

I don't believe it can done in a such a way as to produce sustained value and lead to self-sufficient organisations unless it is done in the right way, with the right tooling. I have never seen anyone, anywhere do this.

Giving some point advice e.g. a list of programmes to be initiated, a list of changes required etc. - no matter how pertinent and correct isn't quite the same thing. Where point means relating to this problem, with these goals, in this situation at this point in time.

What I mean by sustained value is a strategy and architecture that can be kept current, used to analyse what should be done as circumstances change (regulatory, market, technology etc.) and what I mean by self-sufficient is the organisation can maintain, integrate, extend etc. the knowledge of their enterprise and its environment represented in the strategy and architecture. Albeit that they may call on some expertise for extending the scope of depth of its application. (Cf. "give a man a fish and you feed him for a day, but teach him how to fish and you feed him for a lifetime").

If we compared this to a town plan - what I am say is:
Giving some point advice (e.g. build this infrastructure or don't build the airport there) - no matter how pertinent and correct the advice may be - is not the same thing as providing a city a mechanism for maintaining information that will allow them to make these types of decisions in future. In the 1st case maybe I don't need a co-ordinate system (a framework), a map, sets of building codes and standards, places to record information on the existing situation (assets, features) and expected changes (demographics, technology, projects) etc. - I can all this in my head, articulate the relevants aspects in my report and make my recommendations. The problem is that most of critical knowledge wouldn't be available for the next decision. What I would have done is made myself more valueable - good for me, not so good for the client.

Few would mistake the giving of this point advice as establishing a strategic and architecture capability. However this mistake seems commonly made in IT.

CIOs need to adapt to the new world

In this item "Most CIO dinosaurs heading for career ice age" the author correctly identifies the need "what's needed is distributed decision-making, rapid response, the use of ad hoc teams, and leadership through collaboration rather than authority."

A question that follows from this is what decision support systems are required to enable this behaviour - certainly not the Excel/Visio/Powerpoint/Email mix that is used by most of the IT organisations to manage the knowledge needed to make decisions.

Nor the specialised tools/languages/systems oriented a various silos e.g. CASE tools and modellers (assured to alienate most non-developers), BP modellers (that operate discretely), CMDBs (with their detailed inventories of current state) or to confuse the issues by putting all ones hopes in yet another paradigm e.g. SOA (having witnesses that past paradigm's function, 4GL, client/server, data, object, etc. haven't solved the problem).

So what is required is a mechanism that allows knowledge to accrete, for all to participate in the gathering an use of information.

This requires some CIO leadership as it requires:recognition that some changes are required i.e.
- current silos of data (and worse still documents) don't work
- a small/minor behavioural change is required by many people i.e. where the record information
- a systems solution is required to enable the behavioural change and integrate the data held in silos.

Many CIO abnegate the need for any significant change and hope that existing strategy and architecture functions (themselves suffering from being yet another silo) can solve the problems within their ambit.