RE: [ba-unrev-talk] Ontologies and Software Architecture
Hear Hear. (01)
Dennis - I resonate greatly with your post below. So much so, it has
tempted me to post a "why I'm working with Doug" message. (02)
One of the things I am learning as I continue working with Doug is that
he seems to an infallible instinct for not falling into the traps of
trying to build world-defining artifacts. I observe him trying to guide
us to build artifacts that help us further our definition of the world,
and hence our ability and understanding of how to live in it, and with
our fellow human beings, with greater grace than we do today. (03)
Since I met him in June 1999, I have resonated deeply with Doug's
thinking because to me, he has always seemed to put artifacts (&
technologies) in second place to humans. He has helped me realize we
should design Artifacts that support Humans to do a better job of
sorting out ideas, values and purpose. Then we have the further hard
work of extending those artifacts to allowing humans an improved
capability to steer by the common values and purposes that emerge as
dominant. (04)
Mei Lin (05)
-----Original Message-----
From: owner-ba-unrev-talk@bootstrap.org
[mailto:owner-ba-unrev-talk@bootstrap.org] On Behalf Of Dennis E.
Hamilton
Sent: Thursday, August 08, 2002 7:12 AM
To: ba-unrev-talk@bootstrap.org
Cc: William Anderson
Subject: RE: [ba-unrev-talk] Ontologies and Software Architecture (06)
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 (07)
- all systems are embedded systems (as my associate Bill
Anderson reminds
me regularly) (08)
- all ontologies are situated (thanks to Bill's and others
work in how
people use systems) (09)
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. (010)
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. (011)
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. (012)
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. (013)
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. (014)
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. (015)
-- Dennis (016)
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/ (017)
-----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 (018)
[ ... ] (019)
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. (020)
[ ... ] (021)