Information Technology Reference
In-Depth Information
An example of a Toulmin argumentation model might be as follows: Object
oriented modelling is a more natural way for most business analysts to capture
requirements. Such a statement is a claim that includes a qualifier - most. The
grounds for this statement might refer to hard facts or evidence that supports
this claim. The warrant might indicate how object concepts provide a closer
correspondence to objects in the real world. The backing for the claim might be:
because object modeling is derived from entity modeling and entity relationship
modeling has considerable history of ecacy in requirements capture. A rebuttal
is a counter claim and has its own argumentation model.
Taken together, the two theories present a potential opportunity to review
how we design methods and their supporting tools. The argumentation model
presents a conversational framework which allows the theory builder to create
an orderly and intelligible conversation - a discussion of the theory. But because
such discourse analysis has the potential to generate large amounts of data by
utilizing a limited set of concepts derived from the domain (the topics in the
entailment mesh from conversation theory) it is possible to make the resulting
analysis more amenable.
6
Implications for Enterprise Architecture
Enterprise Architecture (unlike programming) has no target theory. The exe-
cution of a program can be used to validate the quality of the theory that a
programmer constructed but mechanisms for executing enterprise architectures
are still largely an area of research focus. Prevailing methods and languages for
EA (and using ArchiMate as a canonical example) have focused on developing
artifacts and models for explicit knowledge [6, p.75] and so are subject to Naur's
criticisms. EA frameworks such as TOGAF provides an exhaustive set of activ-
ities, phases of activities, ordering of activities and artifacts to be produced by
activities with the intent of capturing in its entirety a theory of the EA. Accept-
ing the theory building view forces us to reject firstly that such an exhaustive
methodological approach can lead us to a universal theory of Enterprise Archi-
tecture for a domain. Secondly the focus on explicit knowledge does not allow
us to extract from the plethora of method the essence of “why”. Instead, a model
of incremental, modular theory building which involves the real world thorugh a
conversational process as a source of knowledge and validation may unlock the
real value of an enterprise architecture.
This takes us then to a more fundamental re-thinking of method development.
A method for EA should not (algorithmically) take us to a model of EA (because
no one model exists), instead a method should instill in the practitioner, the
cognitive processes for constructing theories about the enterprise architecture.
The conversational approach outlined earlier is one such candidate basis for such
cognitive processes as it enables both the testing of a theory and the collaborative
development of a theory. Indeed it might allow us to measure the ecacy of a
method not by how a solution is designed or quality of solution but by how the
