RE: [ba-unrev-talk] Ontologies and Software Architecture
If you look at software architecture, and especially systems architecture as
a combination of theory building and enactment in the world, it becomes
clear that (01)
- all systems are embedded systems (as my associate Bill Anderson reminds
me regularly) (02)
- all ontologies are situated (thanks to Bill's and others work in how
people use systems) (03)
I think that the conceptualization of a system and its external
architecture -- the in-the-worldness part of the system architecture -- is
in a way an act of ontology-creation as part of the theory-building and
confirmation process. There is a shared conceptualization of the setting
and how the system fits. (04)
Now, having said that, I am uncomfortable with concepts like that of a
"standard ontology." Part of this is that I notice a tendency to deal with
the boundaries of software engineering not by having them be, but by
attempting to turn the world over the boundary into software engineering and
tool-building problems (hence: requirements engineering) and have it be
about the creation of the artifacts and not about situated systems and what
they are to their users and operators in their purposive work. (05)
It seems to me that there is a "requirements gap" between software
engineering and the elicitation and embracing of requirements as they abide
in the user's world. It shows up in an illustrative way on this list when
the discussion of requirements here turns into a proposal for tool building
and agreement on something to develop. (06)
And either way, there is theory building going on. I find one that looks
inward at the artifact to risk a serious sterility and most of all, impose
the engineers view of how the world (should) operate on the delivered
artifact. It is no different than imposing the manager's illusion of how
the world (should/does) operate. (07)
So, I guess we are stuck with theory building. Perhaps then the question
is, what is the context and the vision within which the theory is intended
to be consistent? If you start out with the ontology as given, there's not
much room for discovering that. Perhaps one could go meta-ontological.
It's unclear to me what improvement is available there, though addressing
meta-ontology might reveal something about the "posture" of a system. (08)
Coming back to software architecture as it is practiced in the
small--specifying the internal architecture of system components and the
separation/organization of processing functions--I am not sure that there is
much value to an "ontology" there, although there is certainly a conceptual
framework in which this is done. But it is around the development and
delivery process of the artifact, and that seems pretty "reduced" to me,
ripped out of the setting of the artifact and how it arises as an element in
a purposive system. I notice, on other lists, that software architects are
seen as enforcers of a framework within which programming is then done. All
right, but what about why we are building the thing and the purposes it
serves? And how do we trace that down to and confirm in the delivered
results. That's what I mean about the risk of turning things into software
engineering and development problems. It's like going blind on purpose. (09)
-- Dennis (010)
Dennis E. Hamilton
AIIM DMware Technical Coordinator
------------------
mailto:dennis.hamilton@acm.org tel. +1-206-932-6970
http://DMware.info/ cel. +1-206-779-9430
ODMA Support http://ODMA.info/
The Miser Project http://miser-theory.info/ (011)
-----Original Message-----
From: owner-ba-unrev-talk@bootstrap.org
[mailto:owner-ba-unrev-talk@bootstrap.org]On Behalf Of Henry K van Eyken
Sent: Thursday, August 08, 2002 04:26
To: ba-unrev-talk@bootstrap.org
Cc: Tom Munnecke
Subject: Re: [ba-unrev-talk] Ontologies and volunteers (012)
[ ... ] (013)
Another item I still have difficulty with is how "ontology" fits into
software architecture (so now you know how really ignorant I am). Of
course, there is plenty to read to put me straight here, but, as we all
are aware and Gary may say: ars longa, vita brevis. (014)
[ ... ] (015)