Does Rigour Matter?

Link: http://feedproxy.google.com/~r/Soapbox/~3/WbprZWA5-BA/does-rigour-matter.html

#entarch
#bizarch
#UnicomEA
One of the topics discussed at yesterday’s EA Forum was the question of architectural rigour. This was stimulated by a rich picture of the oil industry, presented by Mesbah Khan, which I intend to cover in a separate post.

At some points in the discussion, I thought I heard the following familiar set of ideas.

0. Architects can produce models at varying levels of detail and rigour, for different purposes.

1. Rich pictures (e.g. Soft Systems Methodology) are less rigorous than Structured Models (e.g. data models, process models).

2. Executive sponsors are unwilling or unable to engage with rigorous models, and prefer vague impressionistic models.

3. Maximum rigour is required if and only if the models are to be used for designing computer systems.

However, there were some voices (including my own) against some of the ideas. In this post, I want to expand a little on these points.

1. There are different styles of “rich picture”. Mesbah’s model of the oil industry was based on a clearly articulated set of underlying concepts, presented some critical organizational issues in a structured way, and was therefore rigorous enough in its own terms. Some of these issues would undoubtedy be lost in the “translation” from rich picture to conventional EA models. (Of course, some people might conclude that his model wasn’t a genuine “rich picture”.)

Meanwhile, the apparent rigour of conventional EA models is often pretty superficial, based on the fact that a lot of the concrete meaning has been emptied out, leaving a set of ambiguously labelled lines and boxes. (Yes, you could implement a computer system based on these models, but it might be a pretty bad system, with poor usability, poor interoperability and unexplained side-effects. What is the value of such rigour?)

2. The idea that executives can’t cope with rigour is insulting. A good executive is highly intelligent, capable of abstract thinking as well as attention to detail, and familiar with a broad range of analytical techniques. However, executives also understand that different levels of detail and rigour are appropriate for different situations, and will be impatient with a model that requires more attention than the current situation allows.

Of course, there are some executives who really are as stupid as they pretend to be, but please don’t base your communications with executives on the patronizing assumption that none of them are as clever as architects.

Thus for some purposes, a quick sketch using PowerPoint or Visio may be sufficient to address stakeholder concerns, but for other purposes they must be motivated to go through the detail. Rigorously. There are times when Management-By-Powerpoint isn’t good enough.

3. The idea that rigour only matters for computer systems is also wrong. A lack of rigour when dividing risks and responsibilities between your organization and your business partners can cost your company more money than your entire IT budget for the next ten years. And a lack of rigour when defining performance bonuses for your middle management can result in perverse incentives – paying people vast sums of money to do unproductive things with expensive side-effects.

In comparison, a lack of rigour in architecting computer systems will probably be sorted out by the developers, or fixed in systems testing, so it might cause a little embarassment and delay. Regrettable and sometimes expensive, but usually not disastrous. Only from an IT-centric perspective would this be regarded as the most significant risk.