#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.
See also Convergence: Symbolic, Imaginary or Real?
A good post, and I agree with much of what you say. I'd add a couple of things around the "rigour" issue. Firstly, I think it is incorrect when people say that executives don't like rigour. Instead, I'd claim that most of them do not understand the notation that comes with rigorous IT models - and why should they unless they come from that background which most don't. Secondly, I believe that what people need to do when creating rigorous models is to understand what the model is for, and it probably is not to communicate. My view is that if you are building a rigorous model of any sort, you need to create clear non-technical ways of illustrating what the model has identified. Usually this won't be in the modelling notation, because that will only work with an audience who understands the notation as well as you do.
ReplyDeleteThanks Doug. Of course executives like rigour. And they often understand IT models well enough to be bemused by the claims of rigour for these models. See Ivo's comment to my post on Multiview. The executives and users are often highly numerate number-crunchers, and they don't always fully appreciate exactly how a vague and poorly documented line-and-box diagram (which IT people appear to regard as rigorous) addresses a set of very precise and business-critical requirements and concerns.
ReplyDeleteWhen data modelling was more popular than it is today, people used to tell me that normalization was rigorous. They knew that Ed Codd had actually proved something mathematically, although they mostly didn't know exactly what he had proved. But mathematics - you can't get more rigorous than that, can you? I used to point out that accountancy is also based on mathematics, but that the existence of a small mathematical core is not enough to turn either accountancy or database design into rigorous disciplines.
I once coached an IT team that were building systems for a marketing department. The marketing people were calculating the cost and effectiveness of campaigns to a pretty impressive level of accuracy, using bits of Excel that the IT team weren't aware of and wouldn't have understood. Meanwhile the IT team were producing vague and unreliable guestimates for project work. Nevertheless, the IT team fondly imagined they were more "literate" than their users, and treated them rather patronizingly.