[Sigia-l] IA system components - add to the list!
Arno Reichenauer
arno.reichenauer at web.de
Mon Mar 17 11:33:41 EST 2003
"Boniface Lau" wrote:
> By agreeing with what you quoted from Eric, aren't you conflicting
> yourself?
Nope.
These are two separate, if also connected things. And I can agree on both of
them. My (!) view on it:
1. there is an IA process that results in "things", which are basically the
deliverables of Information Architects' work. These deliverables somehow
should be useful for building and mainting a website/intranet (that's what I
meant with "contribute to a website/intranet"). These "things" are what I
call an IA system. Again: I have no fixed picture of what should be in
there. Can be components of the web site and more (e.g. maintenance process
descriptions, see below) Actually, in my first post, I asked the members of
the list for opinions on exactly that question.
2. there is a process for developing a framework for IA processes, a
meta-process, if you want. This meta-process then outputs an IA process
framework, from which concrete IA process instances can be drawn, according
to specific project needs. This meta-process is what Eric, in my
understanding, talked about. In this meta-process, it seems reasonable to me
to start out with the different IA systems that are to be delivered by all
you experts in the field (therefore my literature review and the initial
post). Once you know what IA processes are supposed to deliver, you can
start developing different IA process elements which can adress these
deliverables; these IA process elements are then the cornerstones of your IA
process framework.
Sorry if was too unspecific, but that's because I mixed "my" language with
what I perceived to be the language used here on the list in order to be
able to communicate to you. One more example how important a common language
would be..
> I was not there with your IT colleagues. You better ask them.
..
> A system architecture is about the components within a system and
> how they should be connected.
Hm, not very helpful. Sorry, I still don't know what you mean. What
components are you referring to?
> Mind you, a collection of disconnected components is NOT a system. But
> when the web site components are connected, they form what we call a
> web site. Are you saying that a web site is an IA System?
No. Some components of a web site are delivered by IAs, some are delivered
by other professions. The components that are delivered by IAs are one part
of an IA system, as I explained above. Another one might be all the
non-artifacts like maintenance process descriptions etc. And there might be
even more. But they all somehow contribute to the development/maintenance of
a website/intranet. Once more, I have no fixed picture about that yet. I'm
curious to listen to your view on that.
> The definition of IA is "secondary or subordinate" to an IA
> methodology? I found that hard to believe. Thus, I thought you meant
> "collective".
Mind you (I like that ;-): I talked about the definitions of IA as a SYSTEM
and as a PROCESS, not just *the* definition of IA. That's quite a different
thing. And these definitions could result from what I described. Maybe you
want to define IA to describe a discipline, community of practice or
whatever other aspect of the field. But that's not what I am talking about.
> > It should point out that after we'd agree on what parts of a web
> > site we CAN deliver, we could deduce what an IA process CAN cover
> > and what the "maximum" process covers (i.e., the process that covers
> > all the possible deliverables). And then the definition of IA as a
> > process would be obvious. And the definition of IA as a system
> > also.
>
> ISTM what you've described is a group of people not knowing what they
> are supposed to develop. But they know the name of what is being asked
> for. It is called IA. So they charge ahead without agreeing on what IA
> means. In the end, they will simply call the whatever result IA.
?? Sorry, I don't understand you point here. I talked about the member of
the IA community, where obviously different views are held. I guess most IAs
have a quite clear, personal view on what the deliverables of "their" IA
processes are. But, obviously, these views vary. A starting point for an IA
process framework therefore would be to collect the different views on what
the deliverables can be, so you logically could derive what the process
framework should be able to cover.
By the way, I appreciated very much Eric's trying to understand what I tried
to explain rather than merely looking for something to critize. ;-)
Arno
More information about the Sigia-l
mailing list