[Sigia-l] IA system components - add to the list!

[Nuno Lopes]

Hi Boniface. Thanks for replying.

To all the questions the answer was No, No, No and finally Boniface
wrote:

>...  An information architecture should be created before web site
>components.

I'm not talking about websites at the moment. So the issue concerning
the need of defining an information architecture before, after or during
the creation of a website is irrelevant within the scope of my comments
as I've not mentioned once that Web Sites were concerned (others have).
Although I agree with you it is at least desirable to have an
information architecture in place before building a web site.

So by "No to all" I take that an Information Architect does not make use
of these things to implement or describe an information architecture. It
does not make use of classification, taxonomies, thesauri, labeling
techniques etc, nothing of such sort.

So what does an Information Architect uses to architect information
encompassing an information model guiding the implementation?

NOTE: The rest of this post is just an esoteric discussion around
practical misconceptions as the questions sustaining the ones I've based
mine are not at all tackled by Boniface. Nevertheless it may be
interesting in terms of exchanging ideas.

To the following:
>> 5) Instead of calling "components" to these "things" why not call
>> them "artifacts" if for some people the word used does not make any
>> sense?

Boniface wrote:
>A person can create many things - all of which are artifacts. But not
>all of them are components of something.

IMOH not everything that one creates are artifacts, but this is
irrelevant for this discussion. I agree that not all artifacts may be
seen as components. Again, IMOH, irrelevant for this discussion as I've
not stated that all artifacts in the world are components. 

Although I've stated that a classification system, indexing engine, a
taxonomy for a given subject, a thesauri system (whether paper based or
electronic) etc etc are artifacts then can be well seen as components.

A component in IT is not necessarily a "thing" of something else (as
part of), but the word it self is used to enforce characteristics of
reusability that not all subjects have. To help one visualize what I'm
saying, take a visual diagram editor (as probably you use them), one
drags and drops components from a stencil to the diagram as you draw it.
This does not mean that the components you use are part of the diagram,
but means that its usefulness can be materialized in many diagrams (thus
then becoming part of the diagram). If the diagram is the blue print of
your information architecture then these components function as modular
functional abstractions that one can use or not.

But all this issue is irrelevant as you considered that an Information
Architect does not make use of classification, taxonomies, thesauri,
labeling techniques nothing of such sort to describe an information
architecture guiding its implementation.

Boniface wrote:
>I do not see anything wrong with the word "component" as long as it is
>used properly.

Agreed.

To the following:

> As far as I see it on earth, the creation of architectures make use
> of "things" encompassing artifacts in order to work with materials
> (Information?).
> 
> In software industry the word component is used as a superset of
> these "things".  

Boniface wrote:

>The word "component" indicates that something is a part of something
>else.

Not necessarily as I've tried to explain. You use components to assemble
all sorts of things including the description of an architecture, but
before the assembly process they can be seen as part of nothing else
besides a framework of reasoning. This, although IT and many other
fields IT already call some of these things as components before
assembly takes process in order to enforce its reusability
characteristics.

To the following:

> Also in Software Architecture, a system's architecture is not
> defined by its parts (components) but by the sum of its parts
> (components) plus the semantics behind the sum (the glue).
> 
> As far as I've read the posts, no one argued that Information
> Architecture is defined by its parts rather then the sum of its
> parts.  The question was:
> 
> What are those components/artifacts/parts?

Boniface wrote:

>They are structures.

This is an interesting answer that I can't refute, neither have I wanted
to. Why? Not because it is relevant, but because all things can be seen
as structures. What I'm stating is that maybe the objects in question
can be seen as more then that, as for instance they can be seen as
reusable structures encompassing functionality useful to describe and
implement an information architecture, thus components (components have
structure and functionality too). But the answer is No according to
Boniface.

If structures is what you feel comfortable with, so be it (lets move
on). Out of curiosity, what name (single word only) would you give to
things that are according to you simply structures, but in this case
structures built to be reusable (patterns of thought, heuristics, and of
course peaces of information)?

Anyway, this leads me to the following question:

Does an information architect makes use of structures (using your
understating of structures) to describe and implement an information
architecture?

If so, what kind of structures an information architect uses to describe
and create an information architecture?

To the following

> 
> At the moment my perception is that arguing against the need of
> components/artifacts (and the correct perception of their benefits)
> is arguing against the ability to create an architecture concerning
> whatever, including information.

Boniface wrote:

>The issue was not about the need of components/artifacts. 

>The issue was about mistaking web site components for information
>architecture components.

The main issue as far as I understood was about stating the components
that are used by an information architect. The all issue around web site
development was somewhat collateral. Just became relevant due to the
fact that some people were more interested in stating differentiation
with dogmatic answers without further explanation (as all dogmas are).

I understand that some or most artifacts that an Information Architect
uses may not the same as of a Software Architect, Business Architect,
Web Site Architect, etc etc. As I've said in a post of mine the all idea
of an "IA System" does not make sense for me at the moment.

The title was and is: "IA system components". Take the word system out
and you have:

"IA components"

Rephrase the title better and you have:

"Information Architecture - Systems & Components".

>Designing web site components is itself a very interesting topic.

Yes it is, but my comments and questions are around the development of
an information architecture, not around web site development.

I understand your commenting strategy, but I'm afraid that by simply
stating what it is not, you are not clarifying the issue any further.
Nevertheless, you thought of them as relevant, otherwise you would not
have posted any comments. If they are relevant to you then they may be
close in practice, if they are close in practice then probably it is
practice. I'm kidding, hope you can appreciate some humor.

So by your full negation, the question is still open. In other words, in
math if something is not it can be anything. So Information Architecture
is nothing and anything? Ha, crazy mathematicians :)

To further clarify, can you state what are the components and artifacts
that you as an information architect use to describe and implement an
information architecture?

This is because everything that I've read about the subject is somewhat
contradictory to what you say (taking the spiel off). Can you share with
me some whitepapers about the subject that you have written (or your
colleagues sharing your vision), references to some good practical books
acknowledged by you, etc etc. This would be an excellent complement in
my library.

Thanks in advance for all the help, hope we can share our little
knowledge.

Best regards,

Nuno Lopes.