Sunday, May 23, 2010

Horses for courses

I see Methods and Tools recent poll mixed results for UML http://www.methodsandtools.com/dynpoll/oldpoll.php?UMLPoll2

I would suggest few doubt that UML (or UML like OO analysis) is useful. The key things are to determine when it most useful and when it is not particularly useful. It is strange for me to be writing in support of UML as I more usually pointing out that it does fit well in the domains I predominantly work on now e.g. strategy and strategic architecture.

That only 14% of people use UML on all projects makes sense (perhaps they all have complex OO projects), that 45% of people use it, or some of its techniques, on some projects makes ever more sense.

That 11% of people have abandoned it suggests to me that it has been misapplied. Way back when started reading what is now Methods and Tools it was called JOOP (Journal of Object-Oriented Programming) my focus was very much of OO analysis and development methods - but ever since those days I have seen SW developers (or ex developers) promote the use of UML where it is poor suited. They have their hammer (UML) and every problem is treated a nail. This has not helped UML.

The Agile method may be suitable for some projects but I don't see it as well suited to large complex initiatives, involving many parties and systems that need to be supported and extended over many years. This is because it fails to record or communicate complexity to the various stakeholders who need to participate over time i.e. who are not party to the face to face conversations, and don't read the code.

Sunday, April 18, 2010

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.

Friday, April 9, 2010

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).