Information Technology Reference
In-Depth Information
Naur cites a study of five different methods by Floyd et al (cited here for
completeness [2])where the key result that a system of rules will lead to good
solutions is an illusion, what remains is
the effect of methods on the education
of programmers
. Thus the use of methods may themselves not lead to a good
design but the practice of the method may lead to a better innate ability for
theory building.
5 Theory Building and Testing as a Conversation Process
The act of constructing a conceptual model that describes an enterprise archi-
tecture is essentially all about communication. For example, when we engage
in a discussion of budgetary requirements, we are requiring the architecture de-
scription to provide us with a theory of budgetary models. A description of the
communication of how that theory is explicated is at the heart of that architec-
ture description. In a modelling process, participants such as the domain expert
and the systems analyst (who may have no knowledge of the domain) engage in a
conversational process through which concepts understood by the domain expert
are formalised by the systems analyst through some dialogue document in a con-
trolled language[3]. The goal of the modelling process is to reach a state where
all participants agree that they have some degree of common understanding[14].
When Naur describes theory building amongst teams of programmers who
share the same theory he would appear to be alluding to a similar socialisation
process. More recently and in line with what we propose in this section, Kruchten
[5] provides a critique of software architecture from a knowledge management
perspective where architectural knowledge is a composite of the architecture (de-
sign) and a rationale for design decisions. The support for the rationale comes
through a socialisation process framed by the SECI (socialisation, externalisa-
tion, combination, internalisation), model [12]. Significantly, though, the artifact
remains central albeit augmented by more human centred activity.
In the development of a theory, Naur also suggests three tests to check if the
programmers knowledge transcends the written documentation consistent with
Ryle's notions that a theory should be defensible and justifiable by the presenta-
tion of evidence. These are: the programmer can explain how the solution relates
to the affairs of the worlds that it helps to handle; the programmer can explain
why each part of the program is what it is, in other words, is able to support
the actual program text with a justification of some sort; and the programmer
is able to respond constructively to any demand for a modification.
Here we propose that the first test can be addressed by consideration of an
integration of two other philosophical theories in this field: Toulmin's informal
argumentation model [18] and Pask's conversation theory [13] and to suggest
that theory testing can be achieved by constrained conversations using models
as the subject. More pertinently, it may help us to address the “why” of an
enterprise architecture.
