How to align analysis and strategy

I saw this "http://www.alinement.net/component/content/article/42"

My issue with this article is that it identifies a problem - and present no real answer.

This item raises two issues:
- Ambiguity in business strategy significantly impedes BA work and an uncertain strategy will delay getting clear answers to specific questions.
- An ability to make decisions where trade offs are required mean analysis and design impossible.
In both cases what is required is semantic precision.

BA could enhance their role if they applied semantic precision. Natural language and using word documents as the means of maintaining knowledge militates against this. The advice given covers some areas where precision is required - but gives no clues as to how to go about being precise.

Few would disagree that we need to be:
- Clear about the objectives and constraints (e.g. time-horizon)
- Understand the reasons for and importance of requirements (and know which are mandatory, which highly desirable etc.) i.e. record reasoning and priority
- Define the appetite for risk and innovation (e.g. how creative does the solution need to be) and in fact understand what is wrong with the current state (i.e. the implications of ‘doing nothing’)
- Identify and facilitate the resolution of conflicts between stakeholders - which must start by making such conflicts explicit e.g. A thinks XYZ is priority 3, B thinks XYZ is priority 7
- Concisely and specifically document your understanding of the strategies. [Using what semantics?]
- State sensitive assumptions. [And presumbaly relate them to something?]

The question is how can we: be clear, record reasoning and priority, make explicit relationships and record strategies explicitly.

The strategy should not be to put things into "words". It should be 1st to define a small canonical set of concepts (words, relationships) and use these with precision - and ontology if you like. This would allow us to eliminating synonomous terms, relate concepts explicitly etc. This allows us to be clear about what concepts are we dealing with and how do we relate concepts. How do we deal with priorities (and networks of prioritised items).

For example how do we rate importance e.g. is a requirement marginally critical to a high priority business goal more important (less important or equally important), than a requirement very critical to a medium or low priority business goal.

The strange idea of requirements before design, and design before construction

I continually dumb founded that other experienced and intelligent people thing that they leap into the use of a modelling tool to record concepts and analysis without being clear on the requirements or doing design. At present I am focused on modelling of enterprise - their operations, technologies and related transitions and initiatives. I always emplore people to:
1. gather the requirements (e.g. the questions they want the model to answer) BEFORE they start thinking of the design of the model
2. sketch out a rough design in some manual method (on paper, on a white board i.e. on anything but a computer modelling system) and get that design clear in their heads.
3. go about modelling.

But people presented with a modelling tool inevitably leap to 3. Some argue they implicitly know the needs (which I seldom buy) and some say they design best using computers (which I don't buy either).

I have written in other items in detail about why the way model something depends on the answers to be asked of the model. Which I won't recap on here.

AN ANALOGY FROM MY PAST
A CAD system, and in fact architectural drawing themselves, are models of a proposed or existing reality. They are way of communicating and analysing reality.

Once in my distant past after leaving Architecture school I specialised in CAD systems for architects. After a decade of using them (and at that stage I was as proficient as anyone in the world) with them them I became more and more convinced that in the vast majority of cases the use of these tools impairs the cognitive processes associated with conceptual design.

The conceptual design was better done on the back of an envelope, scratched in the sand of modelled roughly from wood and clay. I think this is for deep seated reasons to do with human cognitive processes and design. I think it has to do with issues of gestalt and post cognitive dissonance and the tendency for electronic tools to require greater precision (dimensional, semantic etc.) than should exist at the early stages of design - i.e. where it is better to leave some things loose, woolly, undefined/less defined.

This is not to say that they should not be used - but they should use to elaborate a design (not conceive one).